Petter Reinholdtsen

The Coz profiler, a nice profiler able to run benchmarking experiments on the instrumented multi-threaded program, finally made it into Debian unstable yesterday. Lluís Vilanova and I have spent many months since I blogged about the coz tool in August working with upstream to make it suitable for Debian. There are still issues with clang compatibility, inline assembly only working x86 and minimized JavaScript libraries.

To test it, install 'coz-profiler' using apt and run it like this:

coz run --- /path/to/binary-with-debug-info

This will produce a profile.coz file in the current working directory with the profiling information. This is then given to a JavaScript application provided in the package and available from a project web page. To start the local copy, invoke it in a browser like this:

sensible-browser /usr/share/coz-profiler/viewer/index.htm

See the project home page and the USENIX ;login: article on Coz for more information on how it is working.

A few days ago I ran a very biased and informal survey to get an idea about what options are being used to communicate with end to end encryption with friends and family. I explicitly asked people not to list options only used in a work setting. The background is the uneasy feeling I get when using Signal, a feeling shared by others as a blog post from Sander Venima about why he do not recommend Signal anymore (with feedback from the Signal author available from ycombinator). I wanted an overview of the options being used, and hope to include those options in a less biased survey later on. So far I have not taken the time to look into the individual proposed systems. They range from text sharing web pages, via file sharing and email to instant messaging, VOIP and video conferencing. For those considering which system to use, it is also useful to have a look at the EFF Secure messaging scorecard which is slightly out of date but still provide valuable information.

So, on to the list. There were some used by many, some used by a few, some rarely used ones and a few mentioned but without anyone claiming to use them. Notice the grouping is in reality quite random given the biased self selected set of participants. First the ones used by many:

• Signal
• Email w/OpenPGP (Enigmail, GPGSuite,etc)
• Whatsapp
• IRC w/OTR
• XMPP w/OTR

Then the ones used by a few.

• Mumble
• iMessage (included in iOS from Apple)
• Telegram
• Jitsi
• Keybase file

Then the ones used by even fewer people

• Ring
• Bitmessage
• Wire
• VoIP w/ZRTP or controlled SRTP (e.g using CSipSimple, Linphone)
• Matrix
• Kontalk
• 0bin (encrypted pastebin)
• Appear.in
• riot
• Wickr Me

And finally the ones mentioned by not marked as used by anyone. This might be a mistake, perhaps the person adding the entry forgot to flag it as used?

• Email w/Certificates S/MIME
• Crypho
• CryptPad
• ricochet

Given the network effect it seem obvious to me that we as a society have been divided and conquered by those interested in keeping encrypted and secure communication away from the masses. The finishing remarks from Aral Balkan in his talk "Free is a lie" about the usability of free software really come into effect when you want to communicate in private with your friends and family. We can not expect them to allow the usability of communication tool to block their ability to talk to their loved ones.

Note for example the option IRC w/OTR. Most IRC clients do not have OTR support, so in most cases OTR would not be an option, even if you wanted to. In my personal experience, about 1 in 20 I talk to have a IRC client with OTR. For private communication to really be available, most people to talk to must have the option in their currently used client. I can not simply ask my family to install an IRC client. I need to guide them through a technical multi-step process of adding extensions to the client to get them going. This is a non-starter for most.

I would like to be able to do video phone calls, audio phone calls, exchange instant messages and share files with my loved ones, without being forced to share with people I do not know. I do not want to share the content of the conversations, and I do not want to share who I communicate with or the fact that I communicate with someone. Without all these factors in place, my private life is being more or less invaded.

A while back I received a Gyro sensor for the NXT Mindstorms controller as a birthday present. It had been on my wishlist for a while, because I wanted to build a Segway like balancing lego robot. I had already built a simple balancing robot with the kids, using the light/color sensor included in the NXT kit as the balance sensor, but it was not working very well. It could balance for a while, but was very sensitive to the light condition in the room and the reflective properties of the surface and would fall over after a short while. I wanted something more robust, and had the gyro sensor from HiTechnic I believed would solve it on my wishlist for some years before it suddenly showed up as a gift from my loved ones. :)

