YouTube kullanıcı e-postalarını sızdıran açık için 10.000 dolar ödül alındı

 (brutecat.com)
1 puan yazan GN⁺ 2025-02-13 | 1 yorum | WhatsApp'ta paylaş
  • YouTube kanallarının dahili Google hesabı tanımlayıcısı olan obfuscated Gaia ID açığa çıkıyordu ve bu kimlik Pixel Recorder paylaşım API'si üzerinden e-posta adresleriyle ilişkilendirilebildiği için Google hesabı gizliliği açısından sorun oluşturuyordu
  • Canlı sohbet engelleme menüsündeki Innertube isteği, gerçek bir engelleme yapılmasa bile hedef kanalın Gaia ID bilgisini içeren moderateLiveChatEndpoint parametresini döndürüyordu
  • İstek parametresindeki kanal ID'si değiştirilince kapsam, canlı sohbet mesajı bulunmayan Topic Channel'lara kadar genişledi; sorun belirli katılımcılarla sınırlı değildi
  • Pixel Recorder'ın WriteShareList uç noktası, paylaşım hedefinin obfuscated Gaia ID'sini girdi olarak alıp yanıtta e-posta adresini içeriyordu; ayrıca 2,5 milyon karakterlik kayıt başlığıyla bildirim e-postasının gönderilmesi de engellenebiliyordu
  • Google, 15 Eylül 2024'te bildirimi aldıktan sonra 9 Şubat 2025'te iki açığın da düzeltildiğini doğruladı ve toplam 10.633 dolar ödül ödedi

YouTube engelleme özelliğinde ortaya çıkan Gaia ID

  • Google'ın Internal People API staging discovery belgesinde BlockedTarget nesnesinin obfuscated Gaia ID ve fallbackName kullandığı görüldü
    • profileId, engellenen kullanıcının obfuscated Gaia ID'si
    • fallbackName, engellenen kullanıcının görünen adı
  • Google Hesabı yardımında YouTube'da hesap engellenebileceğine dair bir açıklama vardı; gerçekten de YouTube canlı yayınında bir kullanıcı engellendiğinde bu kullanıcı myaccount.google.com/blocklist içinde görünüyordu
  • Engelleme listesinde kanal adı Mega Prime, fallbackName olarak; 107183641464576740691 ise profile ID olarak gösteriliyordu
  • YouTube kanalının alttaki Google hesabını açığa çıkarmaması gerektiği varsayımıyla, geçmişte Gaia ID'yi e-posta adresine dönüştüren hatalar da bulunduğundan ek yollar aranmaya başlandı

Canlı sohbet menüsünden tüm kanallara genişleme

  • YouTube canlı sohbetinde yalnızca üç nokta menüsünü açmak bile /youtubei/v1/live_chat/get_item_context_menu isteğini tetikliyordu
  • Yanıtta /youtubei/v1/live_chat/moderate adresine giden moderateLiveChatEndpoint ve params değeri yer alıyordu
  • Bu params, Google'da sık kullanılan base64 kodlu protobuf biçimindeydi; çözümlendiğinde engellenecek kullanıcının Gaia ID'sini içeriyordu
    • Örnek yanıtta 113907466537670370590 ve kanalla ilgili tanımlayıcılar bulunuyordu
    • Gerçek bir engelleme yapmadan hedefin Gaia ID'si alınabiliyordu
  • get_item_context_menu istek parametresi çözümlendiğinde engellenmek istenen kanalın channel ID'si, canlı yayın video ID'si ve canlı yayını oluşturanın ID'si yer alıyordu
  • İstek parametresindeki kanal ID'si başka bir değerle değiştirilerek test edildiğinde, YouTube'un otomatik oluşturduğu Topic Channel için Gaia ID 103261974221829892167 da alınabildi

