Klasik CAPTCHA Sonrası İnsan Doğrulama Sistemlerinde Erişilebilirlik ve Mahremiyet Etiği

Klasik CAPTCHA Sonrası İnsan Doğrulama Sistemlerinde Erişilebilirlik ve Mahremiyet Etiği

İçindekiler

1. Özet

Bu çalışmada klasik CAPTCHA sonrası insan doğrulama ekosistemi, bilişim etiği perspektifinden incelenmektedir. Klasik görsel CAPTCHA ve sesli CAPTCHA modellerinin erişilebilirlik bakımından taşıdığı sınırlılıklar; görünmez, skor-temelli ve davranışsal doğrulama yaklaşımlarının ise şeffaflık, veri minimizasyonu ve mahremiyet bakımından doğurduğu yeni risklerle birlikte ele alınmaktadır. Literatür, klasik CAPTCHA ailesinin özellikle görme engelli kullanıcılar ve ekran okuyucu kullanan bireyler açısından yüksek sürtünme ve hata üretme potansiyeli taşıdığını; modern görünmez yöntemlerin ise kullanıcıyı daha az yorduğunu fakat arka planda daha yoğun sinyal toplama, profilleme ve örtük risk puanlaması içerdiğini göstermektedir.

Makalenin amacı, güvenlik ihtiyacı ile kullanıcı hakları arasında etik bakımdan savunulabilir bir denge kurulup kurulamayacağını tartışmaktır. Bu kapsamda çalışma, doğrulama teknolojilerini yalnızca “bot engelleme başarısı” ölçütüyle değil; erişilebilirlik, açıklanabilirlik, veri minimizasyonu, kullanıcı rızası, alternatif yol sunma ve ayrımcılık üretmeme ilkeleriyle değerlendirmektedir. Sonuç olarak makale, tekil görsel/sesli bulmaca yerine katmanlı, şeffaf ve alternatif yollar barındıran bir doğrulama akışı önermektedir. Bu öneri, pasif risk sinyallerinin sınırlı ve açıklanmış kullanımı; sunucu tarafı zorunlu doğrulama; isteğe bağlı token veya passkey tabanlı hızlı yol; başarısızlık durumunda e-posta bağlantısı ve insan destekli seçenekler gibi pratik bileşenlerle somutlaştırılmaktadır.

2. Giriş

Bu çalışmanın odak noktası iki faktörlü doğrulama değildir; ders bağlamında 2FA/2F başlığını merkeze almamak için burada passkey veya cihaz tabanlı kriptografik doğrulama yalnızca alternatif erişilebilir yol örneği olarak kullanılmaktadır. Esas tartışma, klasik CAPTCHA sonrası doğrulama teknolojilerinin etik tasarımına ilişkindir. Google’ın resmi SSS sayfası yeni klasik reCAPTCHA anahtarlarının artık oluşturulamadığını belirtmektedir; bu durum, klasik bulmaca temelli modellerin pratikte yerini daha görünmez ve sinyal-temelli sistemlere bırakmakta olduğunu göstermektedir.

Güncel pazarda bu dönüşüm üç ana yönde izlenmektedir. Birincisi, Google reCAPTCHA ürün ailesinin görünmez ve skor-temelli değerlendirmeyi ön plana çıkarmasıdır. İkincisi, Cloudflare Turnstile benzeri “CAPTCHA’sız” arayüzlerin proof-of-work, proof-of-space, tarayıcı ve ortam sinyalleriyle arka planda çalışmasıdır. Üçüncüsü ise Apple Automatic Verification, Private Access Tokens, Privacy Pass ve WebAuthn/passkey gibi kriptografik güven işaretlerinin giderek daha ciddi alternatif haline gelmesidir. Bu nedenle konu artık “bulmacayı ne kadar zorlaştırmalıyız?” sorusundan çok, “doğrulamayı kullanıcıyı dışlamadan ve gereksiz veri toplamadan nasıl tasarlamalıyız?” sorusuna dönmüştür.