Unfortunately I have not had time to sit down and play with it since then. But that changed some days ago, when I was searching for lego segway information and came across a recipe from HiTechnic for building the HTWay, a segway like balancing robot. Build instructions and source code was included, so it was just a question of putting it all together. And thanks to the great work of many Debian developers, the compiler needed to build the source for the NXT is already included in Debian, so I was read to go in less than an hour. The resulting robot do not look very impressive in its simplicity:

Because I lack the infrared sensor used to control the robot in the design from HiTechnic, I had to comment out the last task (taskControl). I simply placed /* and */ around it get the program working without that sensor present. Now it balances just fine until the battery status run low:

Now we would like to teach it how to follow a line and take remote control instructions using the included Bluetooth receiver in the NXT.

If you, like me, love LEGO and want to make sure we find the tools they need to work with LEGO in Debian and all our derivative distributions like Ubuntu, check out the LEGO designers project page and join the Debian LEGO team. Personally I own a RCX and NXT controller (no EV3), and would like to make sure the Debian tools needed to program the systems I own work as they should.

Jeg ble så imponert over dagens gladnyhet på NRK, om at Forbrukerrådet klager inn vilkårene for bruk av aktivitetsbånd fra Fitbit, Garmin, Jawbone og Mio til Datatilsynet og forbrukerombudet, at jeg sendte følgende brev til forbrukerrådet for å uttrykke min støtte:

Jeg ble veldig glad over å lese at Forbrukerrådet klager inn flere aktivitetsbånd til Datatilsynet for dårlige vilkår. Jeg har ønsket meg et aktivitetsbånd som kan måle puls, bevegelse og gjerne også andre helserelaterte indikatorer en stund nå. De eneste jeg har funnet i salg gjør, som dere også har oppdaget, graverende inngrep i privatsfæren og sender informasjonen ut av huset til folk og organisasjoner jeg ikke ønsker å dele aktivitets- og helseinformasjon med. Jeg ønsker et alternativ som ikke sender informasjon til skyen, men derimot bruker en fritt og åpent standardisert protokoll (eller i det minste en dokumentert protokoll uten patent- og opphavsrettslige bruksbegrensinger) til å kommunisere med datautstyr jeg kontrollerer. Er jo ikke interessert i å betale noen for å tilrøve seg personopplysninger fra meg. Desverre har jeg ikke funnet noe alternativ så langt.

Det holder ikke å endre på bruksvilkårene for enhetene, slik Datatilsynet ofte legger opp til i sin behandling, når de gjør slik f.eks. Fitbit (den jeg har sett mest på). Fitbit krypterer informasjonen på enheten og sender den kryptert til leverandøren. Det gjør det i praksis umulig både å sjekke hva slags informasjon som sendes over, og umulig å ta imot informasjonen selv i stedet for Fitbit. Uansett hva slags historie som forteller i bruksvilkårene er en jo både prisgitt leverandørens godvilje og at de ikke tvinges av sitt lands myndigheter til å lyve til sine kunder om hvorvidt personopplysninger spres ut over det bruksvilkårene sier. Det er veldokumentert hvordan f.eks. USA tvinger selskaper vha. såkalte National security letters til å utlevere personopplysninger samtidig som de ikke får lov til å fortelle dette til kundene sine.

Stå på, jeg er veldig glade for at dere har sett på saken. Vet dere om aktivitetsbånd i salg i dag som ikke tvinger en til å utlevere aktivitets- og helseopplysninger med leverandøren?

Jeg håper en konkurrent som respekterer kundenes privatliv klarer å nå opp i markedet, slik at det finnes et reelt alternativ for oss som har full tillit til at skyleverandører vil prioritere egen inntjening og myndighetspålegg langt foran kundenes rett til privatliv. Jeg har ingen tiltro til at Datatilsynet vil kreve noe mer enn at vilkårene endres slik at de forklarer eksplisitt i hvor stor grad bruk av produktene utraderer privatsfæren til kundene. Det vil nok gjøre de innklagede armbåndene «lovlige», men fortsatt tvinge kundene til å dele sine personopplysninger med leverandøren.

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. Modify the source code using command listed in the the patch block below.
3. Start Signal using the run-signal-app wrapper (for example using `pwd`/run-signal-app).
4. 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.
5. 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.

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.

