Privacy Sandbox teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2022 2. çeyrek için üç aylık rapor.
Google, CMA'ya verdiği taahhütler kapsamında, Özel Korumalı Alan teklifleriyle ilgili paydaş etkileşim süreci hakkında üç ayda bir herkese açık raporlar sunmayı kabul etmiştir (Taahhütler'in 12. ve 17(c)(ii) paragraflarına bakın). Bu Gizlilik Korumalı Alan geri bildirim özet raporları, Chrome'un geri bildirime genel bakış bölümünde listelenen çeşitli kaynaklardan aldığı geri bildirimler (GitHub Issues, privacysandbox.com adresinde kullanıma sunulan geri bildirim formu, sektör paydaşlarıyla yapılan toplantılar ve web standartları forumları dahil ancak bunlarla sınırlı olmamak üzere) toplanarak oluşturulur. Chrome, ekosistemden gelen geri bildirimleri memnuniyetle karşılar ve edinilen bilgileri tasarım kararlarına entegre etmenin yollarını etkin bir şekilde araştırır.
Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu işlem, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanması ve miktara göre azalan düzende düzenlenmesiyle yapılır. Ortak geri bildirim temaları, herkese açık toplantılardaki (W3C, PatCG, IETF) tartışma konuları, doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden gelen sık sorulan sorular incelenerek belirlendi.
Daha ayrıntılı belirtmek gerekirse, web standardı kuruluş toplantılarının tutanakları incelendi ve doğrudan geri bildirim için Google'ın paydaşlarla bire bir toplantı kayıtları, mühendislerin aldığı e-postalar, API posta listesi ve herkese açık geri bildirim formu dikkate alındı. Ardından Google, her API ile ilgili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli tanıtım etkinliklerine katılan ekipler arasında koordinasyon sağladı.
Chrome'un geri bildirimlere verdiği yanıtlarla ilgili açıklamalar, yayınlanan SSS'lerden, paydaşların gündeme getirdiği sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama çalışması için özel olarak belirlenen bir duruştan geliştirilmiştir. Geliştirme ve testin mevcut odağını yansıtan sorular ve geri bildirimler özellikle Topics, Fledge ve Attribution Reporting API'leri ile ilgili olarak alındı.
Geçerli raporlama döneminin sona ermesinden sonra alınan geri bildirimler henüz Chrome yanıtı olarak değerlendirilmeyebilir.
Kısaltmalar sözlüğü
- CHIPS
- Bağımsız Bölümlendirme Durumuna Sahip Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Federated Credential Management
- FPS
- Birinci Taraf Gruplar
- IAB
- Interactive Advertising Bureau
- IDP
- Kimlik Sağlayıcı
- IETF
- Internet Mühendisliği Görev Gücü
- IP
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- uzatma
- Origin Deneme Sürümü
- PatCG
- Private Advertising Technology Community Group
- RP
- Bağlı Taraf
- SSP
- Arz tarafı platformu
- TEE
- Güvenilir Yürütme Ortamı
- UA
- Kullanıcı aracısı dizesi
- UA-CH
- Kullanıcı Aracısı İstemci İpuçları
- W3C
- World Wide Web Konsorsiyumu
- WIPB
- İstençli IP Körlüğü
Belirli bir API/teknolojiyle ilgili olmayan genel geri bildirimler
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Daha net zaman çizelgeleri | Özel Korumalı Alan teknolojileri için daha net ve ayrıntılı sürüm planları. | Dağıtım planıyla ilgili mevcut planlarımızı privacysandbox.com adresinde açıklıyor ve bu sayfayı aylık olarak güncelliyoruz. Bu süreler hem Chrome hem de web geliştiricilerinin geliştirme süresi ile daha geniş ekosistemden yeni teknolojileri test etmek ve benimsemek için gereken süreyle ilgili aldığımız geri bildirimleri dikkate alır. Her teknoloji, testten yayına (lansmana) kadar birden fazla adımdan geçer ve her bir adımın zamanlaması, önceki adımda öğrendiklerimiz ve keşfettiklerimiz doğrultusunda belirlenir. Şu anda kesin bir sürüm tarihi veremiyoruz ancak gelişmeleri privacysandbox.com adresindeki herkese açık zaman çizelgemizde güncelleyeceğiz. |
| Farklı paydaş türleri için yararlı olması | Özel Korumalı Alan teknolojilerinin daha büyük geliştiricileri desteklediği ve nispeten küçük (genel) sitelerin genel (büyük) sitelerden daha fazla katkıda bulunduğuyla ilgili endişeler | Bazı geliştiricilerin Özel Korumalı Alan teknolojilerinin etkisiyle ilgili endişeleri olduğunun farkındayız. Google, Özel Korumalı Alan tekliflerini Google'ın kendi işletmesini tercih ederek rekabeti bozacak şekilde tasarlamamayı veya uygulamamayı ve dijital reklamcılıktaki rekabeti, yayıncıları ve reklamverenleri, ayrıca gizlilik sonuçlarını ve kullanıcı deneyimini etkileyen faktörleri dikkate almayı CMA'ya taahhüt etmiştir. Çalışmalarımızın bu taahhütlere uymasını sağlamak için CMA ile yakın bir şekilde çalışmaya devam ediyoruz.
Özel Korumalı Alan'ın testleri ilerledikçe, yeni teknolojilerin farklı paydaş türleri için nasıl performans gösterdiğini değerlendireceğimiz önemli sorulardan biri olacaktır. Bu bağlamda geri bildirim çok önemlidir. Özellikle teknik tasarımları daha da iyileştirmemize yardımcı olabilecek spesifik ve uygulanabilir geri bildirimler çok önemlidir. |
| Üçüncü taraf çerez desteğinin sonlandırılmasına ilişkin zaman çizelgeleri | Üçüncü taraf çerez desteğinin sonlandırılmasıyla ilgili daha fazla gecikme yaşanmaması için istek | Chrome'un üçüncü taraf çerezlerine yönelik desteğini gecikmeden sonlandırmasını isteyen bazı paydaşlardan ve Özel Korumalı Alan teknolojilerini test etmek ve benimsemek için daha fazla zamana ihtiyaç olduğunu düşünen diğer paydaşlardan geri bildirim aldık. Teknolojilerin karmaşıklığı ve ekosistem için doğru işlemleri yapmanın önemi göz önüne alındığında, sorumlu bir şekilde ilerlemeye kararlıyız. Sektörden ve düzenleyici kurumlardan gelen geri bildirimler bu süreçte kritik öneme sahipti. |
| Üçüncü taraf çerez desteğinin sonlandırılmasına ilişkin zaman çizelgeleri | Üçüncü taraf çerezlerinin desteğinin sonlandırılmasının ertelenmesi ve API'leri test etmek için daha fazla süre verilmesi talepleri. | Chrome'un üçüncü taraf çerezlerine yönelik desteğini gecikmeden sonlandırmasını isteyen bazı paydaşlardan ve Özel Korumalı Alan teknolojilerini test etmek ve benimsemek için daha fazla zamana ihtiyaç olduğunu düşünen diğer paydaşlardan geri bildirim aldık. Teknolojilerin karmaşıklığı ve ekosistem için doğru işlemleri yapmanın önemi göz önüne alındığında, sorumlu bir şekilde ilerlemeye kararlıyız. Sektörden ve düzenleyici kurumlardan gelen geri bildirimler bu süreçte kritik öneme sahipti. |
| Doküman istekleri | Test, analiz ve uygulamanın nasıl yönetileceğini ayrıntılı olarak açıklayan daha fazla kaynak isteğinde bulunma | Geliştiricilerin mevcut materyallerimizi faydalı bulmasından memnuniyet duyuyoruz. Geliştiricilerin yeni teknolojilerin kendileri için nasıl yararlı olabileceğini anlamaya devam edebilmesi amacıyla önümüzdeki haftalar ve aylarda geliştirici çalışma saatleri ve teknik dokümanlar da dahil olmak üzere daha fazla materyal sunmaya kararlıyız.
Ayrıca, en iyi uygulamaları ve demoları paylaşmak için herkese açık harici geliştirici ofis saatleri oturumları düzenledik. Ayrıca, ürün ve mühendislik yöneticileriyle soru-cevap oturumları düzenleyerek canlı tartışma/soru olanağı sunduk. |
| Sektör uzmanlığı | Standart kuruluşlarıyla etkileşime geçen Chrome ekibi, gizlilik ve faydayı doğru şekilde dengelemek için gerekli reklam ekosistemi uzmanlığına sahip değil. | Büyük bir sorumluluğumuz olduğunun farkındayız ve bu konuda doğru kararı vermek için belirli geri bildirimlere ihtiyacımız var. Ayrıca hem gizliliği hem de etki düzeyini kritik ve gerekli tasarım ölçütleri olarak değerlendiririz. Web için Özel Korumalı Alan üzerinde çalışan ekibin reklam ekosisteminde toplam çalışma yılı sayısı yüzlerceyi aşıyor. |
Alakalı İçerik ve Reklamlar Gösterme
Konular
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Farklı paydaş türleri için yararlı olması | Sitelerin trafik düzeyine veya içeriğinin ne kadar uzmanlaştığına bağlı olarak, oluşturulan değer ve bu değerin dağıtımıyla ilgili endişeler dile getirildi. | API'nin yararlılığı testler aracılığıyla araştırılır. Chrome, sınıflandırmanın ve diğer parametrelerin test sonuçlarına göre değişmesini bekler. Sınıflandırmanın veya parametrelerin evrimi, eski sürümlerle uyumsuz değişiklikler gerektirmeyebilir. Ayrıca Chrome, üçüncü taraf çerez desteğinin sonlandırılmasından sonra geri bildirimlerin Topics API'nin gelişimini etkilemeye devam etmesini beklemektedir. |
| Sınıflandırma | Sektör paydaşları, sınıflandırmayı etkileme konusunda söz sahibi olmak ister. | Chrome, sınıflandırmayla ilgili katkılara açıktır. Chrome, sınıflandırmayı değiştirmeye yönelik yönetim modeli hakkındaki geri bildirimlere ve diğer sektör kuruluşlarının sınıflandırmayı uzun vadede geliştirme ve sürdürme konusunda nasıl daha aktif bir rol oynayabileceğine dair tartışmalara çok önem veriyor. |
| Yeterli tarama geçmişi yok | Kullanıcının en son hafta için 5 konu oluşturacak kadar tarama geçmişi yoksa arayanın önceki haftalarda gördüğü konuları gösterme önerisi | Mevcut tasarımımızda bu kullanıcılar rastgele seçilir. Geçmiş konularla olan ilişkiyi araştıracak ve bu konuyu dahil etme olasılığını değerlendireceğiz. Ancak, ilişkilerin olumsuz gizlilik etkileri olabileceğini de göz önünde bulundurmamız gerekiyor. |
| Topics'ı yayıncı adına çağırma | Üçüncü taraf servis sağlayıcılar Topics'i yayıncılarla paylaşabilir mi? | Evet, Topics'in bu şekilde kullanılmasını bekliyoruz. |
| Potansiyel saldırı vektörleri | Gürültüye neden olan konuları belirleme | Chrome, ekosistemdeki birçok kullanıcıdan gelen geri bildirimler doğrultusunda konuları filtrelemeyi ve gürültü eklemeyi tercih etti. Bu kararlar, gizlilik göz önünde bulundurularak alınmıştır. Amaç, bilgilere erişimi, aksi takdirde bu bilgilere erişemeyecek olan kullanıcılarla sınırlamak ve kullanıcılara makul bir inkar hakkı sunmaktır. Bu kararların, burada açıklanan saldırı vektörü gibi dezavantajları olduğunun farkındayız. Ancak gizlilik avantajlarının potansiyel risklerden daha ağır bastığına karar verdik. Bu kararla ilgili herkese açık tartışmalara açığız. |
| Kaynak denemesi uygunluğu | Bir kullanıcının Origin deneme sürümüne uygun olup olmadığını tespit etmenin bir yolu var mı? | Kullanıcı, geçerli bir deneme jetonu sağlayan bir web sayfasını ziyaret ediyor ve tarayıcısı denemenin etkinleştirildiği gruba dahil olsa bile, tarayıcı ayarları veya diğer faktörler nedeniyle kaynak deneme özelliğini kullanamayabilir.
Bu nedenle, bir kaynak deneme özelliğini kullanmaya başlamadan önce, özelliğin kullanılabilir olup olmadığını kontrol etmek için her zaman özellik algılama kullanılmalıdır. |
| Performans üzerindeki etkiler | Topics ile ilgili ek maliyet ve gecikme sorunları | Pahalı ve yavaş x-origin iFrame'lerden kaçınmaya yönelik yaklaşımlar ve Topics API'nin, konuların alınmasının tarama durumunu değiştirmemesi için birbirinden ayrılması önerisi hakkında geri bildirim istiyoruz. |
| Bölünmüş Topics API işlevi | API'nin üç farklı yönü üzerinde daha fazla kontrol sağlama | Kullanım alanını anlıyoruz ve bu sorunu GitHub'da çözmenin olası bir yolunu önerdik. Şu anda bu işlevin geliştirilip geliştirilmeyeceği konusunda ekosistemden daha fazla geri bildirim bekliyoruz. Devam eden tartışmayı burada bulabilirsiniz. |
| Sınıflandırıcı zaman çizelgesi ve dokümanları | Geliştiriciler sınıflandırıcı hakkında daha fazla bilgi istedi. | Sınıflandırıcı hakkında daha fazla bilgiyi burada bulabilirsiniz.
Ayrıca buradan da ulaşabilirsiniz. Ve buraya. |
| Kullanıcı denetimleri ve güvenlik | Belirli konular hassas gruplar için proxy olabilir ve kullanıcıların olumsuz sonuçları önlemek için daha fazla kontrole ihtiyacı vardır. | Topics, kullanıcı kontrolü ve şeffaflık açısından önemli bir adımdır. Kullanıcılar, konuları devre dışı bırakabilir, kendilerine atanan konuları inceleyebilir, konuları kaldırabilir ve belirli bir sayfada hangi şirketlerin kendi konularıyla etkileşimde bulunduğunu anlayabilir. Ayrıca kullanıcılar, tarama geçmişlerini silerek de Konularını etkileyebilir. Geliştiriciler tarafından önerilenler gibi daha gelişmiş kullanıcı kontrolleri hakkındaki tartışmaların devam etmesini memnuniyetle karşılıyoruz. Ancak bu hatada belirtilen endişelerin gerçekten ortadan kaldırıldığından emin olmamız gerekiyor (örneğin, Tarama Geçmişi'nden "yabancı dil eğitimi" konusunu oluşturan web sitelerini değil, yalnızca konuyu kaldırdığımızda kullanıcı tam olarak korunmaz). |
| prebid.js içeren sitelerde konuların kullanımı | Topics API, prebid.js içeren web sitelerinde kullanılabilir mi? | Kısaca yanıt vermek gerekirse evet, mümkündür. Daha fazla bilgiyi burada bulabilirsiniz. |
| Topics API'nin öneri widget'ında kullanılması | Topics API'yi Önerilen widget'ta (ör. Outbrain) kullanabilir miyiz? | API çağrıldıktan sonra alınan Topics'in kullanım alanını sınırlamıyoruz (bu, her geliştiricinin veri politikasına bağlıdır). |
| Gizlilik / Politika | Bazı üçüncü tarafların, konularını arayan herkesle paylaşıp paylaşmayacağı ve yanıtları arayana göre filtreleme amacı hakkında sorular. | Ekosistemdeki birçok kullanıcıdan gelen geri bildirimler doğrultusunda Chrome, bu tür bilgilere erişimi, aksi takdirde bu bilgilere erişemeyecek olan kullanıcılarla sınırlamak için bu tasarımı seçti. Elbette, Topics'i alan yayıncılar ve üçüncü taraflar, sitelerindeki taraflarla hangi bilgileri paylaşacaklarına kendileri karar verebilir. Bu tür paylaşımlar yapan geliştiricilerin, kullanıcılarına bu tür paylaşımlar konusunda şeffaf olmalarını ve onlara kontroller sunmalarını Chrome şiddetle önerir. |
| Gürültülü sinyaller | Zaman içinde% 5 oranında rastgele bir konu yayınlamak çok fazla gürültü / yanlış sinyal oluşturabilir. | Gürültü, kullanıcı gizliliğini korumak için önemli bir yöntemdir. Konuların yararlılığına kıyasla gürültü seviyeleri testler aracılığıyla incelenecektir. |
FLEDGE
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Test koordinasyonu | Performans ve gelir üzerindeki etkiyi test etme | FLEDGE performansı ve hem kaynak denemelerinde hem de genel kullanımda ekosistem testini en iyi şekilde nasıl destekleyebileceğimiz, herkese açık WICG toplantılarında aktif olarak tartışılıyor. |
| FLEDGE için Güvenilir Sunucu | Güvenilir sunucu ne zaman test için kullanılabilir? | Bu geri bildirim için teşekkür ederiz. FLEDGE'de güvenilir sunucuların kullanımıyla ilgili paylaşabileceğimiz daha ayrıntılı bir plan üzerinde aktif olarak çalışıyoruz. |
| Protokol standartlaştırma | SSP'ler ile DSP'ler arasında veri aktarımı için ilgi alanı grupları için ortak etiketler gibi ortak bir protokol olacak mı? | DSP'ler, SSP'ler ve daha geniş reklam ekosisteminden spesifikasyonun olası standartlaşmasıyla ilgili geri bildirimleri memnuniyetle karşılıyoruz. Şu anda ilk test için farklı yaklaşımları deneme sürecinde olduklarından doğrudan test iş ortaklarınızla çalışmanızı öneririz. Ayrıca, reklam ticareti kuruluşlarının, üye şirketleri için yararlı olması durumunda standartlaşma oluşturmak üzere görüşlerini paylaşmalarını teşvik ediyoruz ve bu kuruluşlarla çalışmaya devam etmeyi planlıyoruz. |
| Sıklık sınırı | Kampanya ve reklam grubunda kullanıcı başına sıklık kontrolleri. | FLEDGE, cihaz üzerinde açık artırmalar ve içeriğe dayalı / marka kampanyaları için de sıklık sınırlamasını destekleyecektir. Paylaşılan depolama alanı ve siteye özel sınırlar, ek sıklık sınırı kontrolleri için de kullanılabilir. |
| FLEDGE'in performansa etkisi | FLEDGE açık artırmasında yoğun hesaplama gerektiren teklif verenler | Chrome, site performansı üzerindeki olası etki hakkında geliştiricilerle aktif olarak görüşüyor. Chrome, test sırasında daha fazla bilgi edinme fırsatını memnuniyetle karşılar. |
| FLEDGE'i diğer özelliklerle test etme | Attribution Reporting API ve FLEDGE'deki etkinlik düzeyindeki raporlar nasıl bir araya gelecek? | Bu konu, yakın zamanda yapılan bir WICG/conversion-measurement-api görüşmesinde ele alındı. Ayrıntılı tutanağın bağlantısını burada bulabilirsiniz.
Toplantının özeti, çitli çerçeve reklam raporlaması için mevcut tasarımın, çitli çerçeve içinde oluşturulan bir kimliği bağlamsal bilgilerle ilişkilendirmeyi mümkün kıldığıdır. Bu nedenle, çitli çerçeve içinde oluşturulan etkinlik düzeyindeki raporlar, sunucuda aynı bağlama yönelik bilgilerle birleştirilebilir (1 yerine 2 sunucu tarafı birleştirme kullanılarak). |
| Gösterim sayımı | Alıcılar ve satıcılar arasında hangi gösterim sayma metodolojisinin kullanılması gerekir veya önerilebilir? | FLEDGE API, açık artırma sırasında satıcı ile alıcı arasında metodoloji uyumunu zaten desteklemektedir. Mevcut tasarımımızın ekosistem için neden işe yaramadığına dair geri bildirim olmadan alternatif uygulamalarla ilgili öneriler aldık. |
| Birden Çok Reklam Gösterme | Belirli bir çitli çerçevede bir açık artırmada birden fazla reklam gösterilip gösterilemeyeceği | Bu işlem şu anda bileşen reklamlar (bileşen açık artırmalarıyla karıştırılmamalıdır) aracılığıyla yapılabilir. Bunun için tüm reklamların aynı ilgi alanı grubunda olması gerekir. |
| "Satıcı Tanımlı Kitleler (SDA)" spesifikasyonu ve FLEDGE | FLEDGE, alıcıların reklam isteklerinde SDA'dan profil oluşturmasını engelleyen bir mekanizma olabilir mi? | FLEDGE, yayıncı ziyaretçilerinin hangi SDA'larda olduğunu zaten biliyorsa ve hedefleme aynı sitedeyse alakalı olmayan bilgi sızıntısını önlemek için tasarlanmıştır. FLEDGE'e yerleştirilmiş tüm korumalar kapsamında SDA'larda satın alma işlemini desteklemek önemliyse bir çözüm, satıcının SDA etiketlerini cihaz üzerinde açık artırmaya iletmesi ve alıcı tarafı reklam teknolojisinin, teklif verme mantığı "X Kitlesini satın almak istiyorum" olan kendi İlgi Alanı Grubunu oluşturması olabilir. |
| ABD doları dışındaki para birimleri için destek | FLEDGE'i ABD doları dışındaki para birimleriyle test etme desteği | Bu açıklama için teşekkür ederiz. Diğer para birimlerinin desteğini, özellik isteklerimiz listesine ekledik. Bu özelliğin çok yakında kullanıma sunulmasını umuyoruz. |
| Negatif ilgi alanı grubu hedefleme desteği | Negatif IG hedeflemesini destekleyen bir API: Reklamları yalnızca kullanıcı bir IG'ye ait değilse gösterir. | Desteklenmesi önerilen bazı seçenekler de dahil olmak üzere devam eden tartışmayı github sorununda bulabilirsiniz. |
| FLEDGE'de birden fazla STP | FLEDGE'de çok düzeyli açık artırmalar uygularken Google'ı tercih etme riski | FLEDGE'de birden fazla STP desteği, adil ve eşit bir rekabet ortamı sağlamak için eklenmiştir. Google, Taahhütler kapsamında Özel Korumalı Alan tekliflerini, reklamcılık ürün ve hizmetlerini kendi lehine tercih ederek rekabeti bozacak şekilde tasarlamamayı, geliştirmemeyi veya uygulamamayı taahhüt etmiştir. Google bu konuyu ciddiye alır ve paydaşların teknolojinin belirli yönleriyle ilgili endişelerini tartışmaya açıktır. Chrome, bileşen açık artırma mekanizmasını burada herkese açık olarak belgelemiştir. |
Dijital reklamları ölçme
İlişkilendirme raporları (ve diğer API'ler)
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Çok noktalı ilişkilendirme | Çok noktalı ilişkilendirme için destek isteyen yayıncılar | Mevcut çoklu temas ilişkilendirme yöntemleri, kullanıcının farklı web sitelerindeki gösterimlerini (ve dolayısıyla kimliğini) kesin olarak birbirine bağlamayı gerektirir. Sonuç olarak, mevcut haliyle bu işlev, siteler arası izleme olmadan temel reklam kullanım alanlarını desteklemeyi amaçlayan Özel Korumalı Alan'ın hedefleriyle uyumlu değildir. Bazı durumlarda, kullanıcıları tek tek izlemeden kredi atamasını yaklaşık olarak yapmak (ör. ağırlıklı, rastgele öncelikler kullanarak) mümkündür. |
| Gürültü oluşturma | Raporlardaki gürültü seviyeleriyle ilgili sorular | İlk denememiz, geliştiricilerin kendi epsilon değerlerini ayarlamalarına olanak tanır. Böylece, raporların gürültü düzeyine göre nasıl değiştiğini deneyimleyebilirler. Şu anda geliştiriciler epsilon=64'e kadar bir epsilon değeri seçebilir. Bunu özellikle geliştiricilerin API'leri test etmesini ve uygun epsilon değerleri hakkında bize geri bildirim vermesini kolaylaştırmak için yaptık.
Bu tür geri bildirimler için herkese açık bir istek de gönderdik. |
| Test koordinasyonu | Yerel test aracı, OT için kullanılabilir mi? | Evet, yerel test aracı, OT süresince kullanılabilir. Yerel test aracı, üçüncü taraf çerezleri kullanılabildiği sürece hata ayıklama raporlarıyla kullanılabilir. |
| Sorgu ergonomisi | Anahtarların toplu olarak sorgulanması | Bu değişikliğin, gizlilik maliyeti çok az veya hiç olmadan API ergonomisini iyileştirdiğini kabul ediyoruz. Bir öneride bulunacağız ve bu önerinin desteklenmeye değer olup olmadığı konusunda geniş bir fikir birliğine ulaşılıp ulaşılmadığını göreceğiz. |
| Küçük siteler için daha az doğru veriler | Daha küçük siteler veya kampanyalar daha az doğru veriler alabilir. | Chrome, gürültü tabanlı gizlilik korumalarının daha küçük veri dilimleri üzerinde daha fazla etkisi olduğunu bilir. Ancak daha uzun süreler boyunca toplama gibi yöntemler bu sorunu çözebilir. Ayrıca çok küçük veri dilimleri (ör. bir veya iki satın alma işlemi) temel alınarak elde edilen sonuçların reklamverenler için anlamlı olup olmadığı da net değildir. Chrome, kaynak denemesi sırasında test kullanıcılarını, bu konuda daha spesifik geri bildirim sunabilmek için çeşitli gizlilik ve gürültü parametreleriyle deneme yapma olanağından yararlanmaya teşvik eder. |
Gizli İzlemeyi Sınırlama
Kullanıcı aracısı başlığını kısaltma
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Bot koruması | UA-R'nin bot koruması üzerindeki etkisi | Bu geri bildirim için teşekkür ederiz. Gelecekteki tasarımlarımızı belirlemek için bot koruma yaklaşımları hakkında bilgi topluyoruz. |
| Dağıtım Bağımlılıkları | Yapılandırılmış kullanıcı aracısı (SUA) dağıtım bağımlılıkları | 101 ve sonraki sürümlerdeki Chrome kullanıcılarının% 100'ü için alt sürüm azaltma işlemini içeren "4. Aşama"yı kullanıma sunduk. Güncellemeyi buradan inceleyebilirsiniz. |
Kullanıcı Aracısı İstemci İpuçları
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Desteklenen tüm ipuçlarını listeleme | Bir tarayıcı için desteklenen tüm ipuçlarını programatik bir şekilde öğrenmek isteme. | Bu geri bildirim için teşekkür ederiz. Özellik isteğini değerlendiriyoruz. Bunun yaygın bir kullanım alanı olup olmadığını öğrenmek istiyoruz. |
| UA-CH ve User-Agent başlığının esnekliği | UA-CH, rfc7231 tarafından tanımlandığı üzere User-Agent başlığının sunduğu esnekliğe kıyasla fazlasıyla kuralcı. | Chrome, UA-CH üstbilgilerinin zorunlu niteliğini hem tarayıcılar arası birlikte çalışabilirlik hem de kullanıcı gizliliği koruması (yüksek entropi tanımlayıcıların keyfi olarak eklenmesini önleyerek) açısından UA dizenin esnekliğine kıyasla önemli bir iyileştirme olarak görüyor.
Diğer kullanıcıların da bu endişeyi paylaşıp geri bildirimde bulunmak istemesi ihtimaline karşı sorun açık kalacak. |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | UA-CH aracılığıyla kaybedilebilecek belirli özellikler: Tıklama yönlendirme izleyici ve sahte tıklamalar. | Ekip, bu olası sorunları sahtekarlık önleme ve ölçüm paydaşlarıyla birlikte araştırıyor. |
| Performans | Kritik-CH aracılığıyla ipucu alma gecikmesiyle ilgili endişeler var (ilk sayfa yüklemesinde). | Chrome, performansı artırmanın yollarını araştırıyor. |
Gnatcatcher (WIP)
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Gecikmeyle ilgili sorunlar | Ek atlama eklemek gecikmeyi etkileyebilir | İki atlamalı bir proxy kullanmayı düşünüyor ve kullanıcı gizliliği ile gecikme arasında doğru dengeyi bulmanın yollarını araştırıyoruz. Geri bildirimlerinizi bekliyoruz ve W3C forumlarında daha fazla tartışma yapmaktan memnuniyet duyarız. |
| Sahtekarlık ve bot koruması | Daha az gelişmiş ülkeler de dahil olmak üzere sahtekarlık ve bot koruması üzerindeki etkiler | IP adreslerini proxy olarak kullanma gibi anlamlı şekillerde kullanıcı gizliliğini iyileştirmenin yollarını ararken güvenlik temel bir şarttır. Saygın şirketlerle iş ortaklığı yapan iki atlamalı proxy, doğrulanabilir kullanıcı gizliliği sağlar. Ayrıca, kullanıcı güvenini aktarmaya yardımcı olacak yeni sinyaller için fikirler üzerinde çalışıyoruz. |
| Yerel gizlilik yasalarına uygunluk | Ülke düzeyinde coğrafi veri raporlaması, daha ayrıntılı yerel düzenlemelere uygunluğu zorlaştırıyor | Web sitelerinin yerel şartlara uymaya devam etmesini sağlayacak olası yaklaşımları içeren önerilen ilkelerimizi herkese açık olarak yayınladık. |
Siteler arası gizlilik sınırlarını güçlendirme
Birinci Taraf Gruplar
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Farklı paydaş türleri için yararlı olması | FPS'nin küçük ve büyük yayıncılar üzerindeki etkisi | Özel Korumalı Alan'ın birincil hedefi, mevcut uygulamaları siteler arası izleme mekanizmalarına dayanmayan çözümlerle değiştirerek kullanıcı gizliliğini iyileştirmektir. Bu çözümlerin, farklı tür ve büyüklükteki paydaşlar için olabildiğince geniş kapsamlı bir şekilde yararlı olmasını isteriz. Bu çözümlerin nasıl iyileştirilebileceğine dair spesifik ve uygulanabilir geri bildirimler bekliyoruz. Ayrıca, topluluğun tartışmaları ve testleri sayesinde bu çözümlerin gelişmeye devam etmesini umuyoruz. |
| Gizliliği iyileştirme | Aynı grupta çok fazla site olması, üçüncü taraf çerezleriyle benzer sonuçlara neden olabilir. | Bu geri bildirim için teşekkür ederiz. Doğru sınırların ne olabileceğini değerlendirirken hem kullanıcılara hem de geliştiricilere bu tür bir sınıra ulaşıldığında anlayabilecekleri bir yaklaşım veya sinyaller sunmaya çalışıyoruz. Henüz paylaşabileceğimiz belirli bir teklifimiz yok ancak çok yakında bunu yapmayı umuyoruz. |
| FPS için ekosistem desteği | Gizlilik CG dışında FPS geliştirmeye devam etmek için destek ve endişelerin toplanması | Birinci Taraf Kümeleri önerisinin PrivacyCG'de kalmasını tercih etsek de öneriyi WICG'de takip etmeye devam etmeyi umuyoruz. Birinci taraf kümelerin ve ele alınması amaçlanan kullanım alanlarının tartışılmaya devam etmesine yönelik çok sayıda destek beyanı da bizi cesaretlendirdi. Google, web'in kullanıcı gizliliğini koruyup ona saygı gösterecek şekilde büyümeye ve gelişmeye devam etmesini sağlayacak çözümler bulmaya kararlıdır. |
| Tarayıcı birlikte çalışabilirliği | Diğer tarayıcılar tarafından uygulama | Tarayıcı birlikte çalışabilirliğinin geliştiriciler için ne kadar önemli olduğunun farkındayız ve FPS'nin standartlaştırılması için diğer tarayıcılarla işbirliği yapmaya devam edeceğiz. |
| Gizlilik politikası ile ilgili yaygın şart | Tüm ürünler ve aynı grubun parçası olması gereken yargı alanlarında ortak bir gizlilik politikası sürdürmek mümkün değildir. | Chrome, politika şartlarımızı belirleme aşamasındadır ve bu geri bildirimi dikkate alacaktır. |
Fenced Frames API
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Belge isteği | Korumalı alana alınan iframe'lerle arasındaki farklar | Geri bildiriminiz ve öneriniz için teşekkür ederiz. GitHub'da bu konuyla ilgili bir tartışma sürüyor. Talebi tamamen değerlendirebilmek için bu tartışmadan net bir sonuç elde etmeyi umuyoruz. Herkese açık tartışmaya buradan erişebilirsiniz. |
| API'ler arası özellikler | Çitli çerçevelerde ilişkilendirme raporlaması için varsayılan destek | Çitli çerçevelerin "opak reklamlar modunda" varsayılan olarak Attribution Reporting API'ye izin verme önerisi hakkında geri bildirim istiyoruz. Bu konuyu faydalı bulan geliştiricilerin tartışmaya katılmasını öneririz. |
Shared Storage API
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Veri limitleri | Bölüm başına ne kadar veri depolanabileceğiyle ilgili bir kısıtlama olacak mı? | Evet, sınırlar olacaktır. Daha fazla bilgi için github sorununa bakın. Depolama alanı kotalarına ihtiyacımız var. Mevcut önerimiz, giriş başına 4 KB boyut sınırı, her biri 1024 char16_t karakterle sınırlı olacak anahtar ve değerler ve bir kaynak kapasitesi dolduğunda ek girişlerin kaydedilmesini önleyen bir mekanizmayla 10.000 girişlik kaynak girişi sınırı belirlemektir. Burada önerilen belirli sınırlar hakkında geri bildirim almak için aktif olarak çalışıyoruz. |
| Kullanıcı şeffaflığı | Veri kaynakları ve veri kullanımı için kullanıcı şeffaflığı | Bu geri bildirim için teşekkür ederiz. Bu yaklaşımın, üzerinde çalışılması gereken bir konu olduğunu düşünüyoruz. Özellikle de bunu kullanıcılara yeterli şeffaflık sunacak şekilde yapıp yapamayacağınızı değerlendiriyoruz. |
CHIPS
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Benimseme engellerini kaldırma | CHIPS, ana makine adına bağlı mı olmalı? (alan adı yok koşulu) | OT katılımcılarının bu şartın ek karmaşıklık oluşturduğu ve CHIPS'in benimsenmesine engel olduğu yönündeki geri bildirimleri doğrultusunda bu şartı OT'den kaldırıyoruz.
Bu şartı, standartları geliştirme süreci kapsamında Gizlilik Topluluk Grubu'nda buradan tartışacağız. |
| CHIPS için reklam kullanım alanları | CHIPS, tek bir sitedeki Ads kullanım alanları için kullanılabilir mi? | Bir sitedeki kullanıcı takibi izin verilen bir kullanım alanıdır. Bu kullanım alanını vurgulamak için geliştirici makalemizi güncelledik. |
| Kimlik doğrulaması yapılmış yerleşimler | Oturum açma durumu CHIPS ile korunuyor mu? | Oturum açmış olma durumu şu anda korunmuyor ancak CHIPS'in kullanım amacı bu değildir. Kimlik doğrulaması yapılmış yerleşik içeriklerin kullanım alanının farkındayız ve çözümler üzerinde çalışıyoruz. |
| Test koordinasyonu | Bölme işlemini test etmek için kullanıcının yapması gereken başka işlemler var mı? | OT jetonu geçerli ve ziyaret edilen sayfaların başlıklarında bulunduğu sürece, özellik kullanıcılar tarafından herhangi bir ek işlem gerektirmeden kullanılabilir. |
| Tarayıcı uyumluluğu | Diğer tarayıcıların, bölümlenmiş çerez özelliklerini nasıl ele aldığını anlamak için ilgi duyuyorsanız. | Chrome, tarayıcılar arasında çalışabilecek tasarımları ve uygulamaları belirlemek için W3C gibi herkese açık standartlar gruplarıyla çalışmaya devam etmektedir. |
FedCM
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Potansiyel saldırı vektörleri | Bağlantı dekorasyonu ve zamanlama saldırıları yoluyla olası saldırı vektörleri | Halkın görüşlerini toplamaya ve bu sorunu çözmenin olası yollarını araştırmaya devam ediyoruz. |
| Birden fazla IdP'ye izin veren kullanıcı deneyimi | Tek seferde yalnızca bir kimlik doğrulama hizmeti sağlayıcısı sunulabilir | Birden fazla kimlik doğrulama hizmeti sağlayıcıyı desteklemenin önemine inanıyoruz ve bu hizmet sağlayıcıları destekleme yöntemleri üzerinde aktif olarak çalışıyoruz. |
| İfade gücü | Tarayıcı, birleşik kimlik akışının bir kısmını oluşturduğundan IdP'lerin kullanıcılarına sunmak istediği tüm nüansları yakalamanın zor olması. | Chrome, marka özelleştirmeleri (ör. logolar, renkler) ve dize özelleştirmeleri (ör. "ile giriş yap" yerine "bu makaleye eriş") ekleme konusunda araştırma yapıyor.
Chrome, bu dengenin farkındadır ve hem mümkün olduğunca fazla alanı kapsayacak hem de mümkün olduğunca etkileyici olacak şekilde ekosistemle çalışmaya devam edecektir. |
| Uygulanabilirlik ve birlikte çalışabilirlik | Diğer tarayıcıların FedCM'yi benimsemeyeceği veya uygulamayacağı endişesi. | Chrome, FedID Topluluk Grubu'nda federasyon için ortak çözümler bulmak amacıyla diğer tarayıcı tedarikçileriyle de birlikte çalışmaktadır. |
| Kayıt akışında kişisel veri şartlarını kaldırma önerisi | (1) Kullanıcıya hangi kimlik sağlayıcıyı seçtiğini belirten, ancak e-postasının, resminin ve adının paylaşılacağı bilgisini vermeyen bir kullanıcı deneyimi, gizlilik açısından daha uygun olur.
(2) Kullanım alanları-kayıt, kullanıcı deneyimi ve IdP'den alınan iddiaların seçiminde yetersiz |
Bu konuda hemfikiriz ve geri bildirimi daha kullanıcı dostu ve gizlilik açısından daha uygun bir şekilde nasıl uygulayabileceğimizi araştırıyoruz. |
| Kullanıcının IdP ile etkileşimi | Risk eşiği aşıldığında kullanıcı ile IdP arasında doğrudan etkileşim gerekliliği | Bu geri bildirimi aktif olarak araştırıyoruz. |
Ağ Durumu Bölümlendirme
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Performans | Ağ durumunu bölümlendirmek, CDN'lere yapılan yoğun kaynak kullanan bağlantıların artmasına neden olabilir | Farklı olası anahtarlama şemalarının ölçülmesi de dahil olmak üzere Ağ Durumu Bölme'nin performans özelliklerini hâlâ araştırıyoruz. Performans, güvenlik ve gizlilik arasında henüz bir karar vermedik ve daha fazla veri toplamamız gerekiyor. |
Spam ve sahtekarlıkla mücadele etme
Trust Tokens API
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Yasal geri bildirim | Düzenleyicilerden uzun vadeli uygulanabilirlik hakkında net bir sinyal almadan Güven Jetonları'na zaman ve kaynak yatırımı yapma konusundaki endişeler | Hedefimiz, ekosistem için faydalı olacak teknolojiler geliştirmek. Bu nedenle, sektörden ve düzenleyici kurumlardan gelen geri bildirimler bu süreçte kritik önem taşıyor. Özel Korumalı Alan'ı geliştirirken ve Güven Ağı dahil olmak üzere teklifleri geliştiricilere sunarken dünya çapındaki düzenleyicilerle görüşmeye devam edeceğiz. Tüm yeni teknolojilerde olduğu gibi, şirketlerin karar verirken kendi mevzuat şartları değerlendirmelerini dikkate alması gerekir. |
| Lansman zamanlaması | Güven jetonları ne zaman genel kullanıma sunulacak? | Özel Korumalı Alan'daki mevcut tahminlerimizi privacysandbox.com adresindeki herkese açık zaman çizelgemizde paylaşıyoruz. Genel kullanıma sunma tarihiyle ilgili nihai kararımızı verdikten sonra bunu Chrome'un sürüm yayınlama süreçleri aracılığıyla herkese açık olarak yayınlar ve web sitesindeki zaman çizelgesini güncelleriz. |
| Güven jetonları ve diğer yöntemler | Gizli erişim jetonları gibi standartlaştırılmakta olan diğer jetonlar göz önüne alındığında güven jetonlarının rolü nedir? | Standartlaştırmayla ilgili tartışmalara katılıyoruz. Hedefimiz, her teknolojinin sunduğu farklı kullanım alanlarını etkinleştirirken diğer çalışmalarla mümkün olduğunca uyumlu olmaktır. Örneğin, Güven Jetonları ve Gizlilik Kartı Jetonları, Gizlilik Kartı protokolünü kullanır. |
| Veri limitleri | Sayfa başına jeton kullanma işlemi için maksimum 2 sağlayıcı sınırlayıcı olabilir | Belki de jeton kullanma erişimini bölümlere ayırarak şirketlerin daha fazla kullanıcı entropisi riski olmadan jeton kullanmalarına güvenli bir şekilde izin verebileceğimiz uzun vadeli seçenekler arıyoruz. |
| Erişim kısıtlamaları | Yalnızca onaylanmış (ve doğrulanmış/sahte olmayan yönlendiren) kaynaklar bir jetonun varlığını doğrulayabilir ve jetonu kullanabilir. | Jetonları kimlerin görebileceği ve kullanabileceğiyle ilgili yaklaşımları araştırıyoruz. |
| Cihaz desteği | JavaScript çalışma zamanı bağımlılıkları, belirli cihazlarda kullanımı sınırlar. TT desteği, diğer cihaz türlerinde de çalışacak şekilde genişletilebilir mi? | Gelecekteki geliştirmeler için bu seçeneği değerlendirebiliriz. W3C forumlarında geliştiricilerden daha fazla geri bildirim almak istediğimiz bir konudur. Ayrıca, HTTP başlığı tarafından tetiklenen jeton kullanma işlemiyle ilgili olarak geri bildirimlerinizi beklediğimiz açık bir sorun da var. |
| Kullanım alanları | Güven jetonlarının doğru kullanım alanlarının ne olduğu net değil. Amaçlanan kullanımlar konusunda netlik olmaması | Amacımız, sahtekarlık önleme alanındaki yenilikleri kolaylaştırmak ve her şirketin güven jetonlarıyla özel teknikler kullanabileceğini anlamak. Bu nedenle, amaçlanan kullanımlar konusunda kesin bir tavır takınmadık. Ancak, deneme yapmayı veya özelliği kullanmaya başlamayı düşünen iş ortakları için başlangıç noktası olarak daha fazla örnek içerecek şekilde dokümanlarımızı genişleteceğiz. |
| Güven Jetonu Kapsamı | Bu "trust-token-redemption" özellik politikasının kaldırılması, güven jetonu kapsamını önemli ölçüde artıracaktır. | OT'den geri bildirim toplarken ve sonraki adımlarla ilgili kararlar alırken bu durumu göz önünde bulunduruyoruz. |
| Kartı veren kuruluş güveni | Güven jetonu yayınlayan web sitelerine neden güvenmeliyiz? | Kart çıkarıcı olma konusunda herhangi bir kural yoktur. Herkes kart çıkarabilir. Yayıncıların yalnızca güvendikleri sağlayıcılarla çalışması beklenir. Ayrıca, reklam ekosistemindeki diğer yasal aktörler, şüpheli veya bilinmeyen sağlayıcılarla ilişkili trafiği zaman içinde indirimli fiyattan satın alır (veya satın almayı durdurur). |
| Üçüncü taraf yerleşik hizmetleri | Üçüncü taraf yerleşik hizmetleri güven jetonlarını kullanabilir ve/veya isteyebilir mi? | Evet, üçüncü taraf yerleşik hizmetleri güven jetonu yayınlayabilir ve kullanabilir. |
| Kart veren kuruluş ekosistemi | Güven sinyalleri diğer şirketlerle paylaşılabilirse daha fazla fayda elde edilebilir. | Güven jetonları, düşük düzey bir primitif olarak tasarlanmıştır ve güven/itibar sinyallerini paylaşmak için işbirliği yapan verenler/kullanıcılar tarafından kullanılabilir. |
| Bakım masrafları | Güven jetonu işlemlerinin temel aldığı şifreleme uygulaması, Google'ın tek yöneticisi olduğu BoringSSL'dedir. Kitaplığın bakımı nasıl yönetilecek? | Güven rozetleri, diğer kitaplıklarda da uygulanabilecek standartlaştırılmış kriptografik işlemlere (Gizlilik Geçişi protokolüne bakın) dayanır. Geliştiricilerin, tercih ettikleri kitaplıklarda bu işlemler için destek istemelerini/geliştirmelerini/desteği sürdürmelerini öneririz. |
| Bakım masrafları | Protokol sürümlerinin ne kadar süreyle destekleneceği net değil | Protokol sürümleri için beklenen destek zaman aralıkları hakkında daha fazla ayrıntı geliştirmeyi ve bunları belgelemeyi planlıyoruz. |
| Kartı veren kuruluş sınırları | Zincirin daha alt kısmındaysanız Güven Ağı anahtarlarını yürütme fırsatınız olmayabilir. | Daha fazla kuruluş güven jetonlarını kullanmaya başladıkça bu tür zamanlama dinamiklerinin giderek daha fazla kullanıldığını görüyoruz ve olası çözümleri araştırıyoruz. Daha önce de belirtildiği gibi, şirketlerin daha fazla kullanıcı entropisi riski almadan jetonları güvenli bir şekilde kullanmasına izin verebileceğimiz uzun vadeli seçenekler arıyoruz. Bu sayede sayfadaki konumun veya yükleme sırasının önemi en aza indirilebilir. |
Geliştirme Aşamasında Yeni Sahtekarlık Önleme Çözümleri
| Feedback Theme
(Yaygınlığa göre sıralanmıştır) |
Soru ve Endişeler Özeti | Chrome Yanıtı |
| Cihaz Bütünlüğü Onay Sinyalleri | Platformlar tarafından onaylanan ve web'de kullanıma sunulan cihaz bütünlüğü sinyallerini takip etmek için genellikle güçlü destek | Geri bildirim toplamaya ve herkese açık tasarım ve iterasyon yoluyla öneriyi hayata geçirmeye devam edeceğiz. |
| Cihaz Bütünlüğü Onay Sinyalleri | Yeni sinyaller aracılığıyla ne kadar kullanıcı entropisi aktarılabileceği ve belirli kullanım alanlarının (ör. kullanıcının bankasına giriş yapması) daha yüksek entropi sinyallerini haklı gösterip gösteremeyeceğiyle ilgili sorular. | Kullanıcı gizliliğini korumak için mümkün olduğunca az kullanıcı entropisi içeren yüksek değerli sinyaller sağlamaya çalışıyoruz. |
| Cihaz Bütünlüğü Onay Sinyalleri | Bu sinyal, eski cihazlara veya açık kaynak/değiştirilmiş platformlara erişimi sınırlar mı? | Geliştirme sürecindeki temel ilke olarak evrensel erişime dikkat edilmesi gereken yeni sinyaller vardır. Bu sinyaller, kuluçka sürecine devam ederken önceden ele alınması gereken önemli sorulardır. |
| Cihaz Bütünlüğü Onay Sinyalleri | Yeni sinyallerin, güvenlik ve sahtekarlık önleme şirketlerinin tarayıcıya ve platformlara aşırı derecede güvenmesine neden olup olmayacağı konusunda bazı endişeler vardı.
|
Her yeni sinyal, tarayıcıdan "güven" göstergesi olarak değil, ek veri olarak değerlendirilmelidir. Güvenlik şirketlerinin, ek bir giriş olarak cihaz kimlik doğrulamasını kullanarak kendi özel verilerini, modellerini ve karar motorlarını kullanmaya devam etmesini bekliyoruz. Yeni sinyallerin, ekosistem genelindeki tespit çalışmalarını iyileştireceğini ve sahtekarlığın yapılmasını zorlaştıracağını umuyoruz. |
| Çerez Yaşı İşareti | İlginç bir kavram ancak geçerli kullanım alanları hakkında daha fazla araştırma yapılması gerekiyor. | İlgi düzeylerine bağlı olarak Chrome, bu kavramla ilgili daha fazla fikir üretebilir ve gelecekteki ekosistem geri bildirimleri için bu fikirleri bir açıklama metnine dönüştürebilir. |
| Sahtekarlık Önleme İçin Güvenilir Sunucular | İlginç bir kavram ancak geçerli kullanım alanları hakkında daha fazla araştırma yapılması gerekiyor. | İlgi düzeylerine bağlı olarak Chrome, bu kavramla ilgili daha fazla fikir üretebilir ve gelecekteki ekosistem geri bildirimlerine yönelik bir açıklama metni oluşturabilir. |