10.000 US-Dollar Belohnung für YouTube-Schwachstelle erhalten, die E-Mail-Adressen von Nutzern offenlegte

 (brutecat.com)
1 Punkte von GN⁺ 2025-02-13 | 1 Kommentare | Auf WhatsApp teilen
  • Die obfuscated Gaia ID, der interne Google-Konto-Identifier eines YouTube-Kanals, wurde offengelegt und konnte über die Sharing-API von Pixel Recorder mit einer E-Mail-Adresse verknüpft werden – ein Datenschutzproblem für Google-Konten
  • Die Innertube-Anfrage des Sperrmenüs im Live-Chat gab auch ohne tatsächliches Sperren einen moderateLiveChatEndpoint-Parameter zurück, der die Gaia ID des Zielkanals enthielt
  • Durch Ändern der Channel-ID in den Anfrageparametern ließ sich der Angriff sogar auf Topic Channels ausweiten, die keine Live-Chat-Nachrichten haben; das Problem war also nicht auf bestimmte Teilnehmer beschränkt
  • WriteShareList von Pixel Recorder nahm die obfuscated Gaia ID des Freigabeziels entgegen und enthielt in der Antwort die E-Mail-Adresse; zudem ließ sich der Versand von Benachrichtigungs-E-Mails mit einem Aufnahmetitel von 2,5 Millionen Zeichen verhindern
  • Google erhielt den Bericht am 15. September 2024, bestätigte am 9. Februar 2025 die Behebung beider Schwachstellen und zahlte insgesamt 10.633 US-Dollar Belohnung

Gaia ID, die in der YouTube-Sperrfunktion sichtbar wurde

  • In der Staging-Discovery-Dokumentation von Googles Internal People API zeigte sich, dass das Objekt BlockedTarget eine obfuscated Gaia ID und fallbackName verwendet
    • profileId ist die obfuscated Gaia ID des gesperrten Nutzers
    • fallbackName ist der Anzeigename des gesperrten Nutzers
  • In der Hilfe zu Google-Konten wurde erklärt, dass man Konten auf YouTube sperren kann; sperrt man tatsächlich einen Nutzer in einem YouTube-Livestream, erscheint dieser Nutzer unter myaccount.google.com/blocklist
  • In der Sperrliste wurde der Kanalname Mega Prime als fallbackName und 107183641464576740691 als profile ID angezeigt
  • Ausgehend von der Annahme, dass ein YouTube-Kanal das zugrunde liegende Google-Konto nicht offenlegen darf, und weil es früher bereits Bugs gab, die Gaia IDs in E-Mail-Adressen umwandelten, wurde nach weiteren Wegen gesucht

Vom Live-Chat-Menü zur Ausweitung auf ganze Kanäle

  • Schon das Öffnen des Drei-Punkte-Menüs im YouTube-Live-Chat löst eine Anfrage an /youtubei/v1/live_chat/get_item_context_menu aus
  • Die Antwort enthielt einen moderateLiveChatEndpoint, der zu /youtubei/v1/live_chat/moderate führte, sowie einen params-Wert
  • Diese params waren ein bei Google häufig verwendetes base64-codiertes Protobuf; nach dem Decoding enthielten sie die Gaia ID des zu sperrenden Nutzers
    • Eine Beispielantwort enthielt 113907466537670370590 sowie kanalbezogene Identifier
    • Die Gaia ID des Ziels ließ sich auch ohne tatsächliches Sperren ermitteln
  • Decodierte man die Anfrageparameter von get_item_context_menu, enthielten sie die Channel-ID des zu sperrenden Kanals, die Video-ID des Livestreams und die ID des Livestream-Erstellers
  • Bei Tests, in denen die Channel-ID in den Anfrageparametern durch andere Werte ersetzt wurde, ließ sich auch die Gaia ID 103261974221829892167 eines von YouTube automatisch generierten Topic Channel ermitteln