NRK lanserte for noen uker siden en ny varslerportal som bruker SecureDrop til å ta imot tips der det er vesentlig at ingen utenforstående får vite at NRK er tipset. Det er et langt steg fremover for NRK, og når en leser bloggposten om hva de har tenkt på og hvordan løsningen er satt opp virker det som om de har gjort en grundig jobb der. Men det er ganske mye ekstra jobb å motta tips via SecureDrop, så varslersiden skriver "Nyhetstips som ikke krever denne typen ekstra vern vil vi gjerne ha på nrk.no/03030", og 03030-siden foreslår i tillegg til et webskjema å bruke epost, SMS, telefon, personlig oppmøte og brevpost. Denne artikkelen handler disse andre metodene.

Når en sender epost til en @nrk.no-adresse så vil eposten sendes ut av landet til datamaskiner kontrollert av Microsoft. En kan sjekke dette selv ved å slå opp epostleveringsadresse (MX) i DNS. For NRK er dette i dag "nrk-no.mail.protection.outlook.com". NRK har som en ser valgt å sette bort epostmottaket sitt til de som står bak outlook.com, dvs. Microsoft. En kan sjekke hvor nettverkstrafikken tar veien gjennom Internett til epostmottaket vha. programmet traceroute, og finne ut hvem som eier en Internett-adresse vha. whois-systemet. Når en gjør dette for epost-trafikk til @nrk.no ser en at trafikken fra Norge mot nrk-no.mail.protection.outlook.com går via Sverige mot enten Irland eller Tyskland (det varierer fra gang til gang og kan endre seg over tid).

Vi vet fra introduksjonen av FRA-loven at IP-trafikk som passerer grensen til Sverige avlyttes av Försvarets radioanstalt (FRA). Vi vet videre takket være Snowden-bekreftelsene at trafikk som passerer grensen til Storbritannia avlyttes av Government Communications Headquarters (GCHQ). I tillegg er er det nettopp lansert et forslag i Norge om at forsvarets E-tjeneste skal få avlytte trafikk som krysser grensen til Norge. Jeg er ikke kjent med dokumentasjon på at Irland og Tyskland gjør det samme. Poenget er uansett at utenlandsk etterretning har mulighet til å snappe opp trafikken når en sender epost til @nrk.no. I tillegg er det selvsagt tilgjengelig for Microsoft som er underlagt USAs jurisdiksjon og samarbeider med USAs etterretning på flere områder. De som tipser NRK om nyheter via epost kan dermed gå ut fra at det blir kjent for mange andre enn NRK at det er gjort.

Bruk av SMS og telefon registreres av blant annet telefonselskapene og er tilgjengelig i følge lov og forskrift for blant annet Politi, NAV og Finanstilsynet, i tillegg til IT-folkene hos telefonselskapene og deres overordnede. Hvis innringer eller mottaker bruker smarttelefon vil slik kontakt også gjøres tilgjengelig for ulike app-leverandører og de som lytter på trafikken mellom telefon og app-leverandør, alt etter hva som er installert på telefonene som brukes.

Brevpost kan virke trygt, og jeg vet ikke hvor mye som registreres og lagres av postens datastyrte postsorteringssentraler. Det vil ikke overraske meg om det lagres hvor i landet hver konvolutt kommer fra og hvor den er adressert, i hvert fall for en kortere periode. Jeg vet heller ikke hvem slik informasjon gjøres tilgjengelig for. Det kan være nok til å ringe inn potensielle kilder når det krysses med hvem som kjente til aktuell informasjon og hvor de befant seg (tilgjengelig f.eks. hvis de bærer mobiltelefon eller bor i nærheten).

