Wenn eine App Berechtigungen anfordert, sollte es eine Option zur „Bereitstellung falscher Daten“ geben.

 (archive.md)
1 Punkte von GN⁺ 2023-07-09 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn eine App Berechtigungen anfordert, sollte das OS nicht nur Ja/Nein-Antworten erlauben, sondern für jede Berechtigungskategorie zusätzlich eine „Option zur Bereitstellung falscher Daten“ anbieten
  • Fordert sie Kontakte an, werden generierte Fake-Kontakte geliefert; fordert sie Mikrofonzugriff an, zufällige Umgebungsgeräusche; fordert sie Standortdaten an, die Koordinaten einer kleinen 5×5-m-Insel
  • Wird der Zugriff blockiert, verweigert die App oft die Nutzung mit „Dann ist die App nicht verwendbar“, aber mit falschen Daten würden nur die Dienste bestraft, die unnötige Daten verlangen
  • Ein Boykott verlangt vom Nutzer große persönliche Opfer, trifft Unternehmen aber nur geringfügig; daher sei malicious compliance wirksamer als Boykott
  • Das führt zur Frage der Nutzerkontrolle: Nutzer sollten als Administratoren ihrer eigenen Geräte Apps und Systemsoftware kontrollieren können

Kernvorschlag — Option für falsche Daten je Berechtigung

  • Das OS sollte bei Berechtigungsanfragen neben Ja/Nein für alle Kategorien auch die Auswahl „Ja, aber mit falschen Daten“ anbieten
    • Kontaktanfrage → zufällig generierte Fake-Kontakte
    • Mikrofonanfrage → zufällige Umgebungsgeräusche (random ambiance)
    • Standortanfrage → Antwort, man befinde sich auf einer kleinen 5×5-m-Insel
  • Wenn ein Dienst Daten anfordert, die er nicht benötigt, hat das den Effekt einer Bestrafung, weil seine Datenbank mit nutzlosen Informationen gefüllt wird
  • Anders als beim Blockieren des Zugriffs kann die App bei falschen Daten nicht einfach mit „nicht nutzbar“ reagieren, während unnötige Datensammlung zugleich entwertet wird

Behauptete Vorteile gegenüber Boykotten

  • Auf notwendige Apps zu verzichten bedeutet einen erheblichen persönlichen Verzicht, während Milliardäre davon kaum etwas merken — ein schlechter Tausch
    • Eine Struktur, bei der die kämpfende Seite am meisten verliert, sei für Nutzer nachteilig
  • Das Einspeisen falscher Daten gebe Nutzern mehr Macht
  • Es wird die Formulierung verwendet, „malicious compliance“ mache mehr Spaß als Boykott

In der Diskussion erwähnte bestehende Mittel

  • Standort-Spoofing (location spoofing)

    • Früher war Standort-Spoofing nur als globale Einstellung möglich, nicht sinnvoll pro App
    • In den Android-Entwicklereinstellungen kann eine bestimmte App als Mock-Location-App festgelegt werden, was global wirkt
    • Für Firefox gibt es Erweiterungen zum Spoofing verschiedener Daten wie Geolokation, auf dem Smartphone wäre eine systemnahe Lösung aber nützlicher
    • Bei Pokémon GO gab es Missbrauch mit gefälschten Standortdaten, was die technische Machbarkeit gezeigt hat

  • XPrivacyLua

    • Auf gerooteten Geräten tat es genau das, was Nutzer wollten, benötigte aber Magisk (Systemmodifikationen)
    • Inzwischen wird es nicht mehr gepflegt und ist nicht mit allen Geräten kompatibel

  • Standard-Berechtigungsfunktionen von Android

    • Android erlaubt bereits, den Informationszugriff pro App auszuwählen oder jedes Mal nachzufragen
    • Das ist jedoch nur ein Blockiermechanismus und nicht dasselbe wie die Bereitstellung falscher Daten