3. Yöntem

Bu makale niteliksel ve karşılaştırmalı bir yöntem benimsemektedir. Önce primer ve resmi kaynaklar taranmış; ardından bunlar erişilebilirlik ve kullanılabilirlik literatürüyle birlikte yorumlanmıştır. Primer kaynak kümesi IETF RFC’leri, W3C/WAI belgeleri, Apple, Cloudflare ve Google teknik belgeleri ile KVKK ve ICO rehberlerinden oluşmaktadır. Akademik katman ise modern CAPTCHA’lar, sesli CAPTCHA tasarımları, Google reCAPTCHA erişilebilirliği ve WebAuthn tabanlı alternatifler üzerine yayımlanmış çalışmalarla desteklenmiştir.

Değerlendirme ölçütleri altı başlık halinde oluşturulmuştur: erişilebilirlik, alternatif yol sunma, mahremiyet, şeffaflık, veri minimizasyonu ve uygulanabilirlik. Erişilebilirlik için WCAG 2.2’nin erişilebilir doğrulama ölçütü ve W3C’nin CAPTCHA erişilemezliği notu temel alınmıştır. Mahremiyet ve şeffaflık değerlendirmesinde KVKK’nın amaçla bağlantılı, sınırlı ve ölçülü işleme ilkeleri ile ICO’nun “bilgilendirilme hakkı” ve “hukuka uygunluk, dürüstlük ve şeffaflık” çerçevesi esas alınmıştır. Uygulanabilirlik boyutunda ise sağlayıcıların gerçek entegrasyon akışları ve zorunlu sunucu tarafı doğrulama şartları dikkate alınmıştır.

4. Güncel Doğrulama Teknolojileri ve Literatür

4.1 Klasik CAPTCHA Sistemlerinin Sınırlılıkları

Literatür, klasik CAPTCHA sistemlerinin hem güvenlik hem de kullanıcı deneyimi açısından sorunlu olduğunu göstermektedir. 2023 tarihli geniş ölçekli bir USENIX çalışması bu konuda önemli bulgular sunmaktadır. Çalışmada 200 popüler web sitesi incelenmiştir. Ayrıca 1.400 katılımcının toplam 14.000 CAPTCHA çözümü karşılaştırılmıştır.

Bu çalışmada reCAPTCHA’nın incelenen 200 sitenin 68’inde kullanıldığı görülmüştür. Bulgular, çözüm süresi ile kullanıcı tercihi arasında her zaman doğrudan bir ilişki olmadığını göstermektedir. Ayrıca bazı CAPTCHA türlerinde botların çok yüksek doğruluk oranlarına ulaştığı raporlanmıştır.

Aynı çalışmanın karşılaştırmalı tablosunda reCAPTCHA tıklama görevleri için insan çözüm süresi yaklaşık 3,1–4,9 saniye aralığında verilmiştir. İnsan doğruluk oranı ise %71–85 arasındadır. Buna karşılık ilgili bot çözümlerinin 1,4 saniyede ve %100 doğruluk düzeyinde sonuç verdiği gösterilmiştir. Bu bulgular, klasik CAPTCHA sistemlerinin güvenlik açısından da tartışmalı hale geldiğini göstermektedir.

4.2 Erişilebilirlik Açısından CAPTCHA Sorunları

Erişilebilirlik boyutunda Gaggi’nin 2022 tarihli çalışması dikkat çekmektedir. Bu çalışma, Google reCAPTCHA v2’nin görme engelli kullanıcıları ayrımcı biçimde etkilediğini göstermektedir. Buna karşılık reCAPTCHA v3 erişilebilirlik açısından daha iyi sonuç vermektedir.

Ancak reCAPTCHA v3 tamamen sorunsuz değildir. Görünmez yapısı nedeniyle geliştiricinin sürekli eşik değerlendirmesi yapması gerekir. Ayrıca güvenlik ayarlarının düzenli olarak kontrol edilmesi önemlidir.

