X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/337f2fc102f389a7cc891d0a1961bfae666e94ec..eb8ff3442e46d34cea37644170167d445c5cb3b4:/blog/archive/2017/01/01.rss?ds=sidebyside diff --git a/blog/archive/2017/01/01.rss b/blog/archive/2017/01/01.rss index 554dc369c6..f306d9782f 100644 --- a/blog/archive/2017/01/01.rss +++ b/blog/archive/2017/01/01.rss @@ -6,6 +6,282 @@ http://people.skolelinux.org/pere/blog/ + + Nasjonalbiblioteket avslutter sin ulovlige bruk av Google Skjemaer + http://people.skolelinux.org/pere/blog/Nasjonalbiblioteket_avslutter_sin_ulovlige_bruk_av_Google_Skjemaer.html + http://people.skolelinux.org/pere/blog/Nasjonalbiblioteket_avslutter_sin_ulovlige_bruk_av_Google_Skjemaer.html + Thu, 12 Jan 2017 09:40:00 +0100 + <p>I dag fikk jeg en skikkelig gladmelding. Bakgrunnen er at før jul +arrangerte Nasjonalbiblioteket +<a href="http://www.nb.no/Bibliotekutvikling/Kunnskapsorganisering/Nasjonalt-verksregister/Seminar-om-verksregister">et +seminar om sitt knakende gode tiltak «verksregister»</a>. Eneste +måten å melde seg på dette seminaret var å sende personopplysninger +til Google via Google Skjemaer. Dette syntes jeg var tvilsom praksis, +da det bør være mulig å delta på seminarer arrangert av det offentlige +uten å måtte dele sine interesser, posisjon og andre +personopplysninger med Google. Jeg ba derfor om innsyn via +<a href="https://www.mimesbronn.no/">Mimes brønn</a> i +<a href="https://www.mimesbronn.no/request/personopplysninger_til_google_sk">avtaler +og vurderinger Nasjonalbiblioteket hadde rundt dette</a>. +Personopplysningsloven legger klare rammer for hva som må være på +plass før en kan be tredjeparter, spesielt i utlandet, behandle +personopplysninger på sine vegne, så det burde eksistere grundig +dokumentasjon før noe slikt kan bli lovlig. To jurister hos +Nasjonalbiblioteket mente først dette var helt i orden, og at Googles +standardavtale kunne brukes som databehandlingsavtale. Det syntes jeg +var merkelig, men har ikke hatt kapasitet til å følge opp saken før +for to dager siden.</p> + +<p>Gladnyheten i dag, som kom etter at jeg tipset Nasjonalbiblioteket +om at Datatilsynet underkjente Googles standardavtaler som +databehandleravtaler i 2011, er at Nasjonalbiblioteket har bestemt seg +for å avslutte bruken av Googles Skjemaer/Apps og gå i dialog med DIFI +for å finne bedre måter å håndtere påmeldinger i tråd med +personopplysningsloven. Det er fantastisk å se at av og til hjelper +det å spørre hva i alle dager det offentlige holder på med.</p> + + + + + Bryter NAV sin egen personvernerklæring? + http://people.skolelinux.org/pere/blog/Bryter_NAV_sin_egen_personvernerkl_ring_.html + http://people.skolelinux.org/pere/blog/Bryter_NAV_sin_egen_personvernerkl_ring_.html + Wed, 11 Jan 2017 06:50:00 +0100 + <p>Jeg leste med interesse en nyhetssak hos +<a href="http://www.digi.no/artikler/nav-avslorer-trygdemisbruk-ved-a-spore-ip-adresser/367394">digi.no</a> +og +<a href="https://www.nrk.no/buskerud/trygdesvindlere-avslores-av-utenlandske-ip-adresser-1.13313461">NRK</a> +om at det ikke bare er meg, men at også NAV bedriver geolokalisering +av IP-adresser, og at det gjøres analyse av IP-adressene til de som +sendes inn meldekort for å se om meldekortet sendes inn fra +utenlandske IP-adresser. Politiadvokat i Drammen, Hans Lyder Haare, +er sitert i NRK på at «De to er jo blant annet avslørt av +IP-adresser. At man ser at meldekortet kommer fra utlandet.»</p> + +<p>Jeg synes det er fint at det blir bedre kjent at IP-adresser +knyttes til enkeltpersoner og at innsamlet informasjon brukes til å +stedsbestemme personer også av aktører her i Norge. Jeg ser det som +nok et argument for å bruke +<a href="https://www.torproject.org/">Tor</a> så mye som mulig for å +gjøre gjøre IP-lokalisering vanskeligere, slik at en kan beskytte sin +privatsfære og unngå å dele sin fysiske plassering med +uvedkommede.</p> + +<P>Men det er en ting som bekymrer meg rundt denne nyheten. Jeg ble +tipset (takk #nuug) om +<a href="https://www.nav.no/no/NAV+og+samfunn/Kontakt+NAV/Teknisk+brukerstotte/Snarveier/personvernerkl%C3%A6ring-for-arbeids-og-velferdsetaten">NAVs +personvernerklæring</a>, som under punktet «Personvern og statistikk» +lyder:</p> + +<p><blockquote> + +<p>«Når du besøker nav.no, etterlater du deg elektroniske spor. Sporene +dannes fordi din nettleser automatisk sender en rekke opplysninger til +NAVs tjener (server-maskin) hver gang du ber om å få vist en side. Det +er eksempelvis opplysninger om hvilken nettleser og -versjon du +bruker, og din internettadresse (ip-adresse). For hver side som vises, +lagres følgende opplysninger:</p> + +<ul> +<li>hvilken side du ser på</li> +<li>dato og tid</li> +<li>hvilken nettleser du bruker</li> +<li>din ip-adresse</li> +</ul> + +<p>Ingen av opplysningene vil bli brukt til å identifisere +enkeltpersoner. NAV bruker disse opplysningene til å generere en +samlet statistikk som blant annet viser hvilke sider som er mest +populære. Statistikken er et redskap til å forbedre våre +tjenester.»</p> + +</blockquote></p> + +<p>Jeg klarer ikke helt å se hvordan analyse av de besøkendes +IP-adresser for å se hvem som sender inn meldekort via web fra en +IP-adresse i utlandet kan gjøres uten å komme i strid med påstanden om +at «ingen av opplysningene vil bli brukt til å identifisere +enkeltpersoner». Det virker dermed for meg som at NAV bryter sine +egen personvernerklæring, hvilket +<a href="http://people.skolelinux.org/pere/blog/Er_lover_brutt_n_r_personvernpolicy_ikke_stemmer_med_praksis_.html">Datatilsynet +fortalte meg i starten av desember antagelig er brudd på +personopplysningsloven</a>. + +<p>I tillegg er personvernerklæringen ganske misvisende i og med at +NAVs nettsider ikke bare forsyner NAV med personopplysninger, men i +tillegg ber brukernes nettleser kontakte fem andre nettjenere +(script.hotjar.com, static.hotjar.com, vars.hotjar.com, +www.google-analytics.com og www.googletagmanager.com), slik at +personopplysninger blir gjort tilgjengelig for selskapene Hotjar og +Google , og alle som kan lytte på trafikken på veien (som FRA, GCHQ og +NSA). Jeg klarer heller ikke se hvordan slikt spredning av +personopplysninger kan være i tråd med kravene i +personopplysningloven, eller i tråd med NAVs personvernerklæring.</p> + +<p>Kanskje NAV bør ta en nøye titt på sin personvernerklæring? Eller +kanskje Datatilsynet bør gjøre det?</p> + + + + + Where did that package go? &mdash; geolocated IP traceroute + http://people.skolelinux.org/pere/blog/Where_did_that_package_go___mdash__geolocated_IP_traceroute.html + http://people.skolelinux.org/pere/blog/Where_did_that_package_go___mdash__geolocated_IP_traceroute.html + Mon, 9 Jan 2017 12:20:00 +0100 + <p>Did you ever wonder where the web trafic really flow to reach the +web servers, and who own the network equipment it is flowing through? +It is possible to get a glimpse of this from using traceroute, but it +is hard to find all the details. Many years ago, I wrote a system to +map the Norwegian Internet (trying to figure out if our plans for a +network game service would get low enough latency, and who we needed +to talk to about setting up game servers close to the users. Back +then I used traceroute output from many locations (I asked my friends +to run a script and send me their traceroute output) to create the +graph and the map. The output from traceroute typically look like +this: + +<p><pre> +traceroute to www.stortinget.no (85.88.67.10), 30 hops max, 60 byte packets + 1 uio-gw10.uio.no (129.240.202.1) 0.447 ms 0.486 ms 0.621 ms + 2 uio-gw8.uio.no (129.240.24.229) 0.467 ms 0.578 ms 0.675 ms + 3 oslo-gw1.uninett.no (128.39.65.17) 0.385 ms 0.373 ms 0.358 ms + 4 te3-1-2.br1.fn3.as2116.net (193.156.90.3) 1.174 ms 1.172 ms 1.153 ms + 5 he16-1-1.cr1.san110.as2116.net (195.0.244.234) 2.627 ms he16-1-1.cr2.oslosda310.as2116.net (195.0.244.48) 3.172 ms he16-1-1.cr1.san110.as2116.net (195.0.244.234) 2.857 ms + 6 ae1.ar8.oslosda310.as2116.net (195.0.242.39) 0.662 ms 0.637 ms ae0.ar8.oslosda310.as2116.net (195.0.242.23) 0.622 ms + 7 89.191.10.146 (89.191.10.146) 0.931 ms 0.917 ms 0.955 ms + 8 * * * + 9 * * * +[...] +</pre></p> + +<p>This show the DNS names and IP addresses of (at least some of the) +network equipment involved in getting the data traffic from me to the +www.stortinget.no server, and how long it took in milliseconds for a +package to reach the equipment and return to me. Three packages are +sent, and some times the packages do not follow the same path. This +is shown for hop 5, where three different IP addresses replied to the +traceroute request.</p> + +<p>There are many ways to measure trace routes. Other good traceroute +implementations I use are traceroute (using ICMP packages) mtr (can do +both ICMP, UDP and TCP) and scapy (python library with ICMP, UDP, TCP +traceroute and a lot of other capabilities). All of them are easily +available in <a href="https://www.debian.org/">Debian</a>.</p> + +<p>This time around, I wanted to know the geographic location of +different route points, to visualize how visiting a web page spread +information about the visit to a lot of servers around the globe. The +background is that a web site today often will ask the browser to get +from many servers the parts (for example HTML, JSON, fonts, +JavaScript, CSS, video) required to display the content. This will +leak information about the visit to those controlling these servers +and anyone able to peek at the data traffic passing by (like your ISP, +the ISPs backbone provider, FRA, GCHQ, NSA and others).</p> + +<p>Lets pick an example, the Norwegian parliament web site +www.stortinget.no. It is read daily by all members of parliament and +their staff, as well as political journalists, activits and many other +citizens of Norway. A visit to the www.stortinget.no web site will +ask your browser to contact 8 other servers: ajax.googleapis.com, +insights.hotjar.com, script.hotjar.com, static.hotjar.com, +stats.g.doubleclick.net, www.google-analytics.com, +www.googletagmanager.com and www.netigate.se. I extracted this by +asking <a href="http://phantomjs.org/">PhantomJS</a> to visit the +Stortinget web page and tell me all the URLs PhantomJS downloaded to +render the page (in HAR format using +<a href="https://github.com/ariya/phantomjs/blob/master/examples/netsniff.js">their +netsniff example</a>. I am very grateful to Gorm for showing me how +to do this). My goal is to visualize network traces to all IP +addresses behind these DNS names, do show where visitors personal +information is spread when visiting the page.</p> + +<p align="center"><a href="www.stortinget.no-geoip.kml"><img +src="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geoip-small.png" alt="map of combined traces for URLs used by www.stortinget.no using GeoIP"/></a></p> + +<p>When I had a look around for options, I could not find any good +free software tools to do this, and decided I needed my own traceroute +wrapper outputting KML based on locations looked up using GeoIP. KML +is easy to work with and easy to generate, and understood by several +of the GIS tools I have available. I got good help from by NUUG +colleague Anders Einar with this, and the result can be seen in +<a href="https://github.com/petterreinholdtsen/kmltraceroute">my +kmltraceroute git repository</a>. Unfortunately, the quality of the +free GeoIP databases I could find (and the for-pay databases my +friends had access to) is not up to the task. The IP addresses of +central Internet infrastructure would typically be placed near the +controlling companies main office, and not where the router is really +located, as you can see from <a href="www.stortinget.no-geoip.kml">the +KML file I created</a> using the GeoLite City dataset from MaxMind. + +<p align="center"><a href="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy.svg"><img +src="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy-small.png" alt="scapy traceroute graph for URLs used by www.stortinget.no"/></a></p> + +<p>I also had a look at the visual traceroute graph created by +<a href="http://www.secdev.org/projects/scapy/">the scrapy project</a>, +showing IP network ownership (aka AS owner) for the IP address in +question. +<a href="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy.svg">The +graph display a lot of useful information about the traceroute in SVG +format</a>, and give a good indication on who control the network +equipment involved, but it do not include geolocation. This graph +make it possible to see the information is made available at least for +UNINETT, Catchcom, Stortinget, Nordunet, Google, Amazon, Telia, Level +3 Communications and NetDNA.</p> + +<p align="center"><a href="https://geotraceroute.com/index.php?node=4&host=www.stortinget.no"><img +src="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-small.png" alt="example geotraceroute view for www.stortinget.no"/></a></p> + +<p>In the process, I came across the +<a href="https://geotraceroute.com/">web service GeoTraceroute</a> by +Salim Gasmi. Its methology of combining guesses based on DNS names, +various location databases and finally use latecy times to rule out +candidate locations seemed to do a very good job of guessing correct +geolocation. But it could only do one trace at the time, did not have +a sensor in Norway and did not make the geolocations easily available +for postprocessing. So I contacted the developer and asked if he +would be willing to share the code (he refused until he had time to +clean it up), but he was interested in providing the geolocations in a +machine readable format, and willing to set up a sensor in Norway. So +since yesterday, it is possible to run traces from Norway in this +service thanks to a sensor node set up by +<a href="https://www.nuug.no/">the NUUG assosiation</a>, and get the +trace in KML format for further processing.</p> + +<p align="center"><a href="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-kml-join.kml"><img +src="http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-kml-join.png" alt="map of combined traces for URLs used by www.stortinget.no using geotraceroute"/></a></p> + +<p>Here we can see a lot of trafic passes Sweden on its way to +Denmark, Germany, Holland and Ireland. Plenty of places where the +Snowden confirmations verified the traffic is read by various actors +without your best interest as their top priority.</p> + +<p>Combining KML files is trivial using a text editor, so I could loop +over all the hosts behind the urls imported by www.stortinget.no and +ask for the KML file from GeoTraceroute, and create a combined KML +file with all the traces (unfortunately only one of the IP addresses +behind the DNS name is traced this time. To get them all, one would +have to request traces using IP number instead of DNS names from +GeoTraceroute). That might be the next step in this project.</p> + +<p>Armed with these tools, I find it a lot easier to figure out where +the IP traffic moves and who control the boxes involved in moving it. +And every time the link crosses for example the Swedish border, we can +be sure Swedish Signal Intelligence (FRA) is listening, as GCHQ do in +Britain and NSA in USA and cables around the globe. (Hm, what should +we tell them? :) Keep that in mind if you ever send anything +unencrypted over the Internet.</p> + +<p>PS: KML files are drawn using +<a href="http://ivanrublev.me/kml/">the KML viewer from Ivan +Rublev<a/>, as it was less cluttered than the local Linux application +Marble. There are heaps of other options too.</p> + +<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> + + + Introducing ical-archiver to split out old iCalendar entries http://people.skolelinux.org/pere/blog/Introducing_ical_archiver_to_split_out_old_iCalendar_entries.html