Erweiterte Ideen und Beispiele

  • Datenvergiftung mit AI

    • Vorschlag, Data Minern rekursiv bedeutungslose Informationen zu liefern, um sie zu entwerten
    • Idee, mit AI-generierten Daten sogar Inhalte für das AI-Training zu vergiften

  • Gegenmaßnahmen zu Werbetracking

    • Erwähnt wird AdNauseam (ein Fork von uBlock Origin), das Werbung blockiert und zugleich alle Anzeigen anklickt, um Targeting-Daten zu entwerten
    • Frühere Versuche galten als ressourcenintensiv

  • Störung von Browser-Tracking-Profilen

    • Es gibt Dienste, die mit Browser und Cookies schnell viele Websites durchlaufen, um Fingerprinting und Tracking zu stören
    • Es lassen sich zufällige oder profilbasierte Muster wählen, etwa „surfen wie ein 70-jähriger Hippie aus Ecuador“
    • Genannt wird das von Mozilla entwickelte Beispiel TrackThis

Genannte Grenzen und Bedenken

  • Wer ein zufälliges Geburtsdatum eingibt, bekommt zwar an einem beliebigen Tag Geburtstagsgrüße, weiß bei Sicherheitsfragen aber nicht mehr, welches Datum verwendet wurde
    • Als Ergänzung wird vorgeschlagen, dass das OS dem Nutzer seine eigenen falschen Datenwerte anzeigen können sollte
  • Vor etwa zehn Jahren wurde dies als Startup-Idee geprüft, aber es ließ sich kein Jurist finden, der es rechtlich belastbar absichern konnte
  • Da kommerzielle Entwickler sich davor stark fürchten würden, sei es äußerst unwahrscheinlich, dass Google dies umsetzt
  • Als grundlegende Ursache wird genannt, dass weder Google noch Apple wollen, dass Nutzer Kontrolle haben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-09
