<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>Er lover brutt når personvernpolicy ikke stemmer med praksis?</title>
+ <link>http://people.skolelinux.org/pere/blog/Er_lover_brutt_n_r_personvernpolicy_ikke_stemmer_med_praksis_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Er_lover_brutt_n_r_personvernpolicy_ikke_stemmer_med_praksis_.html</guid>
+ <pubDate>Fri, 9 Dec 2016 14:20:00 +0100</pubDate>
+ <description><p>Når jeg bruker <a href="https://www.ghostery.com/">Ghostery</a>,
+<a href="https://www.ublock.org/">uBlock</a>,
+<a href="https://github.com/gorhill/uMatrix">uMatrix</a>,
+<a href="https://github.com/andryou/scriptsafe">ScriptSafe</a> og andre
+nettleserverktøy (de passer på hverandre) for å holde styr på hvordan
+nettsteder sprer informasjon om hvilke nettsider jeg leser blir det
+veldig synlig hvilke nettsteder som er satt opp til å utveksle
+informasjon med utlandet og tredjeparter. For en stund siden la jeg
+merke til at det virker å være avvik mellom personvernpolicy og
+praksis endel steder, og tok tak i et par konkrete eksempler og sendte
+spørsmål til Datatilsynets kontaktpunkt for veiledning:</p>
+
+<blockquote>
+
+<p>«Jeg har et spørsmål når det gjelder bruken av Google Analytics og
+personvernpolicy. Er det lovlig for et nettsted å si en ting i
+personvernpolicy og gjøre noe annet i virkeligheten? Spesifikt lurer
+jeg på hvilket lov som er brutt hvis nettstedet i HTML-koden til
+nettsidene ber lesernes nettleser om å kontakte Google Analytics og
+slik overleverer sitt IP-nummer til Google, samtidig som
+personvernpolicien hevder at Google Analytics kun får anonymiserte
+data. Google får jo i slike tilfeller alltid overført fullt
+IP-nummer, og nettstedet kan i URL-en som brukes be Google om å ikke
+lagre deler av IP-adressen (omtalt som anonymisering av Google
+Analytics)</p>
+
+<p>Et eksempel er Nettavisen digi.no.
+<a href="http://www.digi.no/artikler/personvernpolicy/208772">Deres
+personvernpolicy</a> sier følgende:</p>
+
+<blockquote>
+ «Tredjeparter (som Google Analytics, Cxense, TNS Gallup) får kun
+ anonymiserte data.»
+</blockquote>
+
+<p>Men når en leser artikler der så blir maskiner i Norge, USA,
+Tyskland, Danmark, Storbritannia, Irland og Nederland varslet om
+besøket og får dermed overlevert full IP-adresse, som datatilsynet har
+uttalt er en personopplysning. Nettsidene er satt opp til be
+nettleseren å kontakte 29 ulike maskiner rundt om i verden. Fire av
+dem er er under DNS-domenene digi.no og tek.no som tilhører samme
+eier. I tillegg ber nettsidene ikke
+<a href="https://support.google.com/analytics/answer/2763052?hl=no">Google
+Analytics om å fjerne siste oktett i IP-adressen ved lagring</a>,
+dvs. flagget «aip=1» er ikke satt i URL-en som brukes for å kontakte
+Google Analytics.</p>
+
+<p>Tilsvarende er også tilfelle for andre nettsteder, så digi.no er
+ikke spesiell i så måte (dagbladet.no er et annet eksempel, det
+gjelder flere).»</p>
+
+</blockquote>
+
+<p>Etter noen dager kunne juridisk rådgiver Elisabeth Krauss Amundsen
+hos Datatilsynet fortelle det følgende:</p>
+
+<blockquote>
+«Hei, og takk for din e-post.</p>
+
+<p>Vår svartjeneste gir deg kortfattet rådgivning. Vi vil derfor ikke konkludere
+i saken din, men gi deg råd og veiledning.</p>
+
+<p>Ut ifra det du skriver er det antakelig flere bestemmelser i
+personopplysingsloven som brytes dersom virksomhetens personvernpolicy
+sier noe annet om behandlingen av personopplysninger enn det som
+faktisk skjer. Antakelig vil det være et brudd på informasjonsplikten
+i personopplysingsloven §§ 18 og
+19&lt;<a href="https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§18">https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§18</a>&gt;
+dersom det gis feilinformasjon om at opplysningene utleveres. Det kan
+også stilles spørsmål om grunnkravene for behandling av
+personopplysninger vil være oppfylt ved en utlevering av
+personopplysninger til en tredjepart, dersom dette ikke er inkludert
+behandlingsgrunnlaget og formålet med behandlingen, se
+personopplysingsloven § 11, jf.
+8.&lt;<a href="https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§11">https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§11</a>&gt;»
+</blockquote>
+
+<!-- Her er full URL som digi ba nettleserne bruke for å melde fra til
+Google Analytics:
+https://www.google-analytics.com/r/collect?v=1&_v=j47&a=666919305&t=pageview&_s=1&dl=http%3A%2F%2Fwww.digi.no%2F&ul=nb-no&de=UTF-8&dt=Digi.no%20-%20IT-bransjens%20nettavis&sd=32-bit&sr=1024x768&vp=400x300&je=0&_u=AEAAAMQAK~&jid=592247632&cid=1641512195.1480086725&tid=UA-54426-28&_r=1&z=328520576
+-->
+
+<p>Oppdatert med kunnskap om lover og regler tok jeg så kontakt med
+Dagbladet på epostadressen de annonserer på sine
+personvernpolicysider:<p>
+
+<blockquote>
+
+<p>«Jeg lurte litt i forbindelse med en bloggpost jeg skriver på, og lurer
+på om dere hjelpe meg med å finne ut av følgende. Først litt
+bakgrunnsinformasjon.
+<a href="http://www.dagbladet.no/2009/08/18/nyheter/avtale/brukeravtale/plikter/7706966/">Dagbladets
+personvernpolicy</a> forteller følgende:</p>
+
+<blockquote>
+ <p>«3. Automatisk innhentet informasjon</p>
+
+ <p>For eksempel IP-adressen din (ikke synlig for andre) samt
+ statistisk, automatisk produsert informasjon, som når du sist var
+ innlogget på tjenesten. Dette er informasjon vi samler for å gjøre
+ tjenesten best mulig.»</p>
+
+</blockquote>
+
+
+<p>Men når en besøker nettsidene til Dagbladet,
+f.eks. <a href="http://dagbladet.no/">forsiden</a>, så er nettsidene
+satt opp til å kontakte mange tredjeparter som slik får tilgang til
+både fullt IP-nummer og i de fleste tilfeller nøyaktig hvilken
+artikkel en leser hos Dagbladet ved at Referer-feltet fylles og legges
+ved. Dette gjelder Google Analytics, Cxense, INS Gallup, Doubleclick
+med flere. Totalt ber forsiden nettleseren om å koble seg opp til 60
+nettsteder med 149 separate oppkoblinger. I hver av disse
+oppkoblingene oversendes IP-adressen til leseren, og i følge
+Datatilsynet er
+«<a href="https://www.datatilsynet.no/Teknologi/Internett/Webanalyse/">en
+IP-adresse definert som en personopplysning fordi den kan spores
+tilbake til en bestemt maskinvare og dermed til en enkeltperson</a>».</p>
+
+<p>Datatilsynet har fortalt meg at i følge personopplysingsloven §§ 18
+og 19 skal informasjonen som gis om bruk og utlevering av
+personopplysninger være korrekt. De forteller videre at det er endel
+grunnkrav som må være oppfylt ved utlevering av personopplysninger til
+tredjeparter, nærmere forklart i personopplysingsloven § 11 som
+henviser til § 8.</p>
+
+<p>Mitt spørsmål er dermed som følger:</p>
+
+ <blockquote>
+
+ <p>Hva mener dere i personpolicyen når dere skriver at IP-adressen ikke
+ er synlig for andre?»</p>
+
+ </blockquote>
+
+</blockquote>
+
+<p>Etter en uke har jeg fortsatt ikke fått svar fra Dagbladet på mitt
+spørsmål, så neste steg er antagelig å høre om Datatilsynet er
+interessert i å se på saken.</p>
+
+<p>Men Dagbladet er ikke det eneste nettstedet som forteller at de
+ikke deler personopplysninger med andre mens observerbar praksis
+dokumenterer noe annet. Jeg sendte derfor også et spørsmål til
+kontaktadressen til nettavisen Digi.no, og der var responsen mye
+bedre:</p>
+
+<blockquote>
+
+<p>«Jeg lurte på en ting i forbindelse med en bloggpost jeg skriver på,
+og lurer på om dere hjelpe meg. Først litt bakgrunnsinformasjon.
+<a href="http://www.digi.no/artikler/personvernpolicy/208772">Digi.nos
+personvernpolicy</a> forteller følgende:</p>
+
+<blockquote>
+ «All personlig informasjon blir lagret i våre systemer, disse er ikke
+ tilgjengelig for tredjeparter, og blir ikke lagret i
+ informasjonskapsler. Tredjeparter (som Google Analytics, Cxense,
+ TNS Gallup) får kun anonymiserte data.»
+</blockquote>
+
+<p>Men når en besøker nettsidene til nettavisen, f.eks.
+<a href="http://www.digi.no/">forsiden</a>, så er nettsidene satt opp
+til å kontakte mange tredjeparter som slik får tilgang til både fullt
+IP-nummer og i de fleste tilfeller nøyaktig hvilken artikkel en leser
+hos Digi.no ved at Referer-feltet fylles og legges ved. Dette gjelder
+både Google Analytics, Cxense blant og INS Gallum. Totalt ber
+forsiden nettleseren om å koble seg opp til 29 nettsteder med 44
+separate oppkoblinger. I hver av disse oppkoblingene sendes
+IP-adressen til leseren over, og i følge Datatilsynet er
+«<a href="https://www.datatilsynet.no/Teknologi/Internett/Webanalyse/">en
+IP-adresse definert som en personopplysning fordi den kan spores
+tilbake til en bestemt maskinvare og dermed til en enkeltperson</a>».
+Det jeg ser virker ikke å være i tråd med personvernpolicyen.</p>
+
+<p>Når en besøker Digi.nos nettsider gjøres det to oppkoblinger til
+Google Analytics, en for å hente ned programkoden som samler
+informasjon fra nettleseren og sender over til Google (analytics.js),
+og en for å overføre det som ble samlet inn. I den siste oppkoblingen
+er det mulig å be Google om å ikke ta vare på hele IP-adressen, men i
+stedet fjerne siste oktett i IP-adressen. Dette omtales ofte litt
+misvisende for «anonymisert» bruk av Google Analytics, i og med at
+fullt IP-nummer blir sendt til Google og det er opp til Google om de
+vil bry seg om ønsket fra de som har laget nettsiden. Ut fra det som
+står i personvernpolicyen ville jeg tro at Digi.no ba google om å ikke
+ta vare på hele IP-nummeret, men når en ser på den andre oppkoblingen
+kan en se at flagget «aio=1» ikke er satt, og at Digi.no ikke ber
+Google om å la være å lagre hele IP-adressen. Dette virker heller
+ikke å være i tråd med personvernpolicyen.</p>
+
+<p>Datatilsynet har fortalt meg at i følge personopplysingsloven §§ 18
+og 19 skal informasjonen som gis om bruk og utlevering av
+personopplysninger være korrekt. De forteller videre at det er endel
+grunnkrav som må være oppfylt ved utlevering av personopplysninger til
+tredjeparter, nærmere forklart i personopplysingsloven § 11 som
+henviser til § 8. Det er uklart for meg om disse kravene er oppfylt
+når IP-adresse og informasjon om hvilke websider som besøkes til
+tredjeparter.</p>
+
+<p>Mitt spørsmål er dermed som følger:</p>
+
+<blockquote>
+
+ <p>Hva mener dere i personpolicyen når dere skriver at «Tredjeparter
+ får kun anonymiserte data»?»</p>
+
+</blockquote>
+
+</blockquote>
+
+<p>Redaksjonssjef Kurt Lekanger svarte samme dag og forklarte at han
+måtte komme tilbake til meg når han hadde med utviklingsavdelingen.
+Seks dager senere lurte jeg på hva han fant ut, og etter noen timer
+fikk jeg så følgende svar fra direktøren for teknologi og
+forretningsutvikling Øystein W. Høie i Teknisk Ukeblad Media:</p>
+
+<blockquote>
+
+<p>«Takk for godt tips! Det er helt riktig at IP og referrer-adresse
+potensielt kan leses ut av tredjepart.</p>
+
+<p>Retningslinjene våre har vært uklare på dette tidspunktet, og vi
+oppdaterer nå disse så dette kommer tydeligere frem. Ny tekst blir som
+følger:</p>
+
+<hr>
+<p>3. Dette bruker vi ikke informasjonen til Informasjon du oppgir til
+oss blir lagret i våre systemer, er ikke tilgjengelig for
+tredjeparter, og blir ikke lagret i informasjonskapsler.
+Informasjonen vil kun benyttes til å gi deg som bruker mer relevant
+informasjon og bedre tjenester.</p>
+
+<p>Tredjeparter (som Google Analytics, Cxense, TNS Gallup) vil kunne
+hente ut IP-adresse og data basert på dine surfemønstre. TU Media AS
+er pliktig å påse at disse tredjepartene behandler data i tråd med
+norsk regelverk.</p>
+<hr>
+
+<p>Ellers har vi nå aktivert anonymisering i Google Analytics
+(aip=1). Kan også nevne at Tek.no-brukere som har kjøpt Tek Ekstra har
+mulighet til å skru av all tracking i kontrollpanelet sitt. Dette er
+noe vi vurderer å rulle ut på alle sidene i vårt nettverk.»</p>
+
+</blockquote>
+
+<p>Det var nyttig å vite at vi er enige om at formuleringen i
+personvernpolicyen er misvisende. Derimot var det nedslående at i
+stedet for å endre praksis for å følge det personvernpolicyen sier om
+å ikke dele personinformasjon med tredjeparter, så velger Digi.no å
+fortsette praksis og i stedet endre personvernpolicyen slik at den å
+dokumentere dagens praksis med spredning av personopplysninger.</p>
+
+<p>Med bakgrunn i at Digi.no ikke har fulgt sin egen personvernpolicy
+spurte jeg hvordan Digi.no kom til å håndtere endringen:</p>
+
+<blockquote>
+
+<p>«Tusen takk for beskjed om endring av personvernpolicy for digi.no.
+Gjelder endringen også andre nettsteder?</p>
+
+<p>Vil tidligere håndteringen av IP-adresser og lesemønster i strid
+med dokumentert personvernpolicy bli varslet til Datatilsynet i tråd
+med
+<a href="https://lovdata.no/forskrift/2000-12-15-1265/§2-6">personopplysningsforskriften
+§ 2-6</a>? Vil leserne bli varslet på en prominent og synlig måte om
+at lesernes IP-adresser og lesemønster har vært utlevert til
+tredjeparter i stid med tidligere formulering om at tredjeparter kun
+får anonymiserte data, og at utleveringen fortsetter etter at
+personvernpolicy er endret for å dokumentere praksis?</p>
+
+<p>Appropos ekstra tilbud til betalende lesere, tilbyr dere en
+mulighet for å betale for å lese som ikke innebærer at en må gjøre det
+mulig å la sine lesevaner blir registeret av tek.no? Betaler gjerne
+for å lese nyheter, men ikke med en bit av privatlivet mitt. :)»</p>
+</blockquote>
+
+<p>Jeg fikk raskt svar tilbake fra direktøren Høie:</p>
+
+<blockquote>
+<p>«Tydeliggjøringen i personvernpolicy gjelder alle våre nettsteder.</p>
+
+<p>Vi kommer til å ta en runde og gå over vår policy i forbindelse med
+dette, og vil i de tilfeller det er påkrevd selvsagt være tydelig
+overfor brukere og tilsyn. Vil samtidig understreke at vår bruk av
+tredjeparts analyseverktøy og annonsetracking er helt på linje med det
+som er normalt for norske kommersielle nettsteder.</p>
+
+<p>Angående spørsmålet ditt:
+<br>Du vil fortsatt vise i våre interne systemer om du blir Ekstra-bruker,
+vi skrur bare av tredjeparts tracking.»</p>
+</blockquote>
+
+<p>Det høres jo ikke bra ut at det er normalt for norske kommersielle
+nettsteder å utlevere lesernes personopplysninger til utlandet. Men
+som en kan lese fra <a href="https://www.nrk.no/norge/kommunen-deler-informasjon-om-deg-med-facebook-og-google-1.13248945">gårdagens oppslag fra NRK</a> gjelder
+det også norske kommuner og andre offentlige aktører, og
+<a href="http://people.skolelinux.org/pere/blog/Snurpenot_overv_kning_av_sensitiv_personinformasjon.html">jeg
+skrev om omfanget av problemet i fjor</a>. Det er uansett ikke en
+praksis jeg tror er i tråd med kravene i personopplysningsloven, og
+heller ikke en praksis jeg som leser synes er greit. Jeg manglet dog
+fortsatt svar på om Digi.no kom til å varsle lesere og Datatilsynet om
+avviket mellom praksis og policy, så jeg forsøkte meg med en ny epost
+i går kveld:</p>
+
+<blockquote>
+
+<p>«Kan du fortelle meg om dere anser det å være påkrevd å varsle
+tilsyn og brukere nå, når dere har oppdaget at praksis ikke har vært i
+tråd med personvernpolicy?»</p>
+
+</blockquote>
+
+<p>Det spørsmålet vet jeg så langt ikke svaret på, men antagelig kan
+Datatilsynet svare på om det er påkrevd å varsle tilsyn og lesere om
+dette. Jeg planlegger å oppdatere denne bloggposten med svaret når
+det kommer.</p>
+
+<p>Jeg synes jo det er spesielt ille når barn får sine
+personopplysninger spredt til utlandet, noe jeg
+<a href="https://www.mimesbronn.no/request/opplysninger_samlet_inn_av_mobil">tok
+opp med NRK i fjor</a>. De to eksemplene jeg nevner er som dere
+forstår ikke unike, men jeg har ikke full oversikt over hvor mange
+nettsteder dette gjelder. Jeg har ikke kapasitet til eller glede av å
+lese alle personvernpolicyer i landet. Kanskje mine lesere kan sende
+meg tips på epost om andre nettsteder med avvik mellom policy og
+praksis? Hvis vi alle går sammen og kontakter de ansvarlige, kanskje
+noen til slutt endrer praksis og slutter å dele lesernes
+personopplysninger med tredjeparter?</p>
+
+<p>Apropos bruken av Google Analytics kan jeg forresten nevne at
+Universitetet i Oslo også har tatt i bruk Google Analytics, men der
+lagres programkoden som overføres til nettleserne lokalt og deler av
+IP-adressen fjernes lokalt på universitetet via en mellomtjener/proxy
+(<a href="https://github.com/unioslo/ipproxy">tilgjengelig via
+github</a>) før informasjon sendes over til Google Analytics. Dermed
+er det mulig for ansvarlige for nettstedet å <em>vite</em> at Google
+ikke har tilgang til komplett IP-adresse. Årsaken til at denne
+metoden brukes er at juristene ved universitetet har konkludert med at
+det er eneste måten en kunne vurdere å bruke Google Analytics uten å
+bryte loven. Risikoen for gjenidentifisering og
+<a href="https://panopticlick.eff.org/">identifisering ved hjelp av
+nettleserinformasjon</a> er fortsatt tilstede, så det er ingen optimal
+løsning, men det er bedre enn å håpe at f.eks. Google og alle som
+lytter på veien skal prioritere norsk lov over sin lokale
+lovgivning.</p>
+</description>
+ </item>
+
<item>
<title>Fri programvare-tilbakeblikk for 2015 og 2016</title>
<link>http://people.skolelinux.org/pere/blog/Fri_programvare_tilbakeblikk_for_2015_og_2016.html</link>
</description>
</item>
- <item>
- <title>Experience and updated recipe for using the Signal app without a mobile phone</title>
- <link>http://people.skolelinux.org/pere/blog/Experience_and_updated_recipe_for_using_the_Signal_app_without_a_mobile_phone.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Experience_and_updated_recipe_for_using_the_Signal_app_without_a_mobile_phone.html</guid>
- <pubDate>Mon, 10 Oct 2016 11:30:00 +0200</pubDate>
- <description><p>In July
-<a href="http://people.skolelinux.org/pere/blog/How_to_use_the_Signal_app_if_you_only_have_a_land_line__ie_no_mobile_phone_.html">I
-wrote how to get the Signal Chrome/Chromium app working</a> without
-the ability to receive SMS messages (aka without a cell phone). It is
-time to share some experiences and provide an updated setup.</p>
-
-<p>The Signal app have worked fine for several months now, and I use
-it regularly to chat with my loved ones. I had a major snag at the
-end of my summer vacation, when the the app completely forgot my
-setup, identity and keys. The reason behind this major mess was
-running out of disk space. To avoid that ever happening again I have
-started storing everything in <tt>userdata/</tt> in git, to be able to
-roll back to an earlier version if the files are wiped by mistake. I
-had to use it once after introducing the git backup. When rolling
-back to an earlier version, one need to use the 'reset session' option
-in Signal to get going, and notify the people you talk with about the
-problem. I assume there is some sequence number tracking in the
-protocol to detect rollback attacks. The git repository is rather big
-(674 MiB so far), but I have not tried to figure out if some of the
-content can be added to a .gitignore file due to lack of spare
-time.</p>
-
-<p>I've also hit the 90 days timeout blocking, and noticed that this
-make it impossible to send messages using Signal. I could still
-receive them, but had to patch the code with a new timestamp to send.
-I believe the timeout is added by the developers to force people to
-upgrade to the latest version of the app, even when there is no
-protocol changes, to reduce the version skew among the user base and
-thus try to keep the number of support requests down.</p>
-
-<p>Since my original recipe, the Signal source code changed slightly,
-making the old patch fail to apply cleanly. Below is an updated
-patch, including the shell wrapper I use to start Signal. The
-original version required a new user to locate the JavaScript console
-and call a function from there. I got help from a friend with more
-JavaScript knowledge than me to modify the code to provide a GUI
-button instead. This mean that to get started you just need to run
-the wrapper and click the 'Register without mobile phone' to get going
-now. I've also modified the timeout code to always set it to 90 days
-in the future, to avoid having to patch the code regularly.</p>
-
-<p>So, the updated recipe for Debian Jessie:</p>
-
-<ol>
-
-<li>First, install required packages to get the source code and the
-browser you need. Signal only work with Chrome/Chromium, as far as I
-know, so you need to install it.
-
-<pre>
-apt install git tor chromium
-git clone https://github.com/WhisperSystems/Signal-Desktop.git
-</pre></li>
-
-<li>Modify the source code using command listed in the the patch
-block below.</li>
-
-<li>Start Signal using the run-signal-app wrapper (for example using
-<tt>`pwd`/run-signal-app</tt>).
-
-<li>Click on the 'Register without mobile phone', will in a phone
-number you can receive calls to the next minute, receive the
-verification code and enter it into the form field and press
-'Register'. Note, the phone number you use will be user Signal
-username, ie the way others can find you on Signal.</li>
-
-<li>You can now use Signal to contact others. Note, new contacts do
-not show up in the contact list until you restart Signal, and there is
-no way to assign names to Contacts. There is also no way to create or
-update chat groups. I suspect this is because the web app do not have
-a associated contact database.</li>
-
-</ol>
-
-<p>I am still a bit uneasy about using Signal, because of the way its
-main author moxie0 reject federation and accept dependencies to major
-corporations like Google (part of the code is fetched from Google) and
-Amazon (the central coordination point is owned by Amazon). See for
-example
-<a href="https://github.com/LibreSignal/LibreSignal/issues/37">the
-LibreSignal issue tracker</a> for a thread documenting the authors
-view on these issues. But the network effect is strong in this case,
-and several of the people I want to communicate with already use
-Signal. Perhaps we can all move to <a href="https://ring.cx/">Ring</a>
-once it <a href="https://bugs.debian.org/830265">work on my
-laptop</a>? It already work on Windows and Android, and is included
-in <a href="https://tracker.debian.org/pkg/ring">Debian</a> and
-<a href="https://launchpad.net/ubuntu/+source/ring">Ubuntu</a>, but not
-working on Debian Stable.</p>
-
-<p>Anyway, this is the patch I apply to the Signal code to get it
-working. It switch to the production servers, disable to timeout,
-make registration easier and add the shell wrapper:</p>
-
-<pre>
-cd Signal-Desktop; cat &lt;&lt;EOF | patch -p1
-diff --git a/js/background.js b/js/background.js
-index 24b4c1d..579345f 100644
---- a/js/background.js
-+++ b/js/background.js
-@@ -33,9 +33,9 @@
- });
- });
-
-- var SERVER_URL = 'https://textsecure-service-staging.whispersystems.org';
-+ var SERVER_URL = 'https://textsecure-service-ca.whispersystems.org';
- var SERVER_PORTS = [80, 4433, 8443];
-- var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments-staging.s3.amazonaws.com';
-+ var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments.s3.amazonaws.com';
- var messageReceiver;
- window.getSocketStatus = function() {
- if (messageReceiver) {
-diff --git a/js/expire.js b/js/expire.js
-index 639aeae..beb91c3 100644
---- a/js/expire.js
-+++ b/js/expire.js
-@@ -1,6 +1,6 @@
- ;(function() {
- 'use strict';
-- var BUILD_EXPIRATION = 0;
-+ var BUILD_EXPIRATION = Date.now() + (90 * 24 * 60 * 60 * 1000);
-
- window.extension = window.extension || {};
-
-diff --git a/js/views/install_view.js b/js/views/install_view.js
-index 7816f4f..1d6233b 100644
---- a/js/views/install_view.js
-+++ b/js/views/install_view.js
-@@ -38,7 +38,8 @@
- return {
- 'click .step1': this.selectStep.bind(this, 1),
- 'click .step2': this.selectStep.bind(this, 2),
-- 'click .step3': this.selectStep.bind(this, 3)
-+ 'click .step3': this.selectStep.bind(this, 3),
-+ 'click .callreg': function() { extension.install('standalone') },
- };
- },
- clearQR: function() {
-diff --git a/options.html b/options.html
-index dc0f28e..8d709f6 100644
---- a/options.html
-+++ b/options.html
-@@ -14,7 +14,10 @@
- &lt;div class='nav'>
- &lt;h1>{{ installWelcome }}&lt;/h1>
- &lt;p>{{ installTagline }}&lt;/p>
-- &lt;div> &lt;a class='button step2'>{{ installGetStartedButton }}&lt;/a> &lt;/div>
-+ &lt;div> &lt;a class='button step2'>{{ installGetStartedButton }}&lt;/a>
-+ &lt;br> &lt;a class="button callreg">Register without mobile phone&lt;/a>
-+
-+ &lt;/div>
- &lt;span class='dot step1 selected'>&lt;/span>
- &lt;span class='dot step2'>&lt;/span>
- &lt;span class='dot step3'>&lt;/span>
---- /dev/null 2016-10-07 09:55:13.730181472 +0200
-+++ b/run-signal-app 2016-10-10 08:54:09.434172391 +0200
-@@ -0,0 +1,12 @@
-+#!/bin/sh
-+set -e
-+cd $(dirname $0)
-+mkdir -p userdata
-+userdata="`pwd`/userdata"
-+if [ -d "$userdata" ] && [ ! -d "$userdata/.git" ] ; then
-+ (cd $userdata && git init)
-+fi
-+(cd $userdata && git add . && git commit -m "Current status." || true)
-+exec chromium \
-+ --proxy-server="socks://localhost:9050" \
-+ --user-data-dir=$userdata --load-and-launch-app=`pwd`
-EOF
-chmod a+rx run-signal-app
-</pre>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&label=PetterReinholdtsenBlog">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff