[homepage.git] / blog / index.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:atom="http://www.w3.org/2005/Atom">
        <channel>
                <title>Petter Reinholdtsen</title>
                <description></description>
                <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>Detecting NFS hangs on Linux without hanging yourself...</title>
                <link>http://people.skolelinux.org/pere/blog/Detecting_NFS_hangs_on_Linux_without_hanging_yourself___.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Detecting_NFS_hangs_on_Linux_without_hanging_yourself___.html</guid>
                <pubDate>Thu, 9 Mar 2017 15:20:00 +0100</pubDate>
                <description>&lt;p&gt;Over the years, administrating thousand of NFS mounting linux
computers at the time, I often needed a way to detect if the machine
was experiencing NFS hang.  If you try to use &lt;tt&gt;df&lt;/tt&gt; or look at a
file or directory affected by the hang, the process (and possibly the
shell) will hang too.  So you want to be able to detect this without
risking the detection process getting stuck too.  It has not been
obvious how to do this.  When the hang has lasted a while, it is
possible to find messages like these in dmesg:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
nfs: server nfsserver not responding, still trying
&lt;br&gt;nfs: server nfsserver OK
&lt;/blockquote&gt;&lt;/p&gt;
  
&lt;p&gt;It is hard to know if the hang is still going on, and it is hard to
be sure looking in dmesg is going to work.  If there are lots of other
messages in dmesg the lines might have rotated out of site before they
are noticed.&lt;/p&gt;

&lt;p&gt;While reading through the nfs client implementation in linux kernel
code, I came across some statistics that seem to give a way to detect
it.  The om_timeouts sunrpc value in the kernel will increase every
time the above log entry is inserted into dmesg.  And after digging a
bit further, I discovered that this value show up in
/proc/self/mountstats on Linux.&lt;/p&gt;

&lt;p&gt;The mountstats content seem to be shared between files using the
same file system context, so it is enough to check one of the
mountstats files to get the state of the mount point for the machine.
I assume this will not show lazy umounted NFS points, nor NFS mount
points in a different process context (ie with a different filesystem
view), but that does not worry me.&lt;/p&gt;

&lt;p&gt;The content for a NFS mount point look similar to this:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
[...]
device /dev/mapper/Debian-var mounted on /var with fstype ext3
device nfsserver:/mnt/nfsserver/home0 mounted on /mnt/nfsserver/home0 with fstype nfs statvers=1.1
        opts:   rw,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,soft,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=129.240.3.145,mountvers=3,mountport=4048,mountproto=udp,local_lock=all
        age:    7863311
        caps:   caps=0x3fe7,wtmult=4096,dtsize=8192,bsize=0,namlen=255
        sec:    flavor=1,pseudoflavor=1
        events: 61063112 732346265 1028140 35486205 16220064 8162542 761447191 71714012 37189 3891185 45561809 110486139 4850138 420353 15449177 296502 52736725 13523379 0 52182 9016896 1231 0 0 0 0 0 
        bytes:  166253035039 219519120027 0 0 40783504807 185466229638 11677877 45561809 
        RPC iostats version: 1.0  p/v: 100003/3 (nfs)
        xprt:   tcp 925 1 6810 0 0 111505412 111480497 109 2672418560317 0 248 53869103 22481820
        per-op statistics
                NULL: 0 0 0 0 0 0 0 0
             GETATTR: 61063106 61063108 0 9621383060 6839064400 453650 77291321 78926132
             SETATTR: 463469 463470 0 92005440 66739536 63787 603235 687943
              LOOKUP: 17021657 17021657 0 3354097764 4013442928 57216 35125459 35566511
              ACCESS: 14281703 14290009 5 2318400592 1713803640 1709282 4865144 7130140
            READLINK: 125 125 0 20472 18620 0 1112 1118
                READ: 4214236 4214237 0 715608524 41328653212 89884 22622768 22806693
               WRITE: 8479010 8494376 22 187695798568 1356087148 178264904 51506907 231671771
              CREATE: 171708 171708 0 38084748 46702272 873 1041833 1050398
               MKDIR: 3680 3680 0 773980 993920 26 23990 24245
             SYMLINK: 903 903 0 233428 245488 6 5865 5917
               MKNOD: 80 80 0 20148 21760 0 299 304
              REMOVE: 429921 429921 0 79796004 61908192 3313 2710416 2741636
               RMDIR: 3367 3367 0 645112 484848 22 5782 6002
              RENAME: 466201 466201 0 130026184 121212260 7075 5935207 5961288
                LINK: 289155 289155 0 72775556 67083960 2199 2565060 2585579
             READDIR: 2933237 2933237 0 516506204 13973833412 10385 3190199 3297917
         READDIRPLUS: 1652839 1652839 0 298640972 6895997744 84735 14307895 14448937
              FSSTAT: 6144 6144 0 1010516 1032192 51 9654 10022
              FSINFO: 2 2 0 232 328 0 1 1
            PATHCONF: 1 1 0 116 140 0 0 0
              COMMIT: 0 0 0 0 0 0 0 0