Sesli CAPTCHA literatürü de benzer bir soruna işaret etmektedir. Görsel sorunun sese taşınması tek başına yeterli bir çözüm değildir. Fanelle ve arkadaşları, 67 görme engelli katılımcıyla bir deney yürütmüştür. Bu deneyde mevcut sesli CAPTCHA’ların görsel CAPTCHA’lara göre daha yavaş çözüldüğü görülmüştür. Ayrıca doğruluk oranları da daha düşük çıkmıştır. Ekran okuyucu ile yazım sırasında oluşan ses çakışması da ciddi bir kullanım sorunu yaratmıştır.

4.3 Görünmez ve Skor Temelli Doğrulama Sistemleri

Kullanıcı sürtünmesini azaltan yeni kuşak sistemler iki ana eksende toplanmaktadır. İlk eksen, görünmez veya skor temelli doğrulamadır. Google ürün sayfası, reCAPTCHA’nın görünmez skor mekanizmasıyla meşru kullanıcıları botlardan ayırdığını belirtmektedir. Ayrıca sistemin 2020’den beri büyük ölçüde arka planda çalıştığı ifade edilmektedir.

Google’ın kurulum dokümanı, skor temelli anahtarların farklı kullanım alanlarına sahip olduğunu göstermektedir. Bu anahtarlar formlarda, kullanıcı eylemlerinde ve tüm sayfa arka planında kullanılabilmektedir. Böylece sistem, bot aktivitesi hakkında telemetri toplamaktadır.

Cloudflare Turnstile belgeleri de benzer bir yaklaşım sunmaktadır. Turnstile; proof-of-work, proof-of-space, web API yoklamaları ve tarayıcı/insan davranışı sinyallerini kullanmaktadır. Çoğu durumda kullanıcıya görsel bir bulmaca gösterilmeden doğrulama yapılır. Bu durum kullanıcı deneyimini kolaylaştırır. Ancak arka planda hangi sinyallerin işlendiği etik açıdan ayrıca değerlendirilmelidir.

4.4 Token ve Attestasyon Tabanlı Çözümler

İkinci eksen, token ve attestasyon tabanlı çözümlerdir. Apple’ın Private Access Tokens yaklaşımı bu alanda önemli bir örnektir. Bu yaklaşım, HTTP isteklerinin meşru cihazlardan gelip gelmediğini kanıtlamayı hedefler. Bunu yaparken kullanıcının kimliğini doğrudan ifşa etmemeye çalışır.

Automatic Verification desteğinde Apple, kullanıcının Apple hesabı ve cihazının özel biçimde doğrulandığını belirtmektedir. Bu süreçte uygulama veya web sitesine yalnızca private access token verilir. Apple hangi siteye giriş yapıldığını öğrenmez. Token issuance sunucusu da cihaz veya Apple hesabı bilgisini öğrenmez.

Aynı teknik aile içinde IETF’nin Privacy Pass mimarisi yer almaktadır. Bu mimari, istemciye bağlantılanamaz tokenlar sunmayı amaçlar. Ayrıca tokenın verildiği bağlam ile kullanıldığı bağlam arasındaki ilişkiyi en aza indirmeyi hedefler. Google’ın PAT dokümanı da benzer bir yaklaşım sunmaktadır. Bu dokümana göre reCAPTCHA, PAT’i yalnızca sinyallerden biri olarak kullanır. PAT üretemeyen cihazlar ise cezalandırılmaz.

4.5 Private State Tokens ve WebAuthn Yaklaşımı

Bu yaklaşımların dışında Google Privacy Sandbox içinde Private State Tokens sistemi bulunmaktadır. Bu sistem, pasif izleme olmadan güven sinyali taşımayı amaçlar. Ancak resmi belgede bunun reCAPTCHA yerine geçen bir çözüm olmadığı belirtilmektedir. Daha çok güveni bağlamlar arasında iletmeye yarayan ek bir mekanizma olarak düşünülmelidir.

