21 Punkte von GN⁺ 2025-06-04 | 11 Kommentare | Auf WhatsApp teilen
  • Es wurde bekannt, dass große Apps wie Meta (Facebook) und Yandex auf Android lokale Ports (127.0.0.1) nutzten, um Identifier und Cookies heimlich zwischen Webbrowser und nativen Apps zu teilen
  • In Websites eingebettete Skripte wie Facebook Pixel und Yandex Metrica übermitteln in Android-Browsern Browsing-Sitzungen und Identifier direkt an native Apps (Facebook, Instagram, Apps aus dem Yandex-Umfeld), wodurch Nutzeridentifizierung und Deanonymisierung möglich werden
  • Diese Methode umgeht alle bisherigen Datenschutzmaßnahmen wie Cookie-Löschung, Inkognito-Modus, Berechtigungseinstellungen oder das Zurücksetzen der Werbe-ID; wenn eine bösartige App lediglich auf dem passenden Port lauscht, kann sie zudem den Browser-Verlauf sammeln
  • Nach der Offenlegung am 3. Juni 2025 entfernte Facebook den Großteil des betreffenden Codes, doch die Technik war über Jahre auf Hunderten Millionen Android-Geräten weltweit im Einsatz. Yandex verwendet seit 2017 fortlaufend ein ähnliches Verfahren
  • Wichtige Browser wie Chrome, Firefox und Brave haben Notfall-Sperrmaßnahmen eingeführt, doch aufgrund struktureller Plattformgrenzen fehlt bislang eine vollständige grundlegende Lösung; betont wird die Notwendigkeit, Android-IPC und die Sicherheit lokaler Netzwerke zu stärken

Disclosure: Verdeckte Web-App-Tracking-Methode über Localhost

  • Die Forschenden entdeckten, dass Meta und Yandex für Milliarden Android-Nutzer native Apps im Hintergrund festgelegte lokale Ports öffnen lassen (z. B. 12580–12585, 29009–30103) und darüber mit auf Webseiten ausgeführtem JavaScript kommunizieren
  • Dadurch werden Cookies, Metadaten und Nutzungsverlauf des Webbrowsers an native Apps übertragen und mit App-Kontoinformationen sowie der Android Advertising ID kombiniert, sodass die Identität von Nutzern mit Webbesuchen verknüpft werden kann

How does this work?

Missbrauch lokaler Android-Ports

  • Unter Android kann jede App mit der Berechtigung INTERNET einen Socket auf 127.0.0.1 (Loopback) öffnen
  • Auch Browser können ohne zusätzliche Einwilligung der Nutzer auf diese Schnittstelle zugreifen
  • In Webseiten eingebettetes JavaScript kann über Standard-Web-APIs Daten zwischen Browser und nativer App senden und empfangen

Web-App-Kopplung bei Meta/Facebook Pixel

  • Wenn das JavaScript von Meta Pixel in einem Android-Browser geladen wird, sendet es den Wert des _fbp-Cookies per WebRTC-STUN-Paket (UDP-Ports 12580–12585) an die native App
  • Auf dem Gerät lauschen Facebook- oder Instagram-Apps (je nach Version z. B. 515.0.0.23.90 / 382.0.0.43.84) auf diesen Ports, empfangen den aus dem Browser kommenden _fbp-Wert und senden ihn per GraphQL an ihre eigenen Server
  • Das _fbp ist ein wichtiges Cookie, das auf etwa 25 % der Top-Million-Websites eingebettet ist. Bislang war websiteübergreifendes Tracking schwierig, weil es pro Website getrennt war, doch mit dieser Methode lassen sich mehrere _fbp-Werte eines Nutzers einem einzigen Konto zuordnen
  • Seit Mai 2025 wurde zusätzlich ein WebRTC-TURN-Verfahren eingeführt; das Skript wurde so geändert, dass es SDP Munging umgeht
  • Das _fbp-Cookie bleibt 90 Tage erhalten und ist sehr weit verbreitet, da es auf 25 % der Top-Websites genutzt wird
  • Nach Reaktionen großer Browser wie Chrome wurde der Code am 3. Juni entfernt

