Mozilla-Standardposition: gegen die Web Environment Integrity API

 (github.com/mozilla)
1 Punkte von GN⁺ 2023-07-26 | 1 Kommentare | Auf WhatsApp teilen
  • In einem Issue in Mozilla standards-positions wurde eine Position zur Web Environment Integrity API angefragt; Mozilla fasste den Vorschlag als im Konflikt mit den Prinzipien eines offenen Webs stehend mit position: negative zusammen
  • Der Vorschlag besagt, dass der Chromium-Prototyp derzeit auf Google Play Integrity angewiesen ist, laut Spezifikation aber anbieterneutral sein soll; der Antragsteller äußerte die Sorge, dass er sich wie EME in der Praxis auf wenige Anbieter konzentrieren könnte
  • Mozilla bewertet die API als potenziellen Mechanismus, der die Wahl von Gerät, Betriebssystem und Browser einschränken könnte, und damit als schädlich für die Offenheit des Web-Ökosystems und nachteilig für Nutzer
  • Der unter den vorgeschlagenen Use Cases genannte Punkt „Erkennung nicht-menschlichen Traffics“ könnte bestehende Web-Nutzungen blockieren, die Inhalte für Menschen umwandeln, prüfen, indexieren oder zusammenfassen, etwa assistive Technologien, automatisierte Tests, Archivierung und Suchmaschinen-Spider
  • Mozilla erklärte, Betrug und ungültigen Traffic zu erkennen sei ein schwieriges Problem und man habe Interesse an Lösungen; dieser Vorschlag erkläre jedoch unzureichend, wie er bei realen Use Cases Fortschritte bringen würde, und habe bei einer Einführung klare Nachteile

Anfrage im Issue und Umfang des Vorschlags

Erste geäußerte Bedenken

  • Der Antragsteller führte EME als Beispiel an: theoretisch anbieterneutral, in der Praxis aber mit nur wenigen breit anerkannten Anbietern
    • Google Widevine: genutzt in Firefox, Chrome und Android auf den meisten Plattformen
    • Microsoft PlayReady: genutzt in Microsoft Edge, Windows und zusammen mit Widevine auf einigen Android-Geräten
    • Apple FairPlay: genutzt in Safari und im Apple-Ökosystem
  • Es wurde befürchtet, dass sich dieselbe Situation auch bei der Web Environment Integrity API ergeben könnte und echte Websites vorab genehmigte Browser verlangen könnten
  • Ein Kommentar kritisierte, dass diese API Endnutzern nichts biete und nur zur Einschränkung von Nutzern eingesetzt werden könne; außerdem sei die Spezifikation vage und der underlying mechanism unklar

Mozillas Gründe für die Ablehnung

  • Mozilla erklärte, der Vorschlag widerspreche Mozillas Web-Prinzipien und -Vision
  • Mozillas Web-Vision besagt, dass Browser, Server und Publisher, die gemeinsame Standards implementieren, automatisch Teil des Webs sein sollten
  • Standards sollten Annahmen über auslieferbare Hardware oder Software vermeiden, und kein bestimmter Akteur sollte entscheiden, welche Formfaktoren, Geräte, Betriebssysteme oder Browser auf das Web zugreifen können
  • Diese Wahlfreiheit ermöglicht es unterschiedlichen Menschen, in Bezug auf assistive Technologien, Lokalisierung, Formfaktor und Preis dasselbe Web zu erreichen
  • Daher sind Mechanismen, die diese Auswahl einschränken sollen, schädlich für die Offenheit des Web-Ökosystems und schlecht für Nutzer

Problem des Use Cases „Erkennung nicht-menschlichen Traffics“

  • Mozilla sieht die vorgeschlagenen Use Cases als abhängig von der Fähigkeit, „detect non-human traffic“ zu können
  • Dieser Ansatz könnte bestehende Web-Nutzungen behindern

    • Assistive Technologien

      • Automatisierte Tests
      • Archivierung
      • Suchmaschinen-Spider
      • Solche Werkzeuge müssen Inhalte, die für Menschen gedacht sind, entgegennehmen und sie wiederum für Menschen umwandeln, testen, indexieren und zusammenfassen können
      • Die im Vorschlag genannten Schutzmaßnahmen wie „holdback“ oder das zufällige Fehlschlagenlassen der Erzeugung von Attestations dürften wahrscheinlich wenig wirksam sein und reichen nach Mozillas Einschätzung nicht aus, um die geäußerten Bedenken auszuräumen