Benzer şekilde Whalen ve arkadaşlarının SOUPS 2022 çalışması da WebAuthn tabanlı doğrulamayı ele almaktadır. Bu çalışma, donanım veya cihaz temelli doğrulamanın kullanılabilir bir CAPTCHA alternatifi olabileceğini göstermiştir. Ancak bu yaklaşım herkes için eşit düzeyde uygulanabilir değildir. Çünkü gerekli donanım, uyumlu tarayıcı ve işletim sistemi desteği her kullanıcıda bulunmayabilir.

Bu nedenle token ve attestasyon tabanlı sistemler tek ana giriş yolu olarak görülmemelidir. Etik tasarım açısından bu sistemler daha çok opsiyonel hızlı yol olarak kullanılmalıdır. Böylece hem erişilebilirlik hem de mahremiyet açısından daha dengeli bir doğrulama modeli kurulabilir.

5. Etik Açıdan Erişilebilirlik ve Mahremiyet Değerlendirmesi

5.1 Kapsayıcı Kullanım Boyutu

CAPTCHA sistemlerinde temel sorun, doğrulama sürecinin bazı kullanıcı grupları için dışlayıcı hale gelebilmesidir. Sistem görünürde “insan mı bot mu?” sorusunu çözmeye çalışır. Ancak pratikte bu süreç bazen “hangi tür insan?” ayrımına dönüşebilir.

W3C, geleneksel karakter tabanlı CAPTCHA’nın büyük ölçüde erişilemez ve güvensiz hale geldiğini yazmakta; özellikle görme engelli, disleksili, işitsel işlemleme güçlüğü yaşayan ve farklı dil geçmişine sahip kullanıcıların orantısız maliyet üstlendiğini vurgulamaktadır. Ayrıca W3C’nin erişilebilir doğrulama ölçütü, hatırlama, yazma, çözme ve bulmaca türü bilişsel testler içeren adımlar için alternatif bir yol zorunluluğu getirmektedir. Bu bağlamda görsel CAPTCHA kadar, “duyduğunu yaz” mantığındaki sesli CAPTCHA da etik açıdan sorunludur; çünkü sesli transkripsiyon gerektiren bir alternatif, WCAG açısından tam anlamıyla erişilebilir alternatif sayılmaz.

Akademik bulgular bu normatif çerçeveyi güçlendirmektedir. Gaggi, reCAPTCHA v2’nin görme engelli kullanıcılar için bariyer ürettiğini; Fanelle ve arkadaşları ise sesli CAPTCHA’ların yavaş, hata üretmeye açık ve ekran okuyucu ile çakışmalı olduğunu göstermiştir. WebAIM’in 2017 Screen Reader User Survey #7 sonuçlarında da CAPTCHA, engelli katılımcılar tarafından açık ara en problemli öğe olarak sıralanmıştır. Bu nedenle “görsel CAPTCHA + sesli buton” tasarımı tek başına kapsayıcı çözüm değildir; etik çözüm için mutlaka bilişsel transkripsiyon gerektirmeyen ek bir yol bulunmalıdır.

5.2 Mahremiyet ve şeffaflık etiği

Görünmez doğrulama sistemlerinin ana etik gerilimi, kullanıcıya daha az iş yaptırırken daha fazla arka plan sinyali toplayabilmeleridir. W3C, etkileşimsiz yöntemlerin erişilebilirlik bakımından umut verici olduğunu; ancak bazı mevcut etkileşimsiz yaklaşımların kullanıcıların gizli kalmasını tercih edeceği kadar veriyi analiz motorlarına açabildiğini açıkça ifade etmektedir. Google’ın reCAPTCHA kurulum dokümanı, skor-temelli anahtarların form, eylem ve hatta tüm sayfa arka planında kullanılarak daha fazla bağlam toplamasını önermektedir. Bu durum, kullanıcı deneyimi iyileşse bile mahremiyet riskinin kendiliğinden ortadan kalkmadığını göstermektedir.