Web-App-Kopplung bei Yandex Metrica

  • Das Skript von Yandex Metrica sendet seit 2017 per HTTP(S) Anfragen an lokale Ports (u. a. 29009, 29010, 30102, 30103)
  • Yandex-Apps (Yandex Maps, Navigator, Browser, Search usw.) halten diese Ports offen und antworten auf eingehende Anfragen mit Daten, die die Base64-kodierte Android Advertising ID (AAID) sowie weitere Geräte-Identifier, UUIDs usw. enthalten
  • Das Browser-Skript sammelt diese Informationen und sendet sie erneut an Yandex-Server, womit die Verknüpfung von Identifikatoren zwischen Browser, App und Server vollständig wird
  • Die Domain yandexmetrica.com wird auf 127.0.0.1 aufgelöst, um die Erkennung zu erschweren und den Erfassungsablauf zu verschleiern
  • Durch die Nutzung von HTTP über Localhost besteht zudem das Risiko, dass der Besuchsverlauf von Webseiten offengelegt wird, falls eine andere App auf denselben Ports lauscht

Konkretes Risiko: Offenlegung des Browser-Verlaufs

  • Wird lokale HTTP-Kommunikation verwendet, kann jede beliebige Android-App, die nur auf dem entsprechenden Port lauscht, Browser-Verlaufseinträge wie besuchte URLs abgreifen
  • Mit einer tatsächlich entwickelten Proof-of-Concept-App und Tests in Chrome, Firefox und Edge wurde nachgewiesen, dass auch privates Browsing und Inkognito-Modus verwundbar sind
  • Nur einige Browser wie Brave und DuckDuckGo schützen sich durch eigene Blocklisten und durch das Einholen einer Nutzereinwilligung

Affected Sites

  • Meta Pixel: auf 5,8 Millionen Websites im Einsatz; beim tatsächlichen Crawling wurde lokale ID-Freigabe auf 15.000 EU- und 17.000 US-Seiten unter den Top 100.000 Sites beobachtet
  • Yandex Metrica: auf 3 Millionen Websites im Einsatz; mit derselben Methode wurde lokale Port-Kommunikation auf 1.260 EU- und 1.312 US-Seiten bestätigt
  • Bei vielen dieser Websites wird automatisches Tracking auch ohne Cookie-Einwilligungsverfahren ausgeführt

History

  • Yandex: begann 2017 mit der Nutzung von HTTP/HTTPS-Ports
  • Meta: stufenweiser Wechsel von HTTP im September 2024 über WebSocket im November 2024 zu WebRTC STUN im Jahr 2025 und TURN im Mai

Abuse Vectors

  • Hauptursachen sind fehlende Beschränkungen für den Zugriff auf Localhost-Sockets unter Android sowie unzureichende Sandbox-Richtlinien
  • Alle bestehenden Schutzmaßnahmen wie Berechtigungseinstellungen, Browser-Inkognito-Modus oder das Zurücksetzen der Werbe-ID werden umgangen
  • Zwar ist die Abgrenzung zu legitimen Webentwicklungszwecken schwierig, doch bleibt dies ein nachgewiesener Fall großflächigen Trackings
  • Browser wie Chrome, Firefox, DuckDuckGo und Brave arbeiten an Notfall-Patches, doch grundlegend sind plattformweite Stärkung von Berechtigungen und Warnhinweisen, Sandbox und IPC-Richtlinien erforderlich

Disclosure

  • Browser-Anbieter wie Chrome, Firefox, DuckDuckGo und Brave wurden um Responsible Disclosure und Zusammenarbeit gebeten
  • Chrome (Version 137), Firefox (Version 138) und Brave setzen kurzfristige Maßnahmen wie das Blockieren anfälliger Ports und das Unterbinden von SDP Munging um
  • Langfristig wird die Notwendigkeit struktureller Verbesserungen wie Kontrolle des Zugriffs auf lokale Netzwerke, Ausbau der Sandbox und Nutzerhinweise betont