Personlig oppmøte hos en NRK-journalist er antagelig det tryggeste, men en bør passe seg for å bruke NRK-kantina. Der bryter de nemlig Sentralbanklovens paragraf 14 og nekter folk å betale med kontanter. I stedet krever de at en varsle sin bankkortutsteder om hvor en befinner seg ved å bruke bankkort. Banktransaksjoner er tilgjengelig for bankkortutsteder (det være seg VISA, Mastercard, Nets og/eller en bank) i tillegg til politiet og i hvert fall tidligere med Se & Hør (via utro tjenere, slik det ble avslørt etter utgivelsen av boken «Livet, det forbannede» av Ken B. Rasmussen). Men hvor mange kjenner en NRK-journalist personlig? Besøk på NRK på Marienlyst krever at en registrerer sin ankost elektronisk i besøkssystemet. Jeg vet ikke hva som skjer med det datasettet, men har grunn til å tro at det sendes ut SMS til den en skal besøke med navnet som er oppgitt. Kanskje greit å oppgi falskt navn.

Når så tipset er kommet frem til NRK skal det behandles redaksjonelt i NRK. Der vet jeg via ulike kilder at de fleste journalistene bruker lokalt installert programvare, men noen bruker Google Docs og andre skytjenester i strid med interne retningslinjer når de skriver. Hvordan vet en hvem det gjelder? Ikke vet jeg, men det kan være greit å spørre for å sjekke at journalisten har tenkt på problemstillingen, før en gir et tips. Og hvis tipset omtales internt på epost, er det jo grunn til å tro at også intern eposten vil deles med Microsoft og utenlands etterretning, slik tidligere nevnt, men det kan hende at det holdes internt i NRKs interne MS Exchange-løsning. Men Microsoft ønsker å få alle Exchange-kunder over "i skyen" (eller andre folks datamaskiner, som det jo innebærer), så jeg vet ikke hvor lenge det i så fall vil vare.

I tillegg vet en jo at NRK har valgt å gi nasjonal sikkerhetsmyndighet (NSM) tilgang til å se på intern og ekstern Internett-trafikk hos NRK ved oppsett av såkalte VDI-noder, på tross av protester fra NRKs journalistlag. Jeg vet ikke om den vil kunne snappe opp dokumenter som lagres på interne filtjenere eller dokumenter som lages i de interne webbaserte publiseringssystemene, men vet at hva noden ser etter på nettet kontrolleres av NSM og oppdateres automatisk, slik at det ikke gir så mye mening å sjekke hva noden ser etter i dag når det kan endres automatisk i morgen.

Personlig vet jeg ikke om jeg hadde turt tipse NRK hvis jeg satt på noe som kunne være en trussel mot den bestående makten i Norge eller verden. Til det virker det å være for mange åpninger for utenforstående med andre prioriteter enn NRKs journalistiske fokus. Og den største truslen for en varsler er jo om metainformasjon kommer på avveie, dvs. informasjon om at en har vært i kontakt med en journalist. Det kan være nok til at en kommer i myndighetenes søkelys, og de færreste har nok operasjonell sikkerhet til at vil tåle slik flombelysning på sitt privatliv.

The Isenkram system provide a practical and easy way to figure out which packages support the hardware in a given machine. The command line tool isenkram-lookup and the tasksel options provide a convenient way to list and install packages relevant for the current hardware during system installation, both user space packages and firmware packages. The GUI background daemon on the other hand provide a pop-up proposing to install packages when a new dongle is inserted while using the computer. For example, if you plug in a smart card reader, the system will ask if you want to install pcscd if that package isn't already installed, and if you plug in a USB video camera the system will ask if you want to install cheese if cheese is currently missing. This already work just fine.

But Isenkram depend on a database mapping from hardware IDs to package names. When I started no such database existed in Debian, so I made my own data set and included it with the isenkram package and made isenkram fetch the latest version of this database from git using http. This way the isenkram users would get updated package proposals as soon as I learned more about hardware related packages.

The hardware is identified using modalias strings. The modalias design is from the Linux kernel where most hardware descriptors are made available as a strings that can be matched using filename style globbing. It handle USB, PCI, DMI and a lot of other hardware related identifiers.

