Petter Reinholdtsen

Entries tagged "surveillance".

New and improved sqlcipher in Debian for accessing Signal database
12th November 2023

For a while now I wanted to have direct access to the Signal database of messages and channels of my Desktop edition of Signal. I prefer the enforced end to end encryption of Signal these days for my communication with friends and family, to increase the level of safety and privacy as well as raising the cost of the mass surveillance government and non-government entities practice these days. In August I came across a nice recipe on how to use sqlcipher to extract statistics from the Signal database explaining how to do this. Unfortunately this did not work with the version of sqlcipher in Debian. The sqlcipher package is a "fork" of the sqlite package with added support for encrypted databases. Sadly the current Debian maintainer announced more than three years ago that he did not have time to maintain sqlcipher, so it seemed unlikely to be upgraded by the maintainer. I was reluctant to take on the job myself, as I have very limited experience maintaining shared libraries in Debian. After waiting and hoping for a few months, I gave up the last week, and set out to update the package. In the process I orphaned it to make it more obvious for the next person looking at it that the package need proper maintenance.

The version in Debian was around five years old, and quite a lot of changes had taken place upstream into the Debian maintenance git repository. After spending a few days importing the new upstream versions, realising that upstream did not care much for SONAME versioning as I saw library symbols being both added and removed with minor version number changes to the project, I concluded that I had to do a SONAME bump of the library package to avoid surprising the reverse dependencies. I even added a simple autopkgtest script to ensure the package work as intended. Dug deep into the hole of learning shared library maintenance, I set out a few days ago to upload the new version to Debian experimental to see what the quality assurance framework in Debian had to say about the result. The feedback told me the pacakge was not too shabby, and yesterday I uploaded the latest version to Debian unstable. It should enter testing today or tomorrow, perhaps delayed by a small library transition.

Armed with a new version of sqlcipher, I can now have a look at the SQL database in ~/.config/Signal/sql/db.sqlite. First, one need to fetch the encryption key from the Signal configuration using this simple JSON extraction command:

/usr/bin/jq -r '."key"' ~/.config/Signal/config.json

Assuming the result from that command is 'secretkey', which is a hexadecimal number representing the key used to encrypt the database. Next, one can now connect to the database and inject the encryption key for access via SQL to fetch information from the database. Here is an example dumping the database structure:

% sqlcipher ~/.config/Signal/sql/db.sqlite
sqlite> PRAGMA key = "x'secretkey'";
sqlite> .schema
CREATE TABLE sqlite_stat1(tbl,idx,stat);
CREATE TABLE conversations(
      id STRING PRIMARY KEY ASC,
      json TEXT,

      active_at INTEGER,
      type STRING,
      members TEXT,
      name TEXT,
      profileName TEXT
    , profileFamilyName TEXT, profileFullName TEXT, e164 TEXT, serviceId TEXT, groupId TEXT, profileLastFetchedAt INTEGER);
CREATE TABLE identityKeys(
      id STRING PRIMARY KEY ASC,
      json TEXT
    );
CREATE TABLE items(
      id STRING PRIMARY KEY ASC,
      json TEXT
    );
CREATE TABLE sessions(
      id TEXT PRIMARY KEY,
      conversationId TEXT,
      json TEXT
    , ourServiceId STRING, serviceId STRING);
CREATE TABLE attachment_downloads(
    id STRING primary key,
    timestamp INTEGER,
    pending INTEGER,
    json TEXT
  );
CREATE TABLE sticker_packs(
    id TEXT PRIMARY KEY,
    key TEXT NOT NULL,

    author STRING,
    coverStickerId INTEGER,
    createdAt INTEGER,
    downloadAttempts INTEGER,
    installedAt INTEGER,
    lastUsed INTEGER,
    status STRING,
    stickerCount INTEGER,
    title STRING
  , attemptedStatus STRING, position INTEGER DEFAULT 0 NOT NULL, storageID STRING, storageVersion INTEGER, storageUnknownFields BLOB, storageNeedsSync
      INTEGER DEFAULT 0 NOT NULL);
CREATE TABLE stickers(
    id INTEGER NOT NULL,
    packId TEXT NOT NULL,

    emoji STRING,
    height INTEGER,
    isCoverOnly INTEGER,
    lastUsed INTEGER,
    path STRING,
    width INTEGER,

    PRIMARY KEY (id, packId),
    CONSTRAINT stickers_fk
      FOREIGN KEY (packId)
      REFERENCES sticker_packs(id)
      ON DELETE CASCADE
  );
CREATE TABLE sticker_references(
    messageId STRING,
    packId TEXT,
    CONSTRAINT sticker_references_fk
      FOREIGN KEY(packId)
      REFERENCES sticker_packs(id)
      ON DELETE CASCADE
  );
CREATE TABLE emojis(
    shortName TEXT PRIMARY KEY,
    lastUsage INTEGER
  );
CREATE TABLE messages(
        rowid INTEGER PRIMARY KEY ASC,
        id STRING UNIQUE,
        json TEXT,
        readStatus INTEGER,
        expires_at INTEGER,
        sent_at INTEGER,
        schemaVersion INTEGER,
        conversationId STRING,
        received_at INTEGER,
        source STRING,
        hasAttachments INTEGER,
        hasFileAttachments INTEGER,
        hasVisualMediaAttachments INTEGER,
        expireTimer INTEGER,
        expirationStartTimestamp INTEGER,
        type STRING,
        body TEXT,
        messageTimer INTEGER,
        messageTimerStart INTEGER,
        messageTimerExpiresAt INTEGER,
        isErased INTEGER,
        isViewOnce INTEGER,
        sourceServiceId TEXT, serverGuid STRING NULL, sourceDevice INTEGER, storyId STRING, isStory INTEGER
        GENERATED ALWAYS AS (type IS 'story'), isChangeCreatedByUs INTEGER NOT NULL DEFAULT 0, isTimerChangeFromSync INTEGER
        GENERATED ALWAYS AS (
          json_extract(json, '$.expirationTimerUpdate.fromSync') IS 1
        ), seenStatus NUMBER default 0, storyDistributionListId STRING, expiresAt INT
        GENERATED ALWAYS
        AS (ifnull(
          expirationStartTimestamp + (expireTimer * 1000),
          9007199254740991
        )), shouldAffectActivity INTEGER
        GENERATED ALWAYS AS (
          type IS NULL
          OR
          type NOT IN (
            'change-number-notification',
            'contact-removed-notification',
            'conversation-merge',
            'group-v1-migration',
            'keychange',
            'message-history-unsynced',
            'profile-change',
            'story',
            'universal-timer-notification',
            'verified-change'
          )
        ), shouldAffectPreview INTEGER
        GENERATED ALWAYS AS (
          type IS NULL
          OR
          type NOT IN (
            'change-number-notification',
            'contact-removed-notification',
            'conversation-merge',
            'group-v1-migration',
            'keychange',
            'message-history-unsynced',
            'profile-change',
            'story',
            'universal-timer-notification',
            'verified-change'
          )
        ), isUserInitiatedMessage INTEGER
        GENERATED ALWAYS AS (
          type IS NULL
          OR
          type NOT IN (
            'change-number-notification',
            'contact-removed-notification',
            'conversation-merge',
            'group-v1-migration',
            'group-v2-change',
            'keychange',
            'message-history-unsynced',
            'profile-change',
            'story',
            'universal-timer-notification',
            'verified-change'
          )
        ), mentionsMe INTEGER NOT NULL DEFAULT 0, isGroupLeaveEvent INTEGER
        GENERATED ALWAYS AS (
          type IS 'group-v2-change' AND
          json_array_length(json_extract(json, '$.groupV2Change.details')) IS 1 AND
          json_extract(json, '$.groupV2Change.details[0].type') IS 'member-remove' AND
          json_extract(json, '$.groupV2Change.from') IS NOT NULL AND
          json_extract(json, '$.groupV2Change.from') IS json_extract(json, '$.groupV2Change.details[0].aci')
        ), isGroupLeaveEventFromOther INTEGER
        GENERATED ALWAYS AS (
          isGroupLeaveEvent IS 1
          AND
          isChangeCreatedByUs IS 0
        ), callId TEXT
        GENERATED ALWAYS AS (
          json_extract(json, '$.callId')
        ));
CREATE TABLE sqlite_stat4(tbl,idx,neq,nlt,ndlt,sample);
CREATE TABLE jobs(
        id TEXT PRIMARY KEY,
        queueType TEXT STRING NOT NULL,
        timestamp INTEGER NOT NULL,
        data STRING TEXT
      );
CREATE TABLE reactions(
        conversationId STRING,
        emoji STRING,
        fromId STRING,
        messageReceivedAt INTEGER,
        targetAuthorAci STRING,
        targetTimestamp INTEGER,
        unread INTEGER
      , messageId STRING);
CREATE TABLE senderKeys(
        id TEXT PRIMARY KEY NOT NULL,
        senderId TEXT NOT NULL,
        distributionId TEXT NOT NULL,
        data BLOB NOT NULL,
        lastUpdatedDate NUMBER NOT NULL
      );
CREATE TABLE unprocessed(
        id STRING PRIMARY KEY ASC,
        timestamp INTEGER,
        version INTEGER,
        attempts INTEGER,
        envelope TEXT,
        decrypted TEXT,
        source TEXT,
        serverTimestamp INTEGER,
        sourceServiceId STRING
      , serverGuid STRING NULL, sourceDevice INTEGER, receivedAtCounter INTEGER, urgent INTEGER, story INTEGER);
CREATE TABLE sendLogPayloads(
        id INTEGER PRIMARY KEY ASC,

        timestamp INTEGER NOT NULL,
        contentHint INTEGER NOT NULL,
        proto BLOB NOT NULL
      , urgent INTEGER, hasPniSignatureMessage INTEGER DEFAULT 0 NOT NULL);
CREATE TABLE sendLogRecipients(
        payloadId INTEGER NOT NULL,

        recipientServiceId STRING NOT NULL,
        deviceId INTEGER NOT NULL,

        PRIMARY KEY (payloadId, recipientServiceId, deviceId),

        CONSTRAINT sendLogRecipientsForeignKey
          FOREIGN KEY (payloadId)
          REFERENCES sendLogPayloads(id)
          ON DELETE CASCADE
      );
CREATE TABLE sendLogMessageIds(
        payloadId INTEGER NOT NULL,

        messageId STRING NOT NULL,

        PRIMARY KEY (payloadId, messageId),

        CONSTRAINT sendLogMessageIdsForeignKey
          FOREIGN KEY (payloadId)
          REFERENCES sendLogPayloads(id)
          ON DELETE CASCADE
      );
CREATE TABLE preKeys(
        id STRING PRIMARY KEY ASC,
        json TEXT
      , ourServiceId NUMBER
        GENERATED ALWAYS AS (json_extract(json, '$.ourServiceId')));
CREATE TABLE signedPreKeys(
        id STRING PRIMARY KEY ASC,
        json TEXT
      , ourServiceId NUMBER
        GENERATED ALWAYS AS (json_extract(json, '$.ourServiceId')));
CREATE TABLE badges(
        id TEXT PRIMARY KEY,
        category TEXT NOT NULL,
        name TEXT NOT NULL,
        descriptionTemplate TEXT NOT NULL
      );
CREATE TABLE badgeImageFiles(
        badgeId TEXT REFERENCES badges(id)
          ON DELETE CASCADE
          ON UPDATE CASCADE,
        'order' INTEGER NOT NULL,
        url TEXT NOT NULL,
        localPath TEXT,
        theme TEXT NOT NULL
      );
CREATE TABLE storyReads (
        authorId STRING NOT NULL,
        conversationId STRING NOT NULL,
        storyId STRING NOT NULL,
        storyReadDate NUMBER NOT NULL,

        PRIMARY KEY (authorId, storyId)
      );
CREATE TABLE storyDistributions(
        id STRING PRIMARY KEY NOT NULL,
        name TEXT,

        senderKeyInfoJson STRING
      , deletedAtTimestamp INTEGER, allowsReplies INTEGER, isBlockList INTEGER, storageID STRING, storageVersion INTEGER, storageUnknownFields BLOB, storageNeedsSync INTEGER);
CREATE TABLE storyDistributionMembers(
        listId STRING NOT NULL REFERENCES storyDistributions(id)
          ON DELETE CASCADE
          ON UPDATE CASCADE,
        serviceId STRING NOT NULL,

        PRIMARY KEY (listId, serviceId)
      );
CREATE TABLE uninstalled_sticker_packs (
        id STRING NOT NULL PRIMARY KEY,
        uninstalledAt NUMBER NOT NULL,
        storageID STRING,
        storageVersion NUMBER,
        storageUnknownFields BLOB,
        storageNeedsSync INTEGER NOT NULL
      );
CREATE TABLE groupCallRingCancellations(
        ringId INTEGER PRIMARY KEY,
        createdAt INTEGER NOT NULL
      );
CREATE TABLE IF NOT EXISTS 'messages_fts_data'(id INTEGER PRIMARY KEY, block BLOB);
CREATE TABLE IF NOT EXISTS 'messages_fts_idx'(segid, term, pgno, PRIMARY KEY(segid, term)) WITHOUT ROWID;
CREATE TABLE IF NOT EXISTS 'messages_fts_content'(id INTEGER PRIMARY KEY, c0);
CREATE TABLE IF NOT EXISTS 'messages_fts_docsize'(id INTEGER PRIMARY KEY, sz BLOB);
CREATE TABLE IF NOT EXISTS 'messages_fts_config'(k PRIMARY KEY, v) WITHOUT ROWID;
CREATE TABLE edited_messages(
        messageId STRING REFERENCES messages(id)
          ON DELETE CASCADE,
        sentAt INTEGER,
        readStatus INTEGER
      , conversationId STRING);
CREATE TABLE mentions (
        messageId REFERENCES messages(id) ON DELETE CASCADE,
        mentionAci STRING,
        start INTEGER,
        length INTEGER
      );
CREATE TABLE kyberPreKeys(
        id STRING PRIMARY KEY NOT NULL,
        json TEXT NOT NULL, ourServiceId NUMBER
        GENERATED ALWAYS AS (json_extract(json, '$.ourServiceId')));
CREATE TABLE callsHistory (
        callId TEXT PRIMARY KEY,
        peerId TEXT NOT NULL, -- conversation id (legacy) | uuid | groupId | roomId
        ringerId TEXT DEFAULT NULL, -- ringer uuid
        mode TEXT NOT NULL, -- enum "Direct" | "Group"
        type TEXT NOT NULL, -- enum "Audio" | "Video" | "Group"
        direction TEXT NOT NULL, -- enum "Incoming" | "Outgoing
        -- Direct: enum "Pending" | "Missed" | "Accepted" | "Deleted"
        -- Group: enum "GenericGroupCall" | "OutgoingRing" | "Ringing" | "Joined" | "Missed" | "Declined" | "Accepted" | "Deleted"
        status TEXT NOT NULL,
        timestamp INTEGER NOT NULL,
        UNIQUE (callId, peerId) ON CONFLICT FAIL
      );
[ dropped all indexes to save space in this blog post ]
CREATE TRIGGER messages_on_view_once_update AFTER UPDATE ON messages
      WHEN
        new.body IS NOT NULL AND new.isViewOnce = 1
      BEGIN
        DELETE FROM messages_fts WHERE rowid = old.rowid;
      END;
CREATE TRIGGER messages_on_insert AFTER INSERT ON messages
      WHEN new.isViewOnce IS NOT 1 AND new.storyId IS NULL
      BEGIN
        INSERT INTO messages_fts
          (rowid, body)
        VALUES
          (new.rowid, new.body);
      END;
CREATE TRIGGER messages_on_delete AFTER DELETE ON messages BEGIN
        DELETE FROM messages_fts WHERE rowid = old.rowid;
        DELETE FROM sendLogPayloads WHERE id IN (
          SELECT payloadId FROM sendLogMessageIds
          WHERE messageId = old.id
        );
        DELETE FROM reactions WHERE rowid IN (
          SELECT rowid FROM reactions
          WHERE messageId = old.id
        );
        DELETE FROM storyReads WHERE storyId = old.storyId;
      END;
CREATE VIRTUAL TABLE messages_fts USING fts5(
        body,
        tokenize = 'signal_tokenizer'
      );
CREATE TRIGGER messages_on_update AFTER UPDATE ON messages
      WHEN
        (new.body IS NULL OR old.body IS NOT new.body) AND
         new.isViewOnce IS NOT 1 AND new.storyId IS NULL
      BEGIN
        DELETE FROM messages_fts WHERE rowid = old.rowid;
        INSERT INTO messages_fts
          (rowid, body)
        VALUES
          (new.rowid, new.body);
      END;
CREATE TRIGGER messages_on_insert_insert_mentions AFTER INSERT ON messages
      BEGIN
        INSERT INTO mentions (messageId, mentionAci, start, length)
        
    SELECT messages.id, bodyRanges.value ->> 'mentionAci' as mentionAci,
      bodyRanges.value ->> 'start' as start,
      bodyRanges.value ->> 'length' as length
    FROM messages, json_each(messages.json ->> 'bodyRanges') as bodyRanges
    WHERE bodyRanges.value ->> 'mentionAci' IS NOT NULL
  
        AND messages.id = new.id;
      END;
CREATE TRIGGER messages_on_update_update_mentions AFTER UPDATE ON messages
      BEGIN
        DELETE FROM mentions WHERE messageId = new.id;
        INSERT INTO mentions (messageId, mentionAci, start, length)
        
    SELECT messages.id, bodyRanges.value ->> 'mentionAci' as mentionAci,
      bodyRanges.value ->> 'start' as start,
      bodyRanges.value ->> 'length' as length
    FROM messages, json_each(messages.json ->> 'bodyRanges') as bodyRanges
    WHERE bodyRanges.value ->> 'mentionAci' IS NOT NULL
  
        AND messages.id = new.id;
      END;
sqlite>

Finally I have the tool needed to inspect and process Signal messages that I need, without using the vendor provided client. Now on to transforming it to a more useful format.

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

Tags: debian, english, sikkerhet, surveillance.
ONVIF IP camera management tool finally in Debian
24th December 2022

Merry Christmas to you all. Here is a small gift to all those with IP cameras following the ONVIF specification. There is finally a nice command line and GUI tool in Debian to manage ONVIF IP cameras. After working with upstream for a few months and sponsoring the upload, I am very happy to report that the libonvif package entered Debian Sid last night.

The package provide a C library to communicate with such cameras, a command line tool to locate and update settings of (like password) the cameras and a GUI tool to configure and control the units as well as preview the video from the camera. Libonvif is available on Both Linux and Windows and the GUI tool uses the Qt library. The main competitors are non-free software, while libonvif is GNU GPL licensed. I am very glad Debian users in the future can control their cameras using a free software system provided by Debian. But the ONVIF world is full of slightly broken firmware, where the cameras pretend to follow the ONVIF specification but fail to set some configuration values or refuse to provide video to more than one recipient at the time, and the onvif project is quite young and might take a while before it completely work with your camera. Upstream seem eager to improve the library, so handling any broken camera might be just a bug report away.

The package just cleared NEW, and need a new source only upload before it can enter testing. This will happen in the next few days.

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

Tags: debian, english, multimedia, standard, surveillance.
Managing and using ONVIF IP cameras with Linux
19th October 2022

Recently I have been looking at how to control and collect data from a handful IP cameras using Linux. I both wanted to change their settings and to make their imagery available via a free software service under my control. Here is a summary of the tools I found.

First I had to identify the cameras and their protocols. As far as I could tell, they were using some SOAP looking protocol and their internal web server seem to only work with Microsoft Internet Explorer with some proprietary binary plugin, which in these days of course is a security disaster and also made it impossible for me to use the camera web interface. Luckily I discovered that the SOAP looking protocol is actually following the ONVIF specification, which seem to be supported by a lot of IP cameras these days.

Once the protocol was identified, I was able to find what appear to be the most popular way to configure ONVIF cameras, the free software Windows tool named ONVIF Device Manager. Lacking any other options at the time, I tried unsuccessfully to get it running using Wine, but was missing a dotnet 40 library and I found no way around it to run it on Linux.