Browser Version Yandex Facebook Reaktion/Sperrstatus
Chrome 136.0+ betroffen betroffen ab 137 Blockierung von Ports und SDP munging, schrittweise Einführung
Edge 136.0+ betroffen betroffen unklar (Chromium-basiert)
Firefox 138.0.2 betroffen nicht betroffen (1) SDP munging blockiert, UDP-Sperre folgt später
DuckDuckGo 5.233.0 teilweise betroffen (2,3 nicht betroffen (2,3) Blockierung auf Basis einer Blockliste
Brave 1.78.102 nicht betroffen (3,4) nicht betroffen (3,4) seit 2022 Nutzereinwilligung für Localhost-Anfragen erforderlich, Blockliste aktiv
  • 1: SDP Munging blockiert, TURN-Ports derzeit noch nicht blockiert (spätere Einführung geplant)
  • 2,3,4: verschiedene Schutzmechanismen wie Blocklisten, Port-Sperren und Nutzereinwilligung

Bekanntheitsstand bei Nutzern und Betreibern

Website-Betreiber

  • In den offiziellen Dokumentationen von Meta und Yandex wurde dieses Verfahren nicht offengelegt
  • Seit September 2024 häuften sich in Facebook-Entwicklerforen Fragen wie „Warum greift das Pixel-Skript auf localhost zu?“, doch es gab keinerlei offizielle Antwort
  • Die meisten Website-Betreiber und Endnutzer wissen nichts davon. Tracking ist selbst dann möglich, wenn Nutzer nicht eingeloggt sind, den Inkognito-Modus verwenden oder Cookies löschen

Allgemeine Nutzer

  • Tracking funktioniert unabhängig vom Login-Status
  • Schutzmaßnahmen wie Inkognito-Modus oder Cookie-Löschung werden wirkungslos
  • Viele Fälle zeigen, dass es auch auf Websites ohne Cookie-Einwilligungsverfahren funktioniert

FAQ-Zusammenfassung

  • Q: Warum hat Meta dieses Verfahren direkt nach der Offenlegung eingestellt?
    A: Keine offizielle Antwort; nach der Veröffentlichung wurde bestätigt, dass der Paketversand an Android-Nutzer eingestellt wurde
  • Q: Wurde die Forschung peer-reviewt?
    A: Sie wurde von einigen Institutionen geprüft, befand sich aber noch vor der Paper-Begutachtung; wegen des Ausmaßes des Missbrauchs wurde eine schnelle Veröffentlichung beschlossen
  • Q: Ist das in offiziellen Dokumenten von Meta/Yandex beschrieben?
    A: Es gibt keine offizielle technische Dokumentation, nur Anfragen in Entwicklerforen
  • Q: Sind auch iOS oder andere Plattformen betroffen?
    A: Bislang nur auf Android bestätigt; technisch besteht jedoch auch auf iOS, Desktop-Systemen oder Smart-TVs ein potenzielles Risiko

11 Kommentare

 
dhy0613 2025-06-05

Ich fand es schon seltsam, dass der Akku so stark belastet wurde, deshalb hatte ich alle Apps von Meta gelöscht — und dann gab es so etwas also tatsächlich ... Ich sollte wohl auch die übrigen auf dem Galaxy vorinstallierten System-Apps per adb komplett entfernen.

 
savvykang 2025-06-05

Ich traue den Meta-Apps auch nicht, deshalb nutze ich sie nicht und verwende stattdessen nur Chrome im sicheren Ordner.

 
iolothebard 2025-06-05

Die meisten Frameworks, die man als hybride Web-Apps bezeichnet, starten einen localhost-Webserver (wenn auch zu anderen Zwecken). Dinge, die sich weder über die Einstellungen der eingebetteten Browser-Bibliothek (WebKit …) noch per Customizing lösen lassen (der Web-Teil), werden dann auf der Seite des Webservers gelöst, der auf localhost läuft (der native Teil). Dass man das auch so ausnutzen konnte … echt schade.

 
jeiea 2025-06-05

Meiner Meinung nach ist die übliche Kommunikationsmethode zwischen Web und App in Hybrid-Apps die Nutzung von APIs, die auf OS- und Browser-Seite bereitgestellt werden und auch als Bridge bezeichnet werden. Ein lokaler Webserver ist meiner Ansicht nach nicht zwingend erforderlich.
Der Grund, warum der Einsatz eines lokalen Webservers dort problematisch wurde, ist aus meiner Sicht, dass dadurch etwa Schwachstellen möglich werden, bei denen man über einen Zugriff auf einen localhost-Port aus dem Chrome-Inkognito-Modus die Anonymität eines Nutzers aufheben kann. Wenn solche Techniken für Hybrid-Apps zwingend notwendig sind, dann sollten Hybrid-Apps verschwinden.

 
nemorize 2025-06-06

Es ist durchaus üblich, innerhalb einer App einen Webserver zu öffnen, um Funktionen zu verarbeiten, die einen Domainnamen erzwingen, sowie Dinge wie localStorage.

 
ethanhur 2025-06-04

Wenn ich nicht für den Dienst bezahle, bin ich das Produkt. Es wird wohl immer mehr Versuche geben, Menschen über Daten nachzuverfolgen, und es sieht nicht so aus, als ließe sich dieser Trend umkehren. Wir brauchen bessere Alternativen, aber unter dem Kapitalismus fällt mir nicht wirklich ein, wie solche besseren Alternativen aussehen könnten.

 
savvykang 2025-06-04

Ich frage mich, ob der localhost-Zugriff innerhalb und außerhalb des sicheren Galaxy-Ordners voneinander isoliert ist.

 
savvykang 2025-06-04

Die Isolierung scheint nicht zu funktionieren. Wenn ich außerhalb des sicheren Ordners mit Termux den Python-http.server starte und innen mit Chrome darauf zugreife, wird die Verbindung hergestellt.

 
forgotdonkey456 2025-06-05

Ist das nicht eine Sicherheitslücke -_-??

 
jjpark78 2025-06-04

Die richtige Antwort scheint zu sein, keine sozialen Netzwerke zu nutzen …

 
GN⁺ 2025-06-04
Hacker-News-Kommentare
  • So wie ich den gesamten Tracking-Ablauf von Meta verstehe, basiert das auf dem, was im Localmess-Blog beschrieben wird

    1. Wenn ein Nutzer in der Facebook- oder Instagram-App eingeloggt ist, lauscht die jeweilige App im Hintergrund auf eingehenden Traffic an einem bestimmten Port
    2. Wenn der Nutzer mit dem Browser auf dem Handy eine Website besucht (z. B. something-embarassing.com), ist dort häufig das Meta Pixel eingebunden (laut Artikel auf über 5,8 Millionen Websites installiert)
      Tracking ist selbst im Inkognito-Modus weiterhin möglich
    3. Je nach Standort kann die Website eine Zustimmung des Nutzers verlangen; im Artikel wird das nicht genauer erklärt, aber vermutlich sind damit die „Cookie-Banner“ gemeint, denen viele Nutzer gedankenlos zustimmen
    4. Das Meta-Pixel-Skript sendet das _fbp-Cookie (einschließlich Browsing-Informationen) per WebRTC-(STUN)-SDP-Munging an die Instagram- oder Facebook-App
      Dieser Teil ist selbst in den Entwickler-Tools des Browsers nicht sichtbar
    5. Wenn in der App bereits ein Login besteht, kann Meta die „anonyme“ Browser-Aktivität mit den Daten des eingeloggten Nutzers verknüpfen
      Die App übermittelt die _fbp-Informationen und die Nutzer-ID an die Meta-Server
      Weitere bemerkenswerte Punkte:
    • Diese Art, IDs vom Web an die App weiterzugeben, umgeht übliche Datenschutzmaßnahmen wie das Löschen von Cookies, den Inkognito-Modus oder Android-Berechtigungskontrollen

    • Sie eröffnet sogar die Möglichkeit, dass bösartige Apps die Web-Aktivitäten eines Nutzers ausspähen

    • Seit Mitte Mai begann das Meta-Pixel-Skript, das _fbp-Cookie auch per WebRTC TURN zu senden; diese Methode wurde offenbar eingeführt, nachdem das Chrome-Team SDP Munging blockiert hatte

    • Mit Stand vom 2. Juni 2025 wurde kein Verhalten beobachtet, bei dem die Facebook-/Instagram-Apps tatsächlich über diesen neuen Port empfangen

    • Wenn der Hauptanwendungsfall von WebRTC darin besteht, Informationen wie die lokale IP des Nutzers auszulesen und damit Anonymität aufzuheben, verstehe ich nicht, warum so etwas ohne separate Berechtigungsabfrage ausgeführt werden darf

    • Je nach Land kann der Besuch einer Website wie something-embarassing.com weit schwerwiegendere Folgen haben als bloße Peinlichkeit

    • Ich habe es noch nicht vollständig verstanden, aber ich frage mich, ob dazu auch gehört, dass die obligatorischen GDPR-Cookie-Zustimmungsbanner missbraucht werden, um Menschen heimlich zu tracken

  • Ich würde Internetwerbung und Tracking am liebsten einfach verbieten
    Wegen solcher Dinge wird viel zu viel bedeutungsloser Müll produziert
    Meiner Meinung nach existiert das alles nur, damit CEOs sich noch eine Yacht kaufen können

    • Reddit betreibt ebenfalls ziemlich intensives Device-Fingerprinting
      Diese Daten werden auch für das Training von AI-Modellen verkauft
      Ich erwarte, dass bald sogar nicht öffentliche Daten, die nur in Premium-Apps verfügbar sind, aggressiv vermarktet werden

    • Die Frage bleibt, wie man so etwas verbieten könnte und wie man überhaupt beweisen soll, wer gegen ein solches Gesetz verstoßen hat

    • Die Abschaffung von 3rd-party-Cookies im Browser war praktisch gesehen der realistischste erste Schritt
      Aber Google hat das letztes Jahr mithilfe seiner Chrome-Dominanz torpediert
      Rechtlich mag das in Ordnung sein, aber es war unethische Marktmanipulation, die Verbraucherwut hätte auslösen müssen
      Die Google-Führung schien anfangs zu glauben, dass sich die Einnahmen auch ohne Cookies halten ließen; tatsächlich haben sie entweder die Bedeutung von Cookies überhaupt nicht verstanden oder hatten nie ernsthaft vor, sie abzuschaffen

    • Diese Art von Verhalten ist reine Gier
      Erfolgreiche traditionelle Wirtschaftsführer über viele Jahrhunderte hinweg haben sich von einer derart übersteigerten Fixierung auf den eigenen Vorteil ferngehalten
      Selbst durchschnittliche Führungskräfte könnten sich normalerweise über ein so niedriges Niveau erheben und ihre Unternehmen besser führen
      Aber in einer Welt, in der nur noch Gier zählt, bleibt einem wohl nichts anderes übrig, als bitter darüber zu lachen
      Es wäre schön, wenn es ehrlichere und zugleich fähigere CEOs gäbe

    • Ergänzend zum Witz über die „Yacht des CEO“: Die meisten Verbraucher bevorzugen in Wahrheit werbefinanzierte Services/Produkte, weil sie nichts bezahlen müssen
      Wenn es sowohl eine kostenpflichtige als auch eine werbefinanzierte Version gibt, ist Letztere tatsächlich oft im Verhältnis 10:1 beliebter
      Adblocking verschlimmert die Lage sogar eher — echter Widerstand bestünde darin, Services zu boykottieren oder direkt für Alternativen zu bezahlen
      Ein Modell wie BAT (Brave Attention Token), das Mikrozahlungen direkt an Websites verteilt, erscheint mir deutlich sinnvoller
      Die Theorie dahinter lautet: Ich zahle für das, was ich nutze, und bin der eigentliche Kunde statt des Werbetreibenden

  • Tatsächlicher Issue-Report: Localmess-Blog
    Google sagt, man untersuche Missbrauchsfälle, aber paradoxerweise verfolgt Google selbst alle über verschiedene Side Channels wie Wi-Fi-AP-Namen
    Große App-Unternehmen sammeln weiterhin auf ähnliche Weise Daten, um OS-Beschränkungen zu umgehen

  • Noch ein Grund, Big-Tech-Apps möglichst nicht zu installieren und Websites nur dann zu nutzen, wenn es unbedingt sein muss
    Websites sind langsamer und unbequemer, aber durch Sandboxing deutlich sicherer

    • Es ist nicht klar, welche Meta-App den Port öffnet
      Auf Samsung-Handys sind zum Beispiel mehrere Meta-Apps vorinstalliert, und selbst wenn man nur die Facebook-App entfernt, bleiben versteckte Dienste wie com.facebook.services teils bestehen
      Diese Dienste lassen sich nur mit Entwickler-Tools (ADB/UAD) entfernen
      Alternativ würde ich ein iPhone oder ein Pixel empfehlen
  • Technische Informationen zum Meta-Pixel-Skript:
    Meta Pixel hat bis Oktober 2024 per HTTP gesendet, und die Facebook-/Instagram-Apps lauschen an diesem Port weiterhin
    Es wird auch auf den neuen Port 12388 gelauscht, aber ein Skript, das an diesen Port sendet, wurde bislang nicht gefunden
    Dazu gibt es die wissenschaftliche(?) Neugier, ob auch eine andere App gefälschte Nachrichten an diesen Port schicken könnte

    • Ich denke, es gibt zwei Möglichkeiten, solche Tracker zu verwirren
      Die eine ist, gar nichts zu senden, und die andere, massenhaft falsche Daten zu schicken
      Es wäre schön, wenn es auch Geräte gäbe, die Werbe-Tracking-Cookies per P2P untereinander teilen
  • Ich frage mich, ob sich dieses Tracking über verschiedene Profile hinweg fortpflanzen kann
    Falls ja, wäre das aus Unternehmenssicht ein gewaltiges Sicherheitsproblem
    Ich habe getestet, indem ich in einer Userland-App einen Server auf Port 8080 gestartet habe, und beide Profile konnten darauf zugreifen
    Das bedeutet, dass eine in einem Profil kompromittierte App mit Websites und Daten aus einem anderen Profil kommunizieren könnte

    • Allerdings wohl nur dann, wenn die betreffende Website ausdrücklich mit einem Dienst kommuniziert, der an einen lokalen Port ohne Authentifizierung gebunden ist, oder?
  • Ich frage mich, ob eine Privatperson, die auf diese Weise Informationen von fremden Computern sammelt, nach dem CFAA (Computer Fraud and Abuse Act) strafbar wäre

    • Diese Methode erfordert Kontrolle über den Code auf beiden Seiten — sowohl auf der besuchten Website als auch in der auf dem Telefon laufenden App
      Es ist also kein magischer Hack, mit dem sich beliebige Browser-Historien stehlen lassen
      Deshalb ist es schwer, das eindeutig als Hacking zu bezeichnen, und selbst wenn Google/Meta Nutzer ohne Einwilligung tracken, fällt das wohl nicht unter den CFAA

    • Tatsächlich wurden unter dem CFAA schon Leute angeklagt, nur weil sie im Browser „Seitenquelltext anzeigen“ genutzt haben
      Wichtiger als die eigentliche Handlung scheint oft zu sein, wen man damit berührt und welche Beziehung zum Netzwerk besteht

    • Eine Bestrafung wäre möglich

  • Dieses ID-System ließ sich viel zu leicht missbrauchen, und ich vermute, Google wusste das und wusste auch, dass zwingend Regeln gegen Missbrauch nötig wären
    Das könnte bis zu Sanktionen wie einem permanenten Play-Store-Bann, rechtlichen Schritten oder sogar Strafanzeigen führen
    Praktisch ist es aber so, dass Unternehmen in der Größenordnung von Meta fast gar nicht mehr wirksam sanktioniert werden können
    (Und selbst wenn es nicht Meta wäre, könnten solche verdächtigen Aktivitäten auch stillschweigend von Geheimdiensten oder Strafverfolgungsbehörden gebilligt sein — das Problem zu stoppen ist extrem schwer, und selbst offen darüber zu sprechen ist nicht einfach)

    • Google und Apple besitzen das gesamte Betriebssystem
      Sie haben dutzende eigene Möglichkeiten zum Tracking
      Andere Unternehmen verdienen ebenfalls viel Geld, indem sie Klauseln zur Weitergabe von Nutzerdaten mit großen Konzernen neu aushandeln
      Die Deals sind längst geschlossen und die Freigaben erteilt; einige Nutzer machen darüber nur noch Lärm
  • In Firefox kann man WebRTC blockieren, indem man in about:config die Option media.peerconnection.enabled auf false setzt
    In Kombination mit Netguard und Nebulo im non-VPN-Modus lassen sich unnötige Verbindungen zu Meta-Servern blockieren

  • Ich finde, die Europäische Union sollte für solche Dinge Bußgelder in Rekordhöhe verhängen
    Sinnvoll wäre auch eine progressive Abgabe, die sich mit jedem weiteren Verstoß um 1 bis X % erhöht
    Außerdem wäre eine Website nötig, auf der man Verstöße der einzelnen Unternehmen auf einen Blick einsehen kann

    • Meta zahlt zwar jedes Jahr Strafen, macht aber trotzdem rund 70 Milliarden Dollar Nettogewinn

    • Nicht nur Bußgelder: In manchen Fällen sollte es noch härtere Maßnahmen geben, denn Einzelpersonen sind für deutlich geringere Verstöße schon im Gefängnis gelandet