Fazit und Behandlung des Issues

  • Mozilla erklärte, Betrug und ungültigen Traffic zu erkennen sei ein schwieriges Problem und man sei daran interessiert, dieses Problem zu lösen
  • Der Vorschlag zur Web Environment Integrity API erkläre jedoch nicht, wie er bei den aufgeführten Use Cases substanziellen Fortschritt bringen würde, und habe bei einer Einführung klare Nachteile
  • Ein Mozilla-Mitglied kennzeichnete die Position zu diesem Vorschlag auf Basis dieser Analyse als negative
  • Da der Vorschlag aus einem persönlichen GitHub-Repository stammt und weder eine Standard-Track-Arbeit noch Arbeit einer öffentlichen Incubation Group ist, wurde entschieden, dass kein separater Dashboard-Eintrag nötig ist
  • Das Issue wurde am 25. Juli 2023 mit dem Label position: negative versehen und anschließend als erledigt geschlossen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-26
Meinungen auf Hacker News

  • Die Angriffsmethode sieht grob so aus: Der Angreifer baut ein Gerät wie etwa ein Smartphone, erzeugt ein Schlüsselpaar und speichert es im HSM des Geräts, üblicherweise trusted enclave genannt, und signiert dann den öffentlichen Schlüssel mit einem Master-Schlüssel
    Das Gerät führt die Software des Angreifers aus, und wenn vom Nutzer ausgewählte Software mit hohen Rechten ausgeführt wird, ist das HSM so entworfen, dass es diese Tatsache bis zum Neustart irreversibel erkennt. Das HSM signiert die Aussage „Dieses Gerät führt Angreifer-Software aus“ sowie die Inhalte, die die Angreifer-Software übermitteln will, signiert aber nicht, wenn nutzergewählte Software läuft. Zusammen mit dem vom Master-Schlüssel signierten öffentlichen Schlüssel kann ein Mitverschwörer so verifizieren, dass das Gerät nicht unter der Kontrolle des Nutzers steht, sondern unter der Kontrolle einer Instanz, die die Freiheit des Nutzers einschränkt
    Optional kann dieser Nachweis über einen Server des Angreifers laufen und dort in einen neuen Nachweis umgewandelt werden, der Anonymisierung oder beliebige Bedingungsprüfungen durchlaufen hat. Am Ende erhält ein Dritter auf diese Weise die Garantie, dass das Gerät Angreifer-Software ausführt, und kann verhindern, dass der Nutzer die von ihm gewünschte Software ausführt, oder das Gerät so einsetzen lassen, wie es der Angreifer und seine Mitverschwörer wollen. Dieser Angriff läuft auf Android bereits über Googles SafetyNet und die Play Integrity API, auf iOS durch Apple, und wird nun offenbar auf das Web ausgeweitet

    • Mir gefällt, dass das als Angriff bezeichnet wird. Ich habe Google und seine Freunde gedanklich noch nicht als „Man-in-the-Middle“ einsortiert, aber genau das passiert hier im Grunde
      Diese Web Integrity API ist ein Mittel, sich nicht als optionaler, sondern als zwingender Mittelsmann zu etablieren
    • Diese Rahmung wäre nützlich, um das Problem in Medien, Blogs usw. darzustellen. Die Gegenseite dehnt die Bedeutung von Begriffen ja bereits gewaltsam aus, und DRM als „Rückgrat des offenen Internets“ zu präsentieren, war wirklich widerlich
    • In diesem Szenario baut der Angreifer meine Hardware, und das ergibt keinen Sinn. In so einer Lage kann er ohnehin alles tun, was er will, und das unterscheidet sich praktisch nicht von „der Angreifer besitzt die Hardware, also ist buchstäblich alles möglich“
      Und dieser „Angreifer“ gewinnt dabei auch nichts. Das ist kein Angreifer, sondern der Gerätehersteller. Es wirkt seltsam, den TPM als Angreifer zu bezeichnen und damit den Prozess der Remote Attestation zu erklären
    • Letztlich gibt es wegen der physikalischen Realität, dass Strom durch Leitungen fließt, auch Nebenwirkungen, die sich nicht beheben lassen: Eine zusätzliche Partei, die die Hardware ausreichend modifizieren kann, kann weiterhin den Angreifer und seine Mitverschwörer angreifen
      Solche Systeme wälzen die Kosten also auf normale Nutzer ab und nützen nur denjenigen, die solche Fähigkeiten ohnehin haben
    • Gibt es irgendeine Möglichkeit, diesem Angriff bei der Nutzung eines Smartphones zu entgehen? Ich muss dabei an das sterbende Ubuntu Phone denken

  • Wie zu erwarten war, bringt das alles nichts, wenn man die Leute nicht zu Firefox und weg von Chromium-basierten Browsern bekommt. Diejenigen, die in die Sicherheit des Webs und im weiteren Sinne in Vertrauen investiert haben, tragen dafür eine gewisse Verantwortung
    Ich habe noch nichts dazu gesehen, ob Brave das unterstützen wird. Wenn ich das richtig verstehe, gibt es bei Chromium aber wohl keine Wahl, und ich hoffe, dass ich mich irre

    • Wenn man sieht, wie viel Kritik Mozilla in diesem Umfeld abbekommt, fände ich es nur fair, ihnen auch die Anerkennung für das zu geben, was sie richtig machen
      Letztlich sollten wir wohl dauerhaft zu einem gesetzlich abgesicherten Browser-Auswahlbildschirm zurückkehren, wie nach der IE-Bundling-Affäre. Sonst werden Reibung und Anreize weiter einen einzigen dominanten Akteur zementieren
    • Das Endergebnis wird wohl sein, dass DRM-Seiten und Bank-Websites sagen: „Nutzen Sie Chrome, um fortzufahren.“ Nutzer wechseln dann weiter zu Chrome, und Mozilla wird am Ende doch zur Implementierung gedrängt
    • Der Ausdruck „Sicherheit und Schutz“ ist für viele zu einem abscheulichen Begriff geworden. Er erinnert an die autoritäre Dystopie, die Google und andere aufbauen
      Wichtiger sind Freiheit und Interoperabilität
    • Eine Möglichkeit für Systemadministratoren oder IT-Organisationen mit SMB-Kunden wäre, Firefox auf Workstations vorzuinstallieren. Die Nutzer gewöhnen sich dann an den Browser und können ihn auch privat verwenden
      Als Bonus kann man gleich uBlock Origin mit vorinstallieren. Wir machen das so
    • Solche Wechsel werden erst passieren, wenn Menschen Dinge in ihrem gewohnten Browser plötzlich nicht mehr tun können. Ich dachte, Manifest V3 würde User-Skripte kaputtmachen und Adblocking mühsamer machen, aber bisher war das nicht so gravierend, dass ich extra von Chrome weg gewechselt wäre
      Wenn das hier umgesetzt wird, könnte die Identität eines Nutzers als „unzureichend“ eingestuft werden, sodass er bestimmte Websites oder Dienste nicht mehr nutzen kann. Das könnte dann ein Anreiz sein, zu einem anderen Browser ohne diese Funktion zu wechseln

  • Ich habe es auch anderswo gesagt: Die Leute müssen Firefox verwenden. Wenn alle aufgeben, gibt es niemanden mehr mit einer Stimme gegen Googles Unsinn. Google besitzt Chrome und kann damit machen, was es will
    Es geht nicht darum, dass Firefox perfekt oder besser wäre, sondern darum, dass es notwendig ist. Es braucht einen konkurrierenden Browser mit relevantem Marktanteil und einer Rendering-Engine, die Google nicht letztlich kontrolliert. Sonst kann man auch aufhören, sich zu beschweren, und Google einfach tun lassen, was es will

    • Kommt nicht der Großteil von Mozillas Einnahmen aus bezahlter Platzierung von Google als Standardsuchmaschine? Ich weiß nicht, ob sich das in den letzten Jahren geändert hat
      Bei kurzem Nachsehen scheint es so gewesen zu sein, dass vor 5 bis 10 Jahren mehr als 50 % der Einnahmen von Google kamen, aber aktuellere Zahlen habe ich nicht gefunden. Wenn Google Mozillas wichtigste Einnahmequelle ist, insbesondere mit mehr als der Hälfte, dann kontrolliert Google Mozilla faktisch über den Hebel, diese wichtigste Einnahmequelle kappen zu können
      Daraus ergibt sich auch die Frage, welches Unternehmen oder welche Organisation überhaupt Browser entwickeln soll. Alle erwarten, dass Browser kostenlos sind, aber Entwicklung, Betrieb und Wartung sind nicht kostenlos. Kommerzielle Browser-Unternehmen wie Brave müssen den Browser letztlich irgendwie monetarisieren, etwa über BAT-Kryptotoken oder Werbung auf der New-Tab-Seite
    • Wenn Firefox für mich tatsächlich brauchbar wäre, würde ich ihn verwenden, aber das ist er nicht, daher kann ich nicht

  • Kann Mozilla auch seine Position zu seinem eigenen IPA-Vorschlag darlegen, der Nutzer im gesamten Internet verfolgt?
    Man sieht sich auf searchengine.example eine Produktanzeige an, sucht dieses Produkt später auf reviews.example und kauft es dann auf shop.example. Dabei würde der Mozilla-Browser all diese Ereignisse an einen oder mehrere Aggregationsdienste senden, sodass shop.example zumindest auf aggregierter Ebene verstehen kann, dass der Nutzer der Anzeige auf searchengine.example ausgesetzt war und auf reviews.example erneut. Natürlich unter der Voraussetzung, dass man dem Kartell vertraut, das diese Aggregationsdienste betreibt.
    Früher konnten Adtech-Firmen Nutzer auch bei deaktivierten Cookies anhand der Quell-IP-Adresse verfolgen, aber IPA würde Verfolgung über mehrere IP-Adressen hinweg und unabhängig von Cookie-Einstellungen mittels eindeutiger Tracking-IDs ermöglichen. Es wurde auch vorgeschlagen, dass das Betriebssystem eine eindeutige Tracking-ID bereitstellt, die von allen Apps und Browsern auf dem Gerät verwendet werden kann, wodurch sich sogar mehrere Geräte hinter derselben IP unterscheiden ließen.
    https://github.com/patcg-individual-drafts/ipa/

    • Damit Werbung funktioniert, braucht es Attribution. Ohne Attribution, die unabhängig von der Plattform ist, auf der die Werbung gekauft wurde, kann diese Werbeplattform betrügen.
      Das ist etwas anderes als Werbetracking zum Aufbau von Nutzerinteressenprofilen oder Remarketing, bei dem Werbung an frühere Besucher verkauft wird. Die meisten privaten Attributionssysteme sind so entworfen, dass der Werbetreibende zwar zählen kann, wie viele Personen auf eine Anzeige geklickt haben, aber nicht, wer geklickt hat oder was diese Person sonst noch getan hat. Der Safari-Vorschlag begrenzte die Anzahl ausführbarer Kampagnen pro Domain, um zu verhindern, dass pro Nutzer separate „Kampagnen“ erstellt und dadurch Fingerprinting in Echtzeit betrieben wird. Worin sich der Mozilla-Vorschlag unterscheidet, weiß ich nicht.
      Ob sich User-Agents überhaupt um so etwas kümmern sollten, ist eine andere Frage.
      https://www.theregister.com/2023/06/29/google_trueview_skepticism/
      Gerade Remarketing ist der Grund für das „Gefühl, überwacht zu werden“ in moderner Werbung: Man sucht einmal nach etwas und bekommt die ganze nächste Woche 10.000 Anzeigen dafür hinterhergeworfen.
    • Im Originaltext wirkt es so, als könne man zur Position von Mozilla ein GitHub-Issue unter https://github.com/mozilla/standards-positions eröffnen und nachfragen.
    • Fairerweise gesagt ist „Web Integrity“, also Remote Attestation oder ein Unternehmens-Überwachungsagent in „meiner“ Hardware, ein viel grundlegenderes Problem. Denn damit könnte schon das Ausführen eines Fork-Browsers verhindert werden, der absichtliche Sicherheitslücken wie IPA entfernt.
      Es ist bedauerlich, dass Mozilla sich auf Müll wie IPA einlässt, aber zumindest haben Nutzer derzeit noch die Freiheit, es zu deaktivieren, zu entfernen oder zu forken. Bei Remote Attestation ist das Konzept eines User-Agents als Stellvertreter des Nutzers dagegen praktisch Game Over.
    • Egal wie schlecht der Mozilla-Vorschlag ist, das ist Whataboutism. Am Ende dient es Googles Interessen und verteidigt einen noch viel dystopischeren Vorschlag.
    • „Der Mozilla-Browser sendet all diese Ereignisse an einen oder mehrere Aggregationsdienste“ gilt nur, wenn der Nutzer das erlaubt.

  • Browser-Erkennung, „Umgebungs“-Erkennung
    Bestimmte Website-Betreiber könnten als Protestmittel in Chrome unzugängliche Websites entwerfen. Es wäre unterhaltsam zu sehen, wie Google das zu umgehen versucht. Vor allem, wenn das nur bei kleinen, nichtkommerziellen Websites populär würde.

    • Gute Idee. Das könnte helfen, Nutzer daran zu gewöhnen, regelmäßig mehrere Browser zu verwenden. Meine Kinder nutzen auf ihren Android-Geräten bereits mehrere Browser, um YouTube-Werbung zu blockieren. Wenn es einen guten Grund gibt, verwenden Menschen auch gerne andere Browser.
      Ich würde sie aber nicht komplett aussperren, sondern nur auf das unbedingt Nötige beschränken und fortlaufend darauf hinweisen, auf einen anderen Browser zu wechseln oder etwas wie Tampermonkey zu nutzen. Dazu sollte es auch klare Hinweise geben, was genau zu tun ist.
      Was wäre eine gute Methode, um die Unterstützung solcher Funktionen zu erkennen? Eine JavaScript-API?
    • Sechs lange Jahre konnte Chrome nicht auf meine Website zugreifen. Alle anderen Browser schon, aber Chrome konnte eine serverseitige Konfiguration nicht respektieren, die nur Nicht-HTTP/3 erzwungen ausgehandelt und ausschließlich ChaCha/Poly erlaubt sowie AES/RSA ausgeschlossen hat. Microsoft Edge hat das kurz darauf behoben.
      Zum Glück hat Google es vor etwa vier Monaten ebenfalls behoben. In mehreren kostenlosen Cross-Browser-Testtools lässt sich dieser Defekt über Versionstests noch immer zeigen.
    • Könnte als Referenz nützlich sein: https://news.ycombinator.com/item?id=25240299

  • Das mobile Gegenstück, die Play Integrity API, sollte verboten und vor Gericht angefochten werden. Da die Entfernung von Drittanbieter-ROMs eine Kernidee davon ist, verstößt sie meiner Ansicht nach wahrscheinlich auch gegen das EU-Recht auf Reparatur und Gesetze zu Elektroschrott.
    Der Fokus der Debatte sollte auf die Sicherheitsprobleme gelenkt werden, die Google und seine Werbung geschaffen haben.

    • Google missbraucht Trusted Computing. Ich kann verstehen, dass manche Banken es bevorzugen, wenn Code zur Zahlungsabwicklung auf gesperrten Geräten läuft, aber auf solchen Android-Geräten läuft derzeit auch Google-Adware und Spyware, die für ein vertrauenswürdiges Zahlungsgerät überhaupt nicht nötig sind.
      Google sollte zerschlagen werden, damit seine Interessen Android und Chrome nicht weiter vergiften können.

  • Ich würde Mozilla gern etwas spenden, aber ich habe Sorge, dass mein Geld in den Taschen von C-Level-Führungskräften landet. Gibt es eine Möglichkeit, gezielt an das Firefox-Kernteam oder an MDN zu spenden?

    • Eine solche Zweckbindung ergibt aus Mozillas Sicht keinen Sinn. Selbst wenn es Spenden nur für Firefox gäbe: Wenn man damit keine Reinigungskräfte fürs Büro, keine Miete und keine Mitarbeitenden in HR, Buchhaltung oder Recht bezahlen kann, dann kann man auch das „Firefox-Kernteam und MDN“ nicht beschäftigen und betreiben
      Sogar ein absurd überbezahlter CEO ist für ein Unternehmen notwendig. Ich glaube zwar nicht an die Logik, dass man in den USA sehr viel zahlen muss, um einen guten CEO zu bekommen, aber ein schlechter CEO kann ein Unternehmen ruinieren, wie GE, Enron, Boeing oder Twitter zeigen
      Ein unterhaltsames Beispiel dafür, wie Zweckbindungen im Budget scheitern, ist Atlantas MARTA. Früher schrieb ein Finanzierungsgesetz dort eine 50/50-Aufteilung zwischen Betriebskosten und Investitionen vor; am Ende gab es neue Züge, aber alles andere verfiel
    • Machst du bei jedem Kauf dieselbe Analyse? Der Sandwichladen, bei dem du dein Mittagessen kaufst, könnte das Geld genutzt haben, um dem Besitzer und seiner Frau, die an dem Tag gar nicht gearbeitet haben, Pizza zu kaufen. Macht dich das wütend?
      So funktionieren Unternehmen: Geld kommt rein, Geld geht raus, und Produkte werden hergestellt. Du kannst entscheiden, ob du für ein Produkt zahlst, das du magst, oder eben nicht. Wie sie das eingenommene Geld verwenden, ist ihre Sache
    • An die Mozilla Foundation kann man zweckgebunden spenden, und wenn sie das akzeptiert, sind sie an diese Zweckbindung gebunden, solange der Spender ihr nicht zustimmt
      Geld ist aber austauschbar. Wenn du 500 Dollar zur Unterstützung von MDN spendest, kann das die 500 Dollar ersetzen, die vorher aus den laufenden Einnahmen an MDN gingen, sodass andere 500 Dollar in die Taschen des C-Levels oder in Pocket usw. fließen. Die Dollars selbst gehen zwar an den vorgesehenen Ort, ermöglichen aber möglicherweise andere Ausgaben, die dir nicht gefallen
      Anders wäre es, wenn du 50 Milliarden Dollar für MDN spendest. Dann würde das bisherige MDN-Budget sicher frei, aber MDN wird wohl kaum 50 Milliarden Dollar ausgeben, also hätte Geld oberhalb des MDN-Bedarfs kein Ziel
    • Mozilla ist keine Genossenschaft, sondern einfach eine Non-Profit-Körperschaft. Die Entwickler sind wie in anderen Unternehmen Angestellte dieser Körperschaft. Ehrlich gesagt hat das Unternehmen recht ordentliche Einnahmen und ist wohl nicht stark von Spenden abhängig
      Ihre Produkte zu nutzen und Kunde zu werden, dürfte für sie und ihr Manifest wahrscheinlich mehr wert sein
    • Der naheliegendste Weg ist derzeit, für eines ihrer Produkte zu bezahlen. Es gibt Pocket Premium, Firefox Relay und Mozilla VPN

  • Mozilla kann zwar dagegen sein, aber wenn es in Chrome eingebaut wird und intensiv genutzt wird, werden sie es am Ende wohl doch wie bei CDM implementieren
    Nutzer sehen am Ende nur, dass irgendeine Website in Chrome funktioniert und in Firefox nicht. Sobald die realen Kosten in Form potenzieller Marktanteilsverluste entstehen, wird Firefox vermutlich entscheiden, dass es keinen Grund mehr gibt, sich dagegenzustellen

    • Man muss sich nur daran erinnern, wie sich die Strategie „nicht Chrome, aber fast Chrome“ auf Marktanteile ausgewirkt hat. Solche Nutzer haben dann auch kein Problem damit, einfach Chrome zu benutzen, also ist dieser Markt in Wirklichkeit vielleicht gar nicht so groß

  • Auch die Standardisierungsposition von WebKit ist einen Blick wert: https://webkit.org/standards-positions/
    Dieser Fall ist dort noch nicht eingetragen, aber wahrscheinlich werden sie ebenfalls dagegen sein

  • Es gibt eine lange Geschichte klassischer Hacker, die mit Computern Dinge getan haben, die andere Leute nicht wollten, während diese anderen entweder nichts dagegen tun konnten oder bestenfalls ein Wettrüsten führen konnten. Für sie war das schlecht, für die Gesellschaft insgesamt aber sehr gut
    Daraus sind GNU, „IBM Compatible“, Werbeblocker, Firefox, BitTorrent, YouTube ReVanced/youtube-dl und vieles andere entstanden
    Das Ziel von Geräteattestierung für Consumer-Software ist es, dem ein Ende zu setzen. Apple hat das auf iOS zuerst vorangetrieben, und nun breitet es sich mit der Kraft des Kapitalismus auf das gesamte Computing aus. Geräteattestierung bedeutet, dass die Hacker verlieren, und das ist ein schlechtes Ende
    Eine weitere Zwillingsbedrohung ist, dass die Softwareindustrie ihre Sicherheit tatsächlich in den Griff bekommt. Früher waren iOS-Jailbreaks alltäglich, aber seit einem Jahr gab es keinen iOS-Jailbreak mehr. Rust hilft auch nicht
    Wir rasen auf eine Welt zu, in der Produzenten und Inhaber geistiger Eigentumsrechte die von ihnen geschaffenen Inhalte vollständig kontrollieren und diesen Zustand mit modernster Kryptografie und extrem sicherer, aber verbraucherfeindlicher Software aufrechterhalten. Das ist eine der gefährlichsten Entwicklungen der Geschichte, und wenn es einmal Realität wird, gibt es kein Zurück mehr. Stallman hatte recht

    • Gut zusammengefasst. Für mich ist dieser ganze Attestierungs-Müll in Wirklichkeit einfach nur DRM. Natürlich wird das als optionale Funktion vermarktet, die „das Erlebnis verbessern kann“
      Das ist ungefähr so, als würde man sagen, dass sich dein Wohlbefinden verbessern kann, wenn du unter vorgehaltener Waffe deine Brieftasche abgibst