Hacker-News-Kommentare

  • Ich bin für die Idee von „Fake-Daten“, aber Apps sollten dazu verpflichtet werden, elegant damit umzugehen, wenn Nutzer den Zugriff auf echte Daten verweigern
    Als ich früher iOS-Apps entwickelt habe, war es Apple-Richtlinie, dass man Nutzer nicht dafür bestrafen oder die App per exit() beenden durfte, nur weil sie eine Berechtigung verweigert haben; die App musste weiterlaufen
    Noch früher durfte man für die Nutzung einer App nicht einmal ein „Konto“ verlangen. Ich erinnere mich, dass meine Firma vor über zehn Jahren eine Kontopflicht eingeführt hat und damit völlig zu Recht im App Store abgelehnt wurde. Heute scheint diese Haltung aufgeweicht zu sein, wenn man sieht, wie viele Apps inzwischen ein Konto voraussetzen

    • Bei der Aussage „Apps dürfen kein Konto verlangen, um zu funktionieren“ fehlt ein wichtiger Zusatz, oder ich verstehe nicht, was gemeint ist
      Banking-Apps, Online-Spiele, die heutige Twitter-App oder Apps wie Dropbox/Nextcloud – wie sollten die ohne Konto funktionieren?
      Dass die Kontoanforderung bei vielen Apps ein Marketing-Trick ist, stimmt, aber als allgemeine Regel scheint das nicht praktikabel zu sein
    • WhatsApp bestraft Nutzer immer noch, wenn sie den Zugriff auf Kontakte verweigern. Dann werden alle Namen ausgeblendet und nur Telefonnummern angezeigt, selbst wenn die andere Person ihren Namen im Profil gesetzt hat
      Facebook/Meta ist Müll
    • Gefälschte persönliche Daten wie Kontakte oder Fotos sind okay, aber bei Standortdaten wird es heikel
      Wenn es nur darum geht, meinen Standort auf einer Karte anzuzeigen oder Geschäfte in der Nähe zu suchen, kann man ruhig Fake-Daten liefern
      Aber wenn eine App für Internet-Geschwindigkeitstests Geschwindigkeiten nach Provider auf einer Karte darstellt oder Nutzer lokales Wetter melden, um Vorhersagen zu verbessern, dann sollte sie meines Erachtens sagen dürfen: „Gib uns entweder einen genauen Standort oder gar keinen; einen falschen Standort wollen wir nicht“
      Die Plattform müsste entscheiden, ob Apps, die nutzergenerierte Daten entgegennehmen und damit andere beeinflussen, eine Ausnahme bekommen
      Apple scheint hier einen ziemlich guten Mittelweg gefunden zu haben. Man muss Apps keinen „genauen Standort“ erlauben, und bei Fotos kann man der App auch nur die Bilder zeigen, die der Nutzer über den vom System bereitgestellten Bildauswähler ausgewählt hat
    • Am schlimmsten auf iOS ist Google Photos. Wenn man nicht Zugriff auf alle Fotos erlaubt, lässt sich die App gar nicht erst öffnen, und auch „nur ausgewählte Fotos erlauben“ akzeptiert sie nicht
      Das gilt sogar dann, wenn man nur Fotos ansehen will, die bereits in der Cloud gespeichert sind
    • Selbst wenn man sagt: „Apps müssen elegant damit umgehen, wenn Nutzer den Zugriff auf echte Daten verweigern“, was passiert, wenn sie es nicht tun?
      Das ist ein organisatorischer Lösungsansatz für ein technisches Problem, und das funktioniert schwer; die einzig praktische Lösung sind Fake-Daten. Für die App muss es so aussehen, als sei die Berechtigung erteilt worden, auch wenn das in Wirklichkeit nicht der Fall ist

  • Auf gerooteten Android-Geräten konnte XPrivacy das schon vor 7 Jahren, und es gibt auch modernere Alternativen. Ich habe mein Handy aber lange nicht mehr gerootet, deshalb will ich dafür nicht garantieren: https://github.com/M66B/XPrivacy
    Natürlich ist das nichts für den Mainstream, und ich stimme zu, dass so etwas standardmäßig eingebaut sein sollte. Aber sowohl Android als auch iOS erlauben Unsinn wie regional eingeschränkte Apps oder das Blockieren von Screenshots bei DRM-Inhalten, daher dürfte das schwierig werden

    • Als ich es so benutzt habe, habe ich direkt gespürt, wie sehr das System gegen den Nutzer ausgelegt ist, und den Glauben aufgegeben, dass ein Handy ein Computer ist
      Ein Handy ist ein Content-Auslieferungsgerät des Herstellers, und der Nutzer ist ihrem Gutdünken ausgeliefert
    • XPrivacy war wirklich großartig, aber auf modernen Smartphones ist Rooten und das Installieren von Xposed viel komplizierter geworden oder ganz blockiert
      GrapheneOS kam mit Banking-Apps nicht gut klar, Google hat Root über Magisk in Android Beta mehrfach kaputtgemacht, und irgendwann hat es mich einfach nicht mehr interessiert
      Vielleicht könnten GrapheneOS oder ähnliche Projekte so eine Funktion umsetzen
    • XPrivacy war hervorragend, aber wenn man bestimmte Berechtigungen verweigert hat, sind Apps oft abgestürzt. Letztlich konnte es Fake-Daten also nicht gut genug liefern
      Es war so schlimm, dass ich nie direkt auf „Verweigern“ gedrückt habe, sondern immer erst auf „vorübergehend verweigern“. Wenn die App dann lief, habe ich dauerhaft verweigert; wenn sie abstürzte, musste ich die kleinste Menge an Rechten finden, die ich erlauben musste
    • In Factory-Images oder im Android-Upstream wird diese Funktion wohl nie landen, aber wenn die Nachfrage groß genug ist, könnte sie in Projekten wie LineageOS auftauchen
    • Mit „regional eingeschränkten Apps“ ist eigentlich nicht das gemeint, was die Apps selbst tun, sondern dass jeder App Store die Verteilung einer App nur in ausgewählten Regionen erlaubt
      Das ist für App Stores wichtig, weil eine App nicht in allen Ländern eine gute Nutzererfahrung bieten kann, vielleicht nicht in alle Sprachen lokalisiert ist, es keine Moderatoren für Inhalte in der betreffenden Sprache gibt, lokale Gesetze eingehalten werden müssen oder die Vertriebsrechte für urheberrechtlich geschützte Inhalte auf bestimmte Länder beschränkt sind
      Das Verhindern von Screenshots bei DRM-Inhalten ist eine Funktion, die App-Entwickler wegen rechtlicher Anforderungen von Lizenzen für Inhalte wie Filme anfordern. Filmstudios wollen nicht, dass Leute Filme streamen oder mitschneiden, daher braucht die Plattform eine Möglichkeit, solche Inhalte sicher anzuzeigen

  • „Wenn jemand eine Frage stellt, die er nicht zu stellen berechtigt ist, dann bist du nicht verpflichtet, ihm die Wahrheit zu sagen“
    — Leonard Schiffman
    Quelle: „Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services“ https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • Mit der Behauptung, dass das Betriebssystem bei App-Berechtigungsanfragen nicht nur Ja/Nein, sondern auch „Ja, aber der App gefälschte Daten geben“ anbieten sollte, gibt es ein Problem
    Viele Nutzer wissen nicht einmal, wie man eine E-Mail weiterleitet
    Stell dir vor, was für ein Chaos entsteht, wenn solche Leute Google Maps zur Navigation benutzen und gefälschte Daten auswählen, ohne die Bedeutung zu verstehen
    Google Maps: „Biegen Sie rechts ab“
    Fahrer auf einer Küstenstraße: „Alles klar“
    Auto: platsch

    • Das ist vollständig ein User-Experience-Problem
      Man muss die Funktion zur Datenfälschung nur tief in den Einstellungen verstecken, vor dem Einschalten in einfachen Worten klar erklären und auf dem Bildschirm deutlich machen, dass der App wegen einer vom Nutzer selbst aktivierten Datenschutzfunktion Ersatzinformationen bereitgestellt werden und sich das leicht wieder abschalten lässt
      Es wird trotzdem Leute geben, die das versehentlich einschalten, aber für viele andere kann es einen großen Wert haben
    • Das sieht nach einer Lerngelegenheit aus. Oder vielleicht nach einer darwinistischen Gelegenheit
      So oder so ist es ein sich selbst lösendes Problem
    • Dann macht man diese Einstellung eben zu einer Option für fortgeschrittene Nutzer. Nutzer ohne Erfahrung bekommen die Option dann gar nicht zu sehen
    • In so einem Fall hat der Fahrer seine Fahrtrichtung nicht richtig im Blick gehabt, und das ist ein anderes Problem
      Das Betriebssystem sollte besser „Ja“, „Nein“ und „Benutzerdefiniert“ anbieten. Wenn man „Benutzerdefiniert“ wählt, kann man in diesem Menü bei Bedarf Warnhinweise anzeigen, aber man sollte Nutzer nicht daran hindern, es nach ihren Wünschen anzupassen
    • Ich frage mich, ob Google Maps auf iOS viel genutzt wird. Eine Option wie „gefälschte Daten bereitstellen“ könnte Apple vielleicht umsetzen, aber dass Google so etwas tun würde, kann ich mir beim besten Willen nicht vorstellen
      Apple Maps hätte dieses Problem nicht. Man kann Karten auf das Gerät herunterladen, sodass es auch ohne Datenverbindung offline funktionieren kann

  • Es überrascht mich, dass im Top-Kommentar nicht erwähnt wird, dass man unter iOS nicht unterscheiden kann, ob eine Berechtigung erteilt wurde oder nicht
    Wenn eine App zum Beispiel Zugriff auf Fotos anfordert, bekommt sie immer ein Array. Wenn die Berechtigung verweigert wird, ist dieses Array nur leer, sodass man nicht erkennen kann, ob die Mediathek des Nutzers wirklich leer ist oder der Zugriff verweigert wurde. Das ist schön einfach und elegant
    Natürlich kann man bei Fotos heuristisch arbeiten, weil fast jeder ein paar Bilder hat. Bei anderen Typen wie Gesundheitsdaten ist das aber nicht so eindeutig

    • Das stimmt so nicht. Für den Zugriff auf Ortungsdienste gibt es zum Beispiel CLAuthorizationStatus: https://developer.apple.com/documentation/corelocation/claut...
      Für Push-Benachrichtigungen gibt es UNAuthorizationStatus: https://developer.apple.com/documentation/usernotifications/...
      Für Gesundheitsdaten gibt es HKAuthorizationStatus: https://developer.apple.com/documentation/healthkit/hkauthor...
      Für Kontakte gibt es CNAuthorizationStatus: https://developer.apple.com/documentation/contacts/cnauthori...
      Für Fotos gibt es PHAuthorizationStatus: https://developer.apple.com/documentation/photokit/phauthori...
      Fotos sind ein Sonderfall, weil Nutzer zwischen verweigertem Zugriff, eingeschränktem Zugriff und vollem Zugriff wählen können. Ob der Zugriff verweigert wurde, lässt sich erkennen, aber eingeschränkter und voller Zugriff lassen sich nicht unterscheiden
    • Ich frage mich, wie das bei Standortdaten funktioniert
      Und wenn ein Fotoordner leer ist, bedeutet das fast sicher, dass keine Berechtigung vorliegt. Menschen, die noch nie ein Foto gemacht haben, sind sehr selten
    • Wie ist es bei anderen Berechtigungen, bei denen sich realistisch kein leeres Objekt senden lässt
      Wenn der Nutzer etwa erlaubt, dass sein Standort angezeigt wird, enthält das an die App übergebene Standortobjekt natürlich entsprechende Informationen. Würde nicht sofort klar, dass die Berechtigung verweigert wurde, wenn das Betriebssystem ein leeres Standortobjekt zurückgäbe, oder wird das irgendwie hinter einem Fehler versteckt
    • Das ist offensichtlich nicht wahr, und man kann es bei fast jeder App sehen, die Zugriff auf Benachrichtigungen anfordert

  • Ich halte „gefälschte Daten bereitstellen“ für den falschen Ansatz. Der bessere Ansatz wäre, Daten aus alternativen Quellen bereitzustellen, und diese alternative Quelle sollte jedes beliebige andere Programm sein können
    Die alternative Quelle könnte leere Daten sein, Zufallsdaten, gefälschte aber konsistente Daten, Daten aus alternativen Dateien (etwa eine separate Kontaktliste oder Fotos aus Dateien statt von der Kamera), transformierte Daten (zum Beispiel Kamerafotos auf den Kopf gestellt), Filterung, Protokollierung, Rückfrage an den Nutzer bei jedem einzelnen Datenelement, Bereitstellung von Fehlercodes statt Daten samt nutzerdefinierbaren Fehlercodes und überhaupt alles, was der Nutzer möchte. Das sollte sogar den Zugriff auf aktuelles Datum/Uhrzeit umfassen
    Das erhöht die Nutzerkontrolle und ist auch für Tests und Barrierefreiheit nützlich
    Eine meiner Ideen für Betriebssystemdesign sind Proxy-Berechtigungen. In ein berechtigungsbasiertes Sicherheitsmodell würden Proxy-Berechtigungen integriert, sämtliche Ein- und Ausgaben würden sie verwenden, man könnte sie in der Shell besser als mit UNIX-Pipes einsetzen und auch auf andere Weise nutzen. Datum/Uhrzeit wäre ebenfalls eingeschlossen. Außer Yield und Quit könnte kein Systemaufruf ohne Berechtigungsschlüssel verwendet werden

    • Das ist der beste Ansatz und in der Praxis wohl der einzige, der funktionieren kann
      Für App-Entwickler ist es sehr schwer, sauber mit Berechtigungen umzugehen, die sie nicht verwenden können, und der Testumfang wird für eine relativ kleine Nutzergruppe viel größer und schwieriger, daher werden die meisten kleinen kommerziellen Apps das wahrscheinlich nicht ordentlich behandeln
      Berechtigungen zu erlauben, aber alternative Datenquellen einzuspeisen, ist für Entwickler und Nutzer am einfachsten
      Natürlich könnte das auch Betrug erleichtern. Banken würden dann zum Beispiel kompliziertere Verfahren zur Geräteregistrierung verwenden

  • Es gibt keinen Grund, unnötig gegeneinander zu arbeiten. Die einfache Regel lautet: "Nein ist eine Option", außer wenn es wirklich keine Option ist.
    Wenn es keine Option ist, muss sehr klar sein, warum, und das sollte wahrscheinlich im App-Prüfprozess offengelegt werden; andernfalls sollte die App abgelehnt werden.
    Wenn TikTok/Instagram zum Beispiel Kamera- und Mikrofonrechte anfordert, ist beides für die Nutzung der App nicht essenziell, also ist Nein eine Option. Wenn sich Teile einer App auch ohne eine bestimmte Berechtigung nutzen lassen, liegt die Verantwortung bei der App, so entworfen zu sein, dass sie entsprechend funktioniert. Wenn Kamera oder Mikrofon deaktiviert sind, müssen einfach nur die Funktionen, die diese Berechtigung benötigen, bedingt deaktiviert werden.
    Noch einfacher gesagt: Die Beweislast liegt beim Anfragenden. Wenn es nicht klar ist oder man versucht, sich clever herauszuwinden, lautet die Antwort Nein. Das mag streng klingen, aber App-Entwickler können diesen zusätzlichen Schritt komplett vermeiden, indem sie Berechtigungen optional machen.
    Wenn man sich darauf konzentriert, das durchzusetzen, braucht es kein kleinteiliges Wettrüsten, und für die Menschen ist es ebenfalls die bessere Wahl.

    • Klingt gut, aber wie soll man das durchsetzen?
      Die einzigen Stellen, die das hier durchsetzen können, sind die App Stores von Google/Apple/Microsoft. Es ist schwer sicher zu sein, dass sie genügend Anreiz haben, das auf konsistente und nutzerfreundliche Weise durchzusetzen. Wenn sie ihn hätten, hätten sie es vermutlich bereits getan.

  • Samsung-Smartphones haben Schalter für Kamerazugriff und Mikrofonzugriff.
    Wenn man ihn deaktiviert, erscheint diese Meldung:

    Turn off Camera access?  