The downside to the Isenkram specific database is that there is no information about relevant distribution / Debian version, making isenkram propose obsolete packages too. But along came AppStream, a cross distribution mechanism to store and collect metadata about software packages. When I heard about the proposal, I contacted the people involved and suggested to add a hardware matching rule using modalias strings in the specification, to be able to use AppStream for mapping hardware to packages. This idea was accepted and AppStream is now a great way for a package to announce the hardware it support in a distribution neutral way. I wrote a recipe on how to add such meta-information in a blog post last December. If you have a hardware related package in Debian, please announce the relevant hardware IDs using AppStream.

In Debian, almost all packages that can talk to a LEGO Mindestorms RCX or NXT unit, announce this support using AppStream. The effect is that when you insert such LEGO robot controller into your Debian machine, Isenkram will propose to install the packages needed to get it working. The intention is that this should allow the local user to start programming his robot controller right away without having to guess what packages to use or which permissions to fix.

But when I sat down with my son the other day to program our NXT unit using his Debian Stretch computer, I discovered something annoying. The local console user (ie my son) did not get access to the USB device for programming the unit. This used to work, but no longer in Jessie and Stretch. After some investigation and asking around on #debian-devel, I discovered that this was because udev had changed the mechanism used to grant access to local devices. The ConsoleKit mechanism from /lib/udev/rules.d/70-udev-acl.rules no longer applied, because LDAP users no longer was added to the plugdev group during login. Michael Biebl told me that this method was obsolete and the new method used ACLs instead. This was good news, as the plugdev mechanism is a mess when using a remote user directory like LDAP. Using ACLs would make sure a user lost device access when she logged out, even if the user left behind a background process which would retain the plugdev membership with the ConsoleKit setup. Armed with this knowledge I moved on to fix the access problem for the LEGO Mindstorms related packages.

The new system uses a udev tag, 'uaccess'. It can either be applied directly for a device, or is applied in /lib/udev/rules.d/70-uaccess.rules for classes of devices. As the LEGO Mindstorms udev rules did not have a class, I decided to add the tag directly in the udev rules files included in the packages. Here is one example. For the nqc C compiler for the RCX, the /lib/udev/rules.d/60-nqc.rules file now look like this:

SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0694", ATTR{idProduct}=="0001", \
    SYMLINK+="rcx-%k", TAG+="uaccess"

The key part is the 'TAG+="uaccess"' at the end. I suspect all packages using plugdev in their /lib/udev/rules.d/ files should be changed to use this tag (either directly or indirectly via 70-uaccess.rules). Perhaps a lintian check should be created to detect this?

I've been unable to find good documentation on the uaccess feature. It is unclear to me if the uaccess tag is an internal implementation detail like the udev-acl tag used by /lib/udev/rules.d/70-udev-acl.rules. If it is, I guess the indirect method is the preferred way. Michael asked for more documentation from the systemd project and I hope it will make this clearer. For now I use the generic classes when they exist and is already handled by 70-uaccess.rules, and add the tag directly if no such class exist.

To learn more about the isenkram system, please check out my blog posts tagged isenkram.

To help out making life for LEGO constructors in Debian easier, please join us on our IRC channel #debian-lego and join the Debian LEGO team in the Alioth project we created yesterday. A mailing list is not yet created, but we are working on it. :)

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

En av dagens nyheter er at Aftenpostens redaktør Espen Egil Hansen bruker forsiden av papiravisen på et åpent brev til Facebooks sjef Mark Zuckerberg om Facebooks fjerning av bilder, tekster og sider de ikke liker. Det må være uvant for redaktøren i avisen Aftenposten å stå med lua i handa og håpe på å bli hørt. Spesielt siden Aftenposten har vært med på å gi Facebook makten de nå demonstrerer at de har. Ved å melde seg inn i Facebook-samfunnet har de sagt ja til bruksvilkårene og inngått en antagelig bindende avtale. Kanskje de skulle lest og vurdert vilkårene litt nærmere før de sa ja, i stedet for å klage over at reglende de har valgt å akseptere blir fulgt? Personlig synes jeg vilkårene er uakseptable og det ville ikke falle meg inn å gå inn på en avtale med slike vilkår. I tillegg til uakseptable vilkår er det mange andre grunner til å unngå Facebook. Du kan finne en solid gjennomgang av flere slike argumenter hos Richard Stallmans side om Facebook.