The next tool I found to configure the cameras were a non-free Linux Qt client ONVIF Device Tool. I did not like its terms of use, so did not spend much time on it.

To collect the video and make it available in a web interface, I found the Zoneminder tool in Debian. A recent version was able to automatically detect and configure ONVIF devices, so I could use it to set up motion detection in and collection of the camera output. I had initial problems getting the ONVIF autodetection to work, as both Firefox and Chromium refused the inter-tab communication being used by the Zoneminder web pages, but managed to get konqueror to work. Apparently the "Enhanced Tracking Protection" in Firefox cause the problem. I ended up upgrading to the Bookworm edition of Zoneminder in the process to try to fix the issue, and believe the problem might be solved now.

In the process I came across the nice Linux GUI tool ONVIF Viewer allowing me to preview the camera output and validate the login passwords required. Sadly its author has grown tired of maintaining the software, so it might not see any future updates. Which is sad, as the viewer is sightly unstable and the picture tend to lock up. Note, this lockup might be due to limitations in the cameras and not the viewer implementation. I suspect the camera is only able to provide pictures to one client at the time, and the Zoneminder feed might interfere with the GUI viewer. I have asked for the tool to be included in Debian.

Finally, I found what appear to be very nice Linux free software replacement for the Windows tool, named libonvif. It provide a C library to talk to ONVIF devices as well as a command line and GUI tool using the library. Using the GUI tool I was able to change the admin passwords and update other settings of the cameras. I have asked for the package to be included in Debian.

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

Update 2022-10-20: Since my initial publication of this text, I got several suggestions for more free software Linux tools. There is a ONVIF python library (already requested into Debian) and a python 3 fork using a different SOAP dependency. There is also support for ONVIF in Home Assistant, and there is an alternative to Zoneminder called Shinobi. The latter two are not included in Debian either. I have not tested any of these so far.

Tags: debian, english, multimedia, standard, surveillance.
Få en slutt på Digitale utslipp
14th March 2022

På onsdag sendte jeg følgende epost til Utdanningsetaten i Oslo kommune (UDE). Fikk beskjed om at min henvendelse har saksnummer 22/7559-1 i den offentlige postjournalen til UDE. Jeg er spent på hva slags respons jeg får. Mistenker jo de fleste som sprer sine nettsideleseres personopplysninger til utlandet ikke har tenkt så nøye igjennom hva de gjør, og at det er håp om at de tenker seg litt nøyere om hvis de blir klar over problemstillingen. Vet du noen som burde få tilsvarede beskjed og spørsmål? Kanskje du kan sende dem en epost. Hvis alle bidrar blir det kanskje litt bedre.

To: postmottak (at) osloskolen.no
Subject: Digitale utslipp fra osloskolens nettsider

Hei.

Jeg ser at osloskolens nettsider har digitale utslipp av personopplysninger til Google, Facebook og andre, blant annet omtalt på <URL: https://aktuelt.osloskolen.no/personvernerklaring-for-osloskolen/informasjonskapsler/ >.

<URL: https://webbkoll.dataskydd.net/ > kan være et nyttig verktøy for å holde øye med utslippsomfanget på ulike sider.

Kanskje det er en ide å gjøre noe med det, jamfør <URL: https://www.digi.no/artikler/debatt-det-enkleste-tiltaket-er-a-skru-av-google-analytics/517378 >?

Et alternativ til Google Analytics kan være en lokalt installert utgave av <URL: https://matomo.org/ >. Den og flere andre alternativer kan finnes via <URL: https://www.digi.no/artikler/sverige-vil-skrote-amerikansk-skytjeneste-her-er-alternativene/516223?key=5QsV0wRG > på bakgrunn av at svenske myndigheter har innsett at dagens praksis nok er både lite lur og ulovlig. Der henger Norge litt etter, men osloskolen har her mulighet til å være litt i forkant. :)

Fint om dere kan gi beskjed hvilket saksnummer denne henvendelsen får i offentlig postjournal når den er mottatt.

Flere og flere innser at slik spredning av personopplysninger er ugreit. Det har pågått i mange år. Ser jeg blogget første gang om Google Analytics i 2013 og analyserte omfanget i 2015, men det er et langt lerret å bleke.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

Tags: norsk, personvern, surveillance.
Latest Jami back in Debian Testing, and scriptable using dbus
12th January 2021

After a lot of hard work by its maintainer Alexandre Viau and others, the decentralized communication platform Jami (earlier known as Ring), managed to get its latest version into Debian Testing. Several of its dependencies has caused build and propagation problems, which all seem to be solved now.

In addition to the fact that Jami is decentralized, similar to how bittorrent is decentralized, I first of all like how it is not connected to external IDs like phone numbers. This allow me to set up computers to send me notifications using Jami without having to find get a phone number for each computer. Automatic notification via Jami is also made trivial thanks to the provided client side API (as a DBus service). Here is my bourne shell script demonstrating how to let any system send a message to any Jami address. It will create a new identity before sending the message, if no Jami identity exist already:

#!/bin/sh
#
# Usage: $0  
#
# Send  to , create local jami account if
# missing.
#
# License: GPL v2 or later at your choice
# Author: Petter Reinholdtsen


if [ -z "$HOME" ] ; then
    echo "error: missing \$HOME, required for dbus to work"
    exit 1
fi

# First, get dbus running if not already running
DBUSLAUNCH=/usr/bin/dbus-launch
PIDFILE=/run/asterisk/dbus-session.pid
if [ -e $PIDFILE ] ; then
    . $PIDFILE
    if ! kill -0 $DBUS_SESSION_BUS_PID 2>/dev/null ; then
        unset DBUS_SESSION_BUS_ADDRESS
    fi
fi
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] && [ -x "$DBUSLAUNCH" ]; then
    DBUS_SESSION_BUS_ADDRESS="unix:path=$HOME/.dbus"
    dbus-daemon --session --address="$DBUS_SESSION_BUS_ADDRESS" --nofork --nopidfile --syslog-only < /dev/null > /dev/null 2>&1 3>&1 &
    DBUS_SESSION_BUS_PID=$!
    (
        echo DBUS_SESSION_BUS_PID=$DBUS_SESSION_BUS_PID
        echo DBUS_SESSION_BUS_ADDRESS=\""$DBUS_SESSION_BUS_ADDRESS"\"
        echo export DBUS_SESSION_BUS_ADDRESS
    ) > $PIDFILE
    . $PIDFILE
fi &

dringop() {
    part="$1"; shift
    op="$1"; shift
    dbus-send --session \
        --dest="cx.ring.Ring" /cx/ring/Ring/$part cx.ring.Ring.$part.$op $*
}

dringopreply() {
    part="$1"; shift
    op="$1"; shift
    dbus-send --session --print-reply \
        --dest="cx.ring.Ring" /cx/ring/Ring/$part cx.ring.Ring.$part.$op $*
}

firstaccount() {
    dringopreply ConfigurationManager getAccountList | \
      grep string | awk -F'"' '{print $2}' | head -n 1
}

account=$(firstaccount)

if [ -z "$account" ] ; then
    echo "Missing local account, trying to create it"
    dringop ConfigurationManager addAccount \
      dict:string:string:"Account.type","RING","Account.videoEnabled","false"
    account=$(firstaccount)
    if [ -z "$account" ] ; then
        echo "unable to create local account"
        exit 1
    fi
fi

# Not using dringopreply to ensure $2 can contain spaces
dbus-send --print-reply --session \
  --dest=cx.ring.Ring \
  /cx/ring/Ring/ConfigurationManager \
  cx.ring.Ring.ConfigurationManager.sendTextMessage \
  string:"$account" string:"$1" \
  dict:string:string:"text/plain","$2" 

If you want to check it out yourself, visit the the Jami system project page to learn more, and install the latest Jami client from Debian Unstable or Testing.

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

Tags: debian, english, sikkerhet, surveillance.
Bompenge-Norge, med noen tall fra bompengekalkulator
1st June 2020

Det er tett med sensorstasjoner langs veinettet i Norge, som registrerer hvilke kjøretøy som passerer eller tar bilde av de som drar forbi. I følge Vegvesenets nasjonale veidatabank (NVDB), er det 353 bomstasjoner langs det norske veinettet. 21 i nordnorge, 48 i trøndelagsområdet, 13 på nordvestlandet, 91 i bergenstraktene og 180 på østlandsområdet. I tillegg finnes det et utall overvåkningskamera og noen titalls RFID-avlesere for bompengebrikker som samler inn informasjon om hvilke biler som befinner seg hvor i landet. For ikke å glemme alle mobilbasestasjoner som registrerer hvor brukere av mobilnettverket befinner seg. De er ikke tema i dag.

De som kjører mye har interesse av å vite hvor mye bompenger det vil koste å kjøre fra et sted til et annet, og dette behovet har aktørene bak Bompengekalkulatoren tatt sikte på å tilby i markedet. Fornuftig nok har de også en gratistjeneste, slik at de får frivillige til å gi innspill om feil i datagrunnlaget. Jeg ble nylig nysgjerring på hvor mye det til koste å kjøre på kryss og tvers i Norge, og valgte meg ut en teststrekning fra Oslo til Tromsø for å se hvilke beløp som gjelder.

Bompengekalkulatoren viser frem flere rutealternativer for et gitt reisesøk, og i dette tilfellet, for reise fra Oslo Sentralstasjon til Tromsø sentrum, viser den tre alternativ. Merk, disse tallene gjelder bensindrevet personbil. En kan velge takstkategori i webgrensesnittet. Det ene rutealternativet er E6 gjennom Norge, de to andre er E45 og E4 gjennom sverige. E45 er innlandsruten i Sverige, motorvei gjennom store skoger som i følge kalkulatoren skal ta 22 timer og 26 minutter med norsk bompengebeløp på 164 kroner. Jeg har mine tvil til om datasettet til Bompengekalkulatoren har svenske bomstasjoner, så ta dette beløpet med en klype salt. E4 er veien langs Bottenviken og mer befolket område, og skal ta 22 timer og 50 minutter til en norsk bompengebeløp på 71 kroner. Den norske ruten langs E6 skal derimot ta 23 timer og 16 minutter og beløpe seg til 664 kroner. Beløpene er uten autopass-brikke, slik at en slipper å få bilens posisjon registrert i alle bompengebrikkeavleserne som ikke også er bomstasjoner. For trailere er bompengekostnaden 2-3 ganger så høy som for personbil. I tillegg til pengebeløpet, som faktureres etterskuddsvis og de siste årene har blitt umulig å gjøre opp kontant på stedet, så kommer kostnaden med å få sine personopplysninger samlet inn, lagret og gjort tilgjengelig for fremmede på ubestemt tid. Jeg ser på den kostnaden som mye høyere en pengebeløpet som faktureres.

For en tilsvarende tur fra Oslo til Bergen, så forteller kalkulatoren at raskeste vei er riksvei 7 på 7 timer 4 minutter med bompengebeløp 409 kroner. Alternativene listet opp er E134 på 8 timer 37 minutter med bompengebeløp 318 kroner og fylkesivei 40 på 7 timer 30 minutter med beløp 331. Det kan kanskje være greit å sjekke ut før en setter seg i bilen hvor ens personopplysninger vil bli samlet inn og lagret 5 fem år, når en velger hvilken rute en går for.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

Tags: betalkontant, norsk, surveillance.
Jami as a Zoom client, a trick for password protected rooms...
8th May 2020

Half a year ago, I wrote about the Jami communication client, capable of peer-to-peer encrypted communication. It handle both messages, audio and video. It uses distributed hash tables instead of central infrastructure to connect its users to each other, which in my book is a plus. I mentioned briefly that it could also work as a SIP client, which came in handy when the higher educational sector in Norway started to promote Zoom as its video conferencing solution. I am reluctant to use the official Zoom client software, due to their copyright license clauses prohibiting users to reverse engineer (for example to check the security) and benchmark it, and thus prefer to connect to Zoom meetings with free software clients.

Jami worked OK as a SIP client to Zoom as long as there was no password set on the room. The Jami daemon leak memory like crazy (approximately 1 GiB a minute) when I am connected to the video conference, so I had to restart the client every 7-10 minutes, which is not great. I tried to get other SIP Linux clients to work without success, so I decided I would have to live with this wart until someone managed to fix the leak in the dring code base. But another problem showed up once the rooms were password protected. I could not get my dial tone signaling through from Jami to Zoom, and dial tone signaling is used to enter the password when connecting to Zoom. I tried a lot of different permutations with my Jami and Asterisk setup to try to figure out why the signaling did not get through, only to finally discover that the fundamental problem seem to be that Zoom is simply not able to receive dial tone signaling when connecting via SIP. There seem to be nothing wrong with the Jami and Asterisk end, it is simply broken in the Zoom end. I got help from a very skilled VoIP engineer figuring out this last part. And being a very skilled engineer, he was also able to locate a solution for me. Or to be exact, a workaround that solve my initial problem of connecting to password protected Zoom rooms using Jami.

So, how do you do this, I am sure you are wondering by now. The trick is already documented from Zoom, and it is to modify the SIP address to include the room password. What is most surprising about this is that the automatically generated email from Zoom with instructions on how to connect via SIP do not mention this. The SIP address to use normally consist of the room ID (a number), an @ character and the IP address of the Zoom SIP gateway. But Zoom understand a lot more than just the room ID in front of the at sign. The format is "[Meeting ID].[Password].[Layout].[Host Key]", and you can here see how you can both enter password, control the layout (full screen, active presence and gallery) and specify the host key to start the meeting. The full SIP address entered into Jami to provide the password will then look like this (all using made up numbers):

sip:657837644.522827@192.168.169.170

Now if only jami would reduce its memory usage, I could even recommend this setup to others. :)

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

Tags: debian, english, sikkerhet, surveillance.
Totalovervåkning av innbyggernes bevegelser - nei takk!
16th April 2020

Jeg er blitt spurt hva jeg synes om lansering av smittestopp-appen, overvåkningsløsningen lansert av Folkehelseinstituttet, Simula-senteret og Regjeringen i dag, fulgt av klare trusler fra regjeringen om konsekvenser hvis befolkningen ikke tar den i bruk. Rekker ikke skrive noe fyldig om temaet, men det er klart for meg at den utraderer retten til privatliv samt utgjør en personlig sikkerhetsrisiko for alle som tar den i bruk. Bare det er nok til at det fremstår som en svært dårlig ide å bli med på denne "dugnaden". Det finnes andre og bedre tilnærminger enn den valgt av FHI. Har de valgt sin tilnærming for å sikre seg nok et datasett i den fremtidige ehelse-portalen? Potensialet for misbruk av informasjon samlet inn av appen er for stort, effekten på neste krise for klar og gevinsten for liten.

For å si det med forhenværende leder i Datatilsynet, Georg Apenes, som skrev i en kronikk den gang Datatilsynet vernet privatsfæren at «SENTRALT I en liberal forestillingsverden finner vi aksept av borgerens rett til å kunne velge å være i fred; å være u-iakttatt, uregistrert og anonym». Det er ikke uten grunn han startet kronikken med «Personvern et fremmedord i enkelte av de statsorganene som samler inn, oppbevarer og bruker personopplysninger». Der har nok statsorganene bare blitt dårligere på 13 år.

Det er jo også verdt å merke seg at personvernrådet i EU (EDPB) mener smittestopp-appen opererer i strid med prinsippet om dataminimering. Også de ser at det finnes mye bedre måter å gjøre dette på.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

Tags: norsk, surveillance.
What would it cost to store all 2018 phone calls in Norway?
25th November 2019

Four years ago, I did a back of the envelope calculation on how much it would cost to store audio recordings of all the phone calls in Norway, and came up with NOK 2.1 million / EUR 250 000 for the year 2013. It is time to repeat the calculation using updated numbers. The calculation is based on how much data storage is needed for each minute of audio, how many minutes all the calls in Norway sums up to, multiplied by the cost of data storage.

The number of phone call minutes for 2018 was fetched from the NKOM statistics site, and for 2018, land line calls are listed as 434 238 000 minutes, while mobile phone calls are listed with 7 542 006 000 minutes. The total number of minutes is thus 7 976 244 000. For simplicity, I decided to ignore any advantages in audio compression the last four years, and continue to assume 60 Kbytes/min as the last time.

Storage prices still varies a lot, but as last time, I decide to take a reasonable big and cheap hard drive, and double its price to include the surrounding costs into account. A 10 TB disk cost less than 4500 NOK / 450 EUR these days, and doubling it give 9000 NOK per 10 TB.

So, with the parameters in place, lets update the old table estimating cost for calls in a given year:

YearCall minutesSizePrice in NOK / EUR
200524 000 000 0001.3 PiB1 170 000 / 117 000
201218 000 000 0001.0 PiB900 000 / 90 000
201317 000 000 000950 TiB855 000 / 85 500
20187 976 244 000445 TiB401 100 / 40 110

Both the cost of storage and the number of phone call minutes have dropped since the last time, bringing the cost down to a level where I guess even small organizations can afford to store the audio recording from every phone call taken in a year in Norway. Of course, this is just the cost of buying the storage equipment. Maintenance, need to be included as well, but the volume of a single year is about a single rack of hard drives, so it is not much more than I could fit in my own home. Wonder how much the electricity bill would raise if I had that kind of storage? I doubt it would be more than a few tens of thousand NOK per year.

Tags: english, personvern, surveillance.
Jami/Ring, finally functioning peer to peer communication client
19th June 2019

Some years ago, in 2016, I wrote for the first time about the Ring peer to peer messaging system. It would provide messaging without any central server coordinating the system and without requiring all users to register a phone number or own a mobile phone. Back then, I could not get it to work, and put it aside until it had seen more development. A few days ago I decided to give it another try, and am happy to report that this time I am able to not only send and receive messages, but also place audio and video calls. But only if UDP is not blocked into your network.

The Ring system changed name earlier this year to Jami. I tried doing web search for 'ring' when I discovered it for the first time, and can only applaud this change as it is impossible to find something called Ring among the noise of other uses of that word. Now you can search for 'jami' and this client and the Jami system is the first hit at least on duckduckgo.

Jami will by default encrypt messages as well as audio and video calls, and try to send them directly between the communicating parties if possible. If this proves impossible (for example if both ends are behind NAT), it will use a central SIP TURN server maintained by the Jami project. Jami can also be a normal SIP client. If the SIP server is unencrypted, the audio and video calls will also be unencrypted. This is as far as I know the only case where Jami will do anything without encryption.

Jami is available for several platforms: Linux, Windows, MacOSX, Android, iOS, and Android TV. It is included in Debian already. Jami also work for those using F-Droid without any Google connections, while Signal do not. The protocol is described in the Ring project wiki. The system uses a distributed hash table (DHT) system (similar to BitTorrent) running over UDP. On one of the networks I use, I discovered Jami failed to work. I tracked this down to the fact that incoming UDP packages going to ports 1-49999 were blocked, and the DHT would pick a random port and end up in the low range most of the time. After talking to the developers, I solved this by enabling the dhtproxy in the settings, thus using TCP to talk to a central DHT proxy instead of peering directly with others. I've been told the developers are working on allowing DHT to use TCP to avoid this problem. I also ran into a problem when trying to talk to the version of Ring included in Debian Stable (Stretch). Apparently the protocol changed between beta2 and the current version, making these clients incompatible. Hopefully the protocol will not be made incompatible in the future.

It is worth noting that while looking at Jami and its features, I came across another communication platform I have not tested yet. The Tox protocol and family of Tox clients. It might become the topic of a future blog post.

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

Tags: debian, english, sikkerhet, surveillance.
En grunn til å takke nei til usikker digital post
2nd April 2018

Brevpost er beskyttet av straffelovens bestemmelse som gjør det kriminelt å åpne andres brev. Dette følger av (ny) straffelovs § 205 (Krenkelse av retten til privat kommunikasjon), som sier at «Med bot eller fengsel inntil 2 år straffes den som uberettiget ... c) åpner brev eller annen lukket skriftlig meddelelse som er adressert til en annen, eller på annen måte skaffer seg uberettiget tilgang til innholdet.» Dette gjelder såvel postbud som alle andre som har befatning med brevet etter at avsender har befatning med et lukket brev. Tilsvarende står også tidligere utgaver av den norske straffeloven.