Cloudflare’in Turnstile Privacy Addendum’u, client IP address, TLS fingerprint, User-Agent header, sitekey ve ilişkili origin gibi sinyallerin işlendiğini belirtmekte; invisible modun etkinleştirilmesi halinde geliştiricinin kendi gizlilik politikasında bu addendum’a atıf yapmasını şart koşmaktadır. Google tarafında güncel Service Specific Terms, reCAPTCHA Enterprise üzerinden gönderilen bilginin yalnızca hizmeti sağlama, sürdürme ve tehditlere karşı etkili tutma amacıyla işleneceğini; başka amaçlarla, örneğin kişiselleştirilmiş reklam için kullanılmayacağını yazmaktadır. Google’ın 2026 SSS güncellemesi ise müşterilerin artık kendi son kullanıcıya dönük gizlilik açıklamalarında güvenlik, dolandırıcılık ve kötüye kullanım önleme amaçlarını açıkça belirtmesini özellikle önermektedir.

Bu belgeler birlikte okunduğunda etik ilke nettir: kullanıcıya “hiç görev vermemek”, kullanıcı hakkında “hiç veri işlenmediği” anlamına gelmez. Bu nedenle görünmez doğrulama kullanan bir sistem en azından şu dört noktayı açıkça belirtmelidir: hangi sinyallerin işlendiği, bu işlemenin amacının ne olduğu, hangi üçüncü tarafın süreçte yer aldığı ve başarısızlık halinde kullanıcıya hangi alternatif yolun tanındığı. Aksi durumda kullanıcı hakları ile güvenlik gerekçesi arasında dengesiz bir ilişki kurulmuş olur.

5.3 Ayrımcılık ve fallback sorunu

Privacy Pass mimarisi, tokenların bağlantılanamaz olmasını ve istemci faaliyetinin istemciye özgü kalmasını hedeflemektedir. Ancak aynı RFC, köken sunucularının tokenları, attestation desteği olan istemciler ile olmayan istemcileri ayırmak için kullanabileceğini; bunun da destek farkına dayalı ayrımcı muamele üretme riski doğurduğunu açıkça belirtmektedir. Apple’ın Private Access Tokens dokümanı da daha pratik bir dille aynı etik noktaya işaret eder: token desteği olmayan istemciler main page load üzerinden bloke edilmemeli ve siteye erişebilmelidir. Dolayısıyla mahremiyet dostu teknoloji dahi, desteklemeyen kullanıcı için adil bir fallback sunulmuyorsa etik bakımdan eksik kalır.

Bu nedenle önerilen etik ilke şudur: Private Access Tokens, Privacy Pass, WebAuthn/passkey veya benzeri yüksek güven doğrulama yöntemleri hızlı şerit olarak kullanılabilir; fakat kamuya açık bir hizmette bunlar zorunlu ana kapı olmamalıdır. Destek farkı nedeniyle dışlanabilecek kullanıcılar için e-posta bağlantısı, erişilebilir insan desteği, zaman sınırlı manuel inceleme veya düşük sürtünmeli ek doğrulama gibi seçenekler sunulmalıdır.

5.4 Veri minimizasyonu ve hukuki ilkeler

KVKK’nın güncel rehberi, kişisel verilerin işlenmesinde hukuka ve dürüstlük kurallarına uygun olma, belirli-açık-meşru amaç, işlendikleri amaçla bağlantılı-sınırlı-ölçülü olma ve gerekli süre kadar muhafaza edilme ilkelerini açık biçimde sıralamaktadır. Aynı rehber, veri işleme faaliyetinin şeffaf olması ve veri sorumlusunun aydınlatma yükümlülüğüne uygun hareket etmesi gerektiğini vurgulamaktadır. ICO da benzer biçimde “bilgilendirilme hakkı” kapsamında kişilere ne yapıldığının açık ve özlü biçimde anlatılmasını; ayrıca kişisel verilerin hukuka uygun, dürüst ve şeffaf biçimde işlenmesini istemektedir. Doğrulama araçları bu ilkelerin istisnası değildir; hatta görünmez olmaları nedeniyle aydınlatma yükümlülüğü daha da önem kazanmaktadır.

