Converted pages to temp site.

[homepage.git] / blog / archive / 2017 / 01 / 01.rss

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries from January 2017</title>
                <description>Entries from January 2017</description>
                <link>https://www.hungry.com/~pere/blog/</link>

        
        <item>
                <title>Nasjonalbiblioteket avslutter sin ulovlige bruk av Google Skjemaer</title>
                <link>https://www.hungry.com/~pere/blog/Nasjonalbiblioteket_avslutter_sin_ulovlige_bruk_av_Google_Skjemaer.html</link>        
                <guid isPermaLink="true">https://www.hungry.com/~pere/blog/Nasjonalbiblioteket_avslutter_sin_ulovlige_bruk_av_Google_Skjemaer.html</guid>
                <pubDate>Thu, 12 Jan 2017 09:40:00 +0100</pubDate>
                <description>&lt;p&gt;I dag fikk jeg en skikkelig gladmelding.  Bakgrunnen er at før jul
arrangerte Nasjonalbiblioteket
&lt;a href=&quot;http://www.nb.no/Bibliotekutvikling/Kunnskapsorganisering/Nasjonalt-verksregister/Seminar-om-verksregister&quot;&gt;et
seminar om sitt knakende gode tiltak «verksregister»&lt;/a&gt;.  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
&lt;a href=&quot;https://www.mimesbronn.no/&quot;&gt;Mimes brønn&lt;/a&gt; i
&lt;a href=&quot;https://www.mimesbronn.no/request/personopplysninger_til_google_sk&quot;&gt;avtaler
og vurderinger Nasjonalbiblioteket hadde rundt dette&lt;/a&gt;.
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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Bryter NAV sin egen personvernerklæring?</title>
                <link>https://www.hungry.com/~pere/blog/Bryter_NAV_sin_egen_personvernerkl_ring_.html</link>        
                <guid isPermaLink="true">https://www.hungry.com/~pere/blog/Bryter_NAV_sin_egen_personvernerkl_ring_.html</guid>
                <pubDate>Wed, 11 Jan 2017 06:50:00 +0100</pubDate>
                <description>&lt;p&gt;Jeg leste med interesse en nyhetssak hos
&lt;a href=&quot;http://www.digi.no/artikler/nav-avslorer-trygdemisbruk-ved-a-spore-ip-adresser/367394&quot;&gt;digi.no&lt;/a&gt;
og
&lt;a href=&quot;https://www.nrk.no/buskerud/trygdesvindlere-avslores-av-utenlandske-ip-adresser-1.13313461&quot;&gt;NRK&lt;/a&gt;
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.»&lt;/p&gt;

&lt;p&gt;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
&lt;a href=&quot;https://www.torproject.org/&quot;&gt;Tor&lt;/a&gt; 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.&lt;/p&gt;