Pixel Recorder wurde zum Pfad für die E-Mail-Umwandlung

  • Auf der Suche nach Bugs oder Logikfehlern in älteren Google-Produkten, mit denen sich Gaia IDs in E-Mails umwandeln lassen, wurde gemeinsam mit nathan Pixel Recorder untersucht
  • Auf einem Pixel-Smartphone wurde eine Testaufnahme erstellt und mit dem Google-Konto synchronisiert; anschließend wurden die Endpunkte von recorder.google.com im Web verwendet
  • Beim Teilen der Aufnahme mit einer Test-E-Mail enthielt die WriteShareList-Anfrage in der Liste der Freigabeziele die obfuscated Gaia ID
  • Die Antwort von PlaybackService/WriteShareList auf pixelrecorder-pa.clients6.google.com gab die E-Mail-Adresse des jeweiligen Freigabeziels zurück
    • Die Testantwort enthielt vrptest2@gmail.com
    • Auch als die Gaia ID 107183641464576740691 aus dem YouTube-Sperrtest eingesetzt wurde, kam redacted@gmail.com zurück
  • Damit war eine Angriffskette möglich, bei der eine auf YouTube ermittelte Gaia ID in die Sharing-API von Pixel Recorder eingesetzt wird, um die E-Mail-Adresse herauszufinden

2,5 Millionen Zeichen langer Aufnahmetitel verhinderte Benachrichtigungs-E-Mails

  • Wenn in Pixel Recorder eine Aufnahme mit dem Opfer geteilt wurde, erhielt dieses eine E-Mail-Benachrichtigung, was die Angriffswirkung hätte abschwächen können
  • Im Teilen-Popup gab es keine Option zum Abschalten von Benachrichtigungen, und auch eine Analyse des Anfrage-Protobufs mit req2proto zeigte kein Feld zum Deaktivieren von Benachrichtigungen
  • Die Struktur WriteShareListRequest enthielt folgende Felder
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Selbst wenn ein Nutzer gleichzeitig hinzugefügt und entfernt wurde, wurde weiterhin eine E-Mail versendet
  • Da der Aufnahmetitel in der Betreffzeile der Benachrichtigungs-E-Mail enthalten war, lag die Vermutung nahe, dass ein extrem langer Aufnahmetitel den E-Mail-Versand fehlschlagen lassen könnte
  • Über den Endpunkt UpdateRecordingTitle wurde ein Python-Skript geschrieben und getestet, das den Aufnahmetitel auf 2,5 Millionen Zeichen änderte; serverseitig gab es keine Längenbegrenzung für den Titel
  • Nachdem der Titel auf 2,5 Millionen Zeichen gesetzt worden war, wurde beim Teilen mit einem anderen Testnutzer keine Benachrichtigungs-E-Mail versendet

Finale PoC und Ablauf der Bearbeitung

  • Die fertige Angriffskette bestand aus drei Schritten
    • Über den YouTube-Innertube-Endpunkt /get_item_context_menu die obfuscated Gaia ID des Zielkanals ermitteln
    • Eine Pixel-Recorder-Aufnahme mit sehr langem Titel mit dem Ziel teilen, um die Gaia ID in eine E-Mail-Adresse umzuwandeln
    • Den Nutzer wieder aus den Freigabezielen der Pixel-Recorder-Aufnahme entfernen, um aufzuräumen
  • Das PoC-Video ist als YouTube-Video verfügbar