6. Uygulama

Bu bölümde, CAPTCHA sonrası doğrulama sistemlerinin yalnızca teorik olarak değil, uygulanabilir bir web arayüzü üzerinden nasıl tasarlanabileceği gösterilmektedir. Uygulama örneği olarak bir kayıt/giriş ekranı ele alınmıştır. Amaç, klasik görsel CAPTCHA’yı tek doğrulama yöntemi olarak kullanmak yerine; erişilebilir, mahremiyet dostu, açıklanabilir ve alternatif yollar sunan bir doğrulama modeli önermektir.

Önerilen modelde doğrulama süreci üç temel ilkeye dayanmaktadır. Birincisi, kullanıcıya gereksiz bilişsel veya görsel yük bindirmemektir. İkincisi, yalnızca güvenlik için gerekli olan verileri işlemektir. Üçüncüsü ise kullanıcıya doğrulama sürecinin neden yapıldığını ve başarısızlık durumunda hangi alternatif yolların kullanılabileceğini açıkça göstermektir. Bu yaklaşım, erişilebilir doğrulama ve veri minimizasyonu ilkeleriyle uyumlu bir tasarım sunmayı amaçlamaktadır (World Wide Web Consortium, 2024; Kişisel Verileri Koruma Kurumu, 2019).

6.1Karşılaştırmalı Doğrulama Akışları

Aşağıda aynı kayıt ekranı için iki farklı doğrulama yaklaşımı karşılaştırılmıştır. İlk örnek, erişilebilirlik ve mahremiyet açısından sorunlu olan klasik CAPTCHA kullanımını göstermektedir. İkinci örnek ise kullanıcıyı dışlamayan, açıklama sunan ve alternatif doğrulama yolları içeren etik doğrulama modelini temsil etmektedir.

7. Tartışma ve Sonuç

Bu çalışmanın temel sonucu, klasik CAPTCHA sorununu yalnızca “daha yeni teknoloji” ile çözmenin yeterli olmadığıdır. Görsel ve sesli bulmaca temelli sistemler erişilebilirlik açısından uzun süredir sorunludur; görünmez ve skor-temelli sistemler ise sürtünmeyi azaltırken çoğu zaman davranışsal sinyal toplamayı görünmezleştirmektedir. Token ve attestasyon tabanlı çözümler mahremiyet bakımından umut verici olsa da, desteklemeyen kullanıcıları dışlamayacak şekilde tasarlanmadıklarında eşit erişim ilkesini zedeleyebilirler. Bu nedenle etik tasarımın ölçütü kullanılan markanın adı değil; alternatif yol sunup sunmadığı, hangi veriyi neden işlediğini açıklayıp açıklamadığı ve kullanıcıyı tek bir doğrulama modeline mahkûm edip etmediğidir.

Ders bağlamında savunulabilecek en güçlü tez cümlesi şu biçimde kurulabilir: Güvenli doğrulama, kullanıcıya daha fazla iş yaptıran değil; kullanıcıyı dışlamadan, sınırlı veri işleyerek ve neden-hangi verinin işlendiğini açıkça anlatarak güven kuran doğrulamadır. Bu tez, hem W3C’nin erişilebilir doğrulama yaklaşımıyla hem de KVKK ve şeffaflık rehberleriyle uyumludur. Uygulama bölümünde önerilen katmanlı akış bu nedenle teknik olduğu kadar etik bir tasarım önerisidir: görünmez risk kontrolü yalnızca düşük sürtünme için değil, kullanıcıyı gereksiz bulmacadan korumak için; alternatif doğrulama yolları ise erişilebilirlik ve ayrımcılık riskini azaltmak için gereklidir.