Når en registrerer seg på usikre digitale postkasseløsningene, som f.eks. Digipost og e-Boks, og slik tar disse i bruk, så gir en de som står bak løsningene tillatelse til å åpne sine brev. Dette er nødvendig for at innholdet i digital post skal kunne vises frem til mottaker via tjenestens websider. Dermed gjelder ikke straffelovens paragraf om forbud mot å åpne brev, da tilgangen ikke lenger er uberettiget. En gir altså fremmede tilgang til å lese sin korrespondanse. I tillegg vil bruk av slike usikre digitale postbokser føre til at det blir registrert når du leser brevene, hvor du befinner deg (vha. tilkoblingens IP-adresse), hvilket utstyr du bruker og en rekke annen personlig informasjon som ikke er tilgjengelig når papirpost brukes. Jeg foretrekker at det er lovmessig beskyttelse av min korrespondanse, som jo inneholder privat og personlig informasjon. Det bidrar til litt bedre vern av personlig integritet i dagens norske samfunn.

Tags: norsk, personvern, surveillance.
H, Ap, Frp og Venstre går for DNA-innsamling av hele befolkningen
14th March 2018

I går kom det nok et argument for å holde seg unna det norske helsevesenet. Da annonserte et stortingsflertall, bestående av Høyre, Arbeiderpartiet, Fremskrittspartiet og Venstre, at de går inn for å samle inn og lagre DNA-prøver fra hele befolkningen i Norge til evig tid. Endringen gjelder innsamlede blodprøver fra nyfødte i Norge. Det vil dermed ta litt tid før en har hele befolkningen, men det er dit vi havner gitt nok tid. I dag er det nesten hundre prosent oppslutning om undersøkelsen som gjøres like etter fødselen, på bakgrunn av blodprøven det er snakk om å lagre, for å oppdage endel medfødte sykdommer. Blodprøven lagres i dag i inntil seks år. Stortingets flertallsinnstilling er at tidsbegrensingen skal fjernes, og mener at tidsubegrenset lagring ikke vil påvirke oppslutningen om undersøkelsen.

Datatilsynet har ikke akkurat applaudert forslaget:

«Datatilsynet mener forslaget ikke i tilstrekkelig grad synliggjør hvilke etiske og personvernmessige utfordringer som må diskuteres før en etablerer en nasjonal biobank med blodprøver fra hele befolkningen.»

Det er flere historier om hvordan innsamlet biologisk materiale har blitt brukt til andre formål enn de ble innsamlet til, og historien om folkehelseinstituttets lagring på vegne av politiet (Kripos) av innsamlet biologisk materiale og DNA-informasjon i strid med loven viser at en ikke kan være trygg på at lover og intensjoner beskytter de som blir berørt mot misbruk av slik privat og personlig informasjon.

Det er verdt å merke seg at det kan forskes på de innsamlede blodprøvene uten samtykke fra den det gjelder (eller foreldre når det gjelder barn), etter en lovendring for en stund tilbake, med mindre det er sendt inn skjema der en reserverer seg mot forskning uten samtykke. Skjemaet er tilgjengelig fra folkehelseinstituttets websider, og jeg anbefaler, uavhengig av denne saken, varmt alle å sende inn skjemaet for å dokumentere hvor mange som ikke synes det er greit å fjerne krav om samtykke.

I tillegg bør en kreve destruering av alt biologisk materiale som er samlet inn om en selv, for å redusere eventuelle negative konsekvenser i fremtiden når materialet kommer på avveie eller blir brukt uten samtykke, men det er så vidt jeg vet ikke noe system for dette i dag.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Oppdatering 2023-09-21: FHI har flyttet skjemaet for å reservere seg mot forskning uten samtykke.

Tags: norsk, personvern, surveillance.
Overvåkning i Kina vs. Norge
12th February 2018

Jeg lar meg fascinere av en artikkel i Dagbladet om Kinas håndtering av Xinjiang, spesielt følgende utsnitt:

«I den sørvestlige byen Kashgar nærmere grensa til Sentral-Asia meldes det nå at 120.000 uigurer er internert i såkalte omskoleringsleirer. Samtidig er det innført et omfattende helsesjekk-program med innsamling og lagring av DNA-prøver fra absolutt alle innbyggerne. De mest avanserte overvåkingsmetodene testes ut her. Programmer for å gjenkjenne ansikter og stemmer er på plass i regionen. Der har de lokale myndighetene begynt å installere GPS-systemer i alle kjøretøy og egne sporingsapper i mobiltelefoner.

Politimetodene griper så dypt inn i folks dagligliv at motstanden mot Beijing-regimet øker.»

Beskrivelsen avviker jo desverre ikke så veldig mye fra tilstanden her i Norge.

Dataregistrering Kina Norge
Innsamling og lagring av DNA-prøver fra befolkningen Ja Delvis, planlagt for alle nyfødte.
Ansiktsgjenkjenning Ja Ja
Stemmegjenkjenning Ja Nei
Posisjons-sporing av mobiltelefoner Ja Ja
Posisjons-sporing av biler Ja Ja

I Norge har jo situasjonen rundt Folkehelseinstituttets lagring av DNA-informasjon på vegne av politiet, der de nektet å slette informasjon politiet ikke hadde lov til å ta vare på, gjort det klart at DNA tar vare på ganske lenge. I tillegg finnes det utallige biobanker som lagres til evig tid, og det er planer om å innføre evig lagring av DNA-materiale fra alle spebarn som fødes (med mulighet for å be om sletting).

I Norge er det system på plass for ansiktsgjenkjenning, som en NRK-artikkel fra 2015 forteller er aktiv på Gardermoen, samt brukes til å analysere bilder innsamlet av myndighetene. Brukes det også flere plasser? Det er tett med overvåkningskamera kontrollert av politi og andre myndigheter i for eksempel Oslo sentrum.

Jeg er ikke kjent med at Norge har noe system for identifisering av personer ved hjelp av stemmegjenkjenning.

Posisjons-sporing av mobiltelefoner er ruinemessig tilgjengelig for blant annet politi, NAV og Finanstilsynet, i tråd med krav i telefonselskapenes konsesjon. I tillegg rapporterer smarttelefoner sin posisjon til utviklerne av utallige mobil-apper, der myndigheter og andre kan hente ut informasjon ved behov. Det er intet behov for noen egen app for dette.

Posisjons-sporing av biler er rutinemessig tilgjengelig via et tett nett av målepunkter på veiene (automatiske bomstasjoner, køfribrikke-registrering, automatiske fartsmålere og andre veikamera). Det er i tillegg vedtatt at alle nye biler skal selges med utstyr for GPS-sporing (eCall).

Det er jammen godt vi lever i et liberalt demokrati, og ikke en overvåkningsstat, eller?

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Tags: norsk, surveillance.
Visualizing GSM radio chatter using gr-gsm and Hopglass
29th September 2017

Every mobile phone announce its existence over radio to the nearby mobile cell towers. And this radio chatter is available for anyone with a radio receiver capable of receiving them. Details about the mobile phones with very good accuracy is of course collected by the phone companies, but this is not the topic of this blog post. The mobile phone radio chatter make it possible to figure out when a cell phone is nearby, as it include the SIM card ID (IMSI). By paying attention over time, one can see when a phone arrive and when it leave an area. I believe it would be nice to make this information more available to the general public, to make more people aware of how their phones are announcing their whereabouts to anyone that care to listen.

I am very happy to report that we managed to get something visualizing this information up and running for Oslo Skaperfestival 2017 (Oslo Makers Festival) taking place today and tomorrow at Deichmanske library. The solution is based on the simple recipe for listening to GSM chatter I posted a few days ago, and will show up at the stand of Åpen Sone from the Computer Science department of the University of Oslo. The presentation will show the nearby mobile phones (aka IMSIs) as dots in a web browser graph, with lines to the dot representing mobile base station it is talking to. It was working in the lab yesterday, and was moved into place this morning.

We set up a fairly powerful desktop machine using Debian Buster/Testing with several (five, I believe) RTL2838 DVB-T receivers connected and visualize the visible cell phone towers using an English version of Hopglass. A fairly powerfull machine is needed as the grgsm_livemon_headless processes from gr-gsm converting the radio signal to data packages is quite CPU intensive.

The frequencies to listen to, are identified using a slightly patched scan-and-livemon (to set the --args values for each receiver), and the Hopglass data is generated using the patches in my meshviewer-output branch. For some reason we could not get more than four SDRs working. There is also a geographical map trying to show the location of the base stations, but I believe their coordinates are hardcoded to some random location in Germany, I believe. The code should be replaced with code to look up location in a text file, a sqlite database or one of the online databases mentioned in the github issue for the topic.

If this sound interesting, visit the stand at the festival!

Tags: debian, english, personvern, surveillance.
Easier recipe to observe the cell phones around you
24th September 2017

A little more than a month ago I wrote how to observe the SIM card ID (aka IMSI number) of mobile phones talking to nearby mobile phone base stations using Debian GNU/Linux and a cheap USB software defined radio, and thus being able to pinpoint the location of people and equipment (like cars and trains) with an accuracy of a few kilometer. Since then we have worked to make the procedure even simpler, and it is now possible to do this without any manual frequency tuning and without building your own packages.

The gr-gsm package is now included in Debian testing and unstable, and the IMSI-catcher code no longer require root access to fetch and decode the GSM data collected using gr-gsm.

Here is an updated recipe, using packages built by Debian and a git clone of two python scripts:

  1. Start with a Debian machine running the Buster version (aka testing).
  2. Run 'apt install gr-gsm python-numpy python-scipy python-scapy' as root to install required packages.
  3. Fetch the code decoding GSM packages using 'git clone github.com/Oros42/IMSI-catcher.git'.
  4. Insert USB software defined radio supported by GNU Radio.
  5. Enter the IMSI-catcher directory and run 'python scan-and-livemon' to locate the frequency of nearby base stations and start listening for GSM packages on one of them.
  6. Enter the IMSI-catcher directory and run 'python simple_IMSI-catcher.py' to display the collected information.

Note, due to a bug somewhere the scan-and-livemon program (actually its underlying program grgsm_scanner) do not work with the HackRF radio. It does work with RTL 8232 and other similar USB radio receivers you can get very cheaply (for example from ebay), so for now the solution is to scan using the RTL radio and only use HackRF for fetching GSM data.

As far as I can tell, a cell phone only show up on one of the frequencies at the time, so if you are going to track and count every cell phone around you, you need to listen to all the frequencies used. To listen to several frequencies, use the --numrecv argument to scan-and-livemon to use several receivers. Further, I am not sure if phones using 3G or 4G will show as talking GSM to base stations, so this approach might not see all phones around you. I typically see 0-400 IMSI numbers an hour when looking around where I live.

I've tried to run the scanner on a Raspberry Pi 2 and 3 running Debian Buster, but the grgsm_livemon_headless process seem to be too CPU intensive to keep up. When GNU Radio print 'O' to stdout, I am told there it is caused by a buffer overflow between the radio and GNU Radio, caused by the program being unable to read the GSM data fast enough. If you see a stream of 'O's from the terminal where you started scan-and-livemon, you need a give the process more CPU power. Perhaps someone are able to optimize the code to a point where it become possible to set up RPi3 based GSM sniffers? I tried using Raspbian instead of Debian, but there seem to be something wrong with GNU Radio on raspbian, causing glibc to abort().

Tags: debian, english, personvern, surveillance.
Datalagringsdirektivet kaster skygger over Høyre og Arbeiderpartiet
7th September 2017

For noen dager siden publiserte Jon Wessel-Aas en bloggpost om «Konklusjonen om datalagring som EU-kommisjonen ikke ville at vi skulle få se». Det er en interessant gjennomgang av EU-domstolens syn på snurpenotovervåkning av befolkningen, som er klar på at det er i strid med EU-lovgivingen.

Valgkampen går for fullt i Norge, og om noen få dager er siste frist for å avgi stemme. En ting er sikkert, Høyre og Arbeiderpartiet får ikke min stemme denne gangen heller. Jeg har ikke glemt at de tvang igjennom loven som skulle pålegge alle data- og teletjenesteleverandører å overvåke alle sine kunder. En lov som er vedtatt, og aldri opphevet igjen.

Det er tydelig fra diskusjonen rundt grenseløs digital overvåkning (eller "Digital Grenseforsvar" som det kalles i Orvellisk nytale) at hverken Høyre og Arbeiderpartiet har noen prinsipielle sperrer mot å overvåke hele befolkningen, og diskusjonen så langt tyder på at flere av de andre partiene heller ikke har det. Mange av de som stemte for Datalagringsdirektivet i Stortinget (64 fra Arbeiderpartiet, 25 fra Høyre) er fortsatt aktive og argumenterer fortsatt for å radere vekk mer av innbyggernes privatsfære.

Når myndighetene demonstrerer sin mistillit til folket, tror jeg folket selv bør legge litt innsats i å verne sitt privatliv, ved å ta i bruk ende-til-ende-kryptert kommunikasjon med sine kjente og kjære, og begrense hvor mye privat informasjon som deles med uvedkommende. Det er jo ingenting som tyder på at myndighetene kommer til å være vår privatsfære. Det er mange muligheter. Selv har jeg litt sans for Ring, som er basert på p2p-teknologi uten sentral kontroll, er fri programvare, og støtter meldinger, tale og video. Systemet er tilgjengelig ut av boksen fra Debian og Ubuntu, og det finnes pakker for Android, MacOSX og Windows. Foreløpig er det få brukere med Ring, slik at jeg også bruker Signal som nettleserutvidelse.

Tags: dld, norsk, personvern, stortinget, surveillance, valg.
Simpler recipe on how to make a simple $7 IMSI Catcher using Debian
9th August 2017

On friday, I came across an interesting article in the Norwegian web based ICT news magazine digi.no on how to collect the IMSI numbers of nearby cell phones using the cheap DVB-T software defined radios. The article refered to instructions and a recipe by Keld Norman on Youtube on how to make a simple $7 IMSI Catcher, and I decided to test them out.

The instructions said to use Ubuntu, install pip using apt (to bypass apt), use pip to install pybombs (to bypass both apt and pip), and the ask pybombs to fetch and build everything you need from scratch. I wanted to see if I could do the same on the most recent Debian packages, but this did not work because pybombs tried to build stuff that no longer build with the most recent openssl library or some other version skew problem. While trying to get this recipe working, I learned that the apt->pip->pybombs route was a long detour, and the only piece of software dependency missing in Debian was the gr-gsm package. I also found out that the lead upstream developer of gr-gsm (the name stand for GNU Radio GSM) project already had a set of Debian packages provided in an Ubuntu PPA repository. All I needed to do was to dget the Debian source package and built it.

The IMSI collector is a python script listening for packages on the loopback network device and printing to the terminal some specific GSM packages with IMSI numbers in them. The code is fairly short and easy to understand. The reason this work is because gr-gsm include a tool to read GSM data from a software defined radio like a DVB-T USB stick and other software defined radios, decode them and inject them into a network device on your Linux machine (using the loopback device by default). This proved to work just fine, and I've been testing the collector for a few days now.

The updated and simpler recipe is thus to

  1. start with a Debian machine running Stretch or newer,
  2. build and install the gr-gsm package available from http://ppa.launchpad.net/ptrkrysik/gr-gsm/ubuntu/pool/main/g/gr-gsm/,
  3. clone the git repostory from https://github.com/Oros42/IMSI-catcher,
  4. run grgsm_livemon and adjust the frequency until the terminal where it was started is filled with a stream of text (meaning you found a GSM station).
  5. go into the IMSI-catcher directory and run 'sudo python simple_IMSI-catcher.py' to extract the IMSI numbers.