All apps will be blocked from using the camera. Apps  
will still work, but they will only be able to access an  
empty black screen. For example, you can still make  
and receive video calls, but the other person won't be  
able to see you.
    • Für den Mikrofonzugriff: 
      Turn off Microphone access?  
All apps will be blocked from using the microphone  
Apps will still work, but they won't be able to access  
any sounds from the microphone. For example, you  
can still make and receive calls, but the other person  
won't be able to hear you.

  • Besser als "für jede Kategorie eine Option 'Ja, aber der App gefälschte Daten geben'" wären app-spezifische Einstellungen.
    Vielleicht möchte man Standortdaten fast keiner App geben, aber Google Maps und einer App für Notrufe schon. Dasselbe gilt für Kontakte und persönliche Daten.
    Allerdings würden solche Apps auf heftigen Widerstand von Google und anderen Unternehmen stoßen, die von Nutzerprofiling profitieren.

    • Stimme zu, aber es sollte pro App und zugleich pro Berechtigungskategorie sein.
      Zum Beispiel sollte man einer App für eine Berechtigung echte Daten geben können, für eine andere gefälschte Daten oder benutzerdefinierte/manuell eingegebene Daten und eine dritte Berechtigung ablehnen können.
      Man möchte die Einstellung vielleicht auch vorübergehend ändern, etwa zu Testzwecken oder wenn man in einer Wetter-App für den aktuellen Standort kurz das Wetter an einem anderen Ort sehen und danach wieder zum echten Standort zurückkehren will.

  • Wenn eine App meine Daten braucht, um mein Erlebnis zu verbessern, und zwar nur mein Erlebnis, dann sollte sich bei gefälschten Daten auch nur mein Erlebnis verschlechtern. Dem App-Entwickler oder Eigentümer sollte das egal sein.
    Wenn das Ziel aber, wie in den meisten Fällen, darin besteht, mich per Data Mining auszuwerten, dann funktionieren gefälschte Daten ziemlich gut, um das zu stören.
    Natürlich bringt das bei WhatsApp kaum etwas, weil Menschen bereitwillig ihre komplette Kontaktliste mit Facebook/Meta synchronisieren, nur um ein etwas besseres Messaging-Erlebnis zu bekommen.

    • Ich musste das auch tun und fand es extrem unerquicklich, aber das war nicht bloß ein "etwas besseres Erlebnis".
      Zumindest mobil sind App und Dienst kaum brauchbar, bevor man die Kontakte synchronisiert hat.