Tag Datenschutz

  • BKA: Telefonsupport ade

    In seinem Volkszählungsurteil erklärte das Bundesverfassungsgericht schon 1983:

    Wer nicht mit hinreichender Sicherheit überschauen kann, welche ihn betreffende Informationen in bestimmten Bereichen seiner sozialen Umwelt bekannt sind, und wer das Wissen möglicher Kommunikationspartner nicht einigermaßen abzuschätzen vermag, kann in seiner Freiheit wesentlich gehemmt werden, aus eigener Selbstbestimmung zu planen oder zu entscheiden.

    Diese Erwägung ist, was hinter den Auskunftsrechten steht, die seit den Urzeiten des Datenschutzes bestehen (auch wenn viele Unternehmen sie erst mit den verschärften Sanktionen der DSGVO bemerkt haben). Sie sorgte auch dafür, dass mensch von Anfang bei den diversen Polizeien kostenlos Auskunft verlangen konnte über die dort zur eigenen Person gespeicherten Daten. Seit 2003 hat zusätzlich der Auskunftsgenerator bei datenschmutz.de das etwas weniger nervig gemacht.

    Weil ich diesen Dienst betreibe, fragen mich gelegentlich NutzerInnen, was wohl irgendwelche Auskunfte bedeuten, die sie von Behörden bekommen. So auch neulich, als sich jemand wunderte, wie er in die Datei PIAV-WSK komme – „WSK“ steht hier für Waffen- und Sprengstoffkriminalität. Schon der Namen lässt ahnen: das ist keine Datei, in der mensch gerne einen Eintrag hat.

    Die Speicherung war zudem selbst nach Maßstäben deutscher Polizeidatenbanken besonders wenig nachvollziehbar. Aus dem lakonischen „Landfriedensbruch”, das in der Auskunft stand, konnte jedenfalls ich keine WSK-Relevanz erkennen. Und so dachte ich mir, ich frage mal wieder beim BKA nach. Früher stand auf den Auskünften die Durchwahl zum behördlichen Datenschutzbeauftragten des BKA, der die Auskünfte abwickelt[1], und das hat früher manchmal wirklich geholfen.

    Nicht mehr. Auf den Briefen steht inzwischen nur noch die Nummer der BKA-Telefonzentrale. Böses ahnend rief ich neulich dort an und hörte kaum überrascht irgendeine Warteschleife irgendwas aus dem Telefon quaken. Ich fingerte schon nach dem Auflegeknopf, als sich überraschend schnell doch ein Mensch meldete, dazu noch mit ganz unbeamtigen Sound. Jedoch musste ich „Rückfrage zu Auskunftsersuchen“ nicht fertigsprechen, bevor er auch schon sagte (nicht ganz wörtlich): „Das machen die Datenschützer. Wir haben Anweisung, da nicht hinzuverbinden, und die heben auch nicht ab. Schreiben Sie eine Mail.“

    Diese Einstellung des Telefonsupports mag nur ein kleiner Nadelstich gegen das Menschenrecht auf informationelle Selbstbestimmung (also das „mit hinreichender Sicherheit überschauen” des BVerfG) sein. Aber wer hinreichend oft „sagen wir nicht wegen Gefährdung des Bestands des Bundes“ in halb autogenerierten amtlichen Antwort- oder eher Abwimmelmails gelesen hat, wird ahnen, dass der Wegfall von Gesprächsmöglichkeiten ein durchaus erheblicher Verlust ist. Ich jedenfalls werde erstaunt sein über jedes Faktoid, das das BKA per Mail herauslässt.

    PIAV-WSK und der Landfriedensbruch

    Die Speicherung, die ich gerne geklärt gehabt hätte, war übrigens in gewisser Weise ähnlich beunruhigend wie die Einstellung des Telefonsupports.

    Ihre Vorgeschichte war ein Naziaufmarsch irgendwo und eine Gegenkundgebung von ein paar Antifas, die die Polizei zusammengeknüppelt hat. Wie üblich in solchen Fällen, hat die Polizei allen, die sie testierbar verletzt haben könnte, präventiv ein Landfriedensbruch-Verfahren reingewürgt, weil das gegen mögliche Anzeigen der Opfer zusätzlich immunisiert (nicht, dass es das bräuchte; die polizeiliche Straffreiheit ist seit dem verlinkten amnesty-Bericht von 2004 eher schlimmer geworden). Wie zumindest nicht unüblich – so weit funktioniert der Rechtsstaat des Öfteren noch – hat gleich das erste Gericht das Verfahren wegen Bullshittigkeit eingestellt.

    Das sollte für die Polizei Grund sein, den Vorwurf aus ihren Datenbanken zu löschen („regelmäßig“ heißt das in den zahlreichen Urteilen zur Thematik). Ist es aber schon seit jeher (der verlinkte Artikel ist von 2009) nicht, und es finden sich leider zu viele Gerichte, die die speicherwütigen Behörden davonkommen lassen mit: „Klar müsst ihr im Prinzip löschen, aber was ihr hier macht, geht gerade noch so” (mehr zur Logik der Negativprognose). Die Polizei hört das als: „Speichert eingestellte Verfahren nach Lust und Laune“.

    Insofern steht der arme Mensch nun dank LKA Baden-Württemberg als politisch motivierter Krimineller in diversen Datenbanken. Weil fast alle wissen, dass die diversen Staatsschutze Limo-PHWs mit Freude, Fleiß und freier Hand verteilen (übersetzt: Das ist alles Quatsch), ist das zwar ärgerlich, aber vom Schaden her meist noch überschaubar.

    Weniger überschaubar dürfte der mögliche Schaden bei Waffen- und Sprengstoff-Dateien sein, zumal sich das „PIAV” vor dem WSK auf die breit zugreifbare und schwer durchschaubare, wenn auch nicht mehr ganz neue BKA-Superdatenbank bezieht (vgl. Piff, Paff, PIAV von 2017). Während die Einzelregelungen zu PIAV BKA-Geschäftsgeheimnis sind, macht die Auskunft zudem keine verwertbare Angabe zur Frage, wer genau alles die fraglichen Daten sieht und damit vom Waffen- und Sprengstoffverdacht „wissen“ wird.

    Da das BKA die Telefonberatung eingestellt hat, will ich mich mal an einer spekulativen Erklärung der mysteriösen Speicherung versuchen: Im Oktober 2016 hat im beschaulichen Georgsgmünd ein besonders verstrahlter Faschist („Reichsbürger”) einen Polizisten erschossen, der bei der Beschlagnahme seiner – also des Faschisten – Waffen helfen wollte.

    Da es jetzt einer der ihren war – und nicht einer der hunderten anderer Menschen, die FaschistInnen in der BRD in den letzten 30 Jahren umgebracht haben –, ging daraufhin ein Ruck durch die Polizei. Schon nach einigen weiteren, wenn auch weniger tödlichen, Vorfällen dieser Art begann sie, diesem Milleu den Waffenbesitz etwas zu erschweren und ließ sich dafür auch entsprechende Gesetze geben. Disclaimer: Nein, ich glaube nicht, dass das was bringt – aber das ist ein anderes Thema.

    In Zeiten jedoch, in denen die Antisprache vom Extremismus Staatsraison ist, treffen staatliche Maßnahmen „gegen rechts“ natürlich gleich doppelt Linke. Und deshalb vermute ich, dass Menschen mit einem PHW „linksmotivierter Gewalttäter“ (und dafür reichte dem baden-württembergischen LKA schon das eingestellte Polizeischutzverfahren mit Landfriedensbruchgeschmack) ebenfalls keine Waffenscheine mehr bekommen sollen. Sollte es eine nichtleere Schnittmenge von Schützenverein und Antifa geben, dürften bestehende Waffenscheine wohl eingezogen werden.

    Dieser Teil findet ziemlich sicher statt. Spekulativ ist, dass der Mechanismus dazu die PIAV-WSK ist, denn ich habe wie gesagt keine Ahnung von Waffenscheinen und der Art, wie sie vergeben werden. Es ist aber plausibel, dass die Behörden, die sie ausgeben, irgendeine Regelanfrage an die Polizei stellen, und die dann halt Bedenken aus der PIAV-PSK generiert.

    Solange das nur Menschen aus der Schnittmenge von Schützenverein und Antifa trifft, dürfte die Wirkung minimal sein. Aber auch ein Blick in eine trübe Glaskugel reicht mir für die Vorhersage, dass es ein paar Leute ziemlich hart treffen wird, wenn sie plötzlich in den Ruch der Sprengstoffkriminalität kommen. Und wenn es nur ist, dass sie deshalb eine Lehrstelle in einer doofen Behörde verlieren.

    Nachtrag (2023-07-08)

    Wenige Stunden, nachdem ich das geschrieben habe, war ich beim Tag der offenen Tür des Rhein-Neckar-Kreises. Dabei hatte ich Gelegenheit, die Leute, die hier die Waffenscheine ausstellen, nach der PIAV-WSK zu fragen. Die Antwort war nur beschränkt kohärent, aber es klang so, als könnten die Leute dort zwar direkt auf das Bundeszentralregister zugreifen, hätten aber von der PIAV-WSK noch nichts gehört. Das ist zumindest konsistent mit meiner Spekulation.

    [1]

    Tatsächlich machen das fast alle Polizeien so: die behördlichen Datenschutzbeauftragten bearbeiten die Anträge. Mich hat das immer etwas irritiert, denn eigentlich sollten diese den Auskunftsprozess beaufsichtigen und begleiten, und das nicht bei sich selbst tun müssen; ich verweise auf Artikel 39 Abs. 1 DSGVO:

    Dem Datenschutzbeauftragten obliegen zumindest folgende Aufgaben:

    1. Unterrichtung und Beratung des Verantwortlichen oder des Auftragsverarbeiters und der Beschäftigten, die Verarbeitungen durchführen, hinsichtlich ihrer Pflichten nach dieser Verordnung sowie nach sonstigen Datenschutz­ vorschriften der Union bzw. der Mitgliedstaaten;
    2. Überwachung der Einhaltung dieser Verordnung, anderer Datenschutzvorschriften der Union bzw. der Mitgliedstaaten sowie der Strategien des Verantwortlichen oder des Auftragsverarbeiters für den Schutz personenbezogener Daten einschließlich der Zuweisung von Zuständigkeiten, der Sensibilisierung und Schulung der an den Verarbeitungsvorgängen beteiligten Mitarbeiter und der diesbezüglichen Überprüfungen;
    3. Beratung — auf Anfrage — im Zusammenhang mit der Datenschutz-Folgenabschätzung und Überwachung ihrer Durchführung gemäß Artikel 35;
    4. Zusammenarbeit mit der Aufsichtsbehörde;
    5. Tätigkeit als Anlaufstelle für die Aufsichtsbehörde in mit der Verarbeitung zusammenhängenden Fragen, einschließlich der vorherigen Konsultation gemäß Artikel 36, und gegebenenfalls Beratung zu allen sonstigen Fragen.

    Bei den Behördenleitungen kommt das aber schon traditionell an als „Na ja, der ganze Hippiequatsch halt“.

  • Taming an LTE card in Linux

    When I wrote my request for help on how to do voice calls with a PCI-attached cellular modem I realised that writing a bit about how I'm dealing with the IP part of that thing might perhaps be mildly entertaining to some subset of the computer-literate public. After all, we are dealing with rather serious privacy issues here. So, let's start with these:

    Controlling registration

    Just like almost any other piece of mobile phone tech, an LTE card with a SIM inserted will by default try to register with the network operator's infrastructure when it is switched on (or resumed, more likely, in the case of a notebook part). If this is successful, it will create a data point in the logs there, which in turn will be stored for a few days or, depending on the human rights situation in the current jurisdiction (as in: is telecom data retention in effect?), for up to two years. This record links you with a time (at which you used your computer) and a location (at which you presumably were at that point). That's fairly sensitive data by any measure.

    So: You don't want to create these records unless you really want network. But how do you avoid registration? There are various possible ways, but I found the simplest and probably most robust one is to use Linux's rfkill framework, which is in effect a refined version of airline mode. To make that convenient, I am defining two aliases:

    alias fon="sudo rfkill unblock wwan"
    alias keinfon="sudo rfkill block wwan"
    

    (“keinfon“ is “no phone“ in German); put these into your .bashrc or perhaps into .aliases if your .bashrc includes that file.

    Since I consider rfkill relatively a relatively unlikely target for privilege escalation, I have added , NOPASSWD: usr/sbin/rfkill to my system user's line in /etc/sudoers.d, but that's of course optional.

    With that, when I want to use internet over LTE, I type fon, wait a few seconds for the registration to happen and then bring up the interface. When done, I bring down the interface and say keinfon. It would probably be more polite to the service operators if I de-registered from the infrastructure before that, but for all I can see only marginally so; they'll notice you're gone at the next PLU. I don't think there are major privacy implications either way.

    It might be wiser to do the block/unblock routine in pre-up and post-down scripts in /etc/network/interfaces, but since registration is slow and I rather regularly find myself reconnecting while on the cell network, I'd consider that over-automation. And, of course, I still hope that one day I can do GSM voice calls over the interface, in which case the card shouldn't be blocked just because nobody is using it for an internet connection.

    Phone Status

    In case I forget the keinfon, I want to be warned about my gear leaking all the data to o2 (my network operator). I hence wrote a shell script display-phone-status.sh like this:

    #!/bin/sh
    if /usr/sbin/rfkill list | grep -A3 "Wireless WAN" | grep 'blocked: yes' > /dev/null; then
      echo "WWAN blocked."
    else
      /usr/games/xcowsay -t 10 -f "Steve Italic 42" --at 0,520 --image ~/misc/my-icons/telephone.xpm 'Ich petze gerade!'
    fi
    

    The notification you'll want to change, for instance because you won't have the nice icon and may not find the font appropriate. The German in there means ”I'm squealing on you.“. Here's how this works out:

    Screenshot: an old-style telephone with a baloon saying „Ich petze gerade“

    I execute that at every wakeup, which is a bit tricky because xcowsay needs to know the display. If you still run pm-utils and are curious how I'm doing that, poke me and I'll write a post.

    Connection

    Mainly because tooling for MBIM and other more direct access methods felt fairly painful last time I looked, I am still connecting through PPP, even though that's extremely silly over an IP medium like LTE. Part of the reason I'm writing this post is because duckduckgo currently returns nothing useful if you look for “o2 connection string“ or something like that. I tried yesterday because surprisingly while the internet connection worked over GSM, when connected over LTE (see below on how I'm controlling that), executing the good old:

    AT+CGDCONT=1, "IPV4V6", "internet"
    

    would get me an ERROR. That command – basically specifying the protocol requested and the name of an „access point“ (and no, I have never even tried to figure out what role that „access point“ might have had even in GSM) – admittedly seems particularly silly in LTE, where you essentially have an internet connection right from the start. I'm pretty sure it didn't use to hurt LTE connections three years ago, though. Now it does, and so that's my chat script for o2 (put it into /etc/ppp/chat-o2 with the peer definition below):

    IMEOUT 5
    ECHO ON
    ABORT 'BUSY'
    ABORT 'ERROR'
    ABORT 'NO ANSWER'
    ABORT 'NO CARRIER'
    ABORT 'NO DIALTONE'
    ABORT 'RINGING\r\n\r\nRINGING'
    '' "ATZ"
    OK 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0'
    OK "\d\dATD*99#"
    CONNECT ""
    

    You can probably do without almost all of this and just run ATD*99# if you're stingy; but over the past 15 years of using cellular modems in one way or another, each piece of configuration was useful at one time. I'm not claiming they are now.

    Similarly, my /etc/ppp/peers/o2 configuration file might contain a bit of cruft:

    /dev/ttyACM0
    115200
    debug
    noauth
    usepeerdns
    ipcp-accept-remote
    ipcp-accept-local
    remotename any
    user thing
    local
    nocrtscts
    defaultroute
    noipdefault
    connect "/usr/sbin/chat -v -f /etc/ppp/chat-o2"
    
    lcp-echo-interval 300
    lcp-echo-failure 10
    

    I'd expect the liberal LCP configuration at the bottom of the file is still very beneficial in the o2 network.

    To manage the network, I use normal Debian ifupdown with this stanza in /etc/network/interfaces:

    iface o2 inet ppp
      provider o2
    

    To bring up the interface, I have an icon on my desktop that executes sudo ifup o2.

    Monitoring

    To see what's going through a network connection, I have a script monitor in /etc/network/if-up.d; this is unconditionally executed once an interface comes up. A case statement brings up wmnet instances with parameters somewhat adapted to the respective interfaces:

    #!/bin/sh
    case $IFACE in
    wlan* )
      su - anselm -c 'DISPLAY=:0 nohup wmwave -r 200' > /dev/null 2>&1 &
      su - anselm -c "DISPLAY=:0 nohup wmnet -l -x 1000000 -d 200000 -r green -t red -W $IFACE" > /dev/null 2>&1 &
      ;;
    ppp*)
      su - anselm -c "DISPLAY=:0 nohup wmnet -l -x 1000000 -d 200000 -r green -t red -W $IFACE" > /dev/null 2>&1 &
      ;;
    o2 | n900)
      su - anselm -c "DISPLAY=:0 nohup wmnet -l -x 1000000 -d 200000 -r green -t red -W ppp0" > /dev/null 2>&1 &
      ;;
    esac
    

    The complicated su logic is necessary because again, the little window maker dockapps need access to the X display.

    That whole part is a bit weak, not only because of the hard-coded user name and DISPLAY (these are fairly safe bets for a personal computer) and because it relies some configuration of your window manager to place the dockapps at predictable positions.

    More importantly, ifupdown executes the script too early: To ifupdown, the interface is up when the pppd is up. But it is only then that pppd starts to negotiate, and these negotiations fail quite easily (e.g., when you're in a dead zone, and there are plenty of those with o2). If that happens, you have an essentially dead wmnet on the desktop. I clean up rather unspecifically in /etc/network/if-down.d/monitor:

    #!/bin/sh
    case $IFACE in
    wlan* )
      killall wmwave
      killall wmnet
      ;;
    ppp*|o2|n900)
      killall wmnet
      ;;
    esac
    exit 0
    

    The implicit assumption here that the computer will only have one wireless network connection at a time.

    Modem Configuration

    I used to have to do a bit of modem configuration in the olden days. It's rarer these days, but I thought I might as well publish the source of a program, I wrote back then to encapsulate that configuration. I still find it is useful now and then to choose between the access methods LTE (fast, but perhaps smaller cells hence less stable) and GSM (slow, but perhaps more robust with larger cells and better coverage), which this script can do if your card supports the AT+XACT command. While I would guess that includes many Sierra modems, I have no idea how many that may be. Anyway, here's how that ought to look like (and perhaps the most relevant piece of information is the <home>, which means there's an infrastructure connection – as opposed to, for instance, <offline>):

    $ modemconfig.py -a LTE
    Modem is >home<
    Using LTE
    Running on band BAND_LTE_1
    

    If you think you might find this kind of thing useful: It's on https://codeberg.org/AnselmF/sierra-config, and it's trivial to install.

  • Alle Ausländer total verdächtig: Das Entry-Exit-System der EU

    Kurve einer ca. 5m hohen Betonmauer, die von Bereitschaftspolizei bewacht wird.

    Das Foto der polizeigeschützten Betonfestung oben entstand 2009 bei einer Demonstration gegen die „GfA“ – das ist ein Euphemismus für Abschiebeknast – Ingelheim. Am Rande dieser Demonstration gegen ein besonders bedrückendes Symbol des deutsch-europäischen Migrationsregimes hörte ich zum ersten Mal von einem, wir mir damals erschien, aus Menschenrechtsgründen chancenlosen Irrsinnsprojekt, nämlich einer Datenbank, in der die EU alle Übertritte von Schengengrenzen aufzeichnen wollte, dem Entry-Exit-System EES.

    Ein gutes Jahrzehnt später hat es die Autorilla[1] entgegen meiner damaligen Einschätzung geschafft: Das Ding wird wohl in diesem Jahr online gehen, nachdem die entsprechende Rechtsgrundlage – die EU-Verordnung 2017/2226 oder kurz EES-VO – bereits 2017 die drei EU-Organe, also Parlament, Rat und Komission, passiert hat und am letzten Donnerstag auch der Bundestag ein paar offene Parameter in großer Eile in zweiter und dritter Lesung abgenickt hat. Die Bundestagsdrucksache 20/5333 ist ohne Debatte (wer nachlesen will: S. 88 im Plenarprotokoll: Gegenstimmen: die Linke, Enthaltungen: keine; es ging weiter mit Hilfen für Sportvereine) durchgerutscht, ohne dass es jemand gemerkt hätte.

    Die taz zum Beispiel hat in all den Jahren seit 2009 gerade mal zwei Artikel zum EES gehabt, einmal 2014 („Zeigt her eure Hände“) und dann nach der Verabschiedung der EES-VO 2017 („Die EU plant eine Touristendatei“). Angesichts des monströsen Vorhabens finde ich das etwas dünn, denn es geht um:

    Fingerabdrücke…

    Worüber ich besonders heulen könnte: Die Autorilla hat meine schlimmsten Erwartungen von 2009 noch übertroffen. Gut: Damals war auch das Visa-Informationssystem mit seinen Fingerabdruckdaten für (derzeit) beschämende 50 Millionen „Ausländer“ mit Schengen-Visa noch eine ferne Dystopie, die Bereitwilligkeit, mit der eine breite Mehrheit der Bundestagsabgeordneten die offensichtlich fürchterliche Fingerabdruckpflicht im Personalausweis abgenickt hat, schien eine Sache überwunden geglaubter autoritärer Großaufwallung nach Nineeleven. Damals waren noch nicht mal die Fingerabdrücke im gegen Asylsuchende gerichteten EURODAC zum Spurenabgleich nutzbar. Diese drei Datenpunkte mögen ein Gefühl dafür geben, wie sehr sich der Menschenrechtsabbau im Windschatten von Charlie Hebdo und Breitscheidplatz wieder beschleunigt hat.

    Jedenfals: wie bei der Biometrie in den Personalausweisen hat die Autorilla keine Ruhe gegeben und den Kram bei jeder ausländerfeindlichen Mobilisierung wieder ausgepackt. Und jetzt läuft der Mist (fast).

    Auch wenn alles am EES furchtbar ist, ist das größte Desaster sicher, dass ab 2023 nun alle NichtschengenianerInnen (und nicht nur die Visapflichtigen, die schon seit ca. 2014 im VIS biometrisch vermessen sind) ihre Fingerabdrücke abgeben müssen, wenn sie in den „Raum der Freiheit“[2] Schengenia einreisen wollen.

    Das ist vor allem dramatisch, weil diese Fingerabdrücke für drei bis fünf Jahre suchbar gespeichert werden. Und zur Strafverfolgung und Gefahrenabwehr zur Verfügung stehen.

    Klar, wie üblich steht was von „Terrorismus“ und „schwerer Kriminalität“ im Gesetz, auf die die biometrische Fahndung beschränkt sein sollen. Aber speziell für die Verfolgung politischer „Straftaten” (in der Welt der Autorilla: alles oberhalb der Latschdemo) geht das so schnell, dass die lippenbekennenden Einschränkungen praktisch wirkungslos sind. Die Polizei kann in dem Geschäft fast immer Terrorparagraphen aus der 129er-Klasse auspacken und tut das auch – mensch denke etwa an die aktuellen 129er-Verfahren in Leipzig. Wo ihr das doch mal zu peinlich wäre, kann sie immer noch völlig fantastische „Gefahren“ für die Staatsordnung konstruieren. Mein Paradebeispiel für Letzteres ist das 2017er Verbot von indymedia linksunten.

    …wider ausländischen Aktivismus!

    Wenn es soweit ist, schlägt die übliche Biometriefalle zu: Wir hinterlassen überall und ständig biometrische Spuren. Gut, bei den Gesichtern hängt das noch an eher so mäßig funktionierenden Videokameras, aber bei Fingerabdrücken und noch mehr bei Zellmaterial, das grob für DNS-Identifikation taugt, ist mit Mitteln von TeilzeitaktivistInnen nichts zu retten.

    Das weiß auch die Polizei, die in Heidelberg durchaus Fingerabdrücke an wild geklebten Plakaten oder Gafferband bei Bannerdrops genommen hat. Oder von Bierflaschen nach Besetzungspartys in völlig überflüssigerweise für den Abriss vorgesehenen Gebäuden.

    Während es noch keine suchbare Vollerfassung von Fingerabdrücken der Schengen-Untertanen gibt und die entsprechenden Heidelberger Ermittlungen jeweils bis zu unglücklichen ED-Behandlungen ohne Ergebnis blieben, werden (legal eingereiste) AktivistInnen aus Nichtschengenia (ich werfe mal das Wort „Grenzcamp“ ein) bei sowas in Zukunft gleich erwischt. Und obwohl wir Untertanen es vor zwei Jahren nicht hinbekommen haben, die Fingerabdrücke in den Ausweisen etwa durch moderaten Einspruch abzuwenden, gab es gerade letzte Woche Grund zur Hoffnung für uns, dass die Justiz in der Hinsicht um fünf nach Zwölf aushilft.

    Ob ihr das „staatlichen Rassissmus“ nennen wollt oder nicht: Im Effekt ist es das, jedenfalls so lange, bis auch die Fingerabdrücke der SchengenianerInnen suchbar sind. Trotz des verlinkten Hoffnungsschimmers dürfte zumindest das aber dann schon noch irgendwann kommen, wenn sich nicht wieder hinreichend viele Menschen dem entgegenstellen.

    Wie die Herrschaft Freiheitsabbau gerne erstmal an „den Fremden“ ausprobiert – wofür sie meist noch viel Lob aus der „Mitte der Gesellschaft“ bekommt – und erst dann auf die eigenen Untertanen ausrollt, könnt ihr u.a. am nächsten Freitag im Heidelberger Laden für Kultur und Politik im Rahmen der Wochen gegen Rassismus hören.

    Autoritäre Design Patterns: Aufblasen…

    Ich will im Folgenden ein paar besonders pikante Passagen aus den Erwägungsgründen zitieren, weil sie musterhaft Techniken der Autorilla bei der Durchsetzung ihrer Interessen illustrieren.

    Zunächst ist da das Aufblasen von Problemen. Das ursprüngliche Narrativ beim EES war, es brauche die Datenbank absolut dringend, um „overstayer“ zu fangen, Menschen also, die auf einem Touristenvisum einreisen und dann einfach bleiben.

    Vernünftige Menschen zucken bei so etwas mit den Schultern, denn Menschen ohne Papiere gibts nun mal, und es ist auch gar nicht klar, wo eine Datenbank da helfen soll, wenn mensch nicht überall auf den Straßen Ausweiskontrollen haben will (was für vernünftige Menschen kein „wenn“ ist). Die Autorilla hat Anfang der 2010er Jahre aber keine Krise, keinen Anschlag versäumt, ohne irgendwann mit „overstayern“ zu kommen, die entweder Anschläge machen, menschengehandelt wurden oder selbst menschenhandeln.[3]

    Ich finde eher erstaunlich, wie unbekümmert ehrlich die EES-VO in den ersten sechs Erwägungsgründen selbst die Höhepunkte des propagandistischen Trommelfeuers der Autorilla aufzählt:

    (1) In ihrer Mitteilung vom 13. Februar 2008 mit dem Titel „Vorbereitung der nächsten Schritte für die Grenzverwaltung in der Europäischen Union“ legte die Kommission die Notwendigkeit dar…

    (2) Der Europäische Rat hob auf seiner Tagung vom 19. und 20. Juni 2008 hervor, wie wichtig es ist, dass die Arbeit an der Weiterentwicklung der Strategie für den integrierten Grenzschutz der Union fortgesetzt wird…

    (3) In ihrer Mitteilung vom 10. Juni 2009 mit dem Titel „Ein Raum der Freiheit, der Sicherheit und des Rechts im Dienste der Bürger“ empfahl die Kommission…

    (4) Der Europäische Rat forderte auf seiner Tagung vom 23. und 24. Juni 2011 dazu auf, die Arbeit an dem Vorhaben „intelligente Grenzen“ zügig voranzutreiben…

    (5) In seinen strategischen Leitlinien vom Juni 2014 betonte der Europäische Rat, […] dass die Union alle ihr zur Verfügung stehenden Instrumente nutzen muss, um die Mitgliedstaaten bei ihrer Aufgabe zu unterstützen…

    (6) In ihrer Mitteilung vom 13. Mai 2015 mit dem Titel „Die Europäische Migrationsagenda“ stellt die Kommission fest, dass mit der Initiative „Intelligente Grenzen“ nun eine neue Phase eingeleitet werden soll…

    Wenn das eine Abwägung ist, hat die Waage jedenfalls nur eine Schale. Ich weise aus demokratietheoretischer Sicht kurz darauf hin, dass sich hier mit Rat und Kommission jeweils Teile der Exekutive die Bälle zuwerfen, bis eine neue Wahrheit durch gegenseite Bestärkung etabliert ist.

    …Bedarf erzeugen…

    Die Erzählung von den overstayern allerdings hat aus autoritärer Sicht (die sich ja um Panikpotenzial, nicht aber um Plausibilität kümmern muss) einen Fehler: Die gewünschte Speicherfrist von drei Jahren kommt dabei nicht raus, denn ginge es nur um die overstayer-Detektion, könne mensch den ganzen Datensatz bei der Ausreise löschen. Was tun? Einfach: Datenbedarf erzeugen, etwa duch die Schaffung hinreichend komplizierter Regeln. Hier:

    Das EES sollte ein automatisiertes Berechnungssystem enthalten. Das automatisierte Berechnungssystem sollte bei der Berechnung der Höchstdauer von 90 Tagen je Zeitraum von 180 Tagen Aufenthalte im Hoheitsgebiet der am EES-Betrieb beteiligten Mitgliedstaaten berücksichtigen.

    …Features schmuggeln…

    Allerdings reicht das, genau betrachtet, immer noch nur für Speicherdauern bis zu 180 Tagen aus. Wer einige Jahre lang den Acrobat Reader zum Lesen von PDFs verwendet hat, wird die Lösung kennen: Feature Creep, also das Einschmuggeln immer weiterer Möglichkeiten in ein Verfahren, aus dem die Leute nicht mehr so einfach rauskönnen. Sobald die ohnehin eher desinteressierte Öffentlichkeit erstmal vergessen hat, dass sie den ganzen Mist eigentlich nur gekauft hat, um ungezogene Schengentouris zu zählen, kommt ein ganzes Spektrum von Zwecken aufs Tablett, die mensch, wo die Daten doch schon mal da sind, auch erledigen kann:

    Ziele des EES sollten sein, das Außengrenzenmanagement zu verbessern, irreguläre Einwanderung zu verhindern und die Steuerung der Migrationsströme zu erleichtern. Das EES sollte gegebenenfalls insbesondere zur Identifizierung von Personen beitragen, die die Voraussetzungen hinsichtlich der Dauer des zulässigen Aufenthalts im Hoheitsgebiet der Mitgliedstaaten nicht oder nicht mehr erfüllen. Darüber hinaus sollte das EES zur Verhütung, Aufdeckung und Untersuchung terroristischer oder sonstiger schwerer Straftaten beitragen.

    Hu? Wo ist denn jetzt plötzlich der „Terror“ hergekommen? Wer hat die – ohnehin beliebigen, siehe oben – „schweren“ Straftaten aus dem Hut gezaubert? Die protorassistische Präsupposition „wer nicht SchengenianerIn ist, braucht Extraüberwachung, weil sie bestimmt mehr Terror und Schwerkriminalität macht“ hinter diesem kleinen Trick …

  • Es ist wer daheim!

    Vorneweg die wichtigste Nachricht: Der/die Datenschutzbeauftragte von Google hat eine Mailadresse, und sie ist dpo-google@google.com.

    Fragt mensch duckduckgo nach dieser Adresse, kommt derzeit nichts zurück. Google hingegen kommt mit ein paar Matches zurück, darunter https://www.datenanfragen.de/company/google/ (ein Selbsthilfe-Laden, der einen recht guten Eindruck macht) und eine reddit-Seite, auf der auch einiges Naserümpfen stattfindet, weil Google diese Mailadresse eher diskret behandelt. Immerhin: Google hätte sie ja auch aus ihrem Index verbannen können.

    Die Adresse habe ich von, ta-da, der irischen Datenschutzbehörde. Es gibt sie! Es ist dort wer zu Hause! Ein Gedanke, der mich spontan an diese denkwürdige Geschichte erinnert hat:

    Datenschutzpersonal des ULD an den Fenstern ihres Gebäudes

    Rechte wahrscheinlich beim ULD S-H.

    Dass beim irischen DPC jemand daheim ist weiß ich, weil ich tatsächlich eine Antwort bekommen habe auf meine Anfrage an die irische Datenschutzbehörde, wie ich an eine für Datenschutz zuständige Person von Google herankommen könnte. Eingelaufen ist sie am 27. September, exakt einen Tag vor Ablauf der Monatsfrist seit der Eingabe. Wie schaffen die Leute es nur, solche Sachen immer im letzten Moment hinzubekommen?

    Verblüffenderweise ist das auch nicht nur ein Formbrief, denn es steht schon mal drin: „I note you are seeking erasure of an old Google account,“ und dann, nachdem die einschlägigen Rechtsgrundlagen referiert wurden: „We would recommend that you contact Google’s Data Protection Officer (DPO) directly, requesting erasure of your data as per Article 17 of the GDPR, requesting a reply. You can contact the DPO at dpo-google@google.com.“ Schön.

    Auf meine Aufforderung, Google zu ermahnen, weil sie keine klaren Kontaktmöglichkeiten in Datenschutzsachen bieten und schon daher im Konflikt mit der DSGVO stehen, geht der antwortende „Information Officer“ leider nicht ein. Aber gut: Google anpissen ist jetzt sicher nichts, was ich im Bereich der Verhaltensmöglichkeiten des/der irischen DPC verortet hätte.

    Unterdessen habe ich auch schon ein erstes Lebenszeichen von der Google-Adresse:

    Hello,

    Thank you for contacting us. This is an automatic response to let you know that we've received your request and we'll respond as soon as possible.

    We treat requests seriously and we review them in the order in which they're received. If you send multiple requests, it might take us longer to respond to you.

    Thank you for your understanding and cooperation.

    Regards, Google

    Im Schreiben der irischen Datenschutzstelle steht:

    The organisation must respond to you within one month of receiving your request; in certain circumstances, this period may be extended by a further two months.

    Da das Lebenszeichen kaum als Antwort durchgehen wird: die Zeit läuft.

  • Bahnauskuft auf antiken Geräten – und auf Codeberg

    Foto: Altes Mobiltelefon mit Terminal, das eine etwas kryptische Bahnauskunft zeigt

    Bahnauskunft von 2022 auf einem Nokia N900 von 2009: Es braucht inzwischen etwas Mühe, um das gebastelt zu kriegen.

    Als die Bahn-Webseite nicht mehr ordentlich auf kompakten Browsern wie dillo funktionierte und auch nicht per WAP– also Mitte der 2010er Jahre –, habe ich mir ein ein kleines Skript geschrieben, das die wesentlichen Infos zur Zugauskunft aus dem HTML herausklaubte und dann in einem einfachen Kommandozeilen-Interface darstellte. Das war, worum es im letzten Sommer bei meinem Rant gegen Zwangs-Redirects umittelbar ging. Der weitere Hintergrund: Ich will Zugauskünfte von meinem alten Nokia N900 aus bekommen (und im Übrigen seit der Abschaltung von UMTS auch über eine 2G-Funkverbindung, also etwas wie 10 kB/s)[1].

    Nachdem das – jedenfalls nach Maßstäben von Programmen, die HTML auf Webseiten zerpflücken – überraschend lang gut ging, ist das im Rahmen der derzeitigen Verschlimmbesserung der Bahn-Seite neulich kaputt gegangen. Obendrauf ist die Javascript-Soße auf bahn.de damit so undurchsichtig geworden, dass mich die Lust, das Skript zu pflegen, sehr nachhaltig verlassen hat. In dieser Lage kam ein Vortrag über die Bahn-APIs, den jemand bei der Gulasch-Programmiernacht 2019 gehalten hat, gerade recht. Also: Das Video davon.

    In diesem Video habe ich gelernt, dass mein „unpromising“ im Rant vor einem Jahr,

    I know bahn.de has a proper API, too, and I'm sure it would be a lot faster if I used it, but alas, my experiments with it were unpromising [...],

    einen tiefen Hintergrund hat. Die Bahn hat nämlich keine API für die Fahrplanauskunft.

    Was es aber stattdessen gibt: die HaFAS-API, auf die die Reiseplanung der Bahn-App selbst aufsetzt. Und es stellt sich heraus, dass Leute schon mit viel Fleiß ausbaldowert haben, wie die so funktioniert, etwa in pyhafas.

    Mit pyhafas kann ich all das schreckliche HTML-parsing aus dem alten bahnconn.py durch ein paar Aufrufe in pyhafas rein ersetzen. Aber leider: pyhafas ist echt modernes Python, und weil es viel mehr kann als es für bahnconn.py bräuchte, wäre das Rückportieren davon nach Python 2.5 ein ernsthaftes Projekt; mehr habe ich aber auf meinem N900 nicht. Außerdem bin ich bekennender Fan von ein-Modul-und-stdlib-Programmen: die brauchen keine Installation und laufen zudem mit allem, das irgendwie Python verdauen kann, also etwa auch jython oder sowas, was spätestens dann in Frage steht, wenn Abhängigkeiten C-Code enthalten.

    Deshalb habe ich aus pyhafas die Dinge, die bahnconn dringend braucht, abgeschaut und eine minimale, Python-2.5-verträgliche Implementation gebastelt. Das Ergebnis: ein neues bahnconn. Holt es euch, wenn ihr Bahnauskunft auf älteren Geräten haben wollt. Ich habe es jetzt nicht auf Atari TTs probiert, aber ich kann mir gut vorstellen, dass es selbst da noch benutzbar ist.

    Codeberg

    Gerade, als ich den Code einfach wieder hier auf dem Blog abwerfen wollte, habe ich beschlossen, das könne ein guter Anlass sein, endlich mal einen zweiten Blick auf Codeberg zu werfen.

    Bisher habe ich nämlich für allen etwas langlebigeren oder größeren Code (also: nicht einfach nur am Blog abgeworfenen Kram), ganz DIY, ein eigenes Subversion-Repository betrieben. Was in den letzten Jahren neu dazukam, habe ich in git+ssh+cgit gesteckt.

    Natürlich hat das niemand mehr gesehen; nicht mal Suchmaschinen gucken mehr auf sowas, seit aller Code der Welt bei github landet. Deshalb, und auch, weil ich Monstren wie gitea und gitlab wirklich nicht auf meiner Maschine haben will (allerdings: cgit ist ok und würde für Publikation auf subversion-Niveau reichen), habe ich mich mit dem Gedanken, dass mein Kram auf einer öffentlichen Plattform besser aufgehoben sein mag, mehr oder minder abgefunden.

    Auf Github bin ich beruflich schon so viel zu viel unterwegs, und der Laden ist deutlich zu nah am Surveillance Capitalism. Zwar kenne ich hinreichend Projekte und Firmen, die ihnen Geld geben, so dass sie gewiss ein konventionell-kapitalistisches Geschäftsmodell fahren könnten; aber schon da fehlt mir der Glaube. Obendrauf hat mir Microsoft in meinem Leben schon so viel Kummer bereitet, dass ich ihnen (bzw. ihrem Tochterunternehmen) nicht noch mehr KundInnen zutreiben will.

    Codeberg, auf der anderen Seite, wird von einem Verein betrieben und macht generell vieles richtig, bis hin zu Einblendungen von Javascript-Exceptions (warum machen das eigentlich nicht alle?), so dass die Seite nicht einfach heimlich kaputt ist, wenn ich Local Storage verbiete (gitea, die Software, auf der Codeberg soweit ich sehe aufsetzt, kann leider immer noch nicht ohne).

    Von dem gitea-Krampf abgesehen hat gestern alles schön funktioniert, nichts an der Anmeldeprozedur war fies oder unzumutbar. Codeberg hat hiermit erstmal das Anselm Flügel Seal of Approval. Ich denke, da werde ich noch mehr Code hinschaffen. Und mal ernsthaft über Spenden nachdenken.

    [1]Janaja, und natürlich nervte mich die fette Bahn-Webseite mit all dem Unsinn darauf auch auf dem Desktop und auch schon vor der gegenwärtigen Verschlimmbesserung.
  • Abenteuer Irland: Kaputtes Drupal und eine Mail an die Datenschutzbehörde

    Als Reaktion auf meinen Hilferuf gegen Google hat @ulif@chaos.social getrötet:

    Vielleicht einfach mal unverbindlich bei der irischen "Datenschutzbehörde" nachfragen? Nicht als Beschwerde, sondern als einfache Anfrage. Denen müssen sie diese Daten ja eigentlich gemeldet haben.

    Na schön. Das könnte interessant werden. Das erste Ergebnis einer duckduckgo-Anfrage nach „data protection ireland“. führt gleich zur data protection commission (bzw. Choimisiún um Chosaint Sonraí), https://www.dataprotection.ie/, und ich bekomme beim Draufklicken original das hier:

    Screenshot einer Fehlermeldung, die von „inputted in the form“ spricht

    Keine GET-Parameter, kein POST-Payload, einfach nur https://www.dataprotection.ie/, und schon habe ich eine support ID. Oh wow. Interessanterweise ändert sich das auch nicht, wenn ich dataprotection.ie Javascript erlaube; mit einem Firefox (statt einem luakit) erscheint hingegen die Webseite, wie sich die Leute das wohl vorgestellt haben.

    Wie kommt das? Ich curl-e mal eben die Seite und sehe schon recht weit oben:

    <meta name="twitter:card" content="summary_large_image" />
    <meta name="twitter:site" content="@dpcireland" />
    <meta name="twitter:title" content="Homepage | Data Protection Commission" />
    

    und noch ein paar mehr Zeilen Twitter-Service. Diese Leute sollten dringend mal ihrem Kollegen in Baden-Württemberg zuhören.

    Immerhin kommen aber keine Webfonts von Google, und es laufen auf den ersten Blick auch keine externen Tracking-Dienste („Analytics“). Aber ich finde kein Refresh-Meta oder etwas anderes, das erklären könnte, warum luakit diese eigenartige Fehlermeldung ausgeliefert bekommen könnte, während an curl und firefox recht anständige Antworten gehen.

    Leider macht auch dataprotection.ie die bedauerlichen Zwangs-Redirects auf https, so dass es nicht ganz einfach ist, zuzusehen, was mein Browser und der Webserver der IrInnen eigentlich miteinander ausmachen. Aber ich bin neugierig genug auf das, was da zwischen meinem Browser und dem dataprotection.ie-Server vorgeht, dass ich meinen mitmproxy auspacke und damit in die Kommunikation meines eigenen Computers einbreche[1].

    Auf diese Weise sehe ich meinen Request:

    GET https://www.dataprotection.ie/
    Host: www.dataprotection.ie
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    User-Agent: Tracking is lame.
    Accept-Encoding: gzip, deflate
    Accept-Language: C
    Connection: Keep-Alive
    

    Ah… richtig… ich bin ein wenig gemein mit der Sprach-Aushandlung in meinem normalen Browser und frage die Webseiten nach der Sprache C (was weniger gemein ist als es scheinen mag, aber das ist ein längeres Thema). Ein schnelles Experiment bestätitgt, dass es das ist, was den Drupal (das ist das Programm, das deren Webseite macht) der irischen Datenschutzbehörde getötet hat.

    Wenn das noch oder wieder kaputt ist[2], wenn du das hier liest, ist eine einfache Kommandozeile, um das Problem zu reproduzieren:

    $ curl -s -H "Accept-Language: C" https://www.dataprotection.ie/ | head -5
    <!DOCTYPE html>
    <html lang="en">
    <head>
    <title> Website error notice | Data Protection Commission </title>
    </head>
    

    Aber egal, ich war ja eigentlich nicht hier, um Webseiten zu debuggen. Wichtig ist: Ich habe eine Mailadresse. Und das ist viel besser als das, was auf der normalen Webseite steht:

    Screenshot: Kontaktinformation für konventionelle Post, Twitter, Instagram (?) und Linkedin (?) – aber keine e-Mail.

    Echt jetzt? Papierpost ist ja schon noch sowas wie ein offener Standard, aber dann nur die proprietären, überwachungskapitalistischen Dienste Twitter, Instagram und Linkedin für Kontaktaufnahme anzubieten und nicht die offene Mail, das wäre auch für einen normalen Laden schon ein starkes Stück. Für eine Datenschutzbehörde… Na ja, ok, wir reden hier über die irische.

    Immerhin steht in deren data protection statement:

    If you wish to contact our Data Protection Officer in relation to the processing of your personal data by the Commission, you can do so by e-mailing dpo@dataprotection.ie.

    Schön: immerhin gibts da eine Mailadresse, bei der ich mich beschweren könnte, aber ganz ehrlich: Anständige DatenschützerInnen sollten da bitte noch einen PGP-Schlüssel dazuschreiben. Jaja, ich weiß: das hier sind die irischen…

    Ich sollte natürlich nicht so voreingenommen sein; nur weil die bisher ein Witz waren, heißt das ja nicht, dass sie das auch weiter sein werden, und so habe ich ihnen gerade eine Mail geschickt:

    Dear DPO,

    It seems your staff has already fixed it, presumably after I triggered some sort of alarm system while investigating the problem (in which case: apologies!), but your CMS until a few minutes ago produced error messages like the one on http://blog.tfiu.de/media/2022/ie-data-protection-breakage.png when queried with an

    Accept-Language: C

    header. I'm reporting this partly to make sure the apparent fix wasn't a fluke. If it wasn't: kudos to your operations people to have noticed and fixed the problem so quickly.

    While I'm here, can I also put forward the reason I'm contacting you in the first place?

    You see, I'm trying to get rid of a Google account I created perhaps 15 years ago. To do that, Google tells me to log in. When I try that, Google asks for the e-mail address associated to the account (which is <withheld here>), then for the password. After I've put that in, Google sends a mail to the account with a confirmation code, which is perhaps not entirely unreasonable given I've steered clear of Google services requiring authentication for many years.

    But even after entering that confirmation code, it will not let me in, requiring me to enter a telephone number. This is absolutely unreasonable, and I would be grateful if you could tell Google that much; given that Google does not know any telephone number associated to me, there is no way this information could fend off abuse. This is clearly a blantant attempt to skim off the extra piece of data.

    I would normally not be bothering you with this obvious imposition, though; I would have liked to first take this to Google's data protection officer. However, I was unable to locate contact information in Google's privacy statements (I was served the German version), which I claim is in open violation of GDPR Article 13. So, could you

    (a) tell Google to publish a proper e-mail contact address as part of their GDPR information? While I have to admit that the GDPR is not explicit about it, it is clear to me that Google's own web forms, in particular when they require Javascript and Captchas, or, even worse, a google id, are insufficient to fulfil Art 13 1 (b) GDPR.

    (b) meanwhile, provide me with the contact e-mail of Google's data protection officer so I can take my issue to them myself?

    Thanks,

    (not Anselm Flügel)

    Ich bin neugierig, wie es weitergeht. Lobend will ich schon mal erwähnen, dass der irische DPO offenbar keine automatisierten Empfangsbestätigungen („Wir werden uns Ihrem Anliegen so bald wie möglich widmen“) verschickt.

    Fortsetzung folgt. Voraussichtlich.

    Nachtrag (2022-08-31)

    Ich muss das Lob zurücknehmen. Es gab doch eine (halb-) automatisierte Empfangsbestätigung, abgeschickt um 14:47 Lokalzeit in Dublin. Für ein Verfahren, das nur auf Computer setzt, ist das eine komische Zeit bei einer Mail, die am Vorabend um 19:17 MESZ rausging. Wirklich gelesen hat die Mail aber auch niemand. Das weiß ich schon, weil sie mich mit „To Whom It May Concern“ anreden, aber auch wegen der angesichts meiner Anfrage widersinnigen Empfehlung, ich möge mich doch an den Datenschutzbeauftragten „for that organisation“ wenden.

    Weil Leute vielleicht später mal die Evolution des Kundendienstesisch des irischen DPO nachvollziehen wollen, belästige ich euch mit dem Volltext:

    To Whom It May Concern,

    I acknowledge receipt of your e-mail to the Data Protection Commission (DPC) .

    In line with our Customer Service Charter, we aim to reply to the concerns raised by you within 20 working days, though complex complaints may require further time for initial assessment. In doing so, we will communicate clearly, providing you with relevant information or an update regarding your correspondence.

    What can I do to progress my concern?

    In the meantime, if your concern relates to processing of your personal data by an organisation (a “data controller”), or you wish to exercise your data protection rights (for example, access, erasure, rectification), you may wish to contact the data protection officer for that organisation in writing in the first instance. You may wish to forward copies of all written exchanges with the data controller to the DPC if you remain dissatisfied with the response you receive from them. You should send this documentation to info@dataprotection.ie and include the above reference number.

    What if I have already contacted an organisation (“data controller”) about my concerns?

    If you have already exchanged written correspondence with the data controller, and have not included this information with your initial contact with the DPC, you should send this documentation to info@dataprotection.ie quoting the case reference shown above.

    What happens when I send the DPC additional correspondence or documents?

    Please be advised that the Data Protection Commission does not issue acknowledgements for each item of follow up or supplementary correspondence received, but this correspondence will be included on the file reference above and assessed alongside your initial concern. Once this assessment has been carried out, a substantive response will be issued to you in due course.

    This acknowledgement, and the reference number above, is confirmation that we have received your correspondence and that it will receive a response at the earliest opportunity.

    Yours sincerely,

    Alexandra X. [und noch ein Nachname]

    [Ein paar Footer-Zeilen]

    Is le haghaidh an duine nó an eintitis ar …

  • Google: Ohne Telefon kommst du hier nicht raus

    Vor ungefähr 15 Jahren habe ich unvorsichtigerweise einen Google-Account angelegt – ich habe selbst vergessen, warum. Heute morgen hat mich Google an diese Jugendsünde (immerhin aus Zeiten, als Google noch nicht ganz so finster war) erinnert, weil sie eine Bestätigung haben wollten, dass die Mail-Adresse, die ich damals verwendet habe, noch existiert (tut sie).

    Da ich an anmeldepflichtigen Google-Diensten genau gar kein Interesse habe, machte mich daran, den Account zu löschen. Und habe einen Haufen Zeit verschwendet, ohne irgendwohin zu kommen. Mit etwas Geduld habe ich zwar die leicht alarmistische Anleitung fürs Löschen bei Google gefunden. Dort heißt es nach viel Geschwätz:

    Schritt 3: Konto löschen [auf einer Seite, die „Google-Konto löschen“ überschrieben ist, ist es ja schon tapfer, dass das Schritt 3 ist]

    [...]

    Gehen Sie in Ihrem Google-Konto zum Abschnitt Daten und Datenschutz.

    Tja. Dafür müsste ich mich einloggen. Wenn ich das probiere, fordert Google zunächst einen per Mail versandten Bestätigungscode[1] und dann eine Telefonnummer, an die sie einen weiteren Bestätigungscode schicken wollen.

    Das wäre auch dann frech, wenn ihnen die Telefonnummer irgendeine Hilfe wäre, unberechtigte Löschversuche zu unterbinden. Aber das ist sie hier nicht, denn alles, was Google von mir hat, ist diese Mailadresse, und dass ich über sie verfüge, habe ich bereits durch den ersten Bestätigungscode nachgewiesen. Soweit es mich betrifft, ist Googles Verhalten hier von Phishing nicht unterscheidbar.

    Voll Zorn wäre ich nun gerne zum betrieblichen Datenschutzbeauftragten von Google gerannt; ich habe diese Woche noch nicht viel nichtssagendes Kundendienstesisch lesen müssen, und so denke ich, dass ich eine Antwort durchaus gleichmütig hätte ertragen können.

    Aber nein, Artikel 13 DSGVO, nach der zu einer Datenschutzerklärung gehört:

    1. gegebenenfalls die Kontaktdaten des Datenschutzbeauftragten,

    gilt augenscheinlich nicht für Google. Beschweren müsste ich mich über diesen Gesetzesverstoß (und natürlich auch darüber, dass Google das Löschen meines Accounts effektiv verweigert) bei der Aufsichtsbehörde, und das ist die irische Datenschutzbehörde – ein Witz in zwei Wörtern.

    Tja. Was tue ich jetzt? Ein Verwaltungsgerichtsverfahren ist mir ein seit Jahrzehnten toter Account auch nicht wert. Hat wer Ratschläge, wie ich diesen Google-Account trotzdem loswerde?

    So oder so bleibt mein dringender Ratschlag an alle, die sich über Kaltschnäuzigkeit dieser Größenordnung noch ärgern können: Finger weg von Google!

    [1]Schon das ist ja grenzwertig: Was ist denn, wenn ich die Mail-Adresse nicht mehr kontrolliere? Aber gut, das war jetzt nicht mein Problem.
  • Big Brother Award: Wieder nicht cleverreach

    Ich will nicht ganz verhehlen, dass mich die diesjährigen Big Brother Awards ein klein wenig enttäuscht haben. Gewiss waren das alles verdiente Empfänger, aber mein Favorit war wieder mal nicht dabei. Dabei gebe ich den Leuten vom FoeBuD (ich verweigere mich der Umbenennung in digitalcourage aus reiner Nostalgie), dass dessen Verfehlungen überschaubarer sind als die Bewegungsprofile von Lieferando und die garstigen Fintech-Teufeleien von Klarna.

    Dennoch sollte, so finde ich, cleverreach gelegentlich bedacht werden, idealerweise in einer Kategorie „Ausschnüffeln per DSGVO-FUD“. Diese wäre Einrichtungen vorbehalten, die anderen Einrichtungen Überwachungstechnik unterschieben, indem sie die von weiten Teilen der freien Presse geschürten Ängste vor der DSGVO ausnutzen.

    Dieses Thema wird schon durch das augenblickliche Cookie-Banner dieser Leute gesetzt, das modal (also: nichts geht, solange mensch nicht klickt) zunächst von „Privatsphäre respektieren“ redet und dann über allzu bekannte Dark Patterns versucht, den Leuten hart am Rande der Legalität Daten abzupressen:

    Gestauchter Screenshot des cleverreach-cookiebanners: Der Zustimmen-Button ist sehr einladend.

    (ich habe das Legalesisch rausgeschnitten, da es nichts zur Sache tut). Zum Mitschreiben: Ein Laden, der Datenschutz ernstnimmt, braucht keine Cookie-Banner und schon gar keine Dark Patterns. Immerhin, das will ich den Leuten lassen, funktionieren weite Bereiche der Webseite inzwischen (das war vor zwei Jahren noch anders) ohne Javascript. Tatsächlich werden ohne Javascript nicht mal Cookie-Banner ausgespielt (Disclaimer: ich habe nicht nachgesehen, ob dann auch wirklich keine unnötigen Cookies[1] verschickt werden).

    Etwas ungehaltener bin ich schon über die Sirenentöne zur DSGVO, mit denen cleverreach Unternehmen und, noch schlimmer, andere Einrichtungen verunsichert: „eine Mailingliste ist datenschutzmäßig total kompliziert, und wenn du eine betreibst, bist du schon halb im Knast“. Das ist natürlich Unfug, solange beim Abonnieren klar ist, was die Leute kriegen und der dazugehörige Dialog transparent gestaltet ist. Aber welcheR „EntscheiderIn“ – Technik- und Sachkenntnisse sind in solchen Positionen ja eher optional – könnte Sirenentönen schon widerstehen?

    Nun könnte ich mit so ein wenig DSGVO-FUD zur Not noch leben, selbst wenn er zu einer – nur in seltenen Fällen dem Datenschutz wirklich helfenden – Zentralisierung von EDV führt, hier nämlich von jeweils ein paar lokalen Mailinglisten auf jeder Menge voneinander isolierter Server zu einer Firma mit „310.000 Kunden“ mit entsprechend vielen Listen.

    Diese Kunden sind zum Beispiel die Bundesorganisation der GEW, die Ebert-Gedenkstätte in Heidelberg und das Landesmuseum für Arbeit und Technik in Mannheim (dessen aktuellen Namen „Technoseum“ verweigere ich mit gleicher Sturheit wie die „digitalcourage“). Stellt euch vor, ihr wisst, dass jemand von allen drei Läden Info-Mails abonniert hat, notabene freiwillig, was schon eine gewisse Identifikation mit den jeweiligen Zwecken vermuten lässt: Entsteht da nicht ganz von selbst ein Profil?

    Faustregel: „clever“ heißt im Internet so viel wie „fies”

    Aber ist denn die Bildung so eines Profils nicht gegen die DSGVO? Oh, mit hinreichend viel Skrupellosigkeit ist das kein Problem. Und damit komme ich zum wirklich verwerflichen Teil von cleverreachs Geschäft, der meines Erachtens Restzweifel im Hinblick auf die Skrupellosigkeit zuverlässig zerstreut.

    Dazu braucht es einen Blick in die von cleverreach verschickten Mails. Dies sehen typischerweise so aus:

    I     1        [multipa/alternativ, 7bit, 79K]
    I     2 ├─>    [text/plain, quoted, utf-8, 0.7K]
    I     3 └─>    [text/html, quoted, utf-8, 78K]
    

    – sie gibt also vor, dass mensch alternativ ordentlichen Text oder ein HTML-Dokument haben kann. Das Problem ist noch nicht mal, dass es da überhaupt HTML gibt (auch wenn anständige Menschen kein HTML in Mails packen). Das Problem deutet sich an darin, dass der Plain Text nur ein Hundertstel der Länge des HTML-Teils hat. Das ist auch beim Einrechnen des HTML-typischen Fluffs nicht mehr glaubhaft, und in der Tat ist der Plain-Text-Teil nur ein Köder, um Menschen zu cleverreachs Schnüffelseiten zu bringen:

    Ihr E-Mail Programm unterstützt leider keine HTML E-Mails.
    
    Hier finden Sie diesen Newsletter online:
    https://213989.seu2.cleverreach.com/m/dddddddd/dddddd-hhhhhhhhhhhhhhhhhhhhhhhhhh
    hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
    

    (wo d Dezimalziffern und h Sedezimalziffern sind; mit Code im Umfang dieser URL könnten DemoprogrammiererInnen Bälle über den Bildschirm hüpfen lassen). Wer dieser ganz klar personalisierten URL folgt, bekommt immerhin keinen Cookie-Banner, und erstaunlicherweise wird auch kein Javascript ausgeliefert. In der Tat setzen die verschiedenen Ressourcen auch keine nennenswerten Cookies. Allein die URL:

    https://stats-eu2.crsend.com/stats/mc_dddddd_dddddddd_hhhhhhhhhhh-cccccc.gif
    

    (c steht jetzt für Kleinbuchstaben) setzt einen PHP-Session-Cookie – aber das ist vermutlich nur Gedankenlosigkeit. Das wirkliche Problem an dieser Ressource: das ist ein Tracking-Pixel, in schlechter Tradition als leeres GIF von 40 Bytes, das aber (was passiert da wohl im Hintergrund?) jetzt gerade 5 Sekunden für die Auslieferung gebraucht hat.

    Hiermit nimmt cleverreach auf, wer ihre Mails liest und wann sie das tun. Nennt mich paranoid, aber ob und wann ich Werbepost lese, das geht wirklich nur mich etwas an. Ich will auf keinen Fall, dass jemand merkt, wenn ich auf Clickbait hereinfalle.

    Wenig überraschenderweise findet sich dieser Trackversuch auch am Ende der ganz klassisch als Tabelle ausgezeichneten HTML-Alternative in der Mail:

      </center>
      <img src="https://stats-eu2.crsend.com/stats/<wie oben>"
        border="0" alt="" height="1" width="1"></body>
    </html>
    

    Bei HTML dieser Art (und überhaupt: GIFs) werde ich wieder jung: so haben wir Mitte der 1990er Webseiten geschrieben.

    Trotz dieses Schnüffelversuchts wäre es übrigens (wenn es jetzt schon HTML sein muss) datenschützerisch besser, wenn cleverreach den Plain Text-Teil nicht einbasteln würde, denn dann würde mein datensparsames eigenes HTML-Rendering aktiv werden und ich könne die Mail lesen, ohne (wie im normalen Browser fast unvermeidlich) getrackt zu werden. Wie das alles mit meinem Mail-Client zusammengeht, beschreibe ich demnächst mal; ich bestehe jedenfalls darauf, dass Plain Text-Alternativen, die nur Clickbait enthalten, unethischer sind als gar kein Plain Text.

    Entweder Internet-Normalbetrieb oder DSGVO.

    Zugegeben: das verschlagene Unterschieben von Trackingpixeln, um mitzukriegen, wann wer was liest und das dann den eigenen KundInnen als total wichtige Marketingmetrik verkaufen zu können: Das könnte in Zeiten von Google Analytics schon fast als lässliche Sünde durchgehen. Wer sich auf Schurkereien dieser Art einlässt, darf jedoch im Gegenzug nicht Gewerkschaften und SPD-nahe Stiftungen (samt ihrer im Datenschutz eher unbeholfenen HauspolitiologInnen für antisoziale Medien) mit Datenschutzraunen und -drohen von datensparsamen Verfahren in das eigene überwachungskapitalistische Geschäftsmodell ziehen.

    [1]Ich lasse die Frage, ob es wohl „notwendige Cookies“ überhaupt gibt, mal beiseite, denn Antworten auf diese bräuchten jede Menge Platz für haarige technische und soziale Betrachtungen sowie eine Großpackung Wenns und Abers.
  • Lang lebe Small Data

    Zu den unerfreulicheren Begleiterscheinungen der Coronapandemie gehörte die vielstimmige und lautstarke Forderung nach „mehr Daten“, selbst aus Kreisen, die es eigentlich besser wissen[1]. Wie und warum diese Forderung gleich mehrfach falsch ist, illustriert schön ein Graph, der seit ein paar Wochen im RKI-Wochenbericht auftaucht:

    Dargestellt sind die Zahlen von „im Zusammenhang mit“ SARS-2 in deutsche Krankenhäuser aufgenommenen PatientInnen. Die orange Kurve entspricht dabei den „Big Data“-Zahlen aus der versuchten Totalerfassung – d.h., Krankenhäuser melden einfach, wie viele Menschen bei der Aufnahme SARS-2-positiv waren (oder vielleicht auch etwas anderes, wenn sie das anders verstanden haben oder es nicht hinkriegen). Die blaue Kurve hingegen kommt aus der ICOSARI-Surveillance, also aus spezifischen Meldungen über Behandlungen akuter Atemwegsinfektionen aus 71 Kliniken, die für Meldung und Diagnose qualifiziert wurden.

    Wären beide Systeme perfekt, müssten die Kurven im Rahmen der jeweiligen Fehlerbalken (die das RKI leider nicht mitliefert; natürlich zählt keines von beiden ganz genau) übereinanderlaufen. Es ist offensichtlich, dass dies gerade dann nicht der Fall ist, wenn es darauf ankommt, nämlich während der Ausbrüche.

    Eher noch schlimmer ist, dass die Abweichungen systematisch sind – die Entsprechung zu halbwegs vertrauten Messungen wäre, wenn mensch mit einem Meterstab messen würde, dessen Länge eben nicht ein Meter ist, sondern vielleicht 1.50 m. Nochmal schlimmer: seine Länge ändert sich im Laufe der Zeit, und auch abhängig davon, ob mensch Häuser oder Giraffen vermisst. Wäre der Meterstab wenigstens konstant falsch lang, könnte mensch die Messergebnisse im Nachhinein jedenfalls in gewissem Umfang reparieren („die Systematik entfernen“). Bei der Hospitalisierung jedoch wird keine plausible Methode die Kurven zur Deckung bringen.

    Das RKI schreibt dazu:

    Im Vergleich zum Meldesystem wurden hierbei in den Hochinzidenzphasen - wie der zweiten, dritten und vierten COVID-19-Welle - höhere Werte ermittelt. In der aktuellen fünften Welle übersteigt die Hospitalisierungsinzidenz der Meldedaten die COVID- SARI-Hospitalisierungsinzidenz, weil zunehmend auch Fälle an das RKI übermittelt werden, bei denen die SARS-CoV-2-Infektionen nicht ursächlich für die Krankenhauseinweisung ist.

    Die Frage ist nun: Welche Kurve „stimmt“, gibt also das bessere Bild der tatsächlichen Gefährdungssituation für das Gesundheitssystem und die Bevölkerung?

    Meine feste Überzeugung ist, dass die blaue Kurve weit besser geeignet ist für diese Zwecke, und zwar weil es beim Messen und Schätzen keinen Ersatz für Erfahrung, Sachkenntnis und Motivation gibt. In der Vollerfassung stecken jede Menge Unwägbarkeiten. Um ein paar zu nennen:

    • Wie gut sind die Eingangstests?
    • Wie konsequent werden sie durchgeführt?
    • Wie viele Testergebnisse gehen in der Hektik des Notfallbetriebs verloren?
    • Wie viele Fehlbedienungen der Erfassungssysteme gibt es?
    • Haben die Zuständigen vor Ort die Doku gelesen und überhaupt verstanden, was sie erfassen sollen und was nicht?
    • Wie viele Doppelmeldungen gibt es, etwa bei Verlegungen – und wie oft unterbleibt die Meldung ganz, weil das verlegende Krankenhaus meint, das Zielkrankenhaus würde melden und umgekehrt?

    Und ich fange hier noch gar nicht mit Fragen von Sabotage und Ausweichen an. In diesem speziellen Fall – in dem die Erfassten bei der Aufnahme normalerweise nicht viel tun können – wird beides vermutlich eher unwichtig sein. Bei Datensammelprojekten, die mehr Kooperation der Verdateten erfordern, können die Auswahleffekte hingegen durchaus auch andere Fehler dominieren.

    Erfasst mensch demgegenüber Daten an wenigen Stellen, die sich ihrer Verantwortung zudem bewusst sind und in denen es jahrelange Erfahrung mit dem Meldesystem gibt, sind diese Probleme schon von vorneherein kleiner. Vor allem aber lassen sie sich statistisch untersuchen. Damit hat ein statistisch wohldefiniertes Sample – anders als Vollerfassungen in der realen Welt – tendenziell über die Jahre abnehmende Systematiken. Jedenfalls, solange der Kram nicht alle paar Jahre „regelauncht“ wird, was in der heutigen Wissenschaftslandschaft eingestandenermaßen zunehmend Seltenheitswert hat.

    Wenn also wieder wer jammert, er/sie brauche mehr Daten und es dabei um Menschen geht, fragt immer erstmal: Wozu? Und würde es nicht viel mehr helfen, besser definierte Daten zu haben statt mehr Daten? Nichts anderes ist die klassische Datenschutzprüfung:

    • Was ist dein Zweck?
    • Taugen die Daten, die du haben willst, überhaupt dafür? („Eignung“)
    • Ginge es nicht auch mit weniger tiefen Eingriffen? („Notwendigkeit“)
    • Und ist dein Zweck wirklich so großartig, dass er die Eingriffe, die dann noch übrig bleiben, rechtfertigt? („Angemessenheit“)

    Ich muss nach dieser Überlegung einfach mal als steile Thesen formulieren: Datenschutz macht bessere Wissenschaft.

    Nachtrag (2022-05-16)

    Ein weiteres schönes Beispiel für die Vergeblichkeit von Vollerfassungen ergab sich wiederum bei Coronazahlen Mitte Mai 2022. In dieser Zeit (z.B. RKI-Bericht von heute) sticht der bis dahin weitgehend unauffällige Rhein-Hunsrück-Kreis mit Inzidenzen um die 2000 heraus, rund das Doppelte gegenüber dem Nächstplatzierten. Ist dort ein besonders fieser Virusstamm? Gab es große Gottesdienste? Ein Chortreffen gar? Weit gefehlt. Das Gesundheitsamt hat nur retrospektiv Fälle aus den vergangenen Monaten aufgearbeitet und ans RKI gemeldet. Dadurch tauchen all die längst Genesenen jetzt in der Inzidenz auf – als sie wirklich krank waren, war die Inzidenz zu niedrig „gemessen“, und jetzt halt zu hoch.

    So wurden übrigens schon die ganze Zeit die Inzidenzen berechnet: Meldungen, nicht Infektionen. Das geht in dieser Kadenz auch nicht viel anders, denn bei den allermeisten Fällen sind die Infektionsdaten anfänglich unbekannt (und bei richtig vielen bleibt das auch so). Wieder wären weniger, aber dafür sorgfältig und kenntnisreich gewonnene Zahlen (ich sag mal: PCR über Abwässern), hilfreicher gewesen als vollerfassende Big Data.

    [1]Vom Totalausfall der Vernunft etwa bei der Luca-App will ich gar nicht anfangen. Der verlinkte Rant von Fefe spricht mir ganz aus der Seele.

    Nachtrag (2023-02-08): Das sehe übrigens nicht nur ich so.

  • Fortgesetzte Missachtung

    Ich versuche gerade erneut, die Neuregelung (oder eher: Wiederregelung oder vielleicht auch Widerregelung) der Bestandsdatenauskunft nachzuvollzielen und schmökere dazu im letzten einschlägigen Urteil des Bundesverfassungsgerichts vom 27.5.2020 (1 BvR 1873/13). Darin findet das Gericht zunächst, dass die Anfechtungen von Regelungen im BND-Gesetz und im Zollfahndungsgesetz wegen Verfristung unzulässig sind, da der Bundestag in der Zwischenzeit bereits wieder Verschärfungen der entsprechenden Gesetze abgenickt hatte (Rn. 66ff).

    Das ist schon mal sportlich: Die Regierung beschließt neuen Menschenrechtsabbau, bevor das Verfassungsgericht den alten beanstanden kann. Das ist nicht die ungeschickteste Art, auf die Beschränkungen zu reagieren, die so eine lästige Verfassung mit sich bringt.

    Noch bemerkenswerter finde ich allerdings folgende, für höchstreichterliche Verhältnisse doch sehr klaren Worte des Gerichts (Rn. 80):

    Auch § 113 Abs. 1 Satz 2 TKG konnte fristgerecht angegriffen werden. Zwar hat die Norm gegenüber der Vorgängerregelung vom 22. Juni 2004 (BGBl I S. 1190) ‒ trotz geänderten Wortlauts und neuer Regelungsstruktur ‒ für sich genommen keinen grundsätzlich neuen Gehalt. Die Vorgängerregelung wurde jedoch für verfassungswidrig erklärt (BVerfGE 130, 151). Wenn der Gesetzgeber nunmehr eine Regelung mit im Wesentlichen gleichem Inhalt wiederholt, stellt diese einen neuen verfassungsrechtlichen Prüfungsgegenstand dar (vgl. dazu BVerfGE 96, 260 <263>; 102, 127 <141>; vgl. auch BVerfGE 135, 259 <281 Rn. 36>).

    Mit anderen Worten: Das Gericht hat den alten 113er für menschrechtswidrig erklärt, woraufhin die Regierung das Ding einfach ein wenig umformuliert und ganz offenbar im Wissen um seine Menschenrechtswidrigkeit völlig unverfroren wieder beschließen lässt. Dass keineR der betroffenen ParlamentarierInnen den Mut hatte, Einspruch gegen diesen doch besonders offensichtlichen Fall von Grundrechtsfeindlichkeit einzulegen, könnte in Hinblick auf die Funktionsfähigkeit des Parlaments ernüchtern. Andererseits ist das Muster autoritärer Problembewältigung (kein Mitglied der Regierungsparteien darf öffentlich gegen Wünsche von Polizei und Militär sprechen; privat tun sie das übrigens durchaus) leider allzu vertraut, und zwar von allen deutschen Regierungen zumindest in diesem Jahrtausend.

    Wobei: Immerhin hat die Regierung nicht (erkennbar) die vom BVerfG beanstanden Passagen noch wesentlich weiter getrieben (die Passwortabfrage ist wohl eher ein sachlicher Unkenntnis geschuldetes Gimmick). So ein Weitertreiben gab es durchaus schon, vielleicht am eklatantesten bei den Terrordateien (ATD und RED), deren Verschärfungen von 2015 vorgaben, durch recht fundamentale Beanstandungen des BVerfG motiviert zu sein, aber in Wirklichkeit die Menschenrechtsverstöße noch zuspitzten. Oder, wie Michael Plöse richtig feststellt (Vorgänge 208, 4/2014):

    [Der Regierungsentwurf zum ATDG-ÄG kann] kaum mehr nur als eine Enttäuschung bezeichnet werden – er ist vielmehr eine dreiste Provokation des Karlsruher Verfassungskompromisses.
  • Long live PGP

    The other day I ran into two rants against PGP, What's the matter with PGP?, which still is relatively reasonable, and then the raving PGP Problem by people running a security consulting shop called Latacora. It's this second diatribe that made me write this post, because the amount of badmouthing of PGP done there, on the blog of a company promising to teach startups “security“ on top, is not only unwarranted, it's also actively damaging to meaningful encryption.

    Let me start with what I think are the fundamental fallacies of the Latacora folks is: They seem to think that identity, and hence key management, is something that others can do for you, and that thinking about crypto is “bad user experience“. In contrast, I'd argue that crypto you don't notice isn't crypto at all (but instead somewhere on the obfuscation spectrum), and that identity management done by others is equivalent to them encrypting for you.

    You see, if you're encrypting something, you're encrypting it for someone. In public key encryption, this “someone“ has two aspects: a real-world entity (your friend, a bank, whatever), and a public key. Any crypto system that does not make this separation transparent and asks you the question of how well you think the two things match (and whether you care), is fundamentally broken. That's because that question plainly has to be answered. If it's not you who answers it, it's someone else. And hence that someone else is free to change the mapping from key to real-world entity, and hence they determine which real-world entity gets to read what you've encrypted.

    This, by the way, is how https is regularly subverted by businesses, anti-virus software, and occasionally state actors, who simply make your browser trust their word on who is what. At that moment, they can inspect everything your browser exchanges with the rest of the world, be it in “anti-virus portals” or bluntly in surveillance systems. This is also why very few users of “encrypted” messengers would even notice if the operating company snooped on them.

    The big advantage of PGP is what the Latacora people call „obnoxious UX“. Yes, you have to make up your mind on keys, yes, you have to explicitly manage them: but that is what you need to understand if you want meaningful encryption, and plastering abstractions on top of that only gives extra levels people have to understand – and that can break. No: if you want to do encryption, you'll have to understand key management, and PGP makes that as explicit and transparent as any crypto system I've ever seen. That's a feature, not a bug.

    Actually, this one thing is far more important than regular key rotation (as an aside: I'm not aware of anyone ever having broken a PGP secret key because too much material has been encrypted using it; it's certainly not a major reason for failing encryption) or the latest cryptographic primitives (even 1024 bit RSA keys still require serious investment to break, 20 years after they've been state of the art).

    More generally, the scenarios requiring frequent key rotation mostly imagine a targeted attack from a state actor, following you into hotel rooms to steal your secret key and install key loggers to skim your passphrase (or similar). Frankly: it's an illusion to believe a muggle (or even normal wizards doing their daily work) could withstand such a determined and comptentent state actor for a long time.

    But that's not necessary. It's already great progress if Google, the (normal) police, and the people at your employer's computation centre can't read the content of your mails unless they really try hard. Actually, most “adversaries” are not terribly determined and/or terribly competent. You hence don't need a perfect cryptosystem. It just needs to withstand the most basic of man-in-the-middle attacks (which fends off the not terribly competent adversaries), and it needs to require at least a bit of individual effort to break each person's crypto (which fends off the not terribly determined ones). Any system with centralised identity management fails at least on the side of the individual effort – get the central entity to collude, or break it, and you have it all. And given the central entity at least legally sits somewhere if it's commercial, at least for the state of residence it fails the withstand-most-basic criterion as well: The average state has no trouble obtaining court orders as soon as it moans “terrorism”.

    PGP, on the other hand, does a fairly good job on both counts once people have grokked it, at least a much better one than anything SSL-based I've ever seen. People can understand the basic operations of PGP if they want, something that is much harder with SSL and X.509. The problem is that few people want to understand that. But in that case, any kind of crypto is doomed. Hence, the problem isn't PGP, it is, as so often, education. Working on that is effort well spent, as once people have understood PGP to the level of confidently using it, they have a much better chance of being able to competently use other, less explicit crypto systems.

    Having said that: sure, PGP and its UIs could be improved. But you can't get around PGP's long-term keys for e-mail, and whatever alternative you'd come up with, you'll still need keyrings and reasonable UIs to mark up the trust in there. And, in particular, you'll still need open standards so you don't have to take a single company's word for what it does.

    That's basically where I think Latacora's arguments are harmful. But since most of the claims in the article are fairly outrageous, I can't resist commenting them, too:

    • “Absurd Complexity“ – that's not a terribly credible charge given the page comes over HTTPS, which in many ways is a lot more complex than OpenPGP, in particular because it contains the nightmare that is X.509. But really: Much as I am all for reducing complexity, I'm even more for maintaining backward compatibility. Being able to read encrypted mails I got in the 1990ies matters to me, and anything flexible enough to at least support modern crypto and deal with archive data will have to have a certain amount of complexity. Start something new, and in 10 years it'll look the same. Or worse. Only it won't be able to read archival data, and it'll have repeated the history of early bugs software simply has, in particular when you have to worry about side channel attacks.
    • “Swiss Army Knife“ – that would be more convincing if they said how exactly PGP signatures are “mediocre“ or the encryption is a “pretty bad job“. I accept the argument they make a bit down that people may want to have forward secrecy in IM and it's easy to have there, so going for PGP alternatives may be a good idea there. But then I can't remember the last time I used PGP over XMPP, so these alternatives have existed for a long time, without any need to kill PGP.
    • “Mired in Backwards Compatibility“ – well, as said above, backwards compatiblity is great if your systems live a long time. And OpenPGP is doing a reasonable job to have both backwards compatiblity and evolvability. That rolling out new features isn't instantaneous, in particular for a federated, largely volunteer effort, is useless criticism: Build another distributed, open, volunteer effort, and it'll go the same way. Oh, and just incidentally: HTTPS is from the nineties, too, and the X.509 standard was published in 1988.
    • ”Obnoxious UX“, “Long-Term Secrets“, “Incoherent Identity“ – these are the core of Latacora's fallacies; see above.
    • “Broken Authentication“ – I can't say I've thought through the problem they're pointing to here; if it is as bad as they claim, there's no reason not to fix it within OpenPGP rather than invent something entirely new.
    • “Leaks Metadata“ – sure. As long as there's SMTP, there's no way around having quite a bit of cleartext: intermediate mail servers will have an idea who's mailing whom (though of course there's still Mixmaster). Having e-mail, or at least something that doesn't require me to be always online, is so important that the metadata leaks are an almost negligible price to pay, at least compared to the fine-grained activity profile you leak when you leave your phone online all the time, or the loss of control when you (or people you trust) can't run the necessary infrastructure components (as in: a mail server) any more.
    • ”No Forward Secrecy“ – fair enough, but again that's hard to have in store-and-forward e-mail, in particular when you'd like to have mailing lists and the like. Of course, it's true that »[a]gainst serious adversaries and without forward secrecy, breaches are a question of “when”, not “if”.« But on the other hand, most serious adversaries lose interest in the cleartext hours, weeks, or at worst a few years after the communication, or at least stop being terribly serious. So, for these intents and purposes holding …
  • Impfpass ohne App, Apple und Google

    Morgen werden zwei Wochen seit meiner zweiten Corona-Impfung vergangen sein. Damit wird die Impfpassfrage für mich relevant: Mit so einem Ding könnte ich wieder in die Mensa gehen!

    Allerdings habe ich, soweit ich das sehe, keinen Zugang zur offiziellen Covpass-App, weil ich mich von Apples Appstore und Googles Playstore fernhalte und eigentlich auch die Toolchains der beiden nicht auf meinem Rechner haben will. Immerhin gibt es (es lebe der Datenschutz-Aktivismus, der für offene Entwicklung von dem Kram gesorgt hat) die Quellen der Apps (wenn auch leider auf github). Wie kompliziert kann es schon sein, das ohne den ganzen proprietären Zauber nachzubauen?

    Stellt sich raus: schon etwas, aber es ist ein wenig wie eine Kurzgeschichte von H.P. Lovecraft: Die Story entwickelt sich wie beim Schälen einer Zwiebel. Schale um Schale zeigt sich, dass die Wahrheit immer noch tiefer liegt.

    Bei Lovecraft sind nach dem Abpulen der letzten Schale meist alle ProtagonistInnen tot oder wahnsinnig. Im Fall der Covpass-App hingegen ist der Kram sogar dokumentiert: So finden sich die halbwegs lesbare Dokumentation des Datenstroms im QR-Code und das JSON-Schema – leider schon wieder auf github.

    Schale 1: QR-Code scannen

    Ich dachte mir, zum Nachbauen der Covpass-App sollte ich erstmal ihre Eingabe verstehen, also die Daten aus den beiden Impfzertifikaten lesbar darstellen. Der erste Schritt dazu ist etwas, das QR-Codes lesen kann. Ich hatte anderweitig schon mit zbar gespielt, für das es das Debian-Paket python3-zbar gibt. Damit (und mit der unverwüstlichen Python Imaging Library aus python3-pillow) geht das so, wenn das Foto mit dem Zertifikat in der Datei foto.jpeg liegt:

    def get_single_qr_payload(img):
      img = img.convert("L")
    
      scanner = zbar.ImageScanner()
      scanner.parse_config('enable')
      image = zbar.Image(img.size[0], img.size[1], 'Y800', data=img.tobytes())
      if not scanner.scan(image):
        raise ValueError("No QR code found")
    
      decoded = list(image)
      if len(decoded)>1:
        raise ValueError("Multiple QR codes found")
    
      return decoded[0].data
    
    encoded_cert = get_single_qr_payload(Image.open("foto.jpeg"))
    

    Im Groben wandele ich in der Funktion das Bild (das wahrscheinlich in Farbe sein wird) in Graustufen, denn nur damit kommt zbar zurecht. Dann baue ich eine Scanner-Instanz, also das Ding, das nachher in Bildern nach QR-Codes sucht. Die API hier ist nicht besonders pythonesk, und ich habe längst vergessen, was parse_config('enable') eigentlich tut – egal, das ist gut abgehangene Software mit einem C-Kern, da motze ich nicht, noch nicht mal über diesen fourcc-Unsinn, mit dem vor allem im Umfeld von MPEG allerlei Medienformate bezeichnet werden; bei der Konstruktion des zbar.Image heißt „8 bit-Graustufen“ drum "Y800". Na ja.

    Der Rest der Funktion ist dann nur etwas Robustheit und wirft ValueErrors, wenn im Foto nicht genau ein QR-Code gefunden wurde. Auch hier ist die zbar-API vielleicht nicht ganz preiswürdig schön, aber nach dem Scan kann mensch über zbar.Image iterieren, was die verschiedenen gefundenen Barcodes zurückgibt, zusammen mit (aus meiner Sicht eher knappen) Metadaten. Das .data-Attribut ist der gelesene Kram, hier als richtiger String (im Gegensatz zu bytes, was ich hier nach der python3-Migration eher erwartet hätte).

    Schale 2: base45-Kodierung

    Das Ergebnis sieht nach üblichem in ASCII übersetzten Binärkram aus. Bei mir fängt der etwa (ich habe etwas manipuliert, das dürfte so also nicht dekodieren) so an: HC1:6B-ORN*TS0BI$ZDFRH%. Insgesamt sind das fast 600 Zeichen.

    Als ich im Wikipedia-Artikel zum Digitalen Impfnachweis gelesen habe, das seien base45-kodierte Daten, habe ich erst an einen Tippfehler gedacht und es mit base85 versucht, das es in Pythons base64-Modul gibt. Aber nein, weit gefehlt, das wird nichts. War eigentlich klar: die Wahrscheinlichkeit, dass was halbwegs Zufälliges base85-kodiert keine Kleinbuchstaben enthält, ist echt überschaubar. Und base45 gibts wirklich, seit erstem Juli in einem neuen RFC-Entwurf, der sich explizit auf QR-Codes bezieht. Hintergrund ist, dass der QR-Standard eine Kodierungsform (0010, alphanumeric mode) vorsieht, die immer zwei Zeichen in 11 bit packt und dafür nur (lateinische) Großbuchstaben, Ziffern und ein paar Sonderzeichen kann. Extra dafür ist base45 erfunden worden. Fragt mich bloß nicht, warum die Leute nicht einfach binäre QR-Codes verwenden.

    Es gibt bereits ein Python-Modul für base45, aber das ist noch nicht in Debian bullseye, und so habe ich mir den Spaß gemacht, selbst einen Dekodierer zu schreiben. Technisch baue ich das als aufrufbares (also mit einer __call__-Methode) Objekt, weil ich die nötigen Tabellen aus dem globalen Namensraum des Skripts draußenhalten wollte. Das ist natürlich ein Problem, das verschwindet, wenn sowas korrekt in ein eigenes Modul geht.

    Aber so gehts eben auch:

    class _B45Decoder:
      chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-./:"
      code_for_char = dict((c, i) for i, c in enumerate(chars))
      sig_map = [1, 45, 45*45]
    
      def __call__(self, str):
        raw_bytes = [self.code_for_char[s] for s in str]
        cooked_bytes = []
    
        for offset in range(0, len(raw_bytes), 3):
          next_raw = raw_bytes[offset:offset+3]
          next_bytes = sum(w*v for w,v in
            zip(self.sig_map, next_raw))
          if len(next_raw)>2:
            cooked_bytes.append(next_bytes//256)
          cooked_bytes.append(next_bytes%256)
    
        return bytes(cooked_bytes)
    
    b45decode = _B45Decoder()
    

    Die b45decode-Funktion ist, wenn mensch so will, ein Singleton-Objekt der _B45Decoder-Klasse (so hätten das jedenfalls die IBMlerInnen der CovPass-App beschrieben, vgl. unten). Ansonsten bildet das den Grundgedanken von base45 ziemlich direkt ab: Immer drei Bytes werden zur Basis 45 interpretiert, wobei die Wertigkeit der verschiedenen Zeichen im Dictionary code_for_char liegt. Die resultierende Zahl lässt sich in zwei dekodierte Bytes aufteilen. Nur am Ende vom Bytestrom muss mensch aufpassen: Wenn die dekodierte Länge ungerade ist, stehen kodiert nur zwei Byte.

    Und ja: vielleicht wärs hübscher mit dem grouper-Rezept aus der itertools-Doku, aber die next_raw-Zuweisung schien mir klar genug.

    Schale 3: zlib

    Ein b45decode(encoded_cert) gibt erwartungsgemäß wilden Binärkram aus, etwas wie b'x\x9c\xbb\xd4\xe2\xbc\x90Qm!… Das sind, ganz wie die Wikipedia versprochen hat, zlib-komprimierte Daten. Ein zlib.decompress wirkt und führt auf etwas, in dem zum ersten Mal irgendetwas zu erkennen ist; neben viel Binärkram findet sich etwa:

    ...2bdtj2021-07-01bistRobert Koch-InstitutbmamOR...
    

    Keine Frage: Ich mache Fortschritte.

    Schale 4: CBOR/COSE

    An dieser Stelle bin ich auf mir unbekanntes Terrain vorgestoßen: CBOR, die Concise Binary Object Representation (Nerd-Humor: erfunden hat das Carsten Bormann, weshalb ich auch sicher bin, dass das Akronym vor der ausgeschriebenen Form kam) alias RFC 7049. Gedacht ist das als so eine Art binäres JSON; wo es auf die Größe so ankommt wie bei QR-Codes, habe ich schon Verständnis für diese Sorte Sparsamkeit. Dennoch: Sind Protocol Buffers eigentlich tot?

    Praktischerweise gibt es in bullseye das Paket python3-cbor2. Munter habe ich cbor2.loads(raw_payload) geschrieben und war doch etwas enttäuscht, als ich etwas wie:

    CBORTag(18, [b'\xa1\x01&',
      {4: b'^EVf\xa5\x1exW'},
      b'\xa4\x01bDE...',
      b'\xf9\xe9\x9f...'])
    

    zurückbekommen habe. Das ist deutlich mehr viel Binärrauschen als ich erhofft hatte. Aber richtig, das Zeug sollte ja signiert sein, damit die Leute sich ihre Impf- und Testzertifikate nicht einfach selbst schreiben. Die hier genutzte Norm heißt COSE (nämlich CBOR Object Signing and Encryption, RFC 8152 aus dem Jahr 2017). Ich habe das nicht wirklich gelesen, aber Abschnitt 2 verrät gleich mal, dass, wer an einer Signaturprüfung nicht interessiert ist (und das bin ich nicht, solange ich nicht vermuten muss, dass meine Apotheke mich betrogen hat), einfach nur aufs dritte Arrayelement schauen muss. Befriedigenderweise ist das auch das längste Element.

    Ein wenig neugierig war ich aber schon, was da noch so drinsteht. Die 18 aus dem CBORTag heißt nach Abschnitt 4.2, dass das eine Nachricht mit nur einer Unterschrift ist, und der letzte Binärkram ist eben diese eine Unterschrift. Das erste Array-Element sind Header, die mit unterschrieben werden, wieder CBOR-kodiert. Dekodiert ist das {1: -7}, und Überfliegen der COSE-Spezifikation (Tabellen 2 und 5) schlägt vor, dass das heißt: der Kram ist per ECDSA mit einem SHA-256-Hash unterschrieben.

    Tabelle 2 von COSE erklärt auch das nächste Element, die Header, die nicht unterschrieben werden (und über die mensch also Kram in die Nachrichten einfummeln könnte). Das sieht auch erstmal binär aus, ist aber ein „entpacktes“ Dictionary: In meiner Nachricht steht da nur ein Header 4, was der „Key Identifier“ ist. Der Binärkram ist schlicht eine 64-bit-Zahl, die angibt, mit welchem Schlüssel die Unterschrift gemacht wurde (bei PGP wären das die letzten 8 byte des Fingerabdrucks, viel anders wird das bei COSE auch nicht sein).

    Schale 5: CBOR lesbar machen

    Zurück zu den Zwiebelschalen. Wenn also die Nutzdaten im dritten Element des Array von oben sind, sage ich:

    cbor_payload = cbor2.loads(cose_payload.value[2])
    

    Heraus kommt dabei etwas wie:

    {1: 'DE', 4: 1657705736, 6: 1626169736,
    -260: {1: {'v': [{'co': 'DE', 'dn': 2, 'dt': '2021-07-01',
    'is': 'Robert Koch-Institut', 'ma': 'ORG-100030215',
    'mp': 'EU/1/20/1528', 'sd': 2, 'tg': '840539006',...}]}}}
    

    – das ist ziemlich offensichtlich die Datenstruktur, die der Zauber liefern sollte. Nur sind die Schlüssel wirklich unklar. v könnte wohl „Vaccination“ sein, is der Issuer, also der Herausgeber des Impfpasses; die Werte von 4 und 6 sehen verdächtig nach Unix-Timestamps in der nächsten Zeit aus (ja, es sind schon sowas wie 1,6 Milliarden Sekunden vergangen seit dem 1.1.1970).

    Aber Raten ist doof, wenn es Doku gibt. Wie komme ich also zu …

  • Javascript Local Storage

    Es gibt eine große Zahl gruseliger APIs (also: „Kram, den ein Programm tun kann“) in modernem Javascript, von Sensor APIs (zur Abfrage von Beschleunigung und Orientierung des Geräts und des Umgebungslichts) bis Websocket (mit dem weitgehend beliebige Server dauernd mit dem Client reden können, und das auch noch „im Hintergrund“ in Web Workers) – gruselig ist das, weil in aktuellen und nicht weiter modifizierten Browsern jede Webseite dieses Zeug nutzen kann, wobei eingestandenermaßen ein paar besonders dramatische APIs (Mikrofon und Kamera z.B.) noch durch Rückfragen abgesichert sind. Oh: Webseiten können das nicht nur nutzen, viel zu viele brauchen Javascript und gehen nicht, wenn mensch es abdreht.

    Der breite Zugriff auf fast alles von Javascript aus ist der Grund, warum ich des Öfteren ziemlich unwillig auf „please enable Javascript“-Banner (und noch mehr auf ihre Abwesenheit trotz Abhängigkeit von Javascript) reagiere. Javascript erlauben bedeutet spätestens seit XMLHTTPRequest (mit dem Javascript an der NutzerIn vorbei mit dem Ursprungsserver kommunizieren konnte; kam in der ersten Hälfte der Nullerjahre) und CORS (was XMLHTTPRequest und jetzt fetch auf beliebige Server ausweitete, solange die kooperieren; im Firefox tauchte das 2009 auf) einen recht weitgehenden Zugriff auf die eigene Maschine zu erlauben, und das noch ganz ohne Spectre und Freunde – die übrigens ohne ubiquitäres Javascript auf privaten Rechnern weitgehend bedeutungslos wären.

    Eine API, die ziemlich gruselig ist, weil sie Webseiten ein unendlich langes Gedächtnis in eurem Browser gibt, ist Local Storage; damit können Webseiten ernsthafte Datenmengen in eurem Browser speichern und sie wiederfinden, wenn sie das nächste Mal Javascript ausführen dürfen. Dass das zunächst lokal gespeichert wird, hilft nicht viel – per Websocket oder zur Not einem fetch mit Payload ist der Kram auch (wieder) auf jedem Server, der bereit ist, sich das anzuhören. Wohlgemerkt: ohne dass NutzerInnen irgendwas mitbekommen.

    Wenn ihr mein Gruseln nachfühlen wollt, könnt ihr hier mal Javascript einschalten (ihr lasst mich doch sonst kein Javascript ausführen, oder?). Ihr bekommt dann unter diesem Absatz ein Eingabefeld, in das ihr Kram tippen könnt. Wenn ihr einen hinreichend modernen Browser habt (technisch: er muss das storage-Signal schicken; Firefox 78 tut das z.B., Webkit 4.0.37 nicht), könnt ihr eure Nachricht in der Javascript-Warnung am Fuß der Seite sehen, schockierenderweise auch in anderen Fenstern, die ihr auf blog.tfiu.de offen habt. Auf allen halbwegs aktuellen Großbrowsern erscheint der Text jedenfalls nach dem nächsten Reload. Und bleibt auch da. Aufauf, schreibt eurem künftigen Selbst eine Nachricht in den Fuß dieser Seite:

    Gut. Du hast Javascript aus.

    Nennt mich paranoid, aber lustig ist das nicht.

    Und so ärgern mich noch viel mehr als Seiten, die Javascript fordern, Seiten, die ohne Local Storage leer bleiben oder sonst irgendwie undurchschaubar kaputt gehen.

    Was tun?

    Für die großen Browser gibt es allerlei Erweiterungen, die das Management von Local Storage erlauben; im Firefox sehe ich gerade Forget Me Not oder StoragErazor (was gleich noch die IndexedDB-API mit abdeckt, die ähnlich schrecklich ist, aber noch nicht viel genutzt wird); soweit ich erkennen kann, erlaubt das unverzichtbare noscript nicht, Javascript ohne Local Storage laufen zu lassen.

    Für meinen Haupt-Browser, den Luakit (verdammt, schon wieder ein Link von hier in github rein), habe ich eine kleine Erweiterung geschrieben, mit der ich mit der Tastenkombination ,tq schnell local storage ein- und ausschalten kann; auf die Weise kann ich normalerweise ohne Local Storage browsen, wenn dann aber mal wirklich eine Seite kaputt ist (gitlab ist da derzeit so ein ganz schlechtes Beispiel), braucht es nur ein paar Anschläge. Eine Anzeige in der Fußleiste (q/Q für Storage aus/an) kommt auch mit:

    -- Web storage control
    
    -- @module webstorage_control
    -- @copyright Public Domain
    
    local _M = {}
    
    local window = require("window")
    local theme = require("theme")
    local settings = require("settings")
    local modes = require("modes")
    local add_binds = modes.add_binds
    
    function update_webstorage_disp(w)
        if settings.get_setting("webview.enable_html5_database") then
            w.sbar.r.webstorage_d.text = "Q"
        else
            w.sbar.r.webstorage_d.text = "q"
        end
    end
    
    function toggle_local_storage(w)
        local local_storage_enabled =
            settings.get_setting("webview.enable_html5_database")
    
        settings.set_setting("webview.enable_html5_database",
            not local_storage_enabled)
        settings.set_setting("webview.enable_html5_local_storage",
            not local_storage_enabled)
        update_webstorage_disp(w)
    end
    
    window.add_signal("init", function (w)
        local r = w.sbar.r
        r.webstorage_d = widget{type="label"}
        r.layout:pack(r.webstorage_d)
        r.layout:reorder(r.webstorage_d, 1)
        r.webstorage_d.font = theme.font
        update_webstorage_disp(w)
    end)
    
    add_binds("normal", {
        { "^,tq$", "Enable/disable web local storage", toggle_local_storage},
    })
    
    return _M
    
    -- vim: et:sw=4:ts=8:sts=4:tw=80
    

    Wer auch den luakit verwendet, kann das nach .config/luakit/webstorage_control.lua packen und dann:

    require("webstorage_control")
    

    an geeigneter Stelle (z.B. in .config/luakit/rc.lua) unterbringen. Wenn dermaleinst so viele Seiten ohne Local Storage kaputtgehen wie derzeit ohne Javascript, müsste das wahrscheinlich eher wie in der noscript-Erweiterung automatisiert werden.

    Auch wenn ich mal Local Storage erlaube, will ich natürlich nicht, dass der Kram persistent bleibt. Deshalb habe ich noch folgendes kleine Python-Programm geschrieben:

    #!/usr/bin/python
    """
    Clear luakit web local storage and cookies
    
    There's a whitelist applied to both.
    """
    
    
    import fnmatch
    import glob
    import os
    import re
    import sqlite3
    
    
    class Whitelist:
        """A fnmatch-based whitelist.
    
        Test as in "domain in whitelist".  It's not fast, though.
        """
        def __init__(self,
                src_path=os.path.expanduser("~/.config/luakit/cookie.whitelist")):
            with open(src_path) as f:
                self.patterns = [s.strip() for s in f.read().split("\n")]
    
        def __contains__(self, domain):
            for pattern in self.patterns:
                if fnmatch.fnmatch(domain, pattern):
                    return True
            return False
    
    
    def clear_cookies(whitelist):
        """removes cookies from domains not in whitelist from luakit's
        cookies db.
        """
        conn = sqlite3.connect(
            os.path.expanduser("~/.local/share/luakit/cookies.db"))
    
        try:
            all_hosts = list(r[0]
                for r in conn.execute("select distinct host from moz_cookies"))
            for host in all_hosts:
                if host in whitelist:
                    continue
                conn.execute("delete from moz_cookies where host=?",
                    (host,))
        finally:
            conn.commit()
            conn.execute("VACUUM")
            conn.close()
    
    
    def try_unlink(f_name):
        """removes f_name if it exists.
        """
        if os.path.exists(f_name):
            os.unlink(f_name)
    
    
    def clear_local_storage(whitelist):
        """removes luakit's local storage files unless their source
        domains are whitelisted for cookies.
        """
        for f_name in glob.glob(os.path.expanduser(
                "~/.local/share/luakit/local_storage/*.localstorage")):
            mat = re.match("https?_(.*?)_\d+.localstorage",
                os.path.basename(f_name))
            if not mat:
                print("{}???".format(f_name))
                continue
    
            if mat.group(1) in whitelist:
                continue
    
            try_unlink(f_name)
            try_unlink(f_name+"-shm")
            try_unlink(f_name+"-wal")
    
    
    def main():
        whitelist = Whitelist()
        clear_cookies(whitelist)
        clear_local_storage(whitelist)
    
    
    if __name__=="__main__":
        main()
    

    Das Programm liest eine Liste von Shell-Patterns (also etwas wie *.xkcd.com) aus einer Datei ~/.config/luakit/cookie.whitelist und löscht dann alle Cookies und Local Storage-Einträge im Luakit, die nicht von Servern kommen, die in dieser Ausnahmeliste erwähnt sind. Das Ganze läuft bei mir jeden Morgen aus meiner Crontab:

    01 09 * * * ~/mybin/clear_luakit_cookies.py
    

    Aber: Besser wärs, das wäre alles nicht da. In einem Browser, also etwas, mit dem mensch Webseiten anschauen will, hat eine API wie Local Storage mit Persistenz und Signalisierung eigentlich nichts verloren.

    Oh: Der Javascript-Quellcode für den ganzen Spaß mit euren Notizen in der Fußzeile ist erschreckend klein. Für den Fall, dass ich das mal anders schreibe und das so nicht mehr im Seiten-Quellcode zu finden sein wird, hier zunächst der Code für das Eingabefeld oben:

    <div id="textarea-container">
      <p><em>Gut.  Du hast Javascript aus.
      </em></p>
    </div>
    
    <script deferred="deferred">
      function setUp() {
        document.querySelector("#textarea-container").innerHTML =
          `<textarea id="to-store" style="width:100%; height:6cm"
          placeholder="Tippt kram, den ihr im Fuß der Seite sehen wollt."
          ></textarea>`;
        let textSource = document.querySelector("#to-store");
        if (!window.localStorage) {
          textSource.value = "Ah, gut.  Du hast local storage aus.  Dann\n"
            +"geht das hier nicht.  Wie gesagt, das ist gut.";
           return;
        }
    
        if (window.localStorage.savedText) {
          textSource.value = window.localStorage.getItem("savedText");
        }
    
        textSource.addEventListener("input", () => {
          window.localStorage.setItem("savedText", textSource.value);
        });
    
        window.addEventListener("storage", (ev) => {
          textSource.value = ev.newValue;
        });
      }
    
      setUp();
    </script>
    

    Und dann noch der fürs Management der Fußzeile (der sitzt jetzt gerade im head-Element):

    if (window.localStorage) {
      target.innerHTML +=
        `<div id="ls-warning"><p><strong>Schlimmer noch:</strong>
        Dein Browser lässt mich
        auch local storage machen.  Wenn du dir in
        <a href="/javascript-local-storage.html">diesem Artikel</a>
        eine Nachricht hinterlässt, bekommst du sie bei deinem nächsten
        Besuch unten zu sehen; du kannst da sogar dein eigenes
        HTML und Javascript unterbringen und ausführen lassen.</p>
        <p id="user-message"/></div>`;
    
      if (window.localStorage.savedText) {
        document.querySelector("#user-message").innerHTML =
          window.localStorage.savedText;
      }
    
      window.addEventListener("storage", (ev) => {
        document.querySelector("#user-message").innerHTML = ev.newValue;
      });
    }
    
  • Ach, Sparda!

    Werbeschriften der Sparda-Bank

    Bin ich komisch, weil ich nicht gerne Geld geboten bekomme fürs Ausliefern von Bekannten an Banken?

    Ich bin leider Kunde der Sparda-Bank Baden-Württemberg. „Leider“ beispielsweise, weil mich die Bank dann und wann mit 75 Euro dazu bringen will, als Makler für sie tätig zu werden. Fände ich das Konzept Ehre nicht kreuzdoof, müsste ich wegen Betrag und Inhalt des Angebots Satisfaktion fordern.

    Lästiger im Alltag ist das Online-Banking, zumal es mit jedem „Relaunch“ schlimmer wird. Die utopische Hoffnung, ich könnte Kontoauszüge per PGP-verschlüsselter Mail bekommen und Überweisungen per signierter Mail in einem einfachen, maschinenlesbaren Format einreichen, habe ich dabei schon längst aufgegeben. Wahrscheinlich zwingen die diversen Zahlungsdiensterichtlinien die Bank wirklich zu (aus Sicht EDV-kompetenter Menschen) unsinnigen Schnittstellen.

    Aber wenn es schon hakelige Webseiten sein müssen, sollten sie wenigstens technisch so halbwegs in Ordnung sein. Fantastische Maximalforderung: die elementaren Funktionen sollten ohne Javascript gehen; das würde viel mehr für die Sicherheit tun als alle Zweifaktorauthentifizierungen des Universums. I have a dream.

    Die Sparda jedoch geht, wie gesagt, mit großen Schritten in die entgegengesetzte Richtung, kürzlich zu einem Laden namens TEO, mit dem sich einige Sparda-Genossenschaften, wie es aussieht, eine Art Fintech leisten wollten. Um damit nicht gleich bauchzulanden, ziehen sie ihre Kunden aus ihren alten (eingestandenermaßen auch unangenehmen) Systemen dorthin um.

    Schon, dass die KundInnen beim Umzug ein manuelles „onboarding“ samt Neueinrichtung der Konten sowie der (Nicht-) Zustellung von Kontoauszügen duchlaufen müssen, wirkt unnötig umständlich, so sehr ich verstehen kann, dass TEO nicht unbedingt die (vermutlich eher bescheidenen) Passwort-Hashes des alten Sparda-Eigenbaus übernehmen wollten. Bei den Investitionssummen, um die es hier vermutlich geht, wären jedoch elegantere Migrationspfade („bitte ändern sie jetzt ihr Passwort“) schon denkbar gewesen.

    Das um so mehr, als das onboarding richtig schlecht gemacht ist: Es erscheint erstmal ein leerer Bildschirm, und das ändert sich auch dann nicht, wenn mensch den Browser Javascript ausführen lässt. Kein Fallback, nichts, immer nur ein weißes Fenster. Das Javascript von TEO nämlich wirft eine Exception, wenn es kein local storage bekommt, und niemand fängt diese Exception. Ganz im Stil der neuen Zeit gibt es nicht mal ein minimales HTML ohne Skripting – nur weiß. Au weia.

    Zwei Zeilen Javascript würden reichen, um nicht verfügbare local storage zu diagnostizieren und das etwas weniger murksig zu machen (ordentliches HTML wäre natürlich immer noch nett). Etwas mehr Arbeit ist es, dann zu erklären, was da wie lang gespeichert wird und warum es ohne nicht gehen soll. Das jedoch würde ohnehin in die Datenschutzerklärung gehören, viel zusätzliche Arbeit wäre es also nicht. Wenn die Datenschutzerklärung etwas taugen würde, heißt das. Aber dazu gleich.

    Ich könnte jetzt weitermachen mit Punkten, an denen der Kram an allen möglichen und unmöglichen Stellen kaputt geht, ohne dass es irgendeine Sorte Fehlermeldung außerhalb der Javascript-Konsole (und welche Muggels kennen die schon?) gibt. Aber selbst wenn mensch den Browser – was bei Bank-Geschäften schon als schlechte Idee gelten kann – nach und nach immer unvorsichtiger konfiguriert, sind noch schwer verstehbare Schnitzer im Programm, etwa, dass der Flickercode die falsche Größe hat. Die meisten Clients haben inzwischen eine recht zuverlässige Idee von der physikalischen Größe der Anzeige; ein width: 6.5cm im CSS ist doch wirklich nicht zu viel verlangt.

    Ähnliche WTF-Momente ergeben sich in der Datenschutzerklärung der TEOs. Derzeit heißt es dort in 2.3:

    Zur Erhöhung der Kundensicherheit nutzen wir in TEO den Service reCAPTCHA der Google Ireland Limited, Gordon House, 4 Barrow St, Dublin, D04 E5W5, Irland. Im Rahmen der Registrierung in TEO wird das reCAPTCHA zur Erkennung und Unterscheidung zwischen missbräuchlicher Nutzung personenbezogener Daten durch Maschinen und menschliche Eingaben eingesetzt.

    Als ich das gelesen habe, habe ich erstmal mit dem „onboarding“ aufgehört, denn wer mir was verkaufen will, sollte nicht verlangen, dass ich Schaufenster oder Verkehrsschlider auf Zuruf von google abklicke, und mich schon gar nicht zum Ausführen von googles Code nötigen (ebay, hörst du mich?). Sparda beruft sich für diese Frechheit auf Art. 6 1(f) DSGVO, also berechtigte Interessen des Betreibers. Das ist offensichtlich Quatsch; Textchas oder selbst hostbare Tests funktionieren besser und unter weniger Kundenverprellung.

    Am Ende musste ich aber dringend überweisen und war entschlossen, den reCaptcha-Mist zur Not doch durchzustehen. Musste ich am Ende nicht nicht, google hielt meinen Browser offenbar wirklich für menschengesteuert – wer weiß, warum. Aber TEO lädt tatsächlich eine Datei recaptcha__de.js von google-Servern, und zwar dort aus einem Pfad wie /recaptcha/releases/CdDdhZfPbLLrfYLBdThNS0-Y/recaptcha__de.js – da könnte ich schon allein bei der URL ins Grübeln kommen, was für Informationen google da wohl aus dem Banking ausleiten mag (ok: ja, ich vermute in Wirklichkeit auch, dass die Buchstabensuppe eher etwas wie einen git-Commit auf google-Seite identifiziert – aber wenn die googles wollten, könnten sie über Pfade dieser Art fast beliebige Mengen an Information exfiltrieren, was erst dann auffallen würde, wenn mal wer Pfade verschiedener Clients vergliche).

    Was denken sich Leute, wenn sie ohne Not reCaptcha auf ihre Seiten packen? Diese Frage stellt sich fast noch mehr beim nächsten Punkt:

    2.4 Google Web Fonts

    Um Inhalte browserübergreifend korrekt und grafisch ansprechend darzustellen, werden in TEO Web Schriften von Google Fonts verwendet. Die Einbindung dieser Web Fonts erfolgt nicht über Google. Die Schriften liegen lokal auf Servern. Es erfolgt kein externer Serveraufruf bei Google. Es findet keine Informationsübermittlung an Google statt.

    Wenn ich recht verstehe, was die da sagen wollen, dann wäre das: Wir nehmen Fonts von google, aber ziehen sie nicht von google. Dann stellt sich die Frage, was diese Information hier soll – wenn die anfangen, aufzuzählen, wer alles irgendwie an der Software beteiligt war, die auf ihren Servern läuft, sind sie lang beschäftigt.

    Um das noch absurder zu machen: sie lügen (jedenfalls im Effekt). Zumindest gestern und heute versucht die Seite für mich, die URL https://fonts.gstatic.com/s/roboto/v18/KFOmCnqEu92Fr1Mu4mxP.ttf (und noch zwei weitere; ich hoffe, die Buchstabensuppe erhält nicht allzu viel Kompromittierendes über mich) zu dereferenzieren. Damit hat google die IP, via Referrer den Umstand, dass gerade wer überweist, und vermutlich auch die Muggel-Identität, da mich wundern würde, wenn nicht normal der google-Cookie auch an gstatic gehen würde (ich muss gestehen, das nicht näher untersucht zu haben, zumal fonts.gstatic.com auf meinen Maschinen zu localhost auflöst).

    Was soll das? Wenn TEO schon Geld in die Hand nimmt und meint, mir die Wahl des Fonts vorschreiben zu müssen (was ich übrigens lästig finde), dann sollen sie wenigstens irgendwas kaufen statt die vergifteten Geschenke von google zu nehmen und dann noch in ihrer Datenschutzerklärung zu lügen.

    Für eine teilweise Erklärung für die, na ja, Lüge (ich will gnädig sein: „das Versehen“) mit den google-Fonts hilft ein Blick auf die 107 (!) Requests, die mein Browser macht, um die Wurzelseite des Online-Bankings aufzubauen. Dabei zeigt sich, dass immerhin die meisten Daten von TEO-Servern kommen. Es bleiben aber, nach der Vorrede kaum überraschend, doch einige Cross-Site-Requests.

    • die erwähnten Google-Fonts
    • ein CSS, ein Logo, das Captcha-Javascript (von www.gstatic.com)
    • eine bizarre Datei „anchor“, die offenbar im Zusammenhang mit Captcha steht (und die den Browser vermutlich dazu bringt, die Fonts von fonts.gstatic.com zu ziehen)
    • Und dann noch Ressourcen list und logoutWeb von prod-teo.itmr.de, beides JSON, ersteres mit Zeug, was erstmal nach Werbequatsch aussieht, aber vermutlich Identitäsinformation ist.

    Die Suche nach ITMR in der Datenschutzerklärung ist vergeblich, www.itmr.de zeigt ohne Javascript nur einen Spinner:

    Ein Warte-Spinner

    Wenn dieses Ding genug Schöpfungshöhe für Copyright hat, liegt dieses vermutlich bei itmr. Hier verwendet unter der, klar, Satireklausel.

    Der Spinner ist schon mal deutlich mehr als die leere Seite von TEO. Mit Javascript kommt sogar ein Titel: „ITM Research GmbH – Smart Cloud Computing”, ansonsten bleibt es beim Spinner. ITM Research… nichts, was Wikipedia kennen würde. Smart? Na ja. Zieht auch erstmal fünf Pfund Zeug von Google, Fonts und eine Familienpackung Javascript von maps.googleapis.com, einen Haufen PNGs von www.google.com. Ziemlich viel Kram für einen rotierenden Spinner.

    Wenn ich der Seite obendrauf local storage erlaube, kommt endlich das heiß erwartete Cookie-Banner, und zwar so:

    Cookie-Banner mit vor-abgeklickten Trackingcookies

    Echt jetzt? Per default angeklickte Tracking-Cookies? Wie smart muss mensch wohl sein, um für so ein bisschen Überwachungsmehrwert ein fettes Bußgeld zu riskieren?

    Zurück zur Ausgangsfrage: Was für Daten tauscht die Sparda eigentlich mit diesen etwas anrüchigen Gesellen aus? „ITM-ation – unser Synonym für digitale Transformation und Innovation“ schreiben sie, wenn ihnen der Browser gut genug ist. Diese Leute bekommen mit, wenn ich mit der Sparda-Bank rede? Uh.

    Ich klicke auf „Mehr Erfahren”. Beim Bullshit Bingo hätte ich gleich gewonnen:

    Wir realisieren Projekte der digitalen Transformation und Innovation, um Ihnen durch die Digitalisierung von Geschäftsmodellen, Wertschöpfungsketten und Prozessen mehr Wachstum in einem immer stärkeren Wettbewerbsumfeld zu ermöglichen. [...] Wir entwickeln Apps und Web-Apps, um Geschäftsprozesse in digitale Ökosysteme zu transferieren. Wir entwickeln dabei Ihre Datenveredelungsstrategie, setzen aber auch externe Echtzeit-Dienste der künstlichen Intelligenz (KI) wie zum Beispiel Cognitive Services und Watson ein. [...] Eine positive User Experience ist unabdingbar in der Digitalisierung Ihrer Prozesse. Um das jederzeit und von überall zu erzielen, brauchen Sie zwischen Ihrer Anwendung und Ihren Kunden über alle Kanäle und Anwendungsoptionen hinweg funktionale und ansprechende Benutzeroberflächen und Schnittstellen.

    Der Bullshit gegen Ende suggeriert (ebenso wie der konsistente Totalausfall ohne …

  • Wie im Klischee

    Das Bild der EU als „Friedensmacht“, die allenfalls mit etwas Geld die Verhältnisse in der Welt milde verbessert, war natürlich schon immer Quatsch. Die Rücksichtslosigkeit, mit der Kommission und Rat rassistische und neokoloniale Agenden mit Gewalt durchsetzen („gemeinsame Außen- und Sicherheitspolitk“ oder GASP) sah jedoch zu Zeiten der Lomé-Abkommen durchaus deutlich harmloser aus (wobei auch diese viele Millionen Menschenleben erheblich verkürzt haben dürften [1]).

    Die GASP nun verbindet sich derzeit sehr direkt mit der blutigen Migrationspolitik der EU, beispielsweise im Aufbau von Return Case Management-Systemen. Das sind Verfahren, die der EU Zugriff auf Repressionsdatenbanken der Herkunftsländer von Geflüchteten geben. Damit auch die Regierungen der Herkunftsländer etwas davon haben, finanziert die EU wo nötig deren Auf- und Ausbau, inklusive Vollerfassung der Fingerabdrücke der Bevölkerungen.

    Wie das genau aussieht, und wie nebenbei der sicherheits-industrielle Komplex der EU gefüttert wird, hat im letzten November Privacy International (PI) am Beispiel des Senegal dokumentiert: ein Laden namens Civi.Pol, angesiedelt zwischen Rüstungsindustrie sowie französischem Geheimdienst und Innenministerium, baut eine Fingerabdruckdatenbank für sowohl die dortige Regierung als auch das EU-Deportationsmanagement.

    Nachtrag (2024-02-25)

    Nur, damit keine Zweifel bestehen über die Natur der Regierung, die die EU da aufrüstet: In der taz vom 14.2.2024 wird aus dem Senegal berichtet:

    „Anfangs haben sie gegen Demonstrierende Tränengas eingesetzt, heute sind es echte Kugeln.“ Dann fällt ein Name: Alpha Yoro Tounkara. Der Geografie-Student ist eines der drei Todesopfer der Niederschlagung der Proteste am vergangenen Freitag und ein Freund von Ndeye Magatte Seck

    PI hat den Artikel sehr treffend mit diesem offizielle Pressefoto der EU illustriert:

    Ndiaye und Avramopoulos dinieren

    Bildrechte beim Audiovisual Service der Europäischen Kommission; Nutzung für Zwecke der Verbreitung EU-bezogener Information.

    Hier trifft sich der Außenminister des Senegal, Mankeur Ndiaye, mit dem Migrationskommissar der EU, Dimitris Avramopoulos, und schon auf den ersten Blick ist klar, wer hier wem etwas erklärt, wer finster gucken darf und wer lächeln muss, und dass hier Anweisungen in kleinem Rahmen erteilt werden, die die Öffentlichkeit nichts angehen. Es ist auch kein_e Protokollführer_in in Sicht.

    Das Bild ist von 2016; vermutlich ging es bei diesem Gespräch also nicht direkt um den von PI diskutierten Deal. Dass aber die EU meint, ihre Verhandlungen mit Ländern im globalen Süden so illustrieren zu müssen und zu können, das ist zumindest in meiner Welt schon in sich ein Skandal.

    [1]Literaturtipp dazu: Brigitte Erler, Tödliche Hilfe, Freiburg 1985. Leider auch nicht in der Imperial Library of Trantor.
  • Reparaturgesetz zur Bestandsdatenauskunft

    Am Donnerstag hat der Bundestag die nächste Etappe im Marathon des Grundrechteabbaus genommen: ein Gesetz, das die Missachtung der Grundrechte aus diversen anderen Gesetzesvorhaben durch Weitertreiben zu heilen versucht. „Ich habe mir den Ringfinger abgesägt. Schneide ich mir noch den kleinen Finger ab, dann wird es bestimmt besser.”

    Konkret hatte das Bundesverfassungsgericht im vergangenen Mai bemängelt, wie nonchalant Behörden seit den 2013er Änderungen in Telekommunikationsgesetz (TKG) und Telemediengestz (TMG) allerlei Daten über Telekommunizierende – das umfasste durchaus auch PINs und PUKs, auch wenn das offenbar vielen Polizist_innen nicht klar war – von den Telekommunikationsunternehmen bestellen durften. Regierung und Parlament hatten nämlich befunden, es brauche dazu nicht mehr als im Wesentlichen einen Zuruf. Proponenten dieses dreisten Übergriffs hatten damals ernsthaft argumentiert, das sei ja im Groben wie im Telefonbuch nachsehen und brauche drum auch keinen stärkeren Schutz.

    Im Juni 2020 war sich der Bundestag dann nicht zu schade, nochmal dreistere Regeln – vor allem den ganz konkreten Anspruch aufs Rausrücken von Passwörtern – abzunicken, nämlich das „Gesetz zur Bekämpfung des Rechtsextremismus und der Hasskriminalität“. Wohlgemerkt: in Kenntnis der Argumentationen des Verfassungsgerichts, das genau diese Sorte von Generalermächtigung (aber leider auch nicht arg viel mehr) kritisiert hatte. Und offensichtlich ohne alle Bedenken wegen der semantischen Nähe von „Hasskriminalität“ zu „Gedankenverbrechen“.

    Das war sogar Bundespräsident Steinmeier, der als ehemaliger Dienstherr des BND sicher nicht als Aushängeschild menschenrechtlicher Prinzipientreue taugt, zu viel, und er verweigerte die Unterschrift unter die „Hasskriminalität“.

    Vor diesem Hintergrund kam nun dieses „Reparaturgesetz“, das die Spirale noch etwas weiter dreht; ein Muster, das von der „Anti-Terror“-Datei bekannt ist. Nach jedem Rüffel aus Karlsruhe genehmigt der Bundestag der Regierung eine noch krassere Version der verfassungswidrigen Regelung.

    Und das, finde ich, ist ein guter Anlass, nochmal den Stand der Dinge anzusehen, bevor er durch Dutzende Kilobyte Grundrechtsbarock (die am eigentlichen Verstoß natürlich fast nichts ändern) unkenntlich wird. Bevors losgeht, will ich kurz erwähnt haben, dass es noch reichlich Einzelgesetze gibt, die die Zugriffsrechte auf die Daten, um die es hier geht, nochmal speziell regeln, also etwa der Vorratsdatenspeicherungs- und Funkzellenabfrageparagraph §100g StPO oder Regelungen in den Polizeigesetzen der Länder, die nochmal betonen, dass die diskutierten Daten auch fair game sind, wenn noch gar nichts passiert ist („Gefahrenabwehr“). Deren Funktion ist aber nicht, die in TKG und TMG formulierten Zugriffsrechte einzuhegen. Fast immer versuchen diese Gesetze, Verhältnismäßigkeitserwägungen auszuhebeln, die ansonsten die Nutzung der Tk-Daten durch die Polizei verbieten würden – und das klappt ja in der Regel auch ganz gut, weil niemand so viele dieser autoritären Machwerke wegklagen kann wie die Parlemente durchwinken.

    Bestandsdaten

    ...werden in §14 Abs 1 TMG definiert als Daten, die für „die Begründung, inhaltliche Ausgestaltung oder Änderung eines Vertragsverhältnisses zwischen dem Diensteanbieter und dem Nutzer über die Nutzung von Telemedien erforderlich sind“.

    Absatz 2 erlaubt breit („Straftaten und Ordnungswidrigkeiten“) die Nutzung dieser Daten zu präventiven und repressiven Zwecken durch allerlei Polizeien und Geheimdienste. Darin ist auch das in seiner Komposition preiswürdige „zur Abwehr von Gefahren des internationalen Terrorismus oder zur Durchsetzung der Rechte am geistigen Eigentum“ enthalten.

    Während in dem Bereich die Abfrage auf Zuruf stattfand, war bei zivilrechtlichen Ansprüchen (insbesondere auch nach lex facebook, dem „Netzwerkdurchsetzungsgesetz“) eine Anordnung durch ein Landgericht vorgesehen.

    Mindeststandards für die Bestandsdaten werden in §111 TKG gesetzt [1]. Zu erfassen hat der Diensteanbieder (DA) nämlich:

    1. die Rufnummern und anderen Anschlusskennungen,
    2. den Namen und die Anschrift des Anschlussinhabers,
    3. bei natürlichen Personen deren Geburtsdatum,
    4. bei Festnetzanschlüssen auch die Anschrift des Anschlusses,
    5. in Fällen, in denen neben einem Mobilfunkanschluss auch ein Mobilfunkendgerät überlassen wird, die Gerätenummer dieses Gerätes sowie
    6. das Datum des Vertragsbeginns

    – und zwar auch dann, wenn er diese Daten gar nicht braucht. §111 TKG ist übrigens auch, was seit ein paar Jahren die unselige Ausweispflicht beim Kauf einer SIM-Karte begründet.

    Für den Zugriff auf diese Daten können Polizeien und Geheimdienste zwischen zwei Verfahren wählen.

    Erstens können sie (wie viele andere Behörden) den Umweg über die Bundesnetzagentur (BNetzA) gehen. Dazu schreibt §112 TKG („automatisiertes Auskunftsverfahren“) vor, dass die BNetzA in den Dateien des DA so recherchieren kann, dass der DA nicht merkt, was die BNetzA da so tut – ich wäre mal neugierig, ob es dazu wirklich technische Maßnahmen gibt oder ob diese Vertraulichkeit auf dem Erhebet-die-Herzen-Prinzip beruht.

    §112 Abs. 2 listet dann im Großen und Ganzen den gesamte Staatsapparat (insbesondere natürlich alle Polizeien und Geheimdienste) auf als anfrageberechtigt bei der BNetzA, und da der Abs. 1 erlaubt, auch mit unvollständigen Daten abzufragen, können all diese Behörden etwa „Daten von Leuten aus Wattenscheid, die 1982 geboren wurden“ bestellen; das ist ziemlich klar offiziell so gedacht, jedenfalls dem leicht verschämten „nicht benötigte Daten löscht [die anfragende Stelle] unverzüglich“ nach zu urteilen. Dass in irgendeinem Ministerium wer meinte, diese Datenschutz-Tautologie überhaupt ins TKG reinschreiben zu müssen, ist in ganz eigener Weise bezeichnend.

    Der andere Weg, um an Daten über Tk-Nutzer_innen zu kommen, ist das manuelle Auskunftsverfahren nach §113 TKG, das nur Polizeien und Geheimdiensten offen steht (und damit z.B. nicht der BaFin, die in §112 noch explizit eingeschlossen ist). Dabei reden die Behörden direkt mit den DAen. Erwähnenswert dabei, dass diese nach §113 Abs. 4 TKG ihren Kund_innen nicht sagen dürfen, was alles über sie, die Kund_innen, an die Behörden gegangen ist. Warum, so mögt ihr fragen, würde sich irgendwer die Arbeit machen, manuell anzufragen, wenn es doch auch das automatische Verfahren gibt? Nun, die automatischen Abfragen geben nicht mehr als die oben aufgeführten sechs Punkte. Im manuellen Verfahren kommen auch Bankverbindungen, Tarifdetails und überhaupt alles, was die DA so speichern dazu.

    Insbesondere, und das hat das BVerfG ganz wesentlich bewegt, die ganze Norm zu verwerfen, sieht der beanstandete 113er vor:

    Dies [Auskunftspflicht] gilt auch für Daten, mittels derer der Zugriff auf Endgeräte oder auf Speichereinrichtungen, die in diesen Endgeräten oder hiervon räumlich getrennt eingesetzt werden, geschützt wird. [...] Für die Auskunftserteilung nach Satz 3 sind sämtliche unternehmensinternen Datenquellen zu berücksichtigen.

    – beides Regelungen von atemberaubender Eingriffstiefe, an denen der Gesetzgeber, wenn auch mit kleinen Einschränkungen hinsichtlich der Anlässe, am Donnerstag festgehalten hat.

    Also: Die Regierung möchte gerne deine Passwörter bekommen können. Dass das technisch kompliziert ist, da nun hoffentlich in etwa jede_r Passwörter gar nicht mehr speichert (sondern nur deren Hashes), besorgt sie offenbar nicht.

    Der 113er spricht aber auch über Verkehrsdaten; die gehören zur zweiten Kategorie, die im TMG aufgemacht wird:

    Nutzungsdaten

    ...werden in §15 Abs. 1 TMG definiert das das, was es braucht um „die Inanspruchnahme von Telemedien zu ermöglichen und abzurechnen“. Im Gegensatz zu den Bestandsdaten, die erst im TKG konkretisiert werden, ist der Gesetzgeber bei diesen schon im TMG etwas präziser, denn er will „insbesondere“

    1. Merkmale zur Identifikation des Nutzers,
    2. Angaben über Beginn und Ende sowie des Umfangs der jeweiligen Nutzung und
    3. Angaben über die vom Nutzer in Anspruch genommenen Telemedien

    unter Nutzungsdaten verstanden wissen – das ist wohl Erbe des Furors um die Vorratsdatenspeicherung, zumal im Zeitalter von Flatrate oder Volumentarif von all dem normalerweise nicht mehr viel übrigbliebe.

    Eine spezielle Sorte Nutzungsdaten (und die eigentlich saftigen) sind Verkehrsdaten nach §96 TKG, nämlich:

    1. die Nummer oder Kennung der beteiligten Anschlüsse oder der Endeinrichtung, personenbezogene Berechtigungskennungen, bei Verwendung von Kundenkarten auch die Kartennummer, bei mobilen Anschlüssen auch die Standortdaten [zu denen in §98 TKG noch mehr zu lesen ist],
    2. den Beginn und das Ende der jeweiligen Verbindung nach Datum und Uhrzeit und, soweit die Entgelte davon abhängen, die übermittelten Datenmengen,
    3. den vom Nutzer in Anspruch genommenen Telekommunikationsdienst,
    4. die Endpunkte von festgeschalteten Verbindungen, ihren Beginn und ihr Ende nach Datum und Uhrzeit und, soweit die Entgelte davon abhängen, die übermittelten Datenmengen,
    5. sonstige zum Aufbau und zur Aufrechterhaltung der Telekommunikation sowie zur Entgeltabrechnung [die in §97 genauer geregelt ist] notwendige Verkehrsdaten.

    §96 Abs 1 TKG klingt dann ziemlich streng: „Im Übrigen sind Verkehrsdaten vom Diensteanbieter nach Beendigung der Verbindung unverzüglich zu löschen.“ Allerdings ist das Nicht-Übrige etwas wie Entgeltabrechnung – die nach §97 (3) TKG Speicherung bis zu sechs Monaten rechtfertigt –, Marketing bei entsprechender Einwilligung und insbesondere „andere gesetzliche Vorschriften“; gemeint ist natürlich die Vorratsdatenspeicherung, geregelt in §113b (der derzeit nicht angewandt wird, da ja die Vorratsdatenspeicherung mehrfach höchstrichterlich als groteske Missachtung von Grundrechten erkannt wurde).

    Jandl-Gedichte

    2021: Gesetze ähneln immer mehr konkreter Poesie.

    Und hier kommen wir zum vom BVerfG angemäkelten §113 TKG zurück, der nämlich vorsieht, dass sich Behörden in diesem manuellen Verfahren auch die 96er-Daten bei den DAen abholen können. Das gilt für alle Tk-Unternehmen, die mit über 100000 Kund_innen müssen sogar eine „gesicherte elektronische Schnittstelle“ bereitstellen. Immerhin: die Polizei kann noch nicht frei in den Datenbanken der DAen recherchieren: „Dabei ist dafür Sorge zu tragen, dass jedes Auskunftsverlangen durch eine verantwortliche Fachkraft auf Einhaltung der in Absatz 2 [im Wesentlichen: Textform, es geht um Straftaten oder Ordnungswidrigkeiten, und Absender ist Polizei oder Geheimdienst] genannten formalen Voraussetzungen geprüft und die weitere Bearbeitung des Verlangens erst nach einem positiven Prüfergebnis freigegeben wird“ (§113 Abs. 5 TKG).

    Und jetzt?

    Soweit erkennbar, tut das am Donnerstag abgenickte Gesetz alles, um den hier umrissenen (und vom BVerfG als unhaltbar erkannten) Zustand zu erhalten und zu vertiefen. Wer den Entwurf in Bundestagsdrucksache 19/25294 ansieht, erkennt das Muster: Ab Seite 5 wird über 30 Seiten genauer ausgeführt, was die alte Regelung „auf …

Seite 1 / 1

Letzte Ergänzungen