To make it even easier in the future to get this sniffer up and running, I decided to package the gr-gsm project for Debian (WNPP #871055), and the package was uploaded into the NEW queue today. Luckily the gnuradio maintainer has promised to help me, as I do not know much about gnuradio stuff yet.

I doubt this "IMSI cacher" is anywhere near as powerfull as commercial tools like The Spy Phone Portable IMSI / IMEI Catcher or the Harris Stingray, but I hope the existance of cheap alternatives can make more people realise how their whereabouts when carrying a cell phone is easily tracked. Seeing the data flow on the screen, realizing that I live close to a police station and knowing that the police is also wearing cell phones, I wonder how hard it would be for criminals to track the position of the police officers to discover when there are police near by, or for foreign military forces to track the location of the Norwegian military forces, or for anyone to track the location of government officials...

It is worth noting that the data reported by the IMSI-catcher script mentioned above is only a fraction of the data broadcasted on the GSM network. It will only collect one frequency at the time, while a typical phone will be using several frequencies, and not all phones will be using the frequencies tracked by the grgsm_livemod program. Also, there is a lot of radio chatter being ignored by the simple_IMSI-catcher script, which would be collected by extending the parser code. I wonder if gr-gsm can be set up to listen to more than one frequency?

Tags: debian, english, personvern, surveillance.
How does it feel to be wiretapped, when you should be doing the wiretapping...
8th March 2017

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.

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.

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?

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 'the FBI denies any wiretapping', while the reality is that 'the FBI denies any illegal wiretapping'. There is a fundamental and important difference, and it make me sad that the journalists are unable to grasp it.

Update 2017-03-13: Look like The Intercept report that US Senator Rand Paul confirm what I state above.

Tags: english, surveillance.
Nasjonalbiblioteket avslutter sin ulovlige bruk av Google Skjemaer
12th January 2017

I dag fikk jeg en skikkelig gladmelding. Bakgrunnen er at før jul arrangerte Nasjonalbiblioteket et seminar om sitt knakende gode tiltak «verksregister». 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 Mimes brønn i avtaler og vurderinger Nasjonalbiblioteket hadde rundt dette. 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.

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.

Tags: norsk, personvern, surveillance, web.
Bryter NAV sin egen personvernerklæring?
11th January 2017

Jeg leste med interesse en nyhetssak hos digi.no og NRK 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.»

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

Men det er en ting som bekymrer meg rundt denne nyheten. Jeg ble tipset (takk #nuug) om NAVs personvernerklæring, som under punktet «Personvern og statistikk» lyder:

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

  • hvilken side du ser på
  • dato og tid
  • hvilken nettleser du bruker
  • din ip-adresse

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

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 Datatilsynet fortalte meg i starten av desember antagelig er brudd på personopplysningsloven.

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.

Kanskje NAV bør ta en nøye titt på sin personvernerklæring? Eller kanskje Datatilsynet bør gjøre det?

Tags: norsk, nuug, personvern, surveillance.
Where did that package go? — geolocated IP traceroute
9th January 2017

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:

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  * * *
[...]

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.

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

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

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 PhantomJS to visit the Stortinget web page and tell me all the URLs PhantomJS downloaded to render the page (in HAR format using their netsniff example. 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.

map of combined traces for URLs used by www.stortinget.no using GeoIP

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 my kmltraceroute git repository. 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 the KML file I created using the GeoLite City dataset from MaxMind.

scapy traceroute graph for URLs used by www.stortinget.no

I also had a look at the visual traceroute graph created by the scrapy project, showing IP network ownership (aka AS owner) for the IP address in question. The graph display a lot of useful information about the traceroute in SVG format, 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.

example geotraceroute view for www.stortinget.no

In the process, I came across the web service GeoTraceroute 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 the NUUG assosiation, and get the trace in KML format for further processing.

map of combined traces for URLs used by www.stortinget.no using geotraceroute

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.

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.

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.

PS: KML files are drawn using the KML viewer from Ivan Rublev, as it was less cluttered than the local Linux application Marble. There are heaps of other options too.

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

Tags: debian, english, kart, nuug, personvern, stortinget, surveillance, web.
Er lover brutt når personvernpolicy ikke stemmer med praksis?
9th December 2016

Når jeg bruker Ghostery, uBlock, uMatrix, ScriptSafe og andre nettleserverktøy (de passer på hverandre) for å holde styr på hvordan nettsteder sprer informasjon om hvilke nettsider jeg leser blir det veldig synlig hvilke nettsteder som er satt opp til å utveksle informasjon med utlandet og tredjeparter. For en stund siden la jeg merke til at det virker å være avvik mellom personvernpolicy og praksis endel steder, og tok tak i et par konkrete eksempler og sendte spørsmål til Datatilsynets kontaktpunkt for veiledning:

«Jeg har et spørsmål når det gjelder bruken av Google Analytics og personvernpolicy. Er det lovlig for et nettsted å si en ting i personvernpolicy og gjøre noe annet i virkeligheten? Spesifikt lurer jeg på hvilket lov som er brutt hvis nettstedet i HTML-koden til nettsidene ber lesernes nettleser om å kontakte Google Analytics og slik overleverer sitt IP-nummer til Google, samtidig som personvernpolicien hevder at Google Analytics kun får anonymiserte data. Google får jo i slike tilfeller alltid overført fullt IP-nummer, og nettstedet kan i URL-en som brukes be Google om å ikke lagre deler av IP-adressen (omtalt som anonymisering av Google Analytics)

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

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

Men når en leser artikler der så blir maskiner i Norge, USA, Tyskland, Danmark, Storbritannia, Irland og Nederland varslet om besøket og får dermed overlevert full IP-adresse, som datatilsynet har uttalt er en personopplysning. Nettsidene er satt opp til be nettleseren å kontakte 29 ulike maskiner rundt om i verden. Fire av dem er er under DNS-domenene digi.no og tek.no som tilhører samme eier. I tillegg ber nettsidene ikke Google Analytics om å fjerne siste oktett i IP-adressen ved lagring, dvs. flagget «aip=1» er ikke satt i URL-en som brukes for å kontakte Google Analytics.

Tilsvarende er også tilfelle for andre nettsteder, så digi.no er ikke spesiell i så måte (dagbladet.no er et annet eksempel, det gjelder flere).»

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

«Hei, og takk for din e-post.

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

Ut ifra det du skriver er det antakelig flere bestemmelser i personopplysingsloven som brytes dersom virksomhetens personvernpolicy sier noe annet om behandlingen av personopplysninger enn det som faktisk skjer. Antakelig vil det være et brudd på informasjonsplikten i personopplysingsloven §§ 18 og 19<https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§18> dersom det gis feilinformasjon om at opplysningene utleveres. Det kan også stilles spørsmål om grunnkravene for behandling av personopplysninger vil være oppfylt ved en utlevering av personopplysninger til en tredjepart, dersom dette ikke er inkludert behandlingsgrunnlaget og formålet med behandlingen, se personopplysingsloven § 11, jf. 8.<https://lovdata.no/dokument/NL/lov/2000-04-14-31/KAPITTEL_2#§11

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

«Jeg lurte litt i forbindelse med en bloggpost jeg skriver på, og lurer på om dere hjelpe meg med å finne ut av følgende. Først litt bakgrunnsinformasjon. Dagbladets personvernpolicy forteller følgende:

«3. Automatisk innhentet informasjon

For eksempel IP-adressen din (ikke synlig for andre) samt statistisk, automatisk produsert informasjon, som når du sist var innlogget på tjenesten. Dette er informasjon vi samler for å gjøre tjenesten best mulig.»

Men når en besøker nettsidene til Dagbladet, f.eks. forsiden, så er nettsidene satt opp til å kontakte mange tredjeparter som slik får tilgang til både fullt IP-nummer og i de fleste tilfeller nøyaktig hvilken artikkel en leser hos Dagbladet ved at Referer-feltet fylles og legges ved. Dette gjelder Google Analytics, Cxense, INS Gallup, Doubleclick med flere. Totalt ber forsiden nettleseren om å koble seg opp til 60 nettsteder med 149 separate oppkoblinger. I hver av disse oppkoblingene oversendes IP-adressen til leseren, og i følge Datatilsynet er «en IP-adresse definert som en personopplysning fordi den kan spores tilbake til en bestemt maskinvare og dermed til en enkeltperson».

Datatilsynet har fortalt meg at i følge personopplysingsloven §§ 18 og 19 skal informasjonen som gis om bruk og utlevering av personopplysninger være korrekt. De forteller videre at det er endel grunnkrav som må være oppfylt ved utlevering av personopplysninger til tredjeparter, nærmere forklart i personopplysingsloven § 11 som henviser til § 8.

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

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

Etter en uke har jeg fortsatt ikke fått svar fra Dagbladet på mitt spørsmål, så neste steg er antagelig å høre om Datatilsynet er interessert i å se på saken.

Men Dagbladet er ikke det eneste nettstedet som forteller at de ikke deler personopplysninger med andre mens observerbar praksis dokumenterer noe annet. Jeg sendte derfor også et spørsmål til kontaktadressen til nettavisen Digi.no, og der var responsen mye bedre:

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

«All personlig informasjon blir lagret i våre systemer, disse er ikke tilgjengelig for tredjeparter, og blir ikke lagret i informasjonskapsler. Tredjeparter (som Google Analytics, Cxense, TNS Gallup) får kun anonymiserte data.»

Men når en besøker nettsidene til nettavisen, f.eks. forsiden, så er nettsidene satt opp til å kontakte mange tredjeparter som slik får tilgang til både fullt IP-nummer og i de fleste tilfeller nøyaktig hvilken artikkel en leser hos Digi.no ved at Referer-feltet fylles og legges ved. Dette gjelder både Google Analytics, Cxense blant og INS Gallum. Totalt ber forsiden nettleseren om å koble seg opp til 29 nettsteder med 44 separate oppkoblinger. I hver av disse oppkoblingene sendes IP-adressen til leseren over, og i følge Datatilsynet er «en IP-adresse definert som en personopplysning fordi den kan spores tilbake til en bestemt maskinvare og dermed til en enkeltperson». Det jeg ser virker ikke å være i tråd med personvernpolicyen.

Når en besøker Digi.nos nettsider gjøres det to oppkoblinger til Google Analytics, en for å hente ned programkoden som samler informasjon fra nettleseren og sender over til Google (analytics.js), og en for å overføre det som ble samlet inn. I den siste oppkoblingen er det mulig å be Google om å ikke ta vare på hele IP-adressen, men i stedet fjerne siste oktett i IP-adressen. Dette omtales ofte litt misvisende for «anonymisert» bruk av Google Analytics, i og med at fullt IP-nummer blir sendt til Google og det er opp til Google om de vil bry seg om ønsket fra de som har laget nettsiden. Ut fra det som står i personvernpolicyen ville jeg tro at Digi.no ba google om å ikke ta vare på hele IP-nummeret, men når en ser på den andre oppkoblingen kan en se at flagget «aio=1» ikke er satt, og at Digi.no ikke ber Google om å la være å lagre hele IP-adressen. Dette virker heller ikke å være i tråd med personvernpolicyen.

Datatilsynet har fortalt meg at i følge personopplysingsloven §§ 18 og 19 skal informasjonen som gis om bruk og utlevering av personopplysninger være korrekt. De forteller videre at det er endel grunnkrav som må være oppfylt ved utlevering av personopplysninger til tredjeparter, nærmere forklart i personopplysingsloven § 11 som henviser til § 8. Det er uklart for meg om disse kravene er oppfylt når IP-adresse og informasjon om hvilke websider som besøkes til tredjeparter.

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

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

Redaksjonssjef Kurt Lekanger svarte samme dag og forklarte at han måtte komme tilbake til meg når han hadde med utviklingsavdelingen. Seks dager senere lurte jeg på hva han fant ut, og etter noen timer fikk jeg så følgende svar fra direktøren for teknologi og forretningsutvikling Øystein W. Høie i Teknisk Ukeblad Media:

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

Retningslinjene våre har vært uklare på dette tidspunktet, og vi oppdaterer nå disse så dette kommer tydeligere frem. Ny tekst blir som følger:


3. Dette bruker vi ikke informasjonen til Informasjon du oppgir til oss blir lagret i våre systemer, er ikke tilgjengelig for tredjeparter, og blir ikke lagret i informasjonskapsler. Informasjonen vil kun benyttes til å gi deg som bruker mer relevant informasjon og bedre tjenester.

Tredjeparter (som Google Analytics, Cxense, TNS Gallup) vil kunne hente ut IP-adresse og data basert på dine surfemønstre. TU Media AS er pliktig å påse at disse tredjepartene behandler data i tråd med norsk regelverk.


Ellers har vi nå aktivert anonymisering i Google Analytics (aip=1). Kan også nevne at Tek.no-brukere som har kjøpt Tek Ekstra har mulighet til å skru av all tracking i kontrollpanelet sitt. Dette er noe vi vurderer å rulle ut på alle sidene i vårt nettverk.»

Det var nyttig å vite at vi er enige om at formuleringen i personvernpolicyen er misvisende. Derimot var det nedslående at i stedet for å endre praksis for å følge det personvernpolicyen sier om å ikke dele personinformasjon med tredjeparter, så velger Digi.no å fortsette praksis og i stedet endre personvernpolicyen slik at den å dokumentere dagens praksis med spredning av personopplysninger.

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

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

Vil tidligere håndteringen av IP-adresser og lesemønster i strid med dokumentert personvernpolicy bli varslet til Datatilsynet i tråd med personopplysningsforskriften § 2-6? Vil leserne bli varslet på en prominent og synlig måte om at lesernes IP-adresser og lesemønster har vært utlevert til tredjeparter i stid med tidligere formulering om at tredjeparter kun får anonymiserte data, og at utleveringen fortsetter etter at personvernpolicy er endret for å dokumentere praksis?

Appropos ekstra tilbud til betalende lesere, tilbyr dere en mulighet for å betale for å lese som ikke innebærer at en må gjøre det mulig å la sine lesevaner blir registeret av tek.no? Betaler gjerne for å lese nyheter, men ikke med en bit av privatlivet mitt. :)»

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

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

Vi kommer til å ta en runde og gå over vår policy i forbindelse med dette, og vil i de tilfeller det er påkrevd selvsagt være tydelig overfor brukere og tilsyn. Vil samtidig understreke at vår bruk av tredjeparts analyseverktøy og annonsetracking er helt på linje med det som er normalt for norske kommersielle nettsteder.

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

Det høres jo ikke bra ut at det er normalt for norske kommersielle nettsteder å utlevere lesernes personopplysninger til utlandet. Men som en kan lese fra gårdagens oppslag fra NRK gjelder det også norske kommuner og andre offentlige aktører, og jeg skrev om omfanget av problemet i fjor. Det er uansett ikke en praksis jeg tror er i tråd med kravene i personopplysningsloven, og heller ikke en praksis jeg som leser synes er greit. Jeg manglet dog fortsatt svar på om Digi.no kom til å varsle lesere og Datatilsynet om avviket mellom praksis og policy, så jeg forsøkte meg med en ny epost i går kveld:

«Kan du fortelle meg om dere anser det å være påkrevd å varsle tilsyn og brukere nå, når dere har oppdaget at praksis ikke har vært i tråd med personvernpolicy?»

Det spørsmålet vet jeg så langt ikke svaret på, men antagelig kan Datatilsynet svare på om det er påkrevd å varsle tilsyn og lesere om dette. Jeg planlegger å oppdatere denne bloggposten med svaret når det kommer.

Jeg synes jo det er spesielt ille når barn får sine personopplysninger spredt til utlandet, noe jeg tok opp med NRK i fjor. De to eksemplene jeg nevner er som dere forstår ikke unike, men jeg har ikke full oversikt over hvor mange nettsteder dette gjelder. Jeg har ikke kapasitet til eller glede av å lese alle personvernpolicyer i landet. Kanskje mine lesere kan sende meg tips på epost om andre nettsteder med avvik mellom policy og praksis? Hvis vi alle går sammen og kontakter de ansvarlige, kanskje noen til slutt endrer praksis og slutter å dele lesernes personopplysninger med tredjeparter?

Apropos bruken av Google Analytics kan jeg forresten nevne at Universitetet i Oslo også har tatt i bruk Google Analytics, men der lagres programkoden som overføres til nettleserne lokalt og deler av IP-adressen fjernes lokalt på universitetet via en mellomtjener/proxy (tilgjengelig via github) før informasjon sendes over til Google Analytics. Dermed er det mulig for ansvarlige for nettstedet å vite at Google ikke har tilgang til komplett IP-adresse. Årsaken til at denne metoden brukes er at juristene ved universitetet har konkludert med at det er eneste måten en kunne vurdere å bruke Google Analytics uten å bryte loven. Risikoen for gjenidentifisering og identifisering ved hjelp av nettleserinformasjon er fortsatt tilstede, så det er ingen optimal løsning, men det er bedre enn å håpe at f.eks. Google og alle som lytter på veien skal prioritere norsk lov over sin lokale lovgivning.

Oppdatering 2016-12-09: Fikk svar fra direktøren Høie på mitt spørsmål litt etter at jeg hadde publisert denne artikkelen:

Vi kommer til å annonsere en oppdatert policy, og skal undersøke om vi er pliktig å varsle Datatilsynet.

Det vi uansett ønsker å gjøre først, er å gå gjennom hele policy sammen med utviklerne og advokat, så vi er sikre på at vi går frem riktig og at det ikke er flere tvetydigheter som skjuler seg i teksten.

Har du andre idéer eller konkrete innspill til hva som kan gjøre policy tydeligere, tar vi gjerne imot det. Dette er et felt vi ønsker å være ryddige på.

Vi får se om de liker mine innspill, som i grunnen er å ikke pusse på personvernpolicyen men i stedet slutte å spre lesernes personopplysninger til eksterne aktører.

Tags: norsk, personvern, surveillance.
How to talk with your loved ones in private
7th November 2016

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:

Then the ones used by a few.

Then the ones used by even fewer people

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?

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.

Update 2019-10-08: Børge Dvergsdal, who told me he is Customer Relationship Manager @ Whereby (formerly appear.in), asked if I could mention that appear.in is now renamed and found at https://whereby.com/. And sure, why not. Apparently they changed the name because they were unable to trademark appear.in somewhere... While I am at it, I can mention that Ring changed name to Jami, now available from https://jami.net/. Luckily they were able to have a direct redirect from ring.cx to jami.net, so the user experience is almost the same.

Tags: english, personvern, sikkerhet, surveillance.
Aktivitetsbånd som beskytter privatsfæren
3rd November 2016

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.

Tags: norsk, personvern, sikkerhet, surveillance.
Experience and updated recipe for using the Signal app without a mobile phone
10th October 2016

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

The Signal app have worked fine for several months now, and I use it regularly to chat with my loved ones. I had a major snag at the end of my summer vacation, when the the app completely forgot my setup, identity and keys. The reason behind this major mess was running out of disk space. To avoid that ever happening again I have started storing everything in userdata/ in git, to be able to roll back to an earlier version if the files are wiped by mistake. I had to use it once after introducing the git backup. When rolling back to an earlier version, one need to use the 'reset session' option in Signal to get going, and notify the people you talk with about the problem. I assume there is some sequence number tracking in the protocol to detect rollback attacks. The git repository is rather big (674 MiB so far), but I have not tried to figure out if some of the content can be added to a .gitignore file due to lack of spare time.

I've also hit the 90 days timeout blocking, and noticed that this make it impossible to send messages using Signal. I could still receive them, but had to patch the code with a new timestamp to send. I believe the timeout is added by the developers to force people to upgrade to the latest version of the app, even when there is no protocol changes, to reduce the version skew among the user base and thus try to keep the number of support requests down.

Since my original recipe, the Signal source code changed slightly, making the old patch fail to apply cleanly. Below is an updated patch, including the shell wrapper I use to start Signal. The original version required a new user to locate the JavaScript console and call a function from there. I got help from a friend with more JavaScript knowledge than me to modify the code to provide a GUI button instead. This mean that to get started you just need to run the wrapper and click the 'Register without mobile phone' to get going now. I've also modified the timeout code to always set it to 90 days in the future, to avoid having to patch the code regularly.

So, the updated recipe for Debian Jessie:

  1. First, install required packages to get the source code and the browser you need. Signal only work with Chrome/Chromium, as far as I know, so you need to install it.
    apt install git tor chromium
    git clone https://github.com/WhisperSystems/Signal-Desktop.git
    
  2. 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.

Tags: debian, english, sikkerhet, surveillance.
NRKs kildevern når NRK-epost deles med utenlands etterretning?
8th October 2016

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.

Tags: betalkontant, dld, norsk, personvern, sikkerhet, surveillance.
Aftenposten-redaktøren med lua i hånda
9th September 2016

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.

Tags: norsk, surveillance.
E-tjenesten ber om innsyn i eposten til partiene på Stortinget
6th September 2016

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.

Tags: norsk, surveillance.
How to use the Signal app if you only have a land line (ie no mobile phone)
3rd July 2016

For a while now, I have wanted to test the Signal app, as it is said to provide end to end encrypted communication and several of my friends and family are already using it. As I by choice do not own a mobile phone, this proved to be harder than expected. And I wanted to have the source of the client and know that it was the code used on my machine. But yesterday I managed to get it working. I used the Github source, compared it to the source in the Signal Chrome app available from the Chrome web store, applied patches to use the production Signal servers, started the app and asked for the hidden "register without a smart phone" form. Here is the recipe how I did it.

First, I fetched the Signal desktop source from Github, using

git clone https://github.com/WhisperSystems/Signal-Desktop.git

Next, I patched the source to use the production servers, to be able to talk to other Signal users:

cat <<EOF | patch -p0
diff -ur ./js/background.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js
--- ./js/background.js  2016-06-29 13:43:15.630344628 +0200
+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js    2016-06-29 14:06:29.530300934 +0200
@@ -47,8 +47,8 @@
         });
     });
 