Pixel Recorder e-posta dönüştürme yolu oldu

  • Eski Google ürünlerinde Gaia ID'yi e-postaya çevirebilen hata veya mantık kusurları aranırken, nathan ile birlikte Pixel Recorder incelendi
  • Pixel telefonda test kaydı oluşturulup Google hesabına senkronize edildikten sonra web'deki recorder.google.com uç noktası kullanıldı
  • Kayıt test e-postasıyla paylaşıldığında WriteShareList isteği, paylaşım hedefleri listesinde obfuscated Gaia ID içeriyordu
  • pixelrecorder-pa.clients6.google.com üzerindeki PlaybackService/WriteShareList yanıtı, ilgili paylaşım hedefinin e-posta adresini döndürüyordu
    • Test yanıtında vrptest2@gmail.com yer alıyordu
    • YouTube engelleme denemesinde elde edilen 107183641464576740691 Gaia ID girildiğinde de redacted@gmail.com döndü
  • Böylece YouTube'dan elde edilen Gaia ID'yi Pixel Recorder paylaşım API'sine vererek e-posta adresini öğrenmeyi sağlayan bir saldırı zinciri mümkün hale geldi

Bildirim e-postasını engelleyen 2,5 milyon karakterlik kayıt başlığı

  • Pixel Recorder'da bir kayıt mağdurla paylaşıldığında mağdura e-posta bildirimi gönderildiğinden saldırının etkisi azalabilirdi
  • Paylaşım açılır penceresinde bildirimi kapatma seçeneği yoktu; req2proto ile istek protobuf'u incelendiğinde de bildirimi devre dışı bırakan bir alan bulunmadı
  • WriteShareListRequest yapısında şu alanlar vardı
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Kullanıcı aynı anda eklenip kaldırılsa da e-posta gönderilmeye devam ediyordu
  • Bildirim e-postasının konu satırında kayıt başlığının yer almasından yola çıkılarak, kayıt başlığı çok uzun yapılırsa e-posta gönderiminin başarısız olabileceği düşünüldü
  • UpdateRecordingTitle uç noktasıyla kayıt başlığını 2,5 milyon karaktere değiştiren bir Python betiği yazılıp test edildi; sunucu tarafında başlık uzunluğu sınırı yoktu
  • Başlık 2,5 milyon karaktere ayarlandıktan sonra başka bir test kullanıcısıyla paylaşıldığında bildirim e-postası gönderilmedi

Nihai PoC ve işlem takvimi

  • Tamamlanan saldırı zinciri üç adımdan oluşuyordu
    • YouTube Innertube /get_item_context_menu uç noktasından hedef kanalın obfuscated Gaia ID'sini alma
    • Çok uzun başlığa sahip bir Pixel Recorder kaydını hedefle paylaşarak Gaia ID'yi e-posta adresine dönüştürme
    • Pixel Recorder kayıt paylaşım hedeflerinden ilgili kullanıcıyı kaldırarak temizlik yapma
  • PoC videosu YouTube videosu olarak sunuldu