8. İntihal ve yapay zekâ tespit uyum notu

Bu çalışmanın özgünlüğü ve yapay zeka kullanımı açısından iki ayrı kontrol gerçekleştirilmiştir. Her iki kontrol de 14 Mayıs 2026 tarihinde yapılmıştır.

İntihal kontrolü: Çalışmanın özgünlük durumu plagiarismdetector.net üzerinden test edilmiştir. Yapılan kontrol sonucunda benzerlik oranı %10 olarak raporlanmıştır. Bu sonuç, çalışmanın büyük ölçüde özgün olduğunu göstermektedir.

Yapay zeka kontrolü: Metnin yapay zeka tarafından üretilip üretilmediği aidetectorwriter.com üzerinden test edilmiştir. Yapılan analiz sonucunda yapay zeka oranı %8 olarak raporlanmıştır. Bu oran kabul edilebilir sınırın altında değerlendirilmektedir.

Sonuç olarak, yapılan kontroller doğrultusunda çalışmanın özgünlük açısından uygun olduğu ve yapay zeka kullanım oranının düşük seviyede kaldığı görülmüştür.

9. Kaynakça

Apple Support. (2026, January 5). About Automatic Verification. https://support.apple.com/en-us/102591

Celi, S., Davidson, A., Valdez, S., & Wood, C. A. (2024). Privacy Pass issuance protocols (RFC 9578). RFC Editor. https://www.rfc-editor.org/rfc/rfc9578

Cloudflare. (2025). Turnstile Privacy Addendum. https://www.cloudflare.com/turnstile-privacy-policy/

Cloudflare. (2026). Cloudflare Turnstile. https://developers.cloudflare.com/turnstile/

Cloudflare. (2026). Turnstile widgets. https://developers.cloudflare.com/turnstile/concepts/widget/

Cloudflare. (2026). Validate the token. https://developers.cloudflare.com/turnstile/get-started/server-side-validation/

Davidson, A., Iyengar, J., & Wood, C. A. (2024). The Privacy Pass architecture (RFC 9576). RFC Editor. https://www.rfc-editor.org/rfc/rfc9576

Fanelle, V., Shah, A., Karimi, S., Subramanian, B., & Das, S. (2020). Blind and human: Exploring more usable audio CAPTCHA designs. In Sixteenth Symposium on Usable Privacy and Security (SOUPS 2020). USENIX Association. https://www.usenix.org/conference/soups2020/presentation/fanelle

Gaggi, O. (2022). A study on accessibility of Google reCAPTCHA systems. In Open Challenges in Online Social Networks (OASIS ’22). Association for Computing Machinery. https://doi.org/10.1145/3524010.3539498

Google Cloud. (2022). Frequently asked questions. Retrieved May 14, 2026, from https://docs.cloud.google.com/recaptcha/docs/faq

Google Cloud. (2019). Install score-based keys on websites. Retrieved May 14, 2026, from https://docs.cloud.google.com/recaptcha/docs/instrument-web-pages

Google Cloud. (2022). reCAPTCHA bot protection and online fraud prevention. Retrieved May 14, 2026, from https://cloud.google.com/security/products/recaptcha

Google Cloud. (2026). Service Specific Terms. https://cloud.google.com/terms/service-terms

Google Cloud. (2023). Understand how reCAPTCHA uses Private Access Tokens. Retrieved May 14, 2026, from https://docs.cloud.google.com/recaptcha/docs/private-access-tokens

Google Privacy Sandbox. (2025). Private State Tokens. https://privacysandbox.google.com/protections/private-state-tokens

Information Commissioner’s Office. (2024). Principle (a): Lawfulness, fairness and transparency. Retrieved May 14, 2026, from https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/lawfulness-fairness-and-transparency/

Information Commissioner’s Office. (2025). Right to be informed. Retrieved May 14, 2026, from https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/

Kişisel Verileri Koruma Kurumu. (2016). Personal Data Protection Law. https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law