-    var SERVER_URL = 'https://textsecure-service-staging.whispersystems.org';
-    var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments-staging.s3.amazonaws.com';
+    var SERVER_URL = 'https://textsecure-service-ca.whispersystems.org:4433';
+    var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments.s3.amazonaws.com';
     var messageReceiver;
     window.getSocketStatus = function() {
         if (messageReceiver) {
diff -ur ./js/expire.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js
--- ./js/expire.js      2016-06-29 13:43:15.630344628 +0200
+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js2016-06-29 14:06:29.530300934 +0200
@@ -1,6 +1,6 @@
 ;(function() {
     'use strict';
-    var BUILD_EXPIRATION = 0;
+    var BUILD_EXPIRATION = 1474492690000;
 
     window.extension = window.extension || {};
 
EOF

The first part is changing the servers, and the second is updating an expiration timestamp. This timestamp need to be updated regularly. It is set 90 days in the future by the build process (Gruntfile.js). The value is seconds since 1970 times 1000, as far as I can tell.

Based on a tip and good help from the #nuug IRC channel, I wrote a script to launch Signal in Chromium.

#!/bin/sh
cd $(dirname $0)
mkdir -p userdata
exec chromium \
  --proxy-server="socks://localhost:9050" \
  --user-data-dir=`pwd`/userdata --load-and-launch-app=`pwd`

The script start the app and configure Chromium to use the Tor SOCKS5 proxy to make sure those controlling the Signal servers (today Amazon and Whisper Systems) as well as those listening on the lines will have a harder time location my laptop based on the Signal connections if they use source IP address.

When the script starts, one need to follow the instructions under "Standalone Registration" in the CONTRIBUTING.md file in the git repository. I right clicked on the Signal window to get up the Chromium debugging tool, visited the 'Console' tab and wrote 'extension.install("standalone")' on the console prompt to get the registration form. Then I entered by land line phone number and pressed 'Call'. 5 seconds later the phone rang and a robot voice repeated the verification code three times. After entering the number into the verification code field in the form, I could start using Signal from my laptop.

As far as I can tell, The Signal app will leak who is talking to whom and thus who know who to those controlling the central server, but such leakage is hard to avoid with a centrally controlled server setup. It is something to keep in mind when using Signal - the content of your chats are harder to intercept, but the meta data exposing your contact network is available to people you do not know. So better than many options, but not great. And sadly the usage is connected to my land line, thus allowing those controlling the server to associate it to my home and person. I would prefer it if only those I knew could tell who I was on Signal. There are options avoiding such information leakage, but most of my friends are not using them, so I am stuck with Signal for now.

Update 2017-01-10: There is an updated blog post on this topic in Experience and updated recipe for using the Signal app without a mobile phone.

Tags: debian, english, sikkerhet, surveillance.
Snurpenot-overvåkning av sensitiv personinformasjon
9th November 2015

Tenk om et norsk sykehus delte informasjon om hva som blir lest og hvem som leser på sykehusets nettsted, med noen som samarbeider med et fremmed lands etterretningsvesen, og at flere andre fremmede lands etterretningstjenester kan snappe opp informasjonen.

Tenk om flere sykehus, kommuner, helsestasjoner, universitet, høyskoler, grunnskoler, Stortinget, det meste av offentlig forvaltning, medier, adopsjonstjenester og krisesenter gjør det samme?

Tenk om de som lytter kan holde oversikt over norske borgeres interesser, sykdommer, rusmisbruk, adopsjon, abort, barnehager, politiske interesser og sympatier samt hvilke argumenter som har best effekt på beslutningstagere og måter de kan påvirkes. Ville det gitt grunn til bekymring?

Høres det ut som noe tatt ut fra fantasien til George Orwell, forfatteren av dystopien 1984? Det er virkeligheten i Norge i dag, takket være bruken av statistikktjenester som Google Analytics.

Du kan beskytte deg

Men borgerne har et forsvar mot dette angrepet på privatsfæren. Dagens nettlesere har utvidelser som støtter å blokkere slik utlevering av informasjon. Personlig bruker jeg Privacy Badger, Ghostery, NoScript og AdBlock, og anbefaler alle å gjøre noe tilsvarende. Merk at noen av verktøyene lekker informasjon, i tillegg til å gjøre en nyttig jobb, så det er lurt å bruke flere sammen. I tillegg bør hver og en av oss sende inn protest til organisasjonene bak nettsteder som bidrar til dette inngrepet i privatsfæren.

Hvem bidrar til overvåkningen?

Takket være Ghostery la jeg merke til at flere og flere norske nettsteder begynte å la Google Analytics overvåke brukerne. Jeg ble nysgjerrig på hvor mange det gjaldt, og gikk igjennom ca. 2700 norske nettsteder, hovedsakelig offentlig forvaltning. Jeg laget et system for å koble seg opp automatisk og sjekke hvor nettstedene spredte informasjon om besøket. Jeg ble overrasket både over omfanget og hva slags nettsteder som rapporterer besøksinformasjon ut av landet. Omtrent 70 prosent av de 2700 sender informasjon til Google Analytics. Noen tilfeldige eksempler er Akershus Universitetssykehus, Sykehuset Østfold, Lommelegen, Oslo krisesenter, Stortinget, den norske regjering, de fleste politiske partier på Stortinget, NAV, Altinn, NRK, TV2, Helse Førde, Helse Stavanger, Oslo kommune, Nasjonalbiblioteket, Pasientombudet, Kongehuset, Politiet, Teknologirådet, Tollvesenet, Norsk romsenter, Forsvarsbygg og Sivilforsvaret. Og det er mange flere.

Hvordan kan det offentlige Norge omfavne en slik praksis? Det er gode hensikter bak. Google har laget en god tjeneste for nettstedseiere, der de uten å betale med noe annet enn en bit av de besøkenes privatsfære får tilgang til nyttig og presis statistikk over nettstedets bruk ved å besøke netttjenesten hos Google. De færreste merker ulempene angrepet på privatsfæren som nettstedene og Google utgjør.

Hvordan foregår det?

I nettsider kan nettsteder legge inn lenker til programkode som skal kjøres av brukerens nettleser. De som tar i bruk Google Analytics legger typisk inn lenke til et javascript-program hos Google som ber nettleseren ta kontakt med Google og dele IP-adresse, side besøkt, aktuelle cookies og endel informasjon om nettleseren med Google Analytics. Programmet trenger ikke være det samme for alle som henter det fra Google. Det finnes et Google Analytics-tilvalg kalt «anonymisering» som nettstedeier kan ta i bruk. Dette instruerer det omtalte programmet om å be Google slette deler av den oversendte IP-adressen. Full IP-adresse sendes likevel over og er tilgjengelig for alle som snapper opp informasjonen underveis.

Takket være varsleren Edward Snowden, som bidro til uvurderlig dokumentasjon på snurpenot-overvåkningen som nordmenn blir utsatt for, vet vi at Google samarbeider med USAs etteretning som avlytter trafikk sendt til Google Analytics.

Men allerede før Snowden var det bekreftet at både britiske GCHQ og USAs NSA avlytter og lagrer blant annet Internett-trafikk som er innom et av landene, i tillegg til at FRA i Sverige avlytter og lagrer trafikk som passerte grensa til Sverige.

Og som Datatilsynet sa til Dagens Næringsliv i 2013 kunne de vanskelig nekte bruk av skytjenester som Google Analytics når Norge var bundet av EUs «Safe Harbour»-avtale med USA. De måtte derfor se bort fra f.eks. FISAAA-loven (som lar NSA avlytte Internett-trafikk) i sine vurderinger. Når nå EUs «Safe Harbour»-avtale er underkjent, og det foreslås å bruke individuell avtalerett mellom selskaper som juridisk grunnlag for å sende personopplysninger til USA, er det greit å huske på at FISAA-loven og andre som brukes av USA som grunnlag for masseovervåkning overstyrer slike avtaler.

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

Tags: norsk, personvern, surveillance.
Lawrence Lessig interviewed Edward Snowden a year ago
19th October 2015

Last year, US president candidate in the Democratic Party Lawrence interviewed Edward Snowden. The one hour interview was published by Harvard Law School 2014-10-23 on Youtube, and the meeting took place 2014-10-20.

The questions are very good, and there is lots of useful information to be learned and very interesting issues to think about being raised. Please check it out.

I find it especially interesting to hear again that Snowden did try to bring up his reservations through the official channels without any luck. It is in sharp contrast to the answers made 2013-11-06 by the Norwegian prime minister Erna Solberg to the Norwegian Parliament, claiming Snowden is no Whistle-Blower because he should have taken up his concerns internally and using official channels. It make me sad that this is the political leadership we have here in Norway.

Tags: english, personvern, sikkerhet, surveillance.
Alle Stortingets mobiltelefoner kontrolleres fra USA...
7th October 2015

Jeg lot meg fascinere av en artikkel i Aftenposten der det fortelles at «over 600 telefoner som benyttes av stortingsrepresentanter, rådgivere og ansatte på Stortinget, kan «fjernstyres» ved hjelp av programvaren Airwatch, et såkalte MDM-program (Mobile Device Managment)». Det hele bagatelliseres av Stortingets IT-stab, men det er i hovedsak på grunn av at journalisten ikke stiller de relevante spørsmålene. For meg er det relevante spørsmålet hvem som har lovlig tilgang (i henhold til lokal lovgiving, dvs. i hvert fall i Norge, Sverige, UK og USA) til informasjon om og på telefonene, og hvor enkelt det er å skaffe seg tilgang til hvor mobilene befinner seg og informasjon som befinner seg på telefonene ved hjelp av utro tjenere, trusler, innbrudd og andre ulovlige metoder.

Bruken av AirWatch betyr i realiteten at USAs etteretning og politimyndigheter har full tilgang til stortingets mobiltelefoner, inkludert posisjon og innhold, takket være FISAAA-loven og "National Security Letters" og det enkle faktum at selskapet AirWatch er kontrollert av et selskap i USA. I tillegg er det kjent at flere lands etterretningstjenester kan lytte på trafikken når den passerer landegrensene.

Jeg har bedt om mer informasjon fra Stortinget om bruken av AirWatch via Mimes brønn så får vi se hva de har å fortelle om saken. Fant ingenting om 'airwatch' i postjournalen til Stortinget, så jeg trenger hjelp før jeg kan be om innsyn i konkrete dokumenter.

Oppdatering 2015-10-07: Jeg er blitt spurt hvorfor jeg antar at AirWatch-agenten rapporterer til USA og ikke direkte til Stortingets egen infrastruktur. Det stemmer at det er teknisk mulig å sette opp mobiltelefonene til å rapportere til datamaskiner som eies av Stortinget. Jeg antar det rapporteres til AirWatch sine sentrale tjenester basert på det jeg leste fra beskrivelsen av Mobile Device Management på AirWatch sine egne nettsider, koblet med at det brukes en standard app som kan hentes fra "app-butikkene" for å få tilgang. Enten må app-en settes opp individuelt hos Stortinget, eller så får den beskjed fra AirWatch i USA om hvor den skal koble seg opp. I det første tilfellet vil den ikke rapportere direkte til USA, men til programvare utviklet av AirWatch som kjører på en maskin under Stortingets kontroll. Det er litt bedre, men fortsatt vil det være umulig for Stortinget å være sikker på hva programvaren som tar imot forbindelser gjør. Jeg ser fra beskrivelsen av Enterprice Integration hos AirWatch at det er mulig å ha lokal installasjon, og håper innsynsforespørsler mot Stortinget kan fortelle mer om hvordan ting konkret fungerer der.

Tags: norsk, offentlig innsyn, personvern, sikkerhet, stortinget, surveillance.
Blir det virkelig krav om fingeravtrykk i nasjonale ID-kort?
12th May 2015

Noen finner det vanskelig å tro at Stortinget faktisk har vedtatt å kreve at alle norske borgerne må avgi fingeravtrykk til politiet for å fungere i samfunnet. Jeg er blitt spurt hva som er grunnlaget for min påstand i forrige bloggpost om at det nå blir krav om å avgi fingeravtrykk til politiet for å fungere som borger i Norge. De som spør klarer ikke lese det ut fra det som er vedtatt. Her er en liten oppsummering om hva jeg baserer det på. Det sies ikke direkte i hverken proposisjon, innstilling eller vedtak, men fremgår når en ser på indirekte formuleringer.

I stortingsproposisjon 66, avsnitt 6.3.5 (Avgivelse av biometriske personopplysninger) står det

Departementet foreslår at både ansiktsfoto og fingeravtrykk skal kunne opptas og lagres som identifikasjonsdata i de nasjonale ID-kortene, på samme måte som i passene. Lovforslaget er derfor utformet i tråd med passloven § 6 annet ledd, som fastslår at det til bruk for senere verifisering eller kontroll av passinnehaverens identitet kan innhentes og lagres i passet biometrisk personinformasjon i form av ansiktsfoto og fingeravtrykk (to fingre). Dagens ordning med lagring av ansiktsfoto og fingeravtrykk i et kontaktløst smartkort i passet er basert på internasjonale standarder. Fingeravtrykkene i nasjonalt ID-kort vil bli beskyttet på samme måte som fingeravtrykkene i passene.

[...]

For norske forhold understreker departementet at innføring av nasjonale ID-kort sammen med innføring av nye systemer for sikrere utstedelse og kontroll av pass og relaterte dokumenter gir mulighet til å utforme ordningen slik at den best mulig møter utfordringene forbundet med identitetskriminalitet. Det tilsier at fingeravtrykk opptas og lagres i alle nasjonale ID-kort.

Departementet sier altså at sin anbefaling er at fingeravtrykk skal opptas og lagres i alle nasjonale ID-kort. Det skrives som om det blir valgfritt, på samme måten som det skrives passloven, der det i loven sier at det kan «innhentes og lagres i passet biometrisk personinformasjon i form av ansiktsfoto og fingeravtrykk (to fingre)». Men på tross av bruken av «kan» i passloven er det innført krav om å avgi fingeravtrykk for å få et pass i Norge. Proposisjonen sier i tillegg i del 1 (Proposisjonens hovedinnhold) at ID-kortene skal være like pålitelig som pass og ha samme sikkerhetsnivå som pass. Departementet foreslår altså at ID-kortene skal gis etter samme regler som for pass.

Formuleringene fra hovedinnholdet i proposisjonen er videreført i innstillingen fra stortingskomiteen, der det konkret står «De foreslåtte reglene vil gi befolkningen tilbud om et offentlig utstedt identitetsbevis som vil være like pålitelig som passet, og mer praktisk å bruke som legitimasjon» og «Det nasjonale ID-kortet skal også holde samme sikkerhetsnivå som passet». Komiteen har altså ingen kommentarer eller innsigelser til dette forslaget, og gjorde i debatten da saken ble vedtatt det klart at dette var en god sak og at en enstemmig komité var glad for resultatet. Stortinget har dermed stilt seg helt og fullt bak departementets forslag.

For meg er det åpenbart når en leser proposisjonen at «like pålitelig» og «samme sikkerhetsnivå» vil bli tolket av departementet som «med samme biometrisk informasjon som i passene», og departementet forklarer i tillegg i proposisjonen at de har tenkt at fingeravtrykkene «vil bli beskyttet på samme måte som fingeravtrykkene i passene». Jeg ser det dermed som åpenbart at den samme tvangsinnhentingen av fingeravtrykk som gjelder for pass vil bli viderført til de nasjonale ID-kortene.

Det eneste som kan endre dette er massive protester fra befolkningen på at folk som ikke er mistenkt for noe kriminelt skal tvinges til å gi fingeravtrykket til politiet for å f.eks. kunne få bankkonto eller stemme ved valg. Det kunne få departementet til å snu. Det tror jeg ikke vil skje.

Tags: norsk, personvern, surveillance.
Norwegian citizens now required by law to give their fingerprint to the police
10th May 2015

5 days ago, the Norwegian Parliament decided, unanimously, that all citizens of Norway, no matter if they are suspected of something criminal or not, are required to give fingerprints to the police (vote details from Holder de ord). The law make it sound like it will be optional, but in a few years there will be no option any more. The ID will be required to vote, to get a bank account, a bank card, to change address on the post office, to receive an electronic ID or to get a drivers license and many other tasks required to function in Norway. The banks plan to stop providing their own ID on the bank cards when this new national ID is introduced, and the national road authorities plan to change the drivers license to no longer be usable as identity cards. In effect, to function as a citizen in Norway a national ID card will be required, and to get it one need to provide the fingerprints to the police.

In addition to handing the fingerprint to the police (which promised to not make a copy of the fingerprint image at that point in time, but say nothing about doing it later), a picture of the fingerprint will be stored on the RFID chip, along with a picture of the face and other information about the person. Some of the information will be encrypted, but the encryption will be the same system as currently used in the passports. The codes to decrypt will be available to a lot of government offices and their suppliers around the globe, but for those that do not know anyone in those circles it is good to know that the encryption is already broken. And they can be read from 70 meters away. This can be mitigated a bit by keeping it in a Faraday cage (metal box or metal wire container), but one will be required to take it out of there often enough to expose ones private and personal information to a lot of people that have no business getting access to that information.

The new Norwegian national IDs are a vehicle for identity theft, and I feel sorry for us all having politicians accepting such invasion of privacy without any objections. So are the Norwegian passports, but it has been possible to function in Norway without those so far. That option is going away with the passing of the new law. In this, I envy the Germans, because for them it is optional how much biometric information is stored in their national ID.

And if forced collection of fingerprints was not bad enough, the information collected in the national ID card register can be handed over to foreign intelligence services and police authorities, "when extradition is not considered disproportionate".

Update 2015-05-12: For those unable to believe that the Parliament really could make such decision, I wrote a summary of the sources I have for concluding the way I do (Norwegian Only, as the sources are all in Norwegian).

Tags: english, personvern, surveillance.
What would it cost to store all phone calls in Norway?
1st May 2015

Many years ago, a friend of mine calculated how much it would cost to store the sound of all phone calls in Norway, and came up with the cost of around 20 million NOK (2.4 mill EUR) for all the calls in a year. I got curious and wondered what the same calculation would look like today. To do so one need an idea of how much data storage is needed for each minute of sound, how many minutes all the calls in Norway sums up to, and the cost of data storage.

The 2005 numbers are from digi.no, the 2012 numbers are from a NKOM report, and I got the 2013 numbers after asking NKOM via email. I was told the numbers for 2014 will be presented May 20th, and decided not to wait for those, as I doubt they will be very different from the numbers from 2013.

The amount of data storage per minute sound depend on the wanted quality, and for phone calls it is generally believed that 8 Kbit/s is enough. See for example a summary on voice quality from Cisco for some alternatives. 8 Kbit/s is 60 Kbytes/min, and this can be multiplied with the number of call minutes to get the storage requirements.

Storage prices varies a lot, depending on speed, backup strategies, availability requirements etc. But a simple way to calculate can be to use the price of a TiB-disk (around 1000 NOK / 120 EUR) and double it to take space, power and redundancy into account. It could be much higher with high speed and good redundancy requirements.

But back to the question, What would it cost to store all phone calls in Norway? Not much. Here is a small table showing the estimated cost, which is within the budget constraint of most medium and large organisations:

YearCall minutesSizePrice in NOK / EUR
200524 000 000 0001.3 PiB3 mill / 358 000
201218 000 000 0001.0 PiB2.2 mill / 262 000
201317 000 000 000950 TiB2.1 mill / 250 000

This is the cost of buying the storage. Maintenance need to be taken into account too, but calculating that is left as an exercise for the reader. But it is obvious to me from those numbers that recording the sound of all phone calls in Norway is not going to be stopped because it is too expensive. I wonder if someone already is collecting the data?

Tags: english, personvern, surveillance.
The Citizenfour documentary on the Snowden confirmations to Norway
28th February 2015

Today I was happy to learn that the documentary Citizenfour by Laura Poitras finally will show up in Norway. According to the magazine Montages, a deal has finally been made for Cinema distribution in Norway and the movie will have its premiere soon. This is great news. As part of my involvement with the Norwegian Unix User Group, me and a friend have tried to get the movie to Norway ourselves, but obviously we were too late and Tor Fosse beat us to it. I am happy he did, as the movie will make its way to the public and we do not have to make it happen ourselves. The trailer can be seen on youtube, if you are curious what kind of film this is.

The whistle blower Edward Snowden really deserve political asylum here in Norway, but I am afraid he would not be safe.

Tags: english, nuug, personvern, surveillance.
Vi kan selv avsløre mobiltelefonovervåkning
3rd January 2015

Jeg sendte inn følgende leserinnlegg 2014-12-26, og etter en uke synes jeg det er på tide å publisere teksten på bloggen min.

Vi kan selv avsløre mobiltelefonovervåkning

Det er fascinerende å lese hvordan overvåkningen av mobiltelefoner med IMSI-fangere som Aftenposten avslørte har blitt mottatt. Men det er spesielt to poeng som jeg synes har fått for liten oppmerksomhet.

Det ene er at innbyggerne nå selv kan avsløre når noen forsøker å overvåke oss. Det hele lar seg gjøre takket være en fribruksdatabase over plasseringen til kjente mobilbasestasjoner som heter OpenCellID. Enhver med en Android-basert mobiltelefon kan ta i bruk «Android IMSI Catcher Detector» ved å laste den ned fra Internett og slik få tak i verktøyet som Aftenposten brukte for å oppdage de uoffisielle mobilbasestasjonene. Ved hjelp av dette verktøyet kan Android-brukere få varsel i smarttelefonen når slike oppdages, uansett om det er kriminelle, offisielle myndigheter eller utenlandske etterretningsorganisasjoner som står bak. Vi har dermed alle mulighet til å oppdage avlytting, og trenger ikke håpe på at PST, Post og Teletilsynet eller mobilselskapene gjør jobben for oss. De vil uansett måtte holde overvåkning fra offisielle myndigheter skjult for befolkningen.

Det andre er at den viktigste informasjonen IMSI-fangere samler inn er hvem som er i kontakt med hvem og hvor de befinner seg (også kalt metadata), ikke hva som blir sagt og skrevet når folk er i kontakt med hverandre. Den som f.eks. vet hvilke politikere som snakker med hvem kan få innsikt i hvordan politikere påvirkes og hvilke sårbare punkter de har. Forskerne ved senter for Internet og samfunn ved Stanford Law School har dokumenterte i sitt metadata-prosjekt at slik innsamlet informasjon blant annet kan avsløre medisinske tilstander, politiske sympatier, religiøse overbevisninger. I tillegg har den pensjonerte generalen Michael Hayden i USA, som har ledet både CIA og NSA, innrømmet at USA dreper folk basert på innsamlede metadata. Begge deler forteller hvor verdifullt metadata er, og gir grunn til å være mer bekymret for innsamling av metadata enn avlytting.

Seniorrådgiver Roar Thon i Nasjonal Sikkerhetsmyndighet sier ofte at hver og en av oss er ansvarlig for vår egen sikkerhet, og Aftenpostens avsløring har gjort flere kjent med verktøy vi har tilgjengelig for å ta dette ansvaret. Men det reelle problemet er jo ikke at det settes opp utstyr vi ikke kan stole på, men at telefonsystemet er laget slik at det er mulig å sette opp slik utstyr.

Vennlig hilsen
Petter Reinholdtsen
Medlem i foreningen NUUG

Etter at jeg skrev dette innlegget ble en ny Android-app, SnoopSnitch, som gjør tilsvarende sniffing etter uoffisielle mobilbasestasjoner lansert. Jeg vet ikke hvilke av dem som er best.

Tags: norsk, nuug, personvern, surveillance.
Of course USA loses in cyber war - NSA and friends made sure it would happen
19th December 2014

So, Sony caved in (according to Rob Lowe) and demonstrated that America lost its first cyberwar (according to Newt Gingrich). It should not surprise anyone, after the whistle blower Edward Snowden documented that the government of USA and their allies for many years have done their best to make sure the technology used by its citizens is filled with security holes allowing the secret services to spy on its own population. No one in their right minds could believe that the ability to snoop on the people all over the globe could only be used by the personnel authorized to do so by the president of the United States of America. If the capabilities are there, they will be used by friend and foe alike, and now they are being used to bring Sony on its knees.

I doubt it will a lesson learned, and expect USA to lose its next cyber war too, given how eager the western intelligence communities (and probably the non-western too, but it is less in the news) seem to be to continue its current dragnet surveillance practice.

There is a reason why China and others are trying to move away from Windows to Linux and other alternatives, and it is not to avoid sending its hard earned dollars to Cayman Islands (or whatever tax haven Microsoft is using these days to collect the majority of its income. :)

Tags: english, personvern, surveillance.
A Debian package for SMTP via Tor (aka SMTorP) using exim4
10th November 2014

The right to communicate with your friends and family in private, without anyone snooping, is a right every citicen have in a liberal democracy. But this right is under serious attack these days.

A while back it occurred to me that one way to make the dragnet surveillance conducted by NSA, GCHQ, FRA and others (and confirmed by the whisleblower Snowden) more expensive for Internet email, is to deliver all email using SMTP via Tor. Such SMTP option would be a nice addition to the FreedomBox project if we could send email between FreedomBox machines without leaking metadata about the emails to the people peeking on the wire. I proposed this on the FreedomBox project mailing list in October and got a lot of useful feedback and suggestions. It also became obvious to me that this was not a novel idea, as the same idea was tested and documented by Johannes Berg as early as 2006, and both the Mailpile and the Cables systems propose a similar method / protocol to pass emails between users.

To implement such system one need to set up a Tor hidden service providing the SMTP protocol on port 25, and use email addresses looking like username@hidden-service-name.onion. With such addresses the connections to port 25 on hidden-service-name.onion using Tor will go to the correct SMTP server. To do this, one need to configure the Tor daemon to provide the hidden service and the mail server to accept emails for this .onion domain. To learn more about Exim configuration in Debian and test the design provided by Johannes Berg in his FAQ, I set out yesterday to create a Debian package for making it trivial to set up such SMTP over Tor service based on Debian. Getting it to work were fairly easy, and the source code for the Debian package is available from github. I plan to move it into Debian if further testing prove this to be a useful approach.

If you want to test this, set up a blank Debian machine without any mail system installed (or run apt-get purge exim4-config to get rid of exim4). Install tor, clone the git repository mentioned above, build the deb and install it on the machine. Next, run /usr/lib/exim4-smtorp/setup-exim-hidden-service and follow the instructions to get the service up and running. Restart tor and exim when it is done, and test mail delivery using swaks like this:

torsocks swaks --server dutlqrrmjhtfa3vp.onion \
  --to fbx@dutlqrrmjhtfa3vp.onion

This will test the SMTP delivery using tor. Replace the email address with your own address to test your server. :)

The setup procedure is still to complex, and I hope it can be made easier and more automatic. Especially the tor setup need more work. Also, the package include a tor-smtp tool written in C, but its task should probably be rewritten in some script language to make the deb architecture independent. It would probably also make the code easier to review. The tor-smtp tool currently need to listen on a socket for exim to talk to it and is started using xinetd. It would be better if no daemon and no socket is needed. I suspect it is possible to get exim to run a command line tool for delivery instead of talking to a socket, and hope to figure out how in a future version of this system.

Until I wipe my test machine, I can be reached using the fbx@dutlqrrmjhtfa3vp.onion mail address, deliverable over SMTorP. :)

Tags: debian, english, freedombox, personvern, surveillance.
Hva henger under skibrua over E16 på Sollihøgda?
21st September 2014

Rundt omkring i Oslo og Østlandsområdet henger det bokser over veiene som jeg har lurt på hva gjør. De har ut fra plassering og vinkling sett ut som bokser som sniffer ut et eller annet fra forbipasserende trafikk, men det har vært uklart for meg hva det er de leser av. Her om dagen tok jeg bilde av en slik boks som henger under ei skibru på Sollihøgda:

Boksen er tydelig merket «Kapsch >>>», logoen til det sveitsiske selskapet Kapsch som blant annet lager sensorsystemer for veitrafikk. Men de lager mye forskjellig, og jeg kjente ikke igjen boksen på utseendet etter en kjapp titt på produktlista til selskapet.

I og med at boksen henger over veien E16, en riksvei vedlikeholdt av Statens Vegvesen, så antok jeg at det burde være mulig å bruke REST-API-et som gir tilgang til vegvesenets database over veier, skilter og annet veirelatert til å finne ut hva i alle dager dette kunne være. De har både en datakatalog og et søk, der en kan søke etter ulike typer oppføringer innen for et gitt geografisk område. Jeg laget et enkelt shell-script for å hente ut antall av en gitt type innenfor området skibrua dekker, og listet opp navnet på typene som ble funnet. Orket ikke slå opp hvordan URL-koding av aktuelle strenger kunne gjøres mer generisk, og brukte en stygg sed-linje i stedet.

#!/bin/sh
urlmap() {
    sed \
    -e 's/  / /g'   -e 's/{/%7B/g'  \
    -e 's/}/%7D/g'  -e 's/\[/%5B/g' \
    -e 's/\]/%5D/g' -e 's/ /%20/g'  \
    -e 's/,/%2C/g'  -e 's/\"/%22/g' \
    -e 's/:/%3A/g'
}

lookup() {
    url="$1"
    curl -s -H 'Accept: application/vnd.vegvesen.nvdb-v1+xml' \
       "https://www.vegvesen.no/nvdb/api$url" | xmllint --format -
}

for id in $(seq 1 874) ; do
    search="{
  lokasjon: {
    bbox: \"10.34425,59.96386,10.34458,59.96409\",
    srid: \"WGS84\"
  },
   objektTyper: [{
     id: $id, antall: 10
   }]
}"

    query=/sok?kriterie=$(echo $search | urlmap)
    if lookup "$query" |
    grep -q '<totaltAntallReturnert>0<'
    then
    :
    else
    echo $id
    lookup "/datakatalog/objekttyper/$id" |grep '^  <navn>'
    fi
done

exit 0
Aktuelt ID-område 1-874 var riktig i datakatalogen da jeg laget scriptet. Det vil endre seg over tid. Skriptet listet så opp aktuelle typer i og rundt skibrua:
5
  <navn>Rekkverk</navn>
14
  <navn>Rekkverksende</navn>
47
  <navn>Trafikklomme</navn>
49
  <navn>Trafikkøy</navn>
60
  <navn>Bru</navn>
79
  <navn>Stikkrenne/Kulvert</navn>
80
  <navn>Grøft, åpen</navn>
86
  <navn>Belysningsstrekning</navn>
95
  <navn>Skiltpunkt</navn>
96
  <navn>Skiltplate</navn>
98
  <navn>Referansestolpe</navn>
99
  <navn>Vegoppmerking, langsgående</navn>
105
  <navn>Fartsgrense</navn>
106
  <navn>Vinterdriftsstrategi</navn>
172
  <navn>Trafikkdeler</navn>
241
  <navn>Vegdekke</navn>
293
  <navn>Breddemåling</navn>
301
  <navn>Kantklippareal</navn>
318
  <navn>Snø-/isrydding</navn>
445
  <navn>Skred</navn>
446
  <navn>Dokumentasjon</navn>
452
  <navn>Undergang</navn>
528
  <navn>Tverrprofil</navn>
532
  <navn>Vegreferanse</navn>
534
  <navn>Region</navn>
535
  <navn>Fylke</navn>
536
  <navn>Kommune</navn>
538
  <navn>Gate</navn>
539
  <navn>Transportlenke</navn>
540
  <navn>Trafikkmengde</navn>
570
  <navn>Trafikkulykke</navn>
571
  <navn>Ulykkesinvolvert enhet</navn>
572
  <navn>Ulykkesinvolvert person</navn>
579
  <navn>Politidistrikt</navn>
583
  <navn>Vegbredde</navn>
591
  <navn>Høydebegrensning</navn>
592
  <navn>Nedbøyningsmåling</navn>
597
  <navn>Støy-luft, Strekningsdata</navn>
601
  <navn>Oppgravingsdata</navn>
602
  <navn>Oppgravingslag</navn>
603
  <navn>PMS-parsell</navn>
604
  <navn>Vegnormalstrekning</navn>
605
  <navn>Værrelatert strekning</navn>
616
  <navn>Feltstrekning</navn>
617
  <navn>Adressepunkt</navn>
626
  <navn>Friksjonsmåleserie</navn>
629
  <navn>Vegdekke, flatelapping</navn>
639
  <navn>Kurvatur, horisontalelement</navn>
640
  <navn>Kurvatur, vertikalelement</navn>
642
  <navn>Kurvatur, vertikalpunkt</navn>
643
  <navn>Statistikk, trafikkmengde</navn>
647
  <navn>Statistikk, vegbredde</navn>
774
  <navn>Nedbøyningsmåleserie</navn>
775
  <navn>ATK, influensstrekning</navn>
794
  <navn>Systemobjekt</navn>
810
  <navn>Vinterdriftsklasse</navn>
821
  <navn>Funksjonell vegklasse</navn>
825
  <navn>Kurvatur, stigning</navn>
838
  <navn>Vegbredde, beregnet</navn>
862
  <navn>Reisetidsregistreringspunkt</navn>
871
  <navn>Bruksklasse</navn>

Av disse ser ID 775 og 862 mest relevant ut. ID 775 antar jeg refererer til fotoboksen som står like ved brua, mens «Reisetidsregistreringspunkt» kanskje kan være boksen som henger der. Hvordan finner jeg så ut hva dette kan være for noe. En titt på datakatalogsiden for ID 862/Reisetidsregistreringspunkt viser at det er finnes 53 slike målere i Norge, og hvor de er plassert, men gir ellers få detaljer. Det er plassert 40 på østlandet og 13 i Trondheimsregionen. Men siden nevner «AutoPASS», og hvis en slår opp oppføringen på Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det være snakk om Ciber Norge AS, et selskap eid av Ciber Europe Bv?) Et nettsøk på «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i 2013 med tittel «Sjekk dette hvis du vil unngå kø». Artikkelen henviser til vegvesenets nettside reisetider.no som har en kartside for Østlandet som viser at det måles mellom Sandvika og Sollihøgda. Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.