Google ödülü ve düzeltme zaman çizelgesi

  • 2024-09-15: Bildirim tedarikçiye gönderildi
  • 2024-09-16: Tedarikçi raporu triage etti ve Nice catch! yanıtı alındı
  • 2024-10-03: Panel, raporu mevcut takip hatasının kopyası olarak işaretledi ve ilk YouTube obfuscated Gaia ID sızıntısı için eksik bir yama uygulandı
  • 2024-10-03: Pixel Recorder'ın kendisinin de bir güvenlik açığı olduğu tedarikçiye yeniden açıklandı
    • obfuscated Gaia ID, Google Maps ve Google Play yorumcularında da açığa çıkabiliyordu
    • YouTube kanalının obfuscated Gaia ID'sini tekrar sızdıran bir bypass yöntemi de sunuldu
  • 2024-11-05: Panel 3.133 dolar ödül ödedi
    • Gerekçe: orta düzeyde kötüye kullanılabilirlik
    • Yüksek etkili abuse-related methodology olarak sınıflandırıldı
  • 2024-12-03: Ürün ekibi ek ödül değerlendirmesi için raporu yeniden panele gönderdi ve 2025-02-03 açıklama takvimi koordine edildi
  • 2024-12-12: Panel 7.500 dolar ek ödül ödedi
    • Gerekçe: yüksek kötüye kullanılabilirlik
    • Yüksek etkili abuse-related methodology olarak sınıflandırıldı
    • Saldırı zincirinin karmaşıklığı nedeniyle temel tutardan 1 kademe aşağı indirildi
  • 2025-01-29: Tedarikçi açıklama takviminin 2025-02-02'ye uzatılmasını istedi
  • 2025-02-09: Saldırı zincirinin iki bölümünün de düzeltildiği doğrulandı
    • İlk bildirimden 147 gün sonra
  • 2025-02-12: Rapor yayımlandı

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-13
Hacker News yorumları

  • Başlık kafa karıştırıcıydı. Yazının sonuna kadar okumayanlar için söyleyeyim: Sızan e-posta yüzünden masraf yapılmış değil; zaman ve kıvrak zekâ harcanmış ve 10 bin dolarlık bug bounty alınmış

    • İlk başta, kullanıcı e-postalarını sızdıran bir hizmeti kullanıcı başına 10 bin dolara sundukları anlamına geliyor sandım
    • Ben de bunu 10 bin dolarlık bir hizmet olarak sundukları anlamına geliyor sandım
    • Tıklama almak için yazılmış bir başlık da olabilir
    • İlk başta bir tür hash’i brute force etmek için gereken hesaplama maliyeti gibi bir şeyden bahsedecek sanmıştım

  • Sorumlu açıklama, motivasyon ve ödül hakkında çok gürültü var; ama bunun merkezi kalıcı kimliğe karşı bir başka gerekçe olduğundan pek söz edildiğini görmüyorum
    Bir hizmetin tek bir Real Identity™ ile ilişkilendirildiğinde en iyi çalıştığı her iddia edildiğinde, şirketlerin kullanıcıları gerçekten korumaya yalnızca soyut düzeyde ilgi duyduğunu, onu da ancak ara sıra yaptığını düşünüyorum
    YouTube’da etkileşim kurduğunuz herhangi birinin sizi anında doxxing’e birkaç adım daha yaklaştırabildiğini hayal edin; bence bu hatanın gerçek etkisi bu düzeyde. Düzeltilmiş olması iyi, ama bu tür hataların yakın zamanda ortadan kalkacağını sanmıyorum. Şirketlerin ve büyük kurumların bu tasarımın patlamaya hazır bir mayın tarlası olduğunu fark etmesi için ne gerekir?

    • Soyut düzeyde katılıyorum. Bu tür hesaplarda belli ölçüde anonimlik ve gözden çıkarılabilirlik mümkün olmalı. Sonuçta bir yerdeki veritabanında yalnızca bir satırdan ibaret
      Ancak birçok kişi bu şirketlerle gerçek parayla işlem yapıyor. Örneğin YouTube Premium aboneleri ya da içerik üreticileri gibi. Pratikte, o gözden çıkarılabilir hesabın bir yerinde gerçek kimlik belirleyicilerinin saklanması gerekiyor. Dolandırıcılık riski ve bankacılığın gerçekleri nedeniyle, gerçek kimliğinizi ve adresinizi şirkete veriyorsunuz; şirket de bunları saklıyor
      Rastgele uygulamalara veya web sitelerine beni tanımlayacak bilgiler vermiyorum; ama işlem yaptığım taraf kaçınılmaz olarak gerçek hayattaki beni biliyor ve teorik olarak bu verilerin sızabileceği bir nokta haline geliyor
    • Hukuki sonuçları olmadığı için umursamıyorlar
      Bir sağlık hizmeti sağlayıcısı sağlık verilerini sızdırsa tamamen mahvolur

  • “Çalışan exploit POC: Bu video, YouTube Hizmet Şartları’nı ihlal ettiği için kaldırılmıştır” demesi komik

    • Orijinal yazının yazarı, kavram kanıtı için gerçekten var olan bir kullanıcının e-posta adresini ifşa etmişti. Yeniden yüklenen videoda e-posta adresi bulanıklaştırılmış
    • İlk başta bana da öyle görünmüştü, ama yazıyı yeniden açınca video görünüyor gibi. Az önce mi geri yüklendi bilmiyorum

  • Bu başlıktaki her üçüncü yorum Google’ın bu hataya çok az ödeme yaptığı yönünde olduğundan, zafiyet değerlemesi hakkında temel birkaç şey söylemek gerekirse:
    Sunucu tarafı zafiyetlerin değeri düşüktür, çünkü şirketler bunlar için rekabet etmez. Sunucu tarafı zafiyetler için fiilen gri pazar yoktur. Google’ın anında öldürebileceği, bulunduğu anda neredeyse hiç yarı ömrü kalmayan ve kötüye kullanıldığında hedefte güvenilir uzaktan ölçüm üreten bir hataya üçüncü tarafların fiyat biçmesi zordur.
    Buna karşılık Android/Chrome tam zincirleri gibi hataların yüz binlerce dolara satılmasının nedeni, Google’ın iyi oluşmuş bir gri pazarla rekabet etmesidir. Bir aracı o hatayı alıp bir Avrupa ülkesindeki çeşitli kurumlara, potansiyel olarak 6 farklı yere satabilir.
    Yine de bounty ile gri pazarı karşılaştırmak elmalarla portakalları karşılaştırmak gibidir. Google’ın güvenilir bir exploit’e değil, yalnızca yazılabilir olduğunun kanıtına ihtiyacı vardır; bakım maliyeti de gerekmez, bu yüzden gri pazardan çok daha az öder. Pazarın geri kalanındaki toplam tutar birçok aşamaya bölünür ve risk koşulları taşır; Google ise indirimli de olsa cazip bir tek seferlik ödeme sunabilir.
    Saldırganlar mevcut iş süreçlerine uyan zafiyetleri satın alır. Genellikle yeni bir zafiyetle yapılabilecek havalı şeyleri ve para kazanma yollarını spekülatif olarak hayal etmezler. Ödeme bilgisi toplamak, botnet için binlerce makine ele geçirmek mevcut iş süreçleridir. Google hesabı gerçek adlarını ifşa etmek bir iş olabilir mi? Belki olabilir. Halihazırda var mı? Muhtemelen yok.
    Bounty ödemeleri genellikle bir hatanın ne kadar zekice veya ilginç olduğuna dair bir halk oylaması değildir. Gerçi burada biraz öyle de sayılır; sunucu tarafı bir web hatası için 10 bin dolar olağan dışı yüksek hissettiriyor.
    Bu tür hataları bularak geçinen biri için iş stratejisi, çok sayıda bulmakta ustalaşmaktır. Tek bir güvenilir exploit’e aylar harcanan iOS exploit geliştirmeden farklıdır.
    Son dönemde kariyerimde yaptığım zafiyet araştırmaları, diğer pek çok işten daha çok bu tarafa yakın olduğundan bu konuda epey eminim. Yine de HN’de bu tür bounty işini tam zamanlı yapanlar var; biri düzeltirse memnun olurum.

    • Diğer alanların çoğunda insanlar, ürettikleri şeyin karaborsa değeri üzerinden ücretlendirilmez.
      Bu analizi başka şeylere uygularsanız, yeni bir araç ses sistemi ya da bisikletin tavan fiyatı yaklaşık 100 dolar olur; telif hakkı olan tüm malların fiyatı da ağ üzerinden iletme maliyetiyle sınırlanır.
      Google’ın ödediği tutarı, bu işe harcanan zamanla ve son bounty’den beri başarısız olan tüm exploit denemelerine harcanan zamanla bölmek bence daha faydalı.
      Bu alandaki çoğunluk muhtemelen harcadıkları emeğe göre ABD asgari ücretinden daha az kazanıyor ve yıllık altı haneli fırsat maliyeti ödüyor.
      Bu sayı, Google’ın son kullanıcı güvenliğine ve mahremiyetine ne kadar değer verdiğini oldukça doğru gösteriyor. Aynı kişilerin kişisel verilerini çalsınlar diye diğer mühendislere birkaç basamak daha fazla ödeme yapmalarından çok daha düşük bir sayı.
    • Bu HN başlığının çoğunlukla bounty miktarı hakkında olmasından hoşlanmıyorum ama bu aynı zamanda doğal. Buraya yorum yapanların çoğu yazılım sektöründe çalışıyor ve çok yüksek bounty’leri normalleştirmek istiyor.
      Çünkü onlar için ek gelir kaynağı. Yazılım mühendislerinin yüksek ücretli bir meslek olmasını istedikleri gibi bug bounty’lerin de yükselmesini istiyorlar. Çalışanların kendi mesleklerinin ücretlerinin artmasını istemesi doğaldır; hiçbir rasyonalizasyon bu içgüdüyü değiştirmez.
    • “Saldırganlar mevcut iş süreçlerine uyan zafiyetleri satın alır” deniyor ama bunun da bir pazarı yok mu? Örneğin “bizim şaibeli şirketimizi/hükümetimizi eleştiren bu hesabın arkasındaki kişinin kim olduğunu ortaya çıkarıp etkisiz hale getirelim” gibi.
      Saldırgan pazar değerinden ayrı teşvikler de var. Çevrimiçi ünlüleri takip eden şiddet yanlısı biri, böyle bir sıfırıncı gün exploit pazarında kârlı bir müşteri olmayabilir; ama bir şirket dikkatsizlikle hedefin kimliğini şiddet yanlısı bir stalker’a ifşa edebiliyorsa, o zafiyet yine de sorumluluk ve etik risk taşır.
      Kişisel olarak, güvenliğe kusurlu bir dikkat göstererek muazzam miktarda kod basan LeetCode performans sanatçılarına yüklü para veriliyorsa, kötü bir şey olmadan önce onların sayısız hatasını bulup düzeltmeye yardımcı olanlara da iyi ödeme yapılması gerektiğini düşünüyorum.
    • Kolluk kuvvetlerinin sunucu tarafı hataları kötüye kullanması çok daha gri bir alan olabilir, hatta gerçekten yasa dışı olabilir. Buna karşılık belirli bir hedefin cihazını, yani telefonunu veya dizüstü bilgisayarını istismar edebilmek için mahkeme emri alma yönünde standart süreçler kolluk kuvvetleri ya da istihbarat kurumlarında zaten mevcut.

  • “Gerekli saldırı zincirinin karmaşıklığı nedeniyle temel tutardan 1 kademe aşağı uygulandı” deniyor; bu yaygın mı?
    Yalnızca birkaç zafiyet programına katıldım, ama çoğu, sayfa kaynağında kullanıcı e-postasının görünmesi gibi saçma derecede basit ama ciddi kusurlara aksine daha az ödül veriyordu.

    • Ben tersine, web zafiyetine göre görece karmaşık olduğu için puan kırıldığı şeklinde anlamıştım.
    • Bu sanki ters gibi. Fiilen 2 hata bulmuş sayılırlar, bu yüzden temel tutardan yukarı çıkmaları gerekir.

  • “Bir süre önce Google’da araştırma hedefi ararken Internal People API (Staging) discovery dokümanlarını kurcalıyordum” deniyor; bunun öylece herkese açık olması sorun değil mi: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • Bu yalnızca dahili .proto tanımlarından otomatik dönüştürülmüş bir şema dosyası. Google belirsizlik yoluyla güvenliğe değil, gerçek kriptografiye dayanır.
      Üstelik discovery uç noktası herkese açık olarak belgelenmiş[0] ve harici kullanıcılar için yapılmıştır. İçeridekiler discovery uç noktasını okumaz; kod aramasından .proto dosyasını doğrudan görür.
      Google’da çalışmış biri olarak, bir API’yi herkese açık açmak için bürokrasiyle haftalarca boğuşmak gerektiğini gördüm. Bu, yanlışlıkla herkese açık kalmış bir AWS S3 bucket’ı gibi bir şey değil. Ekip bunun herkese açık olduğunu biliyordu ve herkese açmak için bürokrasiyi aşmış olmalı.
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Yazının zaman çizelgesine bakılırsa 2024-09-15’te şirkete bildirilmiş, 2025-01-29’da şirket açıklamanın 2025-02-12’ye kadar ertelenmesini istemiş, 2025-02-09’da exploit’in iki tarafının da düzeltildiği doğrulanmış ve 2025-02-12’de açıklanmış.
    O zaman 136 gün boyunca düzeltilmemiş ve Google erteleme istemiş olmuyor mu? Düzeltmeye kadar 147 gün, açıklamaya kadar 150 gün.
    Google Project Zero’nun başka şirketlere verdiği düzeltme öncesi açıklama süreleriyle karşılaştırınca şöyle diyorlar: “Bu hata için 90 günlük açıklama süresi geçerlidir. 90 günlük süreden önce kullanıcılara bir düzeltme sunulursa, bu hata raporu düzeltme sunulduktan 30 gün sonra açıklanır. Aksi halde süre dolduğunda açıklanır.”
    “Yamanın sürenin dolmasından sonraki 14 gün içinde çıkması bekleniyorsa Project Zero erteleme sağlayabilir… Ancak 14 günlük ek süre, 30 günlük yama uygulama süresiyle çakıştığı için, ek süre içinde düzeltilen güvenlik açıkları da özgün 90 günlük süreden itibaren en geç 120. günde açıklanır.”
    “Düzeltmenin 14 gün içinde hazır olmayacağına karar verilirse özgün 90 günlük süre açıklama zamanı olarak kullanılır. Yani 14 günlük ek erteleme yalnızca geliştirici 14 günlük ek süre içinde düzeltmeyi dağıtmayı taahhüt ettiğinde verilir.”
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • Bu karşılaştırmanın yararlı olduğunu düşünmüyorum. Bu, Google yazılımındaki bir Google hatası; Project Zero’nun buldukları ise genelde birçok kişinin kullandığı yazılımlardaki hatalar, bu yüzden düzeltme aciliyetinin daha yüksek olduğunu anlıyorum.

  • “O params sadece base64 ile kodlanmış protobuf ve Google genelinde yaygın kullanılan bir kodlama biçimi” demeleri yok mu; güzelim ikili mesaj formatını base64 ile kodlayıp bir JSON yığınının içine tıkıştıran sorumlu Google geliştiricisine bir içki ısmarlamak lazım.
    Geleceği görmek istiyorsanız, tabanında “worse is better” yazan bir botun bir mühendisin yüzünü sonsuza dek ezdiğini hayal edin.

    • Bu her yerde var ve berbat. Bazen internette hatlar üzerinden gidip gelen gerçek protobuf baytlarından çok, JSON içinde base64 olarak temsil edilen protobuf baytları mı var diye düşünüp kendime bir içki koyuyorum.
    • İçeride muhtemelen protobuf alanı içindeki base64 protobuf’tur.
      JSON kısmı otomatik dönüşüm.
    • Base64 ile kodlanmış protocol buffer’ın JSON string’i ha; hangi şirketin yaptığını bilmesem de hangi şirketin yaptığını biliyorum.

  • E-posta sistemini bozup postaların gönderilmemesine yol açmaları işin tuzu biberi olmuş. Google gibi sayısız ürün yapmış dev bir şirkette güvenlik sahteymiş gibi hissettiriyor.
    Kodun her satırı potansiyel bir güvenlik açığıysa, milyonlarca satırda bu artık kaçınılmaz. Basit tutmak, örneğin recorder sitesini kapatmak dışında bir yol yok gibi görünüyor; yine de kolay değil.

    • Google’ın başarılı olmuş ama Google’ın genel sistemi içinde yaşatılıp güvenli tutulacak kadar başarılı olmayan birçok ürünü öldürmesinin bir başka nedeni bu olabilir.
    • Ne yazık ki Google’ın kullanıcı sayısı düşünülünce herhangi bir kapatma acı dolu çığlıklar ve “bilgisayarımı boşluk tuşuyla ısıtmaya bağımlıyım” tarzı tepkiler doğuracaktır. https://killedbygoogle.com/ adresine bakın.
    • Güvenliğin “gerçek” gibi hissettirdiği bir örnek ve bunun nasıl yardımcı olduğunu duymak isterim.
      Çoğu yazılım ürünü çok karmaşık bir yazılım yığınına dayanır; kullandığınız tüm kütüphanelere ve işletim sistemlerine %100 güveniyorsanız bence bu yanlış bir zihniyettir. İşlemcilerde bile Meltdown gibi hatalar vardı. Güvenlik sürekli bir mücadeledir; kazandığınızı asla bilemezsiniz, kaybettiğinizi ise ancak bazen anlarsınız.
    • Özünde, kod satırı sayısına dayanarak güvenlik açığı sayısını hesaplayan Drake denklemi[1] gibi bir şey öneriyorsunuz. Bu denkleme başka hangi unsurlar girerdi?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • Mesele şu ki güvenlik sahte. Hiçbir uygulama gerçekten güvenli değil. Uygulama güvenliğine milyonlarca dolar harcasanız bile, tek bir insan kullanıcının tek bir hatasıyla delinebilir.

  • Ben de başlığı GPU hesaplama maliyeti 10 bin dolar gibi bir şey sanmıştım. Eski bir Google ürününü seçip hemen bir açık bulmuş olmalarına bakılırsa, böyle onlarca hatta yüzlerce hata daha var gibi.

    • “Eski bir Google ürününü seçip hemen bir açık buldu” şeklinde işlemiyor. Yazar muhtemelen değerli bir şey bulana kadar birkaç ürünü haftalarca, hatta aylarca didik didik etmiştir.
    • Ben de YouTuber e-posta adreslerini 10 bin dolara satacağı anlamına geldiğini sanmıştım.