&lt;P&gt;Men det er en ting som bekymrer meg rundt denne nyheten.  Jeg ble
tipset (takk #nuug) om
&lt;a href=&quot;https://www.nav.no/no/NAV+og+samfunn/Kontakt+NAV/Teknisk+brukerstotte/Snarveier/personvernerkl%C3%A6ring-for-arbeids-og-velferdsetaten&quot;&gt;NAVs
personvernerklæring&lt;/a&gt;, som under punktet «Personvern og statistikk»
lyder:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;

&lt;p&gt;«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:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;hvilken side du ser på&lt;/li&gt;
&lt;li&gt;dato og tid&lt;/li&gt;
&lt;li&gt;hvilken nettleser du bruker&lt;/li&gt;
&lt;li&gt;din ip-adresse&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;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.»&lt;/p&gt;

&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;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
&lt;a href=&quot;https://people.skolelinux.org/pere/blog/Er_lover_brutt_n_r_personvernpolicy_ikke_stemmer_med_praksis_.html&quot;&gt;Datatilsynet
fortalte meg i starten av desember antagelig er brudd på
personopplysningsloven&lt;/a&gt;.

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Kanskje NAV bør ta en nøye titt på sin personvernerklæring?  Eller
kanskje Datatilsynet bør gjøre det?&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Where did that package go? &amp;mdash; geolocated IP traceroute</title>
                <link>https://www.hungry.com/~pere/blog/Where_did_that_package_go___mdash__geolocated_IP_traceroute.html</link>        
                <guid isPermaLink="true">https://www.hungry.com/~pere/blog/Where_did_that_package_go___mdash__geolocated_IP_traceroute.html</guid>
                <pubDate>Mon, 9 Jan 2017 12:20:00 +0100</pubDate>
                <description>&lt;p&gt;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:

&lt;p&gt;&lt;pre&gt;
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  * * *
[...]
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &lt;a href=&quot;https://www.debian.org/&quot;&gt;Debian&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;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).&lt;/p&gt;

&lt;p&gt;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 &lt;a href=&quot;http://phantomjs.org/&quot;&gt;PhantomJS&lt;/a&gt; to visit the
Stortinget web page and tell me all the URLs PhantomJS downloaded to
render the page (in HAR format using
&lt;a href=&quot;https://github.com/ariya/phantomjs/blob/master/examples/netsniff.js&quot;&gt;their
netsniff example&lt;/a&gt;.  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.&lt;/p&gt;

&lt;p align=&quot;center&quot;&gt;&lt;a href=&quot;www.stortinget.no-geoip.kml&quot;&gt;&lt;img
src=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geoip-small.png&quot; alt=&quot;map of combined traces for URLs used by www.stortinget.no using GeoIP&quot;/&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;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
&lt;a href=&quot;https://github.com/petterreinholdtsen/kmltraceroute&quot;&gt;my
kmltraceroute git repository&lt;/a&gt;.  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 &lt;a href=&quot;www.stortinget.no-geoip.kml&quot;&gt;the
KML file I created&lt;/a&gt; using the GeoLite City dataset from MaxMind.

&lt;p align=&quot;center&quot;&gt;&lt;a href=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy.svg&quot;&gt;&lt;img
src=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy-small.png&quot; alt=&quot;scapy traceroute graph for URLs used by www.stortinget.no&quot;/&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I also had a look at the visual traceroute graph created by
&lt;a href=&quot;http://www.secdev.org/projects/scapy/&quot;&gt;the scrapy project&lt;/a&gt;,
showing IP network ownership (aka AS owner) for the IP address in
question.
&lt;a href=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy.svg&quot;&gt;The
graph display a lot of useful information about the traceroute in SVG
format&lt;/a&gt;, 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.&lt;/p&gt;

&lt;p align=&quot;center&quot;&gt;&lt;a href=&quot;https://geotraceroute.com/index.php?node=4&amp;host=www.stortinget.no&quot;&gt;&lt;img
src=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-small.png&quot; alt=&quot;example geotraceroute view for www.stortinget.no&quot;/&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;In the process, I came across the
&lt;a href=&quot;https://geotraceroute.com/&quot;&gt;web service GeoTraceroute&lt;/a&gt; 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
&lt;a href=&quot;https://www.nuug.no/&quot;&gt;the NUUG assosiation&lt;/a&gt;, and get the
trace in KML format for further processing.&lt;/p&gt;

&lt;p align=&quot;center&quot;&gt;&lt;a href=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-kml-join.kml&quot;&gt;&lt;img
src=&quot;https://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-kml-join.png&quot; alt=&quot;map of combined traces for URLs used by www.stortinget.no using geotraceroute&quot;/&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;PS: KML files are drawn using
&lt;a href=&quot;http://ivanrublev.me/kml/&quot;&gt;the KML viewer from Ivan
Rublev&lt;a/&gt;, as it was less cluttered than the local Linux application
Marble.  There are heaps of other options too.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Introducing ical-archiver to split out old iCalendar entries</title>
                <link>https://www.hungry.com/~pere/blog/Introducing_ical_archiver_to_split_out_old_iCalendar_entries.html</link>        
                <guid isPermaLink="true">https://www.hungry.com/~pere/blog/Introducing_ical_archiver_to_split_out_old_iCalendar_entries.html</guid>
                <pubDate>Wed, 4 Jan 2017 12:20:00 +0100</pubDate>
                <description>&lt;p&gt;Do you have a large &lt;a href=&quot;https://icalendar.org/&quot;&gt;iCalendar&lt;/a&gt;
file with lots of old entries, and would like to archive them to save
space and resources?  At least those of us using KOrganizer know that
turning on and off an event set become slower and slower the more
entries are in the set.  While working on migrating our calendars to a
&lt;a href=&quot;http://radicale.org/&quot;&gt;Radicale CalDAV server&lt;/a&gt; on our
&lt;a href=&quot;https://freedomboxfoundation.org/&quot;&gt;Freedombox server&lt;/a/&gt;, my
loved one wondered if I could find a way to split up the calendar file
she had in KOrganizer, and I set out to write a tool.  I spent a few
days writing and polishing the system, and it is now ready for general
consumption.  The
&lt;a href=&quot;https://github.com/petterreinholdtsen/ical-archiver&quot;&gt;code for
ical-archiver&lt;/a&gt; is publicly available from a git repository on
github.  The system is written in Python and depend on
&lt;a href=&quot;http://eventable.github.io/vobject/&quot;&gt;the vobject Python
module&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;To use it, locate the iCalendar file you want to operate on and
give it as an argument to the ical-archiver script.  This will
generate a set of new files, one file per component type per year for
all components expiring more than two years in the past.  The vevent,
vtodo and vjournal entries are handled by the script.  The remaining
entries are stored in a &#39;remaining&#39; file.&lt;/p&gt;

&lt;p&gt;This is what a test run can look like:

&lt;p&gt;&lt;pre&gt;
% ical-archiver t/2004-2016.ics 
Found 3612 vevents
Found 6 vtodos
Found 2 vjournals
Writing t/2004-2016.ics-subset-vevent-2004.ics
Writing t/2004-2016.ics-subset-vevent-2005.ics
Writing t/2004-2016.ics-subset-vevent-2006.ics
Writing t/2004-2016.ics-subset-vevent-2007.ics
Writing t/2004-2016.ics-subset-vevent-2008.ics
Writing t/2004-2016.ics-subset-vevent-2009.ics
Writing t/2004-2016.ics-subset-vevent-2010.ics
Writing t/2004-2016.ics-subset-vevent-2011.ics
Writing t/2004-2016.ics-subset-vevent-2012.ics
Writing t/2004-2016.ics-subset-vevent-2013.ics
Writing t/2004-2016.ics-subset-vevent-2014.ics
Writing t/2004-2016.ics-subset-vjournal-2007.ics
Writing t/2004-2016.ics-subset-vjournal-2011.ics
Writing t/2004-2016.ics-subset-vtodo-2012.ics
Writing t/2004-2016.ics-remaining.ics
%
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;As you can see, the original file is untouched and new files are
written with names derived from the original file.  If you are happy
with their content, the *-remaining.ics file can replace the original
the the others can be archived or imported as historical calendar
collections.&lt;/p&gt;

&lt;p&gt;The script should probably be improved a bit.  The error handling
when discovering broken entries is not good, and I am not sure yet if
it make sense to split different entry types into separate files or
not.  The program is thus likely to change.  If you find it
interesting, please get in touch. :)&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>