Jeg håper flere norske redaktører på samme vis må stå med lua i hånden inntil de forstår at de selv er med på å føre samfunnet på ville veier ved å omfavne Facebook slik de gjør når de omtaler og løfter frem saker fra Facebook, og tar i bruk Facebook som distribusjonskanal for sine nyheter. De bidrar til overvåkningssamfunnet og raderer ut lesernes privatsfære når de lenker til Facebook på sine sider, og låser seg selv inne i en omgivelse der det er Facebook, og ikke redaktøren, som sitter med makta.

Men det vil nok ta tid, i et Norge der de fleste nettredaktører deler sine leseres personopplysinger med utenlands etterretning.

For øvrig burde varsleren Edward Snowden få politisk asyl i Norge.

I helga kom det et hårreisende forslag fra Lysne II-utvalget satt ned av Forsvarsdepartementet. Lysne II-utvalget var bedt om å vurdere ønskelista til Forsvarets etterretningstjeneste (e-tjenesten), og har kommet med forslag om at e-tjenesten skal få lov til a avlytte all Internett-trafikk som passerer Norges grenser. Få er klar over at dette innebærer at e-tjenesten får tilgang til epost sendt til de fleste politiske partiene på Stortinget. Regjeringspartiet Høyre (@hoyre.no), støttepartiene Venstre (@venstre.no) og Kristelig Folkeparti (@krf.no) samt Sosialistisk Ventreparti (@sv.no) og Miljøpartiet de grønne (@mdg.no) har nemlig alle valgt å ta imot eposten sin via utenlandske tjenester. Det betyr at hvis noen sender epost til noen med en slik adresse vil innholdet i eposten, om dette forslaget blir vedtatt, gjøres tilgjengelig for e-tjenesten. Venstre, Sosialistisk Ventreparti og Miljøpartiet De Grønne har valgt å motta sin epost hos Google, Kristelig Folkeparti har valgt å motta sin epost hos Microsoft, og Høyre har valgt å motta sin epost hos Comendo med mottak i Danmark og Irland. Kun Arbeiderpartiet og Fremskrittspartiet har valgt å motta eposten sin i Norge, hos henholdsvis Intility AS og Telecomputing AS.

Konsekvensen er at epost inn og ut av de politiske organisasjonene, til og fra partimedlemmer og partiets tillitsvalgte vil gjøres tilgjengelig for e-tjenesten for analyse og sortering. Jeg mistenker at kunnskapen som slik blir tilgjengelig vil være nyttig hvis en ønsker å vite hvilke argumenter som treffer publikum når en ønsker å påvirke Stortingets representanter.

Ved hjelp av MX-oppslag i DNS for epost-domene, tilhørende whois-oppslag av IP-adressene og traceroute for å se hvorvidt trafikken går via utlandet kan enhver få bekreftet at epost sendt til de omtalte partiene vil gjøres tilgjengelig for forsvarets etterretningstjeneste hvis forslaget blir vedtatt. En kan også bruke den kjekke nett-tjenesten ipinfo.io for å få en ide om hvor i verden en IP-adresse hører til.

På den positive siden vil forslaget gjøre at enda flere blir motivert til å ta grep for å bruke Tor og krypterte kommunikasjonsløsninger for å kommunisere med sine kjære, for å sikre at privatsfæren vernes. Selv bruker jeg blant annet FreedomBox og Signal til slikt. Ingen av dem er optimale, men de fungerer ganske bra allerede og øker kostnaden for dem som ønsker å invadere mitt privatliv.

For øvrig burde varsleren Edward Snowden få politisk asyl i Norge.

In April we started to work on a Norwegian Bokmål edition of the "open access" book on how to set up and administrate a Debian system. Today I am happy to report that the first draft is now publicly available. You can find it on get the Debian Administrator's Handbook page (under Other languages). The first eight chapters have a first draft translation, and we are working on proofreading the content. If you want to help out, please start contributing using the hosted weblate project page, and get in touch using the translators mailing list. Please also check out the instructions for contributors. A good way to contribute is to proofread the text and update weblate if you find errors.

Our goal is still to make the Norwegian book available on paper as well as electronic form.