Google-Belohnung und Timeline der Behebung

  • 2024-09-15: Meldung an den Vendor gesendet
  • 2024-09-16: Der Vendor triagierte den Report und antwortete mit Nice catch!
  • 2024-10-03: Das Panel markierte den Report als Duplikat eines bestehenden Tracking-Bugs und nahm einen unvollständigen Patch für die anfängliche Offenlegung der obfuscated Gaia ID auf YouTube vor
  • 2024-10-03: Dem Vendor wurde erneut erläutert, dass Pixel Recorder selbst ebenfalls verwundbar war
    • Die obfuscated Gaia ID konnte auch bei Reviewern in Google Maps und Google Play offengelegt werden
    • Außerdem wurde eine Umgehungsmethode bereitgestellt, mit der sich die obfuscated Gaia ID eines YouTube-Kanals erneut leaken ließ
  • 2024-11-05: Das Panel zahlte eine Belohnung von 3.133 US-Dollar
    • Begründung war eine mittlere Ausnutzbarkeit
    • Eingestuft als abuse-related methodology mit hoher Auswirkung
  • 2024-12-03: Das Produktteam schickte den Report zur Prüfung einer zusätzlichen Belohnung erneut an das Panel und stimmte einen Veröffentlichungstermin für den 03.02.2025 ab
  • 2024-12-12: Das Panel zahlte eine zusätzliche Belohnung von 7.500 US-Dollar
    • Begründung war eine hohe Ausnutzbarkeit
    • Eingestuft als abuse-related methodology mit hoher Auswirkung
    • Wegen der Komplexität der Angriffskette wurde eine Herabstufung um eine Stufe vom Basisbetrag vorgenommen
  • 2025-01-29: Der Vendor bat darum, den Veröffentlichungstermin auf den 02.02.2025 zu verlängern
  • 2025-02-09: Es wurde bestätigt, dass beide Teile der Angriffskette behoben waren
    • Dies war 147 Tage nach der ersten Meldung
  • 2025-02-12: Der Report wurde veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-13