Hvis det stemmer, så er dette bokser som leser av AutoPASS-ID-en til alle passerende biler med AutoPASS-brikke, og dermed gjør det mulig for de som kontrollerer boksene å holde rede på hvor en gitt bil er når den passerte et slikt målepunkt. NRK-artikkelen forteller at denne informasjonen i dag kun brukes til å koble to AutoPASS-brikkepasseringer passeringer sammen for å beregne reisetiden, og at bruken er godkjent av Datatilsynet. Det er desverre ikke mulig for en sjåfør som passerer under en slik boks å kontrollere at AutoPASS-ID-en kun brukes til dette i dag og i fremtiden.

I tillegg til denne type AutoPASS-sniffere vet jeg at det også finnes mange automatiske stasjoner som tar betalt pr. passering (aka bomstasjoner), og der lagres informasjon om tid, sted og bilnummer i 10 år. Finnes det andre slike sniffere plassert ut på veiene?

Personlig har jeg valgt å ikke bruke AutoPASS-brikke, for å gjøre det vanskeligere og mer kostbart for de som vil invadere privatsfæren og holde rede på hvor bilen min beveger seg til enhver tid. Jeg håper flere vil gjøre det samme, selv om det gir litt høyere private utgifter (dyrere bompassering). Vern om privatsfæren koster i disse dager.

Takk til Jan Kristian Jensen i Statens Vegvesen for tips om dokumentasjon på vegvesenets REST-API.

Bruksvilkår på bildet er public domain eller CC0 alt etter hva som fungerer best for mottaker.

Oppdatering 2014-12-17: Veldig hyggelig å se at mine notater fikk omtale på vegdata-bloggen.

Tags: kart, norsk, personvern, rfid, surveillance.
FreedomBox milestone - all packages now in Debian Sid
15th April 2014

The Freedombox project is working on providing the software and hardware to make it easy for non-technical people to host their data and communication at home, and being able to communicate with their friends and family encrypted and away from prying eyes. It is still going strong, and today a major mile stone was reached.

Today, the last of the packages currently used by the project to created the system images were accepted into Debian Unstable. It was the freedombox-setup package, which is used to configure the images during build and on the first boot. Now all one need to get going is the build code from the freedom-maker git repository and packages from Debian. And once the freedombox-setup package enter testing, we can build everything directly from Debian. :)

Some key packages used by Freedombox are freedombox-setup, plinth, pagekite, tor, privoxy, owncloud and dnsmasq. There are plans to integrate more packages into the setup. User documentation is maintained on the Debian wiki. Please check out the manual and help us improve it.

To test for yourself and create boot images with the FreedomBox setup, run this on a Debian machine using a user with sudo rights to become root:

sudo apt-get install git vmdebootstrap mercurial python-docutils \
  mktorrent extlinux virtualbox qemu-user-static binfmt-support \
  u-boot-tools
git clone http://anonscm.debian.org/git/freedombox/freedom-maker.git \
  freedom-maker
make -C freedom-maker dreamplug-image raspberry-image virtualbox-image

Root access is needed to run debootstrap and mount loopback devices. See the README in the freedom-maker git repo for more details on the build. If you do not want all three images, trim the make line. Note that the virtualbox-image target is not really virtualbox specific. It create a x86 image usable in kvm, qemu, vmware and any other x86 virtual machine environment. You might need the version of vmdebootstrap in Jessie to get the build working, as it include fixes for a race condition with kpartx.

If you instead want to install using a Debian CD and the preseed method, boot a Debian Wheezy ISO and use this boot argument to load the preseed values:

url=http://www.reinholdtsen.name/freedombox/preseed-jessie.dat

I have not tested it myself the last few weeks, so I do not know if it still work.

If you wonder how to help, one task you could look at is using systemd as the boot system. It will become the default for Linux in Jessie, so we need to make sure it is usable on the Freedombox. I did a simple test a few weeks ago, and noticed dnsmasq failed to start during boot when using systemd. I suspect there are other problems too. :) To detect problems, there is a test suite included, which can be run from the plinth web interface.

Give it a go and let us know how it goes on the mailing list, and help us get the new release published. :) Please join us on IRC (#freedombox on irc.debian.org) and the mailing list if you want to help make this vision come true.

Tags: debian, english, freedombox, sikkerhet, surveillance, web.
EU-domstolen bekreftet i dag at datalagringsdirektivet er ulovlig
8th April 2014

I dag kom endelig avgjørelsen fra EU-domstolen om datalagringsdirektivet, som ikke overraskende ble dømt ulovlig og i strid med borgernes grunnleggende rettigheter. Hvis du lurer på hva datalagringsdirektivet er for noe, så er det en flott dokumentar tilgjengelig hos NRK som jeg tidligere har anbefalt alle å se.

Her er et liten knippe nyhetsoppslag om saken, og jeg regner med at det kommer flere ut over dagen. Flere kan finnes via mylder.

Jeg synes det er veldig fint at nok en stemme slår fast at totalitær overvåkning av befolkningen er uakseptabelt, men det er fortsatt like viktig å beskytte privatsfæren som før, da de teknologiske mulighetene fortsatt finnes og utnyttes, og jeg tror innsats i prosjekter som Freedombox og Dugnadsnett er viktigere enn noen gang.

Update 2014-04-08 12:10: Kronerullingen for å stoppe datalagringsdirektivet i Norge gjøres hos foreningen Digitalt Personvern, som har samlet inn 843 215,- så langt men trenger nok mye mer hvis ikke Høyre og Arbeiderpartiet bytter mening i saken. Det var kun partinene Høyre og Arbeiderpartiet som stemte for Datalagringsdirektivet, og en av dem må bytte mening for at det skal bli flertall mot i Stortinget. Se mer om saken Holder de ord.

Tags: dld, norsk, personvern, sikkerhet, surveillance.
Dokumentaren om Datalagringsdirektivet sendes endelig på NRK
26th March 2014

Foreningen NUUG melder i natt at NRK nå har bestemt seg for når den norske dokumentarfilmen om datalagringsdirektivet skal sendes (se IMDB for detaljer om filmen) . Første visning blir på NRK2 mandag 2014-03-31 kl. 19:50, og deretter visninger onsdag 2014-04-02 kl. 12:30, fredag 2014-04-04 kl. 19:40 og søndag 2014-04-06 kl. 15:10. Jeg har sett dokumentaren, og jeg anbefaler enhver å se den selv. Som oppvarming mens vi venter anbefaler jeg Bjørn Stærks kronikk i Aftenposten fra i går, Autoritær gjøkunge, der han gir en grei skisse av hvor ille det står til med retten til privatliv og beskyttelsen av demokrati i Norge og resten verden, og helt riktig slår fast at det er vi i databransjen som sitter med nøkkelen til å gjøre noe med dette. Jeg har involvert meg i prosjektene dugnadsnett.no og FreedomBox for å forsøke å gjøre litt selv for å bedre situasjonen, men det er mye hardt arbeid fra mange flere enn meg som gjenstår før vi kan sies å ha gjenopprettet balansen.

Jeg regner med at nettutgaven dukker opp på NRKs side om filmen om datalagringsdirektivet om fem dager. Hold et øye med siden, og tips venner og slekt om at de også bør se den.

Tags: dld, freedombox, mesh network, norsk, personvern, sikkerhet, surveillance.
Freedombox on Dreamplug, Raspberry Pi and virtual x86 machine
14th March 2014

The Freedombox project is working on providing the software and hardware for making it easy for non-technical people to host their data and communication at home, and being able to communicate with their friends and family encrypted and away from prying eyes. It has been going on for a while, and is slowly progressing towards a new test release (0.2).

And what day could be better than the Pi day to announce that the new version will provide "hard drive" / SD card / USB stick images for Dreamplug, Raspberry Pi and VirtualBox (or any other virtualization system), and can also be installed using a Debian installer preseed file. The Debian based Freedombox is now based on Debian Jessie, where most of the needed packages used are already present. Only one, the freedombox-setup package, is missing. To try to build your own boot image to test the current status, fetch the freedom-maker scripts and build using vmdebootstrap with a user with sudo access to become root:

git clone http://anonscm.debian.org/git/freedombox/freedom-maker.git \
  freedom-maker
sudo apt-get install git vmdebootstrap mercurial python-docutils \
  mktorrent extlinux virtualbox qemu-user-static binfmt-support \
  u-boot-tools
make -C freedom-maker dreamplug-image raspberry-image virtualbox-image

Root access is needed to run debootstrap and mount loopback devices. See the README for more details on the build. If you do not want all three images, trim the make line. But note that thanks to a race condition in vmdebootstrap, the build might fail without the patch to the kpartx call.

If you instead want to install using a Debian CD and the preseed method, boot a Debian Wheezy ISO and use this boot argument to load the preseed values:

url=http://www.reinholdtsen.name/freedombox/preseed-jessie.dat

But note that due to a recently introduced bug in apt in Jessie, the installer will currently hang while setting up APT sources. Killing the 'apt-cdrom ident' process when it hang a few times during the installation will get the installation going. This affect all installations in Jessie, and I expect it will be fixed soon.

Give it a go and let us know how it goes on the mailing list, and help us get the new release published. :) Please join us on IRC (#freedombox on irc.debian.org) and the mailing list if you want to help make this vision come true.

Tags: debian, english, freedombox, sikkerhet, surveillance, web.
All drones should be radio marked with what they do and who they belong to
21st November 2013

Drones, flying robots, are getting more and more popular. The most know ones are the killer drones used by some government to murder people they do not like without giving them the chance of a fair trial, but the technology have many good uses too, from mapping and forest maintenance to photography and search and rescue. I am sure it is just a question of time before "bad drones" are in the hands of private enterprises and not only state criminals but petty criminals too. The drone technology is very useful and very dangerous. To have some control over the use of drones, I agree with Daniel Suarez in his TED talk "The kill decision shouldn't belong to a robot", where he suggested this little gem to keep the good while limiting the bad use of drones:

Each robot and drone should have a cryptographically signed I.D. burned in at the factory that can be used to track its movement through public spaces. We have license plates on cars, tail numbers on aircraft. This is no different. And every citizen should be able to download an app that shows the population of drones and autonomous vehicles moving through public spaces around them, both right now and historically. And civic leaders should deploy sensors and civic drones to detect rogue drones, and instead of sending killer drones of their own up to shoot them down, they should notify humans to their presence. And in certain very high-security areas, perhaps civic drones would snare them and drag them off to a bomb disposal facility.

But notice, this is more an immune system than a weapons system. It would allow us to avail ourselves of the use of autonomous vehicles and drones while still preserving our open, civil society.

The key is that every citizen should be able to read the radio beacons sent from the drones in the area, to be able to check both the government and others use of drones. For such control to be effective, everyone must be able to do it. What should such beacon contain? At least formal owner, purpose, contact information and GPS location. Probably also the origin and target position of the current flight. And perhaps some registration number to be able to look up the drone in a central database tracking their movement. Robots should not have privacy. It is people who need privacy.

Tags: english, robot, sikkerhet, surveillance.
Det er jo makta som er mest sårbar ved massiv overvåkning av Internett
26th October 2013

De siste måneders eksponering av den totale overvåkningen som foregår i den vestlige verden dokumenterer hvor sårbare vi er. Men det slår meg at de som er mest sårbare for dette, myndighetspersoner på alle nivåer, neppe har innsett at de selv er de mest interessante personene å lage profiler på, for å kunne påvirke dem.

For å ta et lite eksempel: Stortingets nettsted, www.stortinget.no (og forsåvidt også data.stortinget.no), inneholder informasjon om det som foregår på Stortinget, og jeg antar de største brukerne av informasjonen der er representanter og rådgivere på Stortinget. Intet overraskende med det. Det som derimot er mer skjult er at Stortingets nettsted bruker Google Analytics, hvilket gjør at enhver som besøker nettsidene der også rapporterer om besøket via Internett-linjer som passerer Sverige, England og videre til USA. Det betyr at informasjon om ethvert besøk på stortingets nettsider kan snappes opp av svensk, britisk og USAs etterretningsvesen. De kan dermed holde et øye med hvilke Stortingssaker stortingsrepresentantene synes er interessante å sjekke ut, og hvilke sider rådgivere og andre på stortinget synes er interessant å besøke, når de gjør det og hvilke andre representanter som sjekker de samme sidene omtrent samtidig. Stortingets bruk av Google Analytics gjør det dermed enkelt for utenlands etteretning å spore representantenes aktivitet og interesse. Hvis noen av representantene bruker Google Mail eller noen andre tjenestene som krever innlogging, så vil det være enda enklere å finne ut nøyaktig hvilke personer som bruker hvilke nettlesere og dermed knytte informasjonen opp til enkeltpersoner på Stortinget.

Og jo flere nettsteder som bruker Google Analytics, jo bedre oversikt over stortingsrepresentantenes lesevaner og interesse blir tilgjengelig for svensk, britisk og USAs etterretning. Hva de kan bruke den informasjonen til overlater jeg til leseren å undres over.

Tags: norsk, personvern, sikkerhet, stortinget, surveillance.
Good causes: Debian Outreach Program for Women, EFF documenting the spying and Open access in Norway
15th October 2013

The last few days I came across a few good causes that should get wider attention. I recommend signing and donating to each one of these. :)