device binfmt_misc mounted on /proc/sys/fs/binfmt_misc with fstype binfmt_misc
[...]
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The key number to look at is the third number in the per-op list.
It is the number of NFS timeouts experiences per file system
operation.  Here 22 write timeouts and 5 access timeouts.  If these
numbers are increasing, I believe the machine is experiencing NFS
hang.  Unfortunately the timeout value do not start to increase right
away.  The NFS operations need to time out first, and this can take a
while.  The exact timeout value depend on the setup.  For example the
defaults for TCP and UDP mount points are quite different, and the
timeout value is affected by the soft, hard, timeo and retrans NFS
mount options.&lt;/p&gt;

&lt;p&gt;The only way I have been able to get working on Debian and RedHat
Enterprise Linux for getting the timeout count is to peek in /proc/.
But according to
&lt;ahref=&quot;http://docs.oracle.com/cd/E19253-01/816-4555/netmonitor-12/index.html&quot;&gt;Solaris
10 System Administration Guide: Network Services&lt;/a&gt;, the &#39;nfsstat -c&#39;
command can be used to get these timeout values.  But this do not work
on Linux, as far as I can tell.  I
&lt;ahref=&quot;http://bugs.debian.org/857043&quot;&gt;asked Debian about this&lt;/a&gt;,
but have not seen any replies yet.&lt;/p&gt;

&lt;p&gt;Is there a better way to figure out if a Linux NFS client is
experiencing NFS hangs?  Is there a way to detect which processes are
affected?  Is there a way to get the NFS mount going quickly once the
network problem causing the NFS hang has been cleared?  I would very
much welcome some clues, as we regularly run into NFS hangs.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>How does it feel to be wiretapped, when you should be doing the wiretapping...</title>
                <link>http://people.skolelinux.org/pere/blog/How_does_it_feel_to_be_wiretapped__when_you_should_be_doing_the_wiretapping___.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_does_it_feel_to_be_wiretapped__when_you_should_be_doing_the_wiretapping___.html</guid>
                <pubDate>Wed, 8 Mar 2017 11:50:00 +0100</pubDate>
                <description>&lt;p&gt;So the new president in the United States of America claim to be
surprised to discover that he was wiretapped during the election
before he was elected president.  He even claim this must be illegal.
Well, doh, if it is one thing the confirmations from Snowden
documented, it is that the entire population in USA is wiretapped, one
way or another.  Of course the president candidates were wiretapped,
alongside the senators, judges and the rest of the people in USA.&lt;/p&gt;

&lt;p&gt;Next, the Federal Bureau of Investigation ask the Department of
Justice to go public rejecting the claims that Donald Trump was
wiretapped illegally.  I fail to see the relevance, given that I am
sure the surveillance industry in USA believe they have all the legal
backing they need to conduct mass surveillance on the entire
world.&lt;/p&gt;

&lt;p&gt;There is even the director of the FBI stating that he never saw an
order requesting wiretapping of Donald Trump.  That is not very
surprising, given how the FISA court work, with all its activity being
secret.  Perhaps he only heard about it?&lt;/p&gt;

&lt;p&gt;What I find most sad in this story is how Norwegian journalists
present it.  In a news reports the other day in the radio from the
Norwegian National broadcasting Company (NRK), I heard the journalist
claim that &#39;the FBI denies any wiretapping&#39;, while the reality is that
&#39;the FBI denies any illegal wiretapping&#39;.  There is a fundamental and
important difference, and it make me sad that the journalists are
unable to grasp it.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Norwegian Bokmål translation of The Debian Administrator&#39;s Handbook complete, proofreading in progress</title>
                <link>http://people.skolelinux.org/pere/blog/Norwegian_Bokm_l_translation_of_The_Debian_Administrator_s_Handbook_complete__proofreading_in_progress.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Norwegian_Bokm_l_translation_of_The_Debian_Administrator_s_Handbook_complete__proofreading_in_progress.html</guid>
                <pubDate>Fri, 3 Mar 2017 14:50:00 +0100</pubDate>
                <description>&lt;p&gt;For almost a year now, we have been working on making a Norwegian
