X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/004634752854baf4ae880b35fd697a31d4c5d0e5..a8c94673f3e4f51c47ece03204e624e68beafc38:/blog/index.html diff --git a/blog/index.html b/blog/index.html index 0768ca3445..c0a46149d8 100644 --- a/blog/index.html +++ b/blog/index.html @@ -19,6 +19,365 @@ +
+
Er lover brutt når personvernpolicy ikke stemmer med praksis?
+
9th December 2016
+

Når jeg bruker Ghostery, +uBlock, +uMatrix, +ScriptSafe 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:

+ +
+ +

«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)

+ +

Et eksempel er Nettavisen digi.no. +Deres +personvernpolicy sier følgende:

+ +
+ «Tredjeparter (som Google Analytics, Cxense, TNS Gallup) får kun + anonymiserte data.» +
+ +

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 +Google +Analytics om å fjerne siste oktett i IP-adressen ved lagring, +dvs. flagget «aip=1» er ikke satt i URL-en som brukes for å kontakte +Google Analytics.

+ +

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).»

+ +
+ +

Etter noen dager kunne juridisk rådgiver Elisabeth Krauss Amundsen +hos Datatilsynet fortelle det følgende:

+ +
+«Hei, og takk for din e-post.

+ +

Vår svartjeneste gir deg kortfattet rådgivning. Vi vil derfor ikke konkludere +i saken din, men gi deg råd og veiledning.

+ +

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<https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§18> +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.<https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§11>» +

+ + + +

Oppdatert med kunnskap om lover og regler tok jeg så kontakt med +Dagbladet på epostadressen de annonserer på sine +personvernpolicysider:

+ +

+ +

«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. +Dagbladets +personvernpolicy forteller følgende:

+ +
+

«3. Automatisk innhentet informasjon

+ +

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.»

+ +
+ + +

Men når en besøker nettsidene til Dagbladet, +f.eks. forsiden, 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 +«en +IP-adresse definert som en personopplysning fordi den kan spores +tilbake til en bestemt maskinvare og dermed til en enkeltperson».

+ +

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.

+ +

Mitt spørsmål er dermed som følger:

+ +
+ +

Hva mener dere i personpolicyen når dere skriver at IP-adressen ikke + er synlig for andre?»

+ +
+ +
+ +

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.

+ +

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:

+ +
+ +

«Jeg lurte på en ting i forbindelse med en bloggpost jeg skriver på, +og lurer på om dere hjelpe meg. Først litt bakgrunnsinformasjon. +Digi.nos +personvernpolicy forteller følgende:

+ +
+ «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.» +
+ +

Men når en besøker nettsidene til nettavisen, f.eks. +forsiden, 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 +«en +IP-adresse definert som en personopplysning fordi den kan spores +tilbake til en bestemt maskinvare og dermed til en enkeltperson». +Det jeg ser virker ikke å være i tråd med personvernpolicyen.

+ +

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.

+ +

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.

+ +

Mitt spørsmål er dermed som følger:

+ +
+ +

Hva mener dere i personpolicyen når dere skriver at «Tredjeparter + får kun anonymiserte data»?»

+ +
+ +
+ +

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:

+ +
+ +

«Takk for godt tips! Det er helt riktig at IP og referrer-adresse +potensielt kan leses ut av tredjepart.

+ +

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:

+ +
+

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.

+ +

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.

+
+ +

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.»

+ +
+ +

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.

+ +

Med bakgrunn i at Digi.no ikke har fulgt sin egen personvernpolicy +spurte jeg hvordan Digi.no kom til å håndtere endringen:

+ +
+ +

«Tusen takk for beskjed om endring av personvernpolicy for digi.no. +Gjelder endringen også andre nettsteder?

+ +

Vil tidligere håndteringen av IP-adresser og lesemønster i strid +med dokumentert personvernpolicy bli varslet til Datatilsynet i tråd +med +personopplysningsforskriften +§ 2-6? 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?

+ +

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. :)»

+
+ +

Jeg fikk raskt svar tilbake fra direktøren Høie:

+ +
+

«Tydeliggjøringen i personvernpolicy gjelder alle våre nettsteder.

+ +

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.

+ +

Angående spørsmålet ditt: +
Du vil fortsatt vise i våre interne systemer om du blir Ekstra-bruker, +vi skrur bare av tredjeparts tracking.»

+
+ +

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 gårdagens oppslag fra NRK gjelder +det også norske kommuner og andre offentlige aktører, og +jeg +skrev om omfanget av problemet i fjor. 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:

+ +
+ +

«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?»

+ +
+ +

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.

+ +

Jeg synes jo det er spesielt ille når barn får sine +personopplysninger spredt til utlandet, noe jeg +tok +opp med NRK i fjor. 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?

+ +

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 +(tilgjengelig via +github) før informasjon sendes over til Google Analytics. Dermed +er det mulig for ansvarlige for nettstedet å vite 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 +identifisering ved hjelp av +nettleserinformasjon 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.

+
+
+ + + Tags: norsk, personvern, surveillance. + + +
+
+
+
Fri programvare-tilbakeblikk for 2015 og 2016
1st December 2016
@@ -871,196 +1230,6 @@ dele sine personopplysninger med leverandøren.

-
-
Experience and updated recipe for using the Signal app without a mobile phone
-
10th October 2016
-

In July -I -wrote how to get the Signal Chrome/Chromium app working without -the ability to receive SMS messages (aka without a cell phone). It is -time to share some experiences and provide an updated setup.

- -

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 userdata/ 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.

- -

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.

- -

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.

- -

So, the updated recipe for Debian Jessie:

- -
    - -
  1. 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. - -
    -apt install git tor chromium
    -git clone https://github.com/WhisperSystems/Signal-Desktop.git
    -
  2. - -
  3. Modify the source code using command listed in the the patch -block below.
  4. - -
  5. Start Signal using the run-signal-app wrapper (for example using -`pwd`/run-signal-app). - -
  6. 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.
  7. - -
  8. 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.
  9. - -
- -

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 -the -LibreSignal issue tracker 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 Ring -once it work on my -laptop? It already work on Windows and Android, and is included -in Debian and -Ubuntu, but not -working on Debian Stable.

- -

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:

- -
-cd Signal-Desktop; cat <<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 @@
-         <div class='nav'>
-           <h1>{{ installWelcome }}</h1>
-           <p>{{ installTagline }}</p>
--          <div> <a class='button step2'>{{ installGetStartedButton }}</a> </div>
-+          <div> <a class='button step2'>{{ installGetStartedButton }}</a>
-+	    <br> <a class="button callreg">Register without mobile phone</a>
-+
-+	  </div>
-           <span class='dot step1 selected'></span>
-           <span class='dot step2'></span>
-           <span class='dot step3'></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
-
- -

As usual, if you use Bitcoin and want to show your support of my -activities, please send Bitcoin donations to my address -15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

-
-
- - - Tags: debian, english, sikkerhet, surveillance. - - -
-
-
-

RSS feed