Via Debian Project News for 2013-10-14 I came across the Outreach Program for Women program which is a Google Summer of Code like initiative to get more women involved in free software. One debian sponsor has offered to match any donation done to Debian earmarked for this initiative. I donated a few minutes ago, and hope you will to. :)

And the Electronic Frontier Foundation just announced plans to create video documentaries about the excessive spying on every Internet user that take place these days, and their need to fund the work. I've already donated. Are you next?

For my Norwegian audience, the organisation Studentenes og Akademikernes Internasjonale Hjelpefond is collecting signatures for a statement under the heading Bloggers United for Open Access for those of us asking for more focus on open access in the Norwegian government. So far 499 signatures. I hope you will sign it too.

Tags: debian, english, opphavsrett, surveillance.
Videos about the Freedombox project - for inspiration and learning
27th September 2013

The Freedombox project have been going on for a while, and have presented the vision, ideas and solution several places. Here is a little collection of videos of talks and presentation of the project.

A larger list is available from the Freedombox Wiki.

On other news, I am happy to report that Freedombox based on Debian Jessie is coming along quite well, and soon both Owncloud and using Tor should be available for testers of the Freedombox solution. :) In a few weeks I hope everything needed to test it is included in Debian. The withsqlite package is already in Debian, and the plinth package is pending in NEW. The third and vital part of that puzzle is the metapackage/setup framework, which is still pending an upload. Join us on IRC (#freedombox on irc.debian.org) and the mailing list if you want to help make this vision come true.

Tags: debian, english, freedombox, sikkerhet, surveillance, web.
Recipe to test the Freedombox project on amd64 or Raspberry Pi
10th September 2013

I was introduced to the Freedombox project in 2010, when Eben Moglen presented his vision about serving the need of non-technical people to keep their personal information private and within the legal protection of their own homes. The idea is to give people back the power over their network and machines, and return Internet back to its intended peer-to-peer architecture. Instead of depending on a central service, the Freedombox will give everyone control over their own basic infrastructure.

I've intended to join the effort since then, but other tasks have taken priority. But this summers nasty news about the misuse of trust and privilege exercised by the "western" intelligence gathering communities increased my eagerness to contribute to a point where I actually started working on the project a while back.

The initial Debian initiative based on the vision from Eben Moglen, is to create a simple and cheap Debian based appliance that anyone can hook up in their home and get access to secure and private services and communication. The initial deployment platform have been the Dreamplug, which is a piece of hardware I do not own. So to be able to test what the current Freedombox setup look like, I had to come up with a way to install it on some hardware I do have access to. I have rewritten the freedom-maker image build framework to use .deb packages instead of only copying setup into the boot images, and thanks to this rewrite I am able to set up any machine supported by Debian Wheezy as a Freedombox, using the previously mentioned deb (and a few support debs for packages missing in Debian).

The current Freedombox setup consist of a set of bootstrapping scripts (freedombox-setup), and a administrative web interface (plinth + exmachina + withsqlite), as well as a privacy enhancing proxy based on privoxy (freedombox-privoxy). There is also a web/javascript based XMPP client (jwchat) trying (unsuccessfully so far) to talk to the XMPP server (ejabberd). The web interface is pluggable, and the goal is to use it to enable OpenID services, mesh network connectivity, use of TOR, etc, etc. Not much of this is really working yet, see the project TODO for links to GIT repositories. Most of the code is on github at the moment. The HTTP proxy is operational out of the box, and the admin web interface can be used to add/remove plinth users. I've not been able to do anything else with it so far, but know there are several branches spread around github and other places with lots of half baked features.

Anyway, if you want to have a look at the current state, the following recipes should work to give you a test machine to poke at.

Debian Wheezy amd64

  1. Fetch normal Debian Wheezy installation ISO.
  2. Boot from it, either as CD or USB stick.
  3. Press [tab] on the boot prompt and add this as a boot argument to the Debian installer:

    url=http://www.reinholdtsen.name/freedombox/preseed-wheezy.dat
  4. Answer the few language/region/password questions and pick disk to install on.
  5. When the installation is finished and the machine have rebooted a few times, your Freedombox is ready for testing.

Raspberry Pi Raspbian

  1. Fetch a Raspbian SD card image, create SD card.
  2. Boot from SD card, extend file system to fill the card completely.
  3. Log in and add this to /etc/sources.list:

    deb http://www.reinholdtsen.name/freedombox wheezy main
    
  4. Run this as root:

    wget -O - http://www.reinholdtsen.name/freedombox/BE1A583D.asc | \
       apt-key add -
    apt-get update
    apt-get install freedombox-setup
    /usr/lib/freedombox/setup
    
  5. Reboot into your freshly created Freedombox.

You can test it on other architectures too, but because the freedombox-privoxy package is binary, it will only work as intended on the architectures where I have had time to build the binary and put it in my APT repository. But do not let this stop you. It is only a short "apt-get source -b freedombox-privoxy" away. :)

Note that by default Freedombox is a DHCP server on the 192.168.1.0/24 subnet, so if this is your subnet be careful and turn off the DHCP server by running "update-rc.d isc-dhcp-server disable" as root.

Please let me know if this works for you, or if you have any problems. We gather on the IRC channel #freedombox on irc.debian.org and the project mailing list.

Once you get your freedombox operational, you can visit http://your-host-name:8001/ to see the state of the plint welcome screen (dead end - do not be surprised if you are unable to get past it), and next visit http://your-host-name:8001/help/ to look at the rest of plinth. The default user is 'admin' and the default password is 'secret'.

Tags: debian, english, freedombox, sikkerhet, surveillance, web.
Datalagringsdirektivet gjør at Oslo Høyre og Arbeiderparti ikke får min stemme i år
8th September 2013

I 2011 raderte et stortingsflertall bestående av Høyre og Arbeiderpartiet vekk en betydelig del av privatsfæren til det norske folk. Det ble vedtatt at det skulle registreres og lagres i et halvt år hvor alle som bærer på en mobiltelefon befinner seg, hvem de snakker med og hvor lenge de snakket sammen. Det skal også registreres hvem de sendte SMS-meldinger til, hvem en har sendt epost til, og hvilke nett-tjenere en besøkte. Saken er kjent som Datalagringsdirektivet (DLD), og innebærer at alle innbyggerne og andre innenfor Norges grenser overvåkes døgnet rundt. Det ble i praksis innført brev og besøkskontroll av hele befolkningen. Rapporter fra de landene som allerede har innført slik total lagring av borgernes kommunikasjonsmønstre forteller at det ikke hjelper i kriminalitetsbekjempelsen. Den norske prislappen blir mange hundre millioner, uten at det ser ut til å bidra positivt til politiets arbeide. Jeg synes flere hundre millioner i stedet burde vært brukt på noe som kan dokumenteres å ha effekt i kriminalitetsbekjempelsen. Se mer på Wikipedia og Jon Wessel-Aas.

Hva er problemet, tenkter du kanskje? Et åpenbart problem er at medienes kildevern i praksis blir radert ut. Den innsamlede informasjonen gjør det mulig å finne ut hvem som har snakket med journalister på telefon, SMS og epost, og hvem som har vært i nærheten av journalister så sant begge bar med seg en telefon. Et annet er at advokatvernet blir sterkt redusert, der politiet kan finne ut hvem som har snakket med en advokat når, eller vært i møter en med advokat. Et tredje er at svært personlig informasjon kan avledes fra hvilke nettsteder en har besøkt. Har en besøkt hivnorge.no, swingersnorge.com eller andre sider som kan brukes til avlede interesser som hører til privatsfæren, vil denne informasjonen være tilgjengelig takket være datalagringsdirektivet.

De fleste partiene var mot, kun to partier stemte for. Høyre og Arbeiderpartiet. Og både Høyre og Arbeiderpartiet i Oslo har DLD-forkjempere på toppen av sine lister (har ikke sjekket de andre fylkene). Det er dermed helt uaktuelt for meg å stemme på disse partiene. Her er oversikten over partienes valglister i Oslo, med informasjon om hvem som stemte hva i første DLD-votering i Stortinget, basert på informasjon fra mine venner i Holder de Ord samt data.stortinget.no. Først ut er stortingslista fra Høyre for Oslo:

#Navn, fødselsår og valgkretsStemme/kommentar
1. Ine Marie Eriksen Søreide (1976), Gamle Oslo Stemte for DLD
2. Nikolai Astrup (1978), Frogner Stemte mot DLD
3. Michael Tetzschner (1954), Vestre Aker Stemte mot DLD
4. Kristin Vinje (1963), Nordre Aker Ikke til stede
5. Mudassar Hussain Kapur (1976), Nordstrand Ikke til stede
6. Stefan Magnus B. Heggelund (1984), Grünerløkka Ikke til stede
7. Heidi Nordby Lunde (1973), Grünerløkka Ikke til stede
8. Frode Helgerud (1950), Frogner Ikke til stede
9. Afshan Rafiq (1975), Stovner Ikke til stede
10. Astrid Nøklebye Heiberg (1936), Frogner Ikke til stede
11. Camilla Strandskog (1984) St.Hanshaugen Ikke til stede
12. John Christian Elden (1967), Ullern Ikke til stede
13. Berit Solli (1972), Alna Ikke til stede
14. Ola Kvisgaard (1963), Frogner Ikke til stede
15. James Stove Lorentzen (1957), Vestre Aker Ikke til stede
16. Gülsüm Koc (1987), Stovner Ikke til stede
17. Jon Ole Whist (1976), Grünerløkka Ikke til stede
18. Maren Eline Malthe-Sørenssen (1971), Vestre Aker Ikke til stede
19. Ståle Hagen (1968), Søndre Nordstrand Ikke til stede
20. Kjell Omdal Erichsen (1978), Sagene Ikke til stede
21. Saida R. Begum (1987), Grünerløkka Ikke til stede
22. Torkel Brekke (1970), Nordre Aker Ikke til stede
23. Sverre K. Seeberg (1950), Vestre Aker Ikke til stede
24. Julie Margrethe Brodtkorb (1974), Ullern Ikke til stede
25. Fabian Stang (1955), Frogner Ikke til stede

Deretter har vi stortingslista fra Arbeiderpartiet for Oslo:

#Navn, fødselsår og valgkretsStemme/kommentar
1. Jens Stoltenberg (1959), Frogner Ikke til stede i Stortinget, leder av regjeringen som fremmet forslaget
2. Hadia Tajik (1983), Grünerløkka Stemte for DLD
3. Jonas Gahr Støre (1960), Vestre Aker Ikke til stede i Stortinget, medlem av regjeringen som fremmet forslaget
4. Marianne Marthinsen (1980), Grünerløkka Stemte for DLD
5. Jan Bøhler (1952), Alna Stemte for DLD
6. Marit Nybakk (1947), Frogner Stemte for DLD
7. Truls Wickholm (1978), Sagene Stemte for DLD
8. Prableen Kaur (1993), Grorud Ikke til stede
9. Vegard Grøslie Wennesland (1983), St.Hanshaugen Ikke til stede
10. Inger Helene Vaaten (1975), Grorud Ikke til stede
11. Ivar Leveraas (1939), Alna Ikke til stede
12. Grete Haugdal (1971), Gamle Oslo Ikke til stede
13. Olav Tønsberg (1948), Alna Ikke til stede
14. Khamshajiny Gunaratnam (1988), Grorud Ikke til stede
15. Fredrik Mellem (1969), Sagene Ikke til stede
16. Brit Axelsen (1945), Stovner Ikke til stede
17. Dag Bayegan-Harlem (1977), Ullern Ikke til stede
18. Kristin Sandaker (1963), Østeinsjø Ikke til stede
19. Bashe Musse (1965), Grünerløkka Ikke til stede
20. Torunn Kanutte Husvik (1983), St. Hanshaugen Ikke til stede
21. Steinar Andersen (1947), Nordstrand Ikke til stede
22. Anne Cathrine Berger (1972), Sagene Ikke til stede
23. Khalid Mahmood (1959), Østensjø Ikke til stede
24. Munir Jaber (1990), Alna Ikke til stede
25. Libe Solberg Rieber-Mohn (1965), Frogner Ikke til stede

Hvilket parti får så min stemme i år. Jeg tror det blir Piratpartiet. Hvis de kan bidra til at det kommer noen inn på Stortinget med teknisk peiling, så får kanskje ikke overvåkningsgalskapen like fritt spillerom som det har hatt så langt.

Tags: dld, norsk, personvern, stortinget, surveillance, valg.
Dr. Richard Stallman, founder of Free Software Foundation, give a talk in Oslo March 1st 2013
27th February 2013

Dr. Richard Stallman, founder of Free Software Foundation, is giving a talk in Oslo March 1st 2013 17:00 to 19:00. The event is public and organised by Norwegian Unix Users Group (NUUG) (where I am the chair of the board) and The Norwegian Open Source Competence Center. The title of the talk is «The Free Software Movement and GNU», with this description:

The Free Software Movement campaigns for computer users' freedom to cooperate and control their own computing. The Free Software Movement developed the GNU operating system, typically used together with the kernel Linux, specifically to make these freedoms possible.

The meeting is open for everyone. Due to space limitations, the doors opens for NUUG members at 16:15, and everyone else at 16:45. I am really curious how many will show up. See the event page for the location details.

Tags: english, opphavsrett, personvern, sikkerhet, surveillance.
Hva stemte hver stortingsrepresentant i voteringene om datalagringsdirektivet?
9th February 2013

Nytt stortingsvalg er på trappene, og folket får igjen mulighet til å påvirke sammensetningen i vår lovgivende forsamling. Da er det relevant å vite hvilke representanter og partier som har støttet innføringen av brev- og besøkskontroll av hele den norske befolkningen, det vil si datalagringsdirektivet.

Hvis du vil vite hva hver enkelt stortingsrepresentant har stemt i stortingsvoteringene om datalagringsdirektivet, så har nettstedet til Holder De Ord den (så vidt jeg vet) eneste komplette oversikten på sin temaside om innføringen av datalagringsdirektivet. Den har detaljene fra de 11 relevante forslagene som har vært fremmet så lagt. De har vært votert over 2011-04-04, 2011-04-11, 2012-06-11, 2012-10-05 og 2012-12-06.

Hvis du lurer på hva som er problemet med datalagringsdirektivet, anbefaler jeg å lese artiklene fra Jon Wessel-Aas om temaet, samt informasjon fra foreningen Digitalt Personvern.

Oppdatering 2017-04-30: Endret lenke til temaside hos HDO etter at den gamle URL-en sluttet å fungere.

Tags: dld, norsk, personvern, stortinget, surveillance.
Økt overvåkning applauderes igjen av Arbeiderpartiet, Høyre og Fremskrittspartiet
4th February 2013

Jeg ser med gru at Arbeiderpartiet, Høyre og Fremskrittspartiet applauderer tollvesenets forslag om å øke overvåkningen i Norge nok et hakk. Det er ikke så rart, da de som uttaler seg jo også har støttet innføringen av datalagringsdirektivet eller i hvert fall ikke veldig aktivt har motarbeidet det. Innføringen av datalagringsdirektivet er en lovendring som innebærer brev og besøkskontroll for hele befolkningen.

Datalagringsdirektivet har vært oppe til votering i stortinget tre ganger så langt. Det ble vedtatt første gang 2011-04-04 og andre gang 2011-04-11 (lovendringer voteres to ganger), og forslag om å stoppe loven ble nedstemt 2012-12-06 (se også oversikt fra Holder De Ord).

Jan Bøhler i Arbeiderpartiet stemte for å innføre datalagringsdirektivet i lovverket i første votering, var ikke tilstede i andre votering og støttet loven i tredje votering. André Oktay Dahl i Høyre var ikke til stede i første og andre votering men støttet loven i tredje votering. Ulf Leirstein i Fremskrittspartiet stemte mot loven i første votering men var ikke til stede i andre og tredje votering.