Bokmål edition of &lt;a href=&quot;https://debian-handbook.info/&quot;&gt;The Debian
Administrator&#39;s Handbook&lt;/a&gt;.  Now, thanks to the tireless effort of
Ole-Erik, Ingrid and Andreas, the initial translation is complete, and
we are working on the proof reading to ensure consistent language and
use of correct computer science terms.  The plan is to make the book
available on paper, as well as in electronic form.  For that to
happen, the proof reading must be completed and all the figures need
to be translated.  If you want to help out, get in touch.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://people.skolelinux.org/pere/debian-handbook/debian-handbook-nb-NO.pdf&quot;&gt;A

fresh PDF edition&lt;/a&gt; in A4 format (the final book will have smaller
pages) of the book created every morning is available for
proofreading.  If you find any errors, please
&lt;a href=&quot;https://hosted.weblate.org/projects/debian-handbook/&quot;&gt;visit
Weblate and correct the error&lt;/a&gt;.  The
&lt;a href=&quot;http://l.github.io/debian-handbook/stat/nb-NO/index.html&quot;&gt;state
of the translation including figures&lt;/a&gt; is a useful source for those
provide Norwegian bokmål screen shots and figures.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Unlimited randomness with the ChaosKey?</title>
                <link>http://people.skolelinux.org/pere/blog/Unlimited_randomness_with_the_ChaosKey_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Unlimited_randomness_with_the_ChaosKey_.html</guid>
                <pubDate>Wed, 1 Mar 2017 20:50:00 +0100</pubDate>
                <description>&lt;p&gt;A few days ago I ordered a small batch of
&lt;a href=&quot;http://altusmetrum.org/ChaosKey/&quot;&gt;the ChaosKey&lt;/a&gt;, a small
USB dongle for generating entropy created by Bdale Garbee and Keith
Packard.  Yesterday it arrived, and I am very happy to report that it
work great!  According to its designers, to get it to work out of the
box, you need the Linux kernel version 4.1 or later.  I tested on a
Debian Stretch machine (kernel version 4.9), and there it worked just
fine, increasing the available entropy very quickly.  I wrote a small
test oneliner to test.  It first print the current entropy level,
drain /dev/random, and then print the entropy level for five seconds.
Here is the situation without the ChaosKey inserted:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
% cat /proc/sys/kernel/random/entropy_avail; \
  dd bs=1M if=/dev/random of=/dev/null count=1; \
  for n in $(seq 1 5); do \
     cat /proc/sys/kernel/random/entropy_avail; \
     sleep 1; \
  done
300
0+1 oppføringer inn
0+1 oppføringer ut
28 byte kopiert, 0,000264565 s, 106 kB/s
4
8
12
17
21
%
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;The entropy level increases by 3-4 every second.  In such case any
application requiring random bits (like a HTTPS enabled web server)
will halt and wait for more entrpy.  And here is the situation with
the ChaosKey inserted:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
% cat /proc/sys/kernel/random/entropy_avail; \
  dd bs=1M if=/dev/random of=/dev/null count=1; \
  for n in $(seq 1 5); do \
     cat /proc/sys/kernel/random/entropy_avail; \
     sleep 1; \
  done
1079
0+1 oppføringer inn
0+1 oppføringer ut
104 byte kopiert, 0,000487647 s, 213 kB/s
433
1028
1031
1035
1038
%
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;Quite the difference. :) I bought a few more than I need, in case
someone want to buy one here in Norway. :)&lt;/p&gt;

&lt;p&gt;Update: The dongle was presented at Debconf last year.  You might
find &lt;a href=&quot;https://debconf16.debconf.org/talks/94/&quot;&gt;the talk
recording illuminating&lt;/a&gt;.  It explains exactly what the source of
randomness is, if you are unable to spot it from the schema drawing
available from the ChaosKey web site linked at the start of this blog
post.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Detect OOXML files with undefined behaviour?</title>
                <link>http://people.skolelinux.org/pere/blog/Detect_OOXML_files_with_undefined_behaviour_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Detect_OOXML_files_with_undefined_behaviour_.html</guid>
                <pubDate>Tue, 21 Feb 2017 00:20:00 +0100</pubDate>
                <description>&lt;p&gt;I just noticed