Meinungen auf Hacker News

  • Der Titel war verwirrend. Für alle, die den Beitrag nicht bis zum Ende gelesen haben: Es ging nicht darum, dass durch die geleakten E-Mails Kosten entstanden sind, sondern dass Zeit und Einfallsreichtum investiert wurden und dafür ein Bug Bounty von 10.000 Dollar ausgezahlt wurde.

    • Zuerst dachte ich, es bedeute, dass ein Dienst angeboten wird, der Nutzer-E-Mails für 10.000 Dollar pro Nutzer leakt.
    • Ich dachte auch, es sei als Dienst für 10.000 Dollar gemeint.
    • Könnte auch ein Titel gewesen sein, der auf Klicks abzielt.
    • Zuerst dachte ich, es gehe um so etwas wie die Rechenkosten, um irgendeinen Hash per Brute Force zu knacken.

  • Es gibt viel Lärm um Responsible Disclosure, Motivation und Belohnungen, aber kaum jemand spricht darüber, dass dies ein weiteres Argument gegen zentralisierte, permanente Identitäten ist.
    Jedes Mal, wenn ein Dienst behauptet, am besten zu funktionieren, wenn er nur mit einer einzigen Real Identity™ verknüpft ist, habe ich den Eindruck, dass die Anbieter am tatsächlichen Schutz der Nutzer nur abstrakt interessiert sind – und selbst das nur gelegentlich.
    Wenn man sich vorstellt, dass jeder, mit dem man auf YouTube interagiert, sofort drei oder vier Schritte näher daran sein könnte, einen zu doxxen, dann entspricht das meiner Ansicht nach ungefähr den realen Auswirkungen dieses Bugs. Gut, dass er behoben wurde, aber ich glaube nicht, dass Bugs dieser Art bald verschwinden. Was braucht es, damit Anbieter und große Konzerne erkennen, dass dieses Design ein Minenfeld kurz vor der Explosion ist?

    • Abstrakt stimme ich zu. Solche Konten sollten ein gewisses Maß an Anonymität und Wegwerfbarkeit erlauben. Schließlich sind sie ohnehin nur eine Zeile in irgendeiner Datenbank.
      Allerdings machen viele Menschen mit solchen Unternehmen Geschäfte mit echtem Geld. Zum Beispiel YouTube-Premium-Abonnenten oder Content Creator. In der Praxis muss irgendwo in diesem wegwerfbaren Konto ein Identifikator für die reale Identität gespeichert sein. Wegen Betrugsrisiken und der Realität des Bankwesens gibt man dem Unternehmen seine echte Identität und Adresse, und das Unternehmen speichert sie auch.
      Zufälligen Apps oder Websites gebe ich keine Informationen, mit denen man mich identifizieren kann, aber mein Vertragspartner kennt zwangsläufig mein reales Ich und ist theoretisch ein Punkt, an dem diese Daten durchsickern können.
    • Weil es keine rechtlichen Konsequenzen gibt, kümmern sie sich nicht darum.
      Wenn ein medizinischer Dienstleister Gesundheitsdaten leaken würde, würde er komplett auseinandergenommen.

  • „Hier ist ein funktionierender Exploit-POC: Dieses Video wurde wegen Verstoßes gegen die YouTube-Nutzungsbedingungen entfernt“ – ziemlich lustig.

    • Der Autor des Originalbeitrags hat für den Proof of Concept die E-Mail-Adresse eines real existierenden Nutzers offengelegt. Im erneut hochgeladenen Video ist die E-Mail-Adresse verpixelt.
    • Zuerst sah es für mich auch so aus, aber als ich den Beitrag erneut geöffnet habe, scheint das Video sichtbar zu sein. Keine Ahnung, ob es gerade eben wiederhergestellt wurde.

  • Da in diesem Thread gefühlt jeder dritte Kommentar sagt, Google habe für diesen Bug viel zu wenig gezahlt, hier ein paar Grundlagen zur Bewertung von Schwachstellen:
    Serverseitige Schwachstellen haben einen geringen Wert, weil Anbieter dort nicht miteinander konkurrieren. Für serverseitige Schwachstellen gibt es praktisch keinen Graumarkt. Für Dritte ist es schwierig, einen Preis für einen Bug festzulegen, den Google sofort abstellen kann, der ab dem Moment seiner Entdeckung praktisch keine Halbwertszeit mehr hat und dessen Ausnutzung beim Ziel verlässliche Telemetrie auslöst.
    Umgekehrt werden Bugs wie vollständige Android-/Chrome-Chains für Hunderttausende Dollar verkauft, weil Google dort mit einem gut etablierten Graumarkt konkurriert. Ein Anbieter kann so einen Bug nehmen und ihn an mehrere Behörden in einem europäischen Land verkaufen, potenziell an sechs Stellen.
    Trotzdem sind Bounties und Graumärkte ein Vergleich von Äpfeln und Birnen. Google braucht keinen verlässlichen Exploit, sondern nur den Nachweis, dass er geschrieben werden kann, und muss auch keine Wartungskosten tragen; deshalb zahlt Google viel weniger als der Graumarkt. Die Gesamtsumme des übrigen Marktes ist über mehrere Stufen verteilt und mit Risikobedingungen versehen, während Google auch mit Abschlag eine attraktive Einmalzahlung anbieten kann.
    Angreifer kaufen Schwachstellen, die zu bestehenden Geschäftsprozessen passen. In der Regel spekulieren sie nicht darüber, welche coolen Dinge man mit einer neuen Schwachstelle tun könnte und wie man damit Geld verdient. Zahlungsdaten abgreifen oder Tausende Rechner für ein Botnet beschaffen sind bestehende Geschäftsprozesse. Die Klarnamen von Google-Konten offenzulegen – kann das ein Geschäft sein? Vielleicht. Gibt es das schon? Wahrscheinlich nicht.
    Die Höhe einer Bug Bounty ist normalerweise keine Volksabstimmung darüber, wie clever oder interessant ein Bug ist. Wobei es hier ein bisschen doch so ist: 10.000 Dollar für einen serverseitigen Web-Bug wirken ungewöhnlich hoch.
    Für jemanden, der davon lebt, solche Bugs zu finden, besteht die Geschäftsstrategie darin, gut darin zu werden, viele davon zu finden. Das ist etwas anderes als iOS-Exploit-Entwicklung, bei der man Monate in einen einzigen verlässlichen Exploit steckt.
    Die Schwachstellenforschung, die ich zuletzt beruflich gemacht habe, lag deutlich näher an dieser Art Arbeit als an vielen anderen Aufgaben, daher bin ich mir hier ziemlich sicher. Trotzdem gibt es auf HN Leute, die solche Bounty-Arbeit in Vollzeit machen; ich würde mich freuen, wenn jemand von ihnen mich korrigiert.

    • In den meisten anderen Bereichen wird man nicht nach dem Schwarzmarktwert der geschaffenen Sache bezahlt.
      Wenn man diese Analyse auf anderes überträgt, läge die Preisobergrenze für ein neues Autoradio oder Fahrrad bei etwa 100 Dollar, und der Preis aller urheberrechtlich geschützten Güter wäre durch die Kosten begrenzt, sie über das Netz zu übertragen.
      Nützlicher fände ich, den von Google gezahlten Betrag durch die für diese Arbeit aufgewendete Zeit plus die Zeit für alle seit der letzten Bounty gescheiterten Exploit-Versuche zu teilen.
      Ich vermute, dass die große Mehrheit in diesem Bereich im Verhältnis zum Aufwand weniger verdient als den US-Mindestlohn und Opportunitätskosten im sechsstelligen Jahresbereich trägt.
      Diese Zahl zeigt ziemlich genau, welchen Wert Google der Sicherheit und Privatsphäre der Endnutzer beimisst. Sie liegt um Größenordnungen niedriger als das, was Google anderen Ingenieuren zahlt, damit sie die personenbezogenen Daten derselben Leute stehlen.
    • Ich mag nicht, dass es in diesem HN-Thread größtenteils um die Höhe der Bounty geht, aber es ist auch natürlich. Die meisten, die hier kommentieren, arbeiten in der Softwarebranche und möchten sehr hohe Bounties normalisieren.
      Für sie ist das eine zusätzliche Einkommensquelle. So wie Software Engineers wollen, dass ihr Beruf hoch bezahlt ist, wollen sie auch, dass Bug Bounties steigen. Es ist natürlich, dass Arbeitnehmer für ihren Beruf höhere Löhne fordern, und keine Rationalisierung ändert diesen Instinkt.
    • „Angreifer kaufen Schwachstellen, die zu bestehenden Geschäftsprozessen passen“, aber gibt es dafür nicht auch einen Markt? Zum Beispiel: „Lasst uns herausfinden, wer hinter diesem Account steckt, der unser zwielichtiges Unternehmen/unsere Regierung kritisiert, und ihn ausschalten.“
      Es gibt auch Anreize jenseits des Marktwerts für Angreifer. Eine gewalttätige Person, die eine Online-Berühmtheit stalkt, ist auf dem Markt für solche Zero-Day-Exploits vielleicht kein profitabler Kunde; aber wenn ein Unternehmen fahrlässig die Identität des Ziels gegenüber einem gewalttätigen Stalker offenlegen könnte, ist diese Schwachstelle trotzdem ein Haftungs- und ethisches Risiko.
      Persönlich finde ich: Wenn man LeetCode-Performance-Künstlern, die mit unvollständiger Aufmerksamkeit für Sicherheit enorme Mengen Code produzieren, riesige Summen zahlt, sollte man auch die Leute gut bezahlen, die helfen, ihre zahllosen Fehler zu finden und zu beheben, bevor etwas Schlimmes passiert.
    • Dass Strafverfolgungsbehörden serverseitige Bugs ausnutzen, ist eine viel größere Grauzone oder kann tatsächlich illegal sein. Dagegen gibt es für Strafverfolgungs- oder Nachrichtendienste bereits Standardverfahren, um Gerichtsbeschlüsse zu erhalten, die die Ausnutzung des Geräts eines bestimmten Ziels erlauben, also eines Telefons oder Laptops.

  • „Wegen der Komplexität der erforderlichen Angriffskette wurde der Grundbetrag um eine Stufe herabgesetzt“ – ist das üblich?
    Ich habe nur an ein paar Schwachstellenprogrammen teilgenommen, aber die meisten haben für absurd einfache, aber schwerwiegende Fehler, etwa wenn die E-Mail-Adresse eines Nutzers im Page Source auftaucht, eher weniger gezahlt.

    • Ich habe es umgekehrt verstanden: Für eine Web-Schwachstelle war sie relativ komplex, deshalb gab es den Abzug.
    • Das wirkt verkehrt herum. Im Grunde wurden zwei Bugs gefunden, also sollte man den Grundbetrag erhöhen.

  • „Vor einiger Zeit suchte ich bei Google nach einem Forschungsziel und wühlte mich durch die Discovery-Dokumente der Internal People API (Staging)“ – darf so etwas einfach öffentlich sein: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • Das ist nur eine Schema-Datei, die automatisch aus internen .proto-Definitionen konvertiert wurde. Google verlässt sich nicht auf Security through Obscurity, sondern auf echte Kryptografie.
      Außerdem sind Discovery-Endpunkte öffentlich dokumentiert[0] und für externe Nutzer gedacht. Interne Leute würden keine Discovery-Endpunkte lesen, sondern per Codesuche direkt die .proto-Dateien ansehen.
      Aus meiner Erfahrung bei Google musste man sich, um eine API öffentlich freizugeben, wochenlang mit Bürokratie herumschlagen. Das ist kein versehentlich öffentlich gewordener AWS-S3-Bucket. Das Team wusste, dass das öffentlich ist, und hat sich vermutlich durch die Bürokratie gekämpft, um es zu veröffentlichen.
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Wenn man sich die Timeline des Beitrags ansieht: Am 15.09.2024 wurde es dem Unternehmen gemeldet, am 29.01.2025 bat das Unternehmen um eine Verlängerung der Veröffentlichung bis zum 12.02.2025, am 09.02.2025 wurde bestätigt, dass beide Seiten des Exploits behoben waren, und am 12.02.2025 wurde es veröffentlicht.
    Dann war es 136 Tage lang nicht behoben, und Google hat um eine Verlängerung gebeten, oder? Bis zum Fix waren es 147 Tage, bis zur Veröffentlichung 150 Tage.
    Verglichen mit der Frist für eine Veröffentlichung vor dem Fix, die Google Project Zero anderen Unternehmen setzt, heißt es dort: „Für diesen Bug gilt eine Veröffentlichungsfrist von 90 Tagen. Wenn Nutzern vor Ablauf der 90-Tage-Frist ein Fix bereitgestellt wird, wird dieser Bug-Report 30 Tage nach Bereitstellung des Fixes veröffentlicht. Andernfalls wird er zum Fristablauf veröffentlicht.“
    „Wenn erwartet wird, dass ein Patch innerhalb von 14 Tagen nach Ablauf der Frist erscheint, kann Project Zero eine Verlängerung gewähren … Allerdings überschneidet sich die 14-tägige Kulanzfrist mit dem 30-tägigen Zeitraum für die Patch-Bereitstellung, sodass auch Schwachstellen, die innerhalb der Kulanzfrist behoben werden, spätestens am 120. Tag ab der ursprünglichen 90-Tage-Frist veröffentlicht werden.“
    „Wenn wir zu dem Schluss kommen, dass ein Fix nicht innerhalb von 14 Tagen bereit sein wird, verwenden wir die ursprüngliche 90-Tage-Frist als Veröffentlichungszeitpunkt. Das heißt, die 14-tägige Verlängerung wird nur gewährt, wenn der Entwickler zusagt, den Fix innerhalb der 14-tägigen Kulanzfrist auszuliefern.“
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • Ich halte diesen Vergleich nicht für hilfreich. Das hier ist ein Google-Bug in Google-Software, und was Project Zero findet, sind nach meinem Verständnis normalerweise Bugs in Software, die von vielen verschiedenen Leuten genutzt wird, weshalb die Dringlichkeit eines Fixes höher ist.

  • „Diese params sind nur base64-codierte protobufs, ein bei Google allgemein übliches Encoding-Format“ – dem zuständigen Google-Entwickler, der ein tolles binäres Nachrichtenformat base64-codiert und in einen JSON-Klumpen quetscht, sollte man einen ausgeben.
    Wenn man die Zukunft sehen will, muss man sich nur vorstellen, wie ein Stiefel, in dessen Sohle „worse is better“ eingraviert ist, für immer auf das Gesicht eines Engineers tritt.

    • Das gibt es überall, und es ist das Schlimmste. Manchmal frage ich mich, ob über die Internetleitungen nicht mehr als base64 in JSON dargestellte protobuf-Bytes laufen als tatsächliche protobuf-Bytes, und dann gebe ich mir selbst einen aus.
    • Intern dürfte es ein base64-protobuf innerhalb eines protobuf-Felds sein.
      Der JSON-Teil ist eine automatische Konvertierung.
    • Ein JSON-String eines base64-codierten protocol buffers – egal welche Firma das gemacht hat, man weiß, welche Firma das gemacht hat.

  • Dass sie das E-Mail-System kaputtgemacht haben, sodass keine Mail verschickt wurde, ist die Krönung. Bei einem riesigen Unternehmen wie Google, das unzählige Produkte gebaut hat, fühlt sich Security wie etwas Vorgetäuschtes an.
    Wenn jede einzelne Codezeile eine potenzielle Schwachstelle ist, dann ist es bei Millionen von Zeilen einfach unvermeidlich. Außer alles einfach zu halten, zum Beispiel die recorder-Site einzustampfen, scheint es keinen Weg zu geben, aber selbst das ist nicht leicht.

    • Das könnte ein weiterer Grund sein, warum Google viele Produkte killt, die zwar erfolgreich waren, aber nicht erfolgreich genug, um sie im Gesamtsystem von Google weiter am Leben und sicher zu halten.
    • Leider wird angesichts der Nutzerzahlen von Google jede Einstellung Schmerzensschreie und Widerspruch der Art „ich bin darauf angewiesen, meinen Computer mit der Leertaste zu wärmen“ auslösen. Siehe https://killedbygoogle.com/.
    • Ich würde gern Beispiele hören, bei denen sich Security „echt“ anfühlt, und wie das hilft.
      Die meisten Softwareprodukte hängen von einem sehr komplexen Software-Stack ab, und wenn man jeder verwendeten Library und jedem Betriebssystem zu 100 % vertraut, ist das meiner Ansicht nach die falsche Haltung. Selbst Prozessoren hatten Bugs wie Meltdown. Security ist ein andauernder Kampf; man weiß nie, ob man gewonnen hat, und erfährt nur gelegentlich, wenn man verloren hat.
    • Im Grunde schlägst du so etwas wie eine Drake-Gleichung[1] vor, die die Zahl der Sicherheitslücken anhand der Codezeilen berechnet. Welche weiteren Faktoren würden in diese Gleichung eingehen?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • Der Kernpunkt ist, dass Security vorgetäuscht ist. Keine App ist wirklich sicher. Selbst wenn man Millionen Dollar in App-Sicherheit steckt, kann ein einziger Fehler eines menschlichen Nutzers sie kompromittieren.

  • Ich habe den Titel auch missverstanden, im Sinne von 10.000 Dollar GPU-Rechenkosten. Wenn man sich einfach ein altes Google-Produkt herauspickt und sofort eine Lücke findet, scheint es noch Dutzende oder Hunderte solcher Bugs zu geben.

    • So läuft es nicht nach dem Motto „ein altes Google-Produkt herausgepickt und sofort eine Lücke gefunden“. Wahrscheinlich hat der Autor mehrere Produkte über Wochen oder Monate hinweg auseinandergenommen, bis er etwas Wertvolles gefunden hat.
    • Ich habe es auch so missverstanden, als wolle jemand YouTuber-E-Mail-Adressen für 10.000 Dollar verkaufen.