Hvis du lurer på hva som er problemet med datalagringsdirektivet, anbefaler jeg å lese artiklene fra Jon Wessel-Aas om temaet, samt informasjon fra foreningen Digitalt Personvern.

Oppdatering 2013-03-09: Endret lenke til Holder De Ord, som har byttet mange lenker i forbindelse med import av voteringsdata for 2010-2011.

Tags: dld, norsk, personvern, surveillance.
1.4 millioner potensielle journalistsamtaler i politiets hender
27th November 2012

I fjor meldte Dagbladet og andre medier at politiet hadde samlet inn informasjon om 1.4 millioner telefonsamtaler i området rundt Akersgata, regjeringskvartalet og Utøya, i forbindelse med etterforskningen rundt bombeattentatet og massemordet 22. juli 2011. Politiadvokat Pål-Fredrik Hjort Kraby fortalte i følge artikkelen at

- «Dette er ikke kun samtaler som knyttes til Breivik. Dette er alle samtaler som er registrert på basestasjoner i tilknytning til både bomba i Regjeringskvartalet og aksjonen på Utøya. Vi må analysere tid, lengde og fra hvilke basestasjoner de er registrert på. Vi prøver å finne ut hvem som har ringt til en hver tid, også i dagene før.»

Det triste og merkelige er at ingen presseoppslag tok opp hva dette egentlig betød for kildevernet. Et stenkast fra regjeringskvartalet befinner redaksjonene til blant annet VG, Dagbladet og Aftenposten seg. Det betyr at et betydelig antall av journalisters samtaler var og er tilgjengelig for politiet. Og dette var ikke en unik hendelse. Politiet henter rutinemessig ut informasjon om telefonsamtaler i kriminaletterforskningen, og en kan gå ut ifra at det ofte vil være noe kriminelt å undersøke nær en redaksjon da redaksjoner holder til i sentrum og tettsteder, der det meste av annen aktivitet i et område også foregår. F.eks. befinner Aftenposten seg like ved Oslo Sentralstasjon, et ganske kriminelt belastet område, der jeg mistenker politiet ofte hente ut samtaleinformasjon. Og avisen Aftenposten annonserte jo for noen år siden at ansatte kun skulle ha mobiltelefon (noe de kanskje angret på da mobilnettet brøt sammen), hvilket betyr at alle samtaler journalistene gjennomfører går via nabolagets mobilbasestasjoner og dermed blir med og analysert når politiet ber om informasjon om mobilsamtaler i området. Det samme gjelder antagelig de fleste mediehus nå for tiden.

Konsekvensen er at en må gå ut i fra at politiet kan få tilgang til informasjon om alle samtaler med journalister, hvilket bør få varslere og andre som vil tipse journalister til å tenke seg to ganger før de ringer en journalist. Det er for meg en svært uheldig situasjon.

Anders Brenne tipset meg om dette tidligere i år, og har skrevet om problemstillingen i sin bok Digitalt kildevern som ble lansert i år og presentert på et NONA-møte i april. Oppsummeringen fra møtet inneholder flere detaljer og bakgrunnsinformasjon. Jeg synes det er besynderlig at så få journalister tar opp denne problemstillingen, og ikke stiller flere kritiske spørsmål til innføringen av datalagringsdirektivet og den raderingen av personvernet som har foregått i Norge i løpet av mange år nå.

Tags: dld, norsk, personvern, sikkerhet, surveillance.
The fight for freedom and privacy
18th October 2012

Civil liberties and privacy in the western world are going down the drain, and it is hard to fight against it. I try to do my best, but time is limited. I hope you do your best too. A few years ago I came across a marvellous drawing by Clay Bennett visualising some of what is going on.

«They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety.» - Benjamin Franklin

Do you feel safe at the airport? I do not. Do you feel safe when you see a surveillance camera? I do not. Do you feel safe when you leave electronic traces of your behaviour and opinions? I do not. I just remember the Panopticon, and can not help to think that we are slowly transforming our society to a huge Panopticon on our own.

Tags: english, personvern, sikkerhet, surveillance.
TV with face recognition, for improved viewer experience
9th June 2012

Slashdot got a story about Intel planning a TV with face recognition to recognise the viewer, and it occurred to me that it would be more interesting to turn it around, and do face recognition on the TV image itself. It could let the viewer know who is present on the screen, and perhaps look up their credibility, company affiliation, previous appearances etc for the viewer to better evaluate what is being said and done. That would be a feature I would be willing to pay for.

I would not be willing to pay for a TV that point a camera on my household, like the big brother feature apparently proposed by Intel. It is the telescreen idea fetched straight out of the book 1984 by George Orwell.

Tags: english, surveillance.
Overvåkningslogikkens fallitt
23rd July 2011

Det er vanskelig å få gjort noe fornuftig i dag, etter gårdagens tragiske hendelse. Tankene går til de som har mistet sine nærmeste. Jeg kan ikke forstille meg hvor tungt de har det nå, og jeg håper alle jeg kjenner har klart seg.

Jeg undres på hva motivasjonen til de som står bak kan være? Jeg tror en må være ganske desperat for å ty til slike midler, og oppleve at alle andre påvirkningsmuligheter er blokkert. Mon tro om Stortingets totalitære vedtak 4. april i år om å lovfeste massiv overvåkning av hele befolkningen bidro? Jeg undres også på om at gårdagens bombing og massedrap er resultat av de fremmedfiendtlige holdninger som har spredt seg i Norge i mange år, kombinert med Stortingets og regjeringens villighet til å forlate de verdier som vårt liberale demokrati er tuftet på (ved å legge opp til registrering og overvåkning av borgere som _ikke_ er mistenkt for noe kriminelt).

En ting er ganske klart, dog. Massiv kameraovervåkning bidrar ikke til å hindre slik grotesk kriminalitet. Regjeringskvartalet er et av de mest kameraovervåkede områdene i Oslo, og hindret ikke at sprengingen fant sted. Registrering av posisjonen til alle mobiltelefoner som politiet har hatt tilgang til i flere år nå ser ikke ut til å ha hjulpet det heller. De som tror at massiv kommunikasjonskontroll av hele befolkningen vil hindre ekstremister i å skade oss i Norge tror jeg tar feil. Til det tror jeg det må mer åpenhet, mindre kontroll og mer tillit til hver enkelt innbygger, da jeg tror bidrar til å holde ekstreme holdninger i sjakk.

Tags: norsk, personvern, surveillance.
Det totalitære samfunn kommer stadig nærmere
28th March 2011

Høyre har i dag annonsert at de ønsker det totalitære samfunn velkommen, der innbyggerne overvåkes og hvem en kommuniserer med registreres av myndighetene i tilfelle vi gjør noe galt. Ingenting tyder på at datalagringsdirektivet har kriminalforebyggende effekt, og en må dermed gå ut ifra at det ikke er det som er den egentlige begrunnelsen til Arbeiderpartiet og Høyre når de velger å støtte slik massiv overvåkning av borgere som ikke er mistenkt for noe kriminelt.

Mitt lille prosjekt for å motvirke overvåkningssamfunnet, innsamling av informasjon om alle overvåkningskamera i det offentlige rom, rusler videre. Nå er det 96 automatiske trafikkkontroll-kamera registrert og 105 andre overvåkningskamera. Kun 29 personer har så langt bidratt, og det er bare toppen av isfjellet som er registrert. Hvis du vet om et overvåkningskamera i ditt lokalområde, sjekk kartet og få det registrert i OpenStreetmap hvis det mangler.

For noen dager siden ble jeg oppmerksom på en undersøkelse som datatilsynet gjorde i 2009, der de oppdaget at 81% av alle overvåkningskamera i Oslo sentrum var satt opp i strid med reglene. Basert på den undersøkelsen kan en dermed gå ut ifra at de aller fleste overvåkningskamera er lovstridige. Jeg håper vi kan få kartlagt alle lovstridige kamera og bruke denne informasjonen til å få gjort noe med dagens massive overvåkning.

En undersøkelse fra Ås i fjor viste at det er umulig å gå inn til Oslo sentrum uten å bli overvåket. Det er blitt verre siden den gang. F.eks. vet jeg at politiet har montert overvåkningskamera på Nasjonalteateret og Universitetesbygningen ved Karl Johansgate i forbindelse med VM på ski. Det er intet som tyder på at de kommer til å fjerne dem nå når VM er over.

Mitt utgangspunkt er at overvåkningskamera ikke har dokumentert kriminalitetsbekjempende effekt (hvis de fungerte skulle Oslo Sentralstasjon være det minst kriminelt belastede området i Norge), men derimot angriper borgernes rett til å ferdes anonymt i det offentlige rom.

Kartet over overvåkningskamera er fortsatt ikke komplett, så hvis du ser noen kamera som mangler, legg inn ved å følge instruksene fra prosjektsiden. Hvis du vet om noen flere måter å merke overvåkningskamera i OSM, ta kontakt slik at jeg kan få med også disse.

Tags: dld, norsk, personvern, surveillance.
Hvordan kringkaster T-banen i Oslo sine overvåkningskamerasignaler?
5th January 2011

Jeg er den fornøyde eier av en håndholdt trådløs kamerascanner, dvs. en radioscanner som automatisk scanner frekvensområdet 900 - 2500 MHz og snapper opp radiokilder med PAL eller NTCS TV-signal og viser signalet frem på en liten skjerm. Veldig morsom å ha med seg for å se hva som finnes av trådløse overvåkningskamera. En får se bildet som kameraet tar opp. :)

Men en kilde har den ikke klart å snappe opp: Sporveiens overvåkningskamera på T-banestasjonene. Bildet sendes åpenbart trådløst til T-baneføreren, men min scanner har ikke klart å ta inn signalet. For å forsøke å finne ut av dette tok jeg i dag en nærmere titt på en av boksene som sto på Forskningsparken T-banestasjon for å se hva det er som sendes ut.

Boksen hadde følgende tekst:

SupraLink
Outdoor Transmitter 5.8 GHz

default channel [ ]
  identity code [ ]

VTQ Videotronik
06268 Querfurt
www.vtq.de
Made in Germany

AC 230V   [strekkode]
max 10W   84230936

Det var hyggelig av produsenten å legge inn lenke til nettsiden sin. Der hadde de mye stilig elektronikk. Og forklaringen på hvorfor min scanner ikke tar inn signalet er åpenbar ut fra merkelappen. 5.8 GHz er langt over min scanners grense på 2.5 GHz. Trenger visst en kraftigere scanner. :)

Tags: norsk, ruter, surveillance.
Støtte for forskjellige kamera-ikoner på overvåkningskamerakartet
2nd January 2011

I dag har jeg justert litt på kartet over overvåkningskamera, og laget støtte for å gi fotobokser (automatisk trafikk-kontroll) og andre overvåkningskamera forskjellige symboler på kartet, slik at det er enklere å se forskjell på kamera som vegvesenet kontrollerer og andre kamera. Resultatet er lagt ut på kartet over overvåkningskamera i Norge. Det er nå 93 fotobokser av 380 totalt i følge vegvesenet og 80 andre kamera på kartet, totalt 173 kamera. Takk til de 26 stykkene som har bidratt til kamerainformasjonen så langt.

Tags: norsk, personvern, surveillance.
165 norske overvåkningskamera registert så langt i OpenStreetmap.org
24th December 2010

Jeg flikket litt på OpenStreetmap.org i går, og oppdaget ved en tilfeldighet at det er en rekke noder som representerer overvåkningskamera som ikke blir med på kartet med overvåkningskamera i Norge som jeg laget for snart to år siden. Fra før tok jeg med noder merket med man_made=surveillance, mens det er en rekke noder som kun er merket med highway=speed_camera. Endret på koden som henter ut kameralisten fra OSM, og vips er antall kamera økt til 165.

Kartet er fortsatt ikke komplett, så hvis du ser noen kamera som mangler, legg inn ved å følge instruksene fra prosjektsiden. Hvis du vet om noen flere måter å merke overvåkningskamera i OSM, ta kontakt slik at jeg kan få med også disse.

Tags: norsk, personvern, surveillance.
Nå er 74 norske overvåkningskamera registert i OpenStreetmap.org
18th November 2010

Jeg oppdaterte nettopp kartet med overvåkningskamera som jeg startet for ca. et og et halvt år siden, og nå er det 74 kamera på plass. I prosessen med å oppdatere kartet oppdaget jeg ved en tilfeldighet at webreferansen til registermeldingen hos Datatilsynet nå ikke lenger er gyldig (se tidligere melding). Antar Datatilsynet fjerner utdaterte meldinger fra databasen. Konsekvensen blir at kameraoversikten i OSM må ha med søkekriteriene som ble brukt for å finne registermeldingen (dvs. virksomhetsnavn og organisasjonsnummer), slik at eventuelt nye meldinger for samme kamera kan finnes igjen.

Det er dukket opp kamera på kartet i Bergensområdet, Stavangerområdet, Osloområdet, Gjøvikområdet og i Troms. Mange områder og kamera mangler, og jeg er overbevist om at bare en brøkdel av den enorme mengden kamera som nå finnes i det offentlige rom er registrert så langt. Instrukser for å legge inn kamera finnes på websiden for kartet hos personvernforeningen.

Tags: norsk, personvern, surveillance.
Datatilsynet mangler verktøyet som trengs for å kontrollere kameraovervåkning
9th November 2010

En stund tilbake ble jeg oppmerksom på at Datatilsynets verktøy for å holde rede på overvåkningskamera i Norge ikke var egnet til annet enn å lage statistikk, og ikke kunne brukes for å kontrollere om et overvåkningskamera i det offentlige rom er lovlig satt opp og registrert. For å teste hypotesen sendte jeg for noen dager siden følgende spørsmål til datatilsynet. Det omtalte kameraet står litt merkelig plassert i veigrøften ved gangstien langs Sandakerveien, og jeg lurer oppriktig på om det er lovlig plassert og registrert.

Date: Tue, 2 Nov 2010 16:08:20 +0100
From: Petter Reinholdtsen <pere (at) hungry.com>
To: postkasse (at) datatilsynet.no
Subject: Er overvåkningskameraet korrekt registrert?

Hei.

I Nydalen i Oslo er det mange overvåkningskamera, og et av dem er spesielt merkelig plassert like over et kumlokk. Jeg lurer på om dette kameraet er korrekt registrert og i henhold til lovverket.

Finner ingen eierinformasjon på kameraet, og dermed heller ingenting å søke på i <URL: http://hetti.datatilsynet.no/melding/report_search.pl >. Kartreferanse for kameraet er tilgjengelig fra <URL: https://people.skolelinux.no/pere/surveillance-norway/?zoom=17&lat=59.94918&lon=10.76962&layers=B0T >.

Kan dere fortelle meg om dette kameraet er registrert hos Datatilsynet som det skal være i henhold til lovverket?

Det hadde forresten vært fint om rådata fra kameraregisteret var tilgjengelig på web og regelmessig oppdatert, for å kunne søke på andre ting enn organisasjonsnavn og -nummer ved å laste det ned og gjøre egne søk.

Vennlig hilsen,
--
Petter Reinholdtsen

Her er svaret som kom dagen etter:

Date: Wed, 3 Nov 2010 14:44:09 +0100
From: "juridisk" <juridisk (at) Datatilsynet.no>
To: Petter Reinholdtsen
Subject: VS: Er overvåkningskameraet korrekt registrert?

Viser til e-post av 2. november.

Datatilsynet er det forvaltningsorganet som skal kontrollere at personopplysningsloven blir fulgt. Formålet med loven er å verne enkeltpersoner mot krenking av personvernet gjennom behandling av personopplysninger.

Juridisk veiledningstjeneste hos Datatilsynet gir råd og veiledning omkring personopplysningslovens regler på generelt grunnlag.

Datatilsynet har dessverre ikke en fullstendig oversikt over alle kameraer, den oversikten som finner er i vår meldingsdatabase som du finner her: http://www.datatilsynet.no/templates/article____211.aspx

Denne databasen gir en oversikt over virksomheter som har meldt inn kameraovervåkning. Dersom man ikek vet hvilken virksomhet som er ansvarlig, er det heller ikke mulig for Datatilsynet å søke dette opp.

Webkameraer som har så dårlig oppløsning at man ikke kan gjenkjenne enkeltpersoner er ikke meldepliktige, da dette ikke anses som kameraovervåkning i personopplysningslovens forstand. Dersom kameraet du sikter til er et slikt webkamera, vil det kanskje ikke finnes i meldingsdatabasen på grunn av dette. Også dersom et kamera med god oppløsning ikke filmer mennesker, faller det utenfor loven.

Datatilsynet har laget en veileder som gjennomgår når det er lov å overvåke med kamera, se lenke: http://www.datatilsynet.no/templates/article____401.aspx

Dersom det ikke er klart hvem som er ansvarlig for kameraet, er det vanskelig for Datatilsynet å ta kontakt med den ansvarlige for å få avklart om kameraet er satt opp i tråd med tilsynets regelverk. Dersom du mener at kameraet ikke er lovlig ut fra informasjonen ovenfor, kan kameraet anmeldes til politiet.

Med vennlig hilsen

Maria Bakke
Juridisk veiledningstjeneste
Datatilsynet

Personlig synes jeg det bør være krav om å registrere hvert eneste overvåkningskamera i det offentlige rom hos Datatilsynet, med kartreferanse og begrunnelse om hvorfor det er satt opp, slik at enhver borger enkelt kan hente ut kart over områder vi er interessert i og sjekke om det er overvåkningskamera der som er satt opp uten å være registert. Slike registreringer skal jo i dag fornyes regelmessing, noe jeg mistenker ikke blir gjort. Dermed kan kamera som en gang var korrekt registrert nå være ulovlig satt opp. Det burde også være bøter for å ha kamera som ikke er korrekt registrert, slik at en ikke kan ignorere registrering uten at det får konsekvenser.

En ide fra England som jeg har sans (lite annet jeg har sans for når det gjelder overvåkningskamera i England) for er at enhver borger kan be om å få kopi av det som er tatt opp med et overvåkningskamera i det offentlige rom, noe som gjør at det kan komme løpende utgifter ved å sette overvåkningskamera. Jeg tror alt som gjør det mindre attraktivt å ha overvåkningskamera i det offentlige rom er en god ting, så et slikt lovverk i Norge tror jeg hadde vært nyttig.

Tags: norsk, personvern, sikkerhet, surveillance.
Oppdatert kart over overvåkningskamera i Norge
22nd September 2010

For ca. et og et halvt år siden startet jeg på et kart over overvåkningskamera i Norge, i regi av personvernforeningen. Det har blitt oppdatert regelmessing, og jeg oppdaterte det nettopp. Fra den spede start med 22 kamera registrert er det nå registrert 54 kamera. Det er bare en brøkdel av de kamera som finnes i Norge, men det går sakte men sikkert i riktig retning.

Informasjonen registreres fortsatt direkte inn i OpenStreetmap, og hentes automatisk over i spesialkartet når jeg kjører et script for å filtrere ut overvåkningskamera fra OSM-dumpen for Norge.

Tags: norsk, personvern, surveillance.
Kart over overvåkningskamera i Norge
15th February 2009

I regi av personvernforeningen har jeg startet på et kart over overvåkningskamera i Norge. Bakgrunnen er at det etter min mening bærer galt avsted med den massive overvåkningen som finner sted i Norge i dag, og at flere og flere overvåkningskamera gjør det vanskeligere og vanskeligere å gå igjennom livet uten at små og store brødre trenger inn i ens private sfære. Datatilsynet har et register over kameraovervåkning, men det viser seg å være ubrukelig både til å finne ut hvor det er kamera plassert, og til å sjekke om et kamera en kommer over er registrert. Dette nye kartet fikser en av disse manglene, men det vil fortsatt være umulig å vite om et kamera er registrert etter lovens krav eller ikke. Pr. nå er 22 kamera i Oslo registrert, og det trengs flere til å registrere alle. Informasjonen registreres direkte inn i OpenStreetmap, så hentes det automatisk over i spesialkartet.

Tags: norsk, personvern, surveillance.

RSS Feed

Created by Chronicle v4.6