&lt;a href=&quot;http://www.arkivrad.no/aktuelt/riksarkivarens-forskrift-pa-horing&quot;&gt;the
new Norwegian proposal for archiving rules in the goverment&lt;/a&gt; list
&lt;a href=&quot;http://www.ecma-international.org/publications/standards/Ecma-376.htm&quot;&gt;ECMA-376&lt;/a&gt;
/ ISO/IEC 29500 (aka OOXML) as valid formats to put in long term
storage.  Luckily such files will only be accepted based on
pre-approval from the National Archive.  Allowing OOXML files to be
used for long term storage might seem like a good idea as long as we
forget that there are plenty of ways for a &quot;valid&quot; OOXML document to
have content with no defined interpretation in the standard, which
lead to a question and an idea.&lt;/p&gt;

&lt;p&gt;Is there any tool to detect if a OOXML document depend on such
undefined behaviour?  It would be useful for the National Archive (and
anyone else interested in verifying that a document is well defined)
to have such tool available when considering to approve the use of
OOXML.  I&#39;m aware of the
&lt;a href=&quot;https://github.com/arlm/officeotron/&quot;&gt;officeotron OOXML
validator&lt;/a&gt;, but do not know how complete it is nor if it will
report use of undefined behaviour.  Are there other similar tools
available?  Please send me an email if you know of any such tool.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Ruling ignored our objections to the seizure of popcorn-time.no (#domstolkontroll)</title>
                <link>http://people.skolelinux.org/pere/blog/Ruling_ignored_our_objections_to_the_seizure_of_popcorn_time_no___domstolkontroll_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Ruling_ignored_our_objections_to_the_seizure_of_popcorn_time_no___domstolkontroll_.html</guid>
                <pubDate>Mon, 13 Feb 2017 21:30:00 +0100</pubDate>
                <description>&lt;p&gt;A few days ago, we received the ruling from
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/A_day_in_court_challenging_seizure_of_popcorn_time_no_for__domstolkontroll.html&quot;&gt;my
day in court&lt;/a&gt;.  The case in question is a challenge of the seizure
of the DNS domain popcorn-time.no.  The ruling simply did not mention
most of our arguments, and seemed to take everything ØKOKRIM said at
face value, ignoring our demonstration and explanations.  But it is
hard to tell for sure, as we still have not seen most of the documents
in the case and thus were unprepared and unable to contradict several
of the claims made in court by the opposition.  We are considering an
appeal, but it is partly a question of funding, as it is costing us
quite a bit to pay for our lawyer.  If you want to help, please
&lt;a href=&quot;http://www.nuug.no/dns-beslag-donasjon.shtml&quot;&gt;donate to the
NUUG defense fund&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;The details of the case, as far as we know it, is available in
Norwegian from
&lt;a href=&quot;https://www.nuug.no/news/tags/dns-domenebeslag/&quot;&gt;the NUUG
blog&lt;/a&gt;.  This also include
&lt;a href=&quot;https://www.nuug.no/news/Avslag_etter_rettslig_h_ring_om_DNS_beslaget___vurderer_veien_videre.shtml&quot;&gt;the
ruling itself&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>A day in court challenging seizure of popcorn-time.no for #domstolkontroll</title>
                <link>http://people.skolelinux.org/pere/blog/A_day_in_court_challenging_seizure_of_popcorn_time_no_for__domstolkontroll.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/A_day_in_court_challenging_seizure_of_popcorn_time_no_for__domstolkontroll.html</guid>
                <pubDate>Fri, 3 Feb 2017 11:10:00 +0100</pubDate>
                <description>&lt;p align=&quot;center&quot;&gt;&lt;img width=&quot;70%&quot; src=&quot;http://people.skolelinux.org/pere/blog/images/2017-02-01-popcorn-time-in-court.jpeg&quot;&gt;&lt;/p&gt;

&lt;p&gt;On Wednesday, I spent the entire day in court in Follo Tingrett
representing &lt;a href=&quot;https://www.nuug.no/&quot;&gt;the member association
NUUG&lt;/a&gt;, alongside &lt;a href=&quot;https://www.efn.no/&quot;&gt;the member
association EFN&lt;/a&gt; and &lt;a href=&quot;http://www.imc.no&quot;&gt;the DNS registrar
IMC&lt;/a&gt;, challenging the seizure of the DNS name popcorn-time.no.  It
was interesting to sit in a court of law for the first time in my
life.  Our team can be seen in the picture above: attorney Ola
Tellesbø, EFN board member Tom Fredrik Blenning, IMC CEO Morten Emil
Eriksen and NUUG board member Petter Reinholdtsen.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.domstol.no/no/Enkelt-domstol/follo-tingrett/Nar-gar-rettssaken/Beramming/?cid=AAAA1701301512081262234UJFBVEZZZZZEJBAvtale&quot;&gt;The
case at hand&lt;/a&gt; is that the Norwegian National Authority for
Investigation and Prosecution of Economic and Environmental Crime (aka
Økokrim) decided on their own, to seize a DNS domain early last
year, without following
&lt;a href=&quot;https://www.norid.no/no/regelverk/navnepolitikk/#link12&quot;&gt;the
official policy of the Norwegian DNS authority&lt;/a&gt; which require a
court decision.  The web site in question was a site covering Popcorn
Time.  And Popcorn Time is the name of a technology with both legal
and illegal applications.  Popcorn Time is a client combining
searching a Bittorrent directory available on the Internet with
downloading/distribute content via Bittorrent and playing the
downloaded content on screen.  It can be used illegally if it is used
to distribute content against the will of the right holder, but it can
also be used legally to play a lot of content, for example the
millions of movies
&lt;a href=&quot;https://archive.org/details/movies&quot;&gt;available from the
Internet Archive&lt;/a&gt; or the collection
&lt;a href=&quot;http://vodo.net/films/&quot;&gt;available from Vodo&lt;/a&gt;.  We created
&lt;a href=&quot;magnet:?xt=urn:btih:86c1802af5a667ca56d3918aecb7d3c0f7173084&amp;dn=PresentasjonFolloTingrett.mov&amp;tr=udp%3A%2F%2Fpublic.popcorn-tracker.org%3A6969%2Fannounce&quot;&gt;a
video demonstrating legally use of Popcorn Time&lt;/a&gt; and played it in
Court.  It can of course be downloaded using Bittorrent.&lt;/p&gt;

&lt;p&gt;I did not quite know what to expect from a day in court.  The
government held on to their version of the story and we held on to
ours, and I hope the judge is able to make sense of it all.  We will
know in two weeks time.  Unfortunately I do not have high hopes, as
the Government have the upper hand here with more knowledge about the
case, better training in handling criminal law and in general higher
standing in the courts than fairly unknown DNS registrar and member
associations.  It is expensive to be right also in Norway.  So far the
case have cost more than NOK 70 000,-.  To help fund the case, NUUG
and EFN have asked for donations, and managed to collect around NOK 25
000,- so far.  Given the presentation from the Government, I expect
the government to appeal if the case go our way.  And if the case do
not go our way, I hope we have enough funding to appeal.&lt;/p&gt;

&lt;p&gt;From the other side came two people from Økokrim.  On the benches,
appearing to be part of the group from the government were two people
from the Simonsen Vogt Wiik lawyer office, and three others I am not
quite sure who was.  Økokrim had proposed to present two witnesses
from The Motion Picture Association, but this was rejected because
they did not speak Norwegian and it was a bit late to bring in a
translator, but perhaps the two from MPA were present anyway.  All
seven appeared to know each other.  Good to see the case is take
seriously.&lt;/p&gt;

&lt;p&gt;If you, like me, believe the courts should be involved before a DNS
domain is hijacked by the government, or you believe the Popcorn Time
technology have a lot of useful and legal applications, I suggest you
too &lt;a href=&quot;http://www.nuug.no/dns-beslag-donasjon.shtml&quot;&gt;donate to
the NUUG defense fund&lt;/a&gt;.  Both Bitcoin and bank transfer are
available. If NUUG get more than we need for the legal action (very
unlikely), the rest will be spend promoting free software, open
standards and unix-like operating systems in Norway, so no matter what
happens the money will be put to good use.&lt;/p&gt;

&lt;p&gt;If you want to lean more about the case, I recommend you check out
&lt;a href=&quot;https://www.nuug.no/news/tags/dns-domenebeslag/&quot;&gt;the blog
posts from NUUG covering the case&lt;/a&gt;.  They cover the legal arguments
on both sides.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Nasjonalbiblioteket avslutter sin ulovlige bruk av Google Skjemaer</title>
                <link>http://people.skolelinux.org/pere/blog/Nasjonalbiblioteket_avslutter_sin_ulovlige_bruk_av_Google_Skjemaer.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/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>http://people.skolelinux.org/pere/blog/Bryter_NAV_sin_egen_personvernerkl_ring_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/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;http://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>http://people.skolelinux.org/pere/blog/Where_did_that_package_go___mdash__geolocated_IP_traceroute.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/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;http://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;http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-scapy.svg&quot;&gt;&lt;img
src=&quot;http://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;http://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;http://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;http://people.skolelinux.org/pere/blog/images/2017-01-09-www.stortinget.no-geotraceroute-kml-join.kml&quot;&gt;&lt;img
src=&quot;http://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&amp;label=PetterReinholdtsenBlog&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>