Özel Korumalı Alan teklifleri ve Chrome'un yanıtları hakkında alınan ekosistem geri bildirimlerini özetleyen, 2022 Ç2 için üç aylık rapor.
Google, CMA'ya olan taahhütlerinin bir parçası olarak, Özel Korumalı Alan teklifleri için paydaş etkileşimi süreciyle ilgili üç aylık raporları kamuya açık bir şekilde sunmayı kabul etmiştir (Taahhütler'ün 12 ve 17(c)(ii) paragraflarına bakın). Bu Özel Korumalı Alan geri bildirim özet raporları, geri bildirim genel bakışı bölümünde listelenen ve bunlarla sınırlı olmamak üzere Chrome'un çeşitli kaynaklardan aldığı geri bildirimler toplanarak oluşturulur: GitHub Sorunları, privacysandbox.com adresinde kullanıma sunulan geri bildirim formu, sektörden paydaşlarla toplantılar ve web standartları forumları. Chrome, ekosistemden alınan geri bildirimleri memnuniyetle karşılar ve öğrendiklerini tasarım kararlarına entegre etmenin yollarını aktif olarak araştırır.
Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanmasıyla ve azalan düzende düzenleyerek yapılır. Yaygın geri bildirim temaları; herkese açık toplantılarda ele alınan tartışma konuları (W3C, PatCG, IETF), doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden sıklıkla sorulan sorular incelenerek belirlenmiştir.
Daha net açıklamak gerekirse web standardı kuruluş toplantıları için toplantı notları incelendi ve doğrudan geri bildirim sağlamak amacıyla Google'ın bire bir paydaş toplantılarıyla ilgili kayıtları, tek tek mühendisler tarafından alınan e-postalar, API posta listesi ve genel geri bildirim formu dikkate alındı. Daha sonra Google, her bir API ile ilişkili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli destek faaliyetlerinde yer alan ekipler arasında koordinasyon sağladı.
Chrome'un geri bildirimlere verdiği yanıtların açıklamaları; yayınlanan SSS'lerden, paydaşlar tarafından dile getirilen sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama alıştırmasının amaçları doğrultusunda, özel olarak bir pozisyonun belirlenmesinden alınmıştır. Geliştirme ve test çalışmalarının şu andaki odaklandığı konuları ele aldık. Özellikle Topics, Fledge ve Attribution Reporting API'leriyle ilgili sorular ve geri bildirimler alındı.
Geçerli raporlama döneminin bitiminden sonra alınan geri bildirimde henüz Chrome yanıtı dikkate alınmamış olabilir.
Kısaltmalar sözlüğü
- ÇİPLER
- Bağımsız Bölümlendirilmiş Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Birleştirilmiş Kimlik Bilgisi Yönetimi
- FPS
- Birinci Taraf Gruplar
- IAB
- İnteraktif Reklamcılık Bürosu
- IdP
- Kimlik Sağlayıcı
- IETF
- İnternet Mühendisliği Görev Gücü
- YA
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- UZ
- Kaynak Denemesi
- PatCG
- Özel Reklamcılık Teknolojisi Topluluğu Grubu
- RP
- Bağlı Taraf
- STP
- Arz Tarafı Platformu
- TEE
- Güvenilir Yürütme Ortamı
- UA
- User Agent dizesi
- UA-CH
- Kullanıcı Aracısı İstemci İpuçları
- W3C
- World Wide Web Konsorsiyumu
- WIPB
- Hasta IP Körlüğü
Genel geri bildirim, belirli bir API/Teknoloji yok
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Daha net zaman çizelgeleri | Özel Korumalı Alan teknolojileri için daha net ve ayrıntılı sürüm planları. | privacysandbox.com adresinde dağıtım programıyla ilgili mevcut planlarımızı oluşturuyor ve her ay güncelliyoruz. Bu testlerde hem Chrome hem de web geliştiricileri için olan geliştirme süresi ve yeni teknolojileri test edip benimsemek için gereken zamanda geniş ekosistemden aldığımız geri bildirimler dikkate alınır. Her teknoloji, testten yayınlamaya (lansman) kadar birden çok adımdan geçer. Her adımın zamanlaması, önceki adımda öğrendiğimiz ve ele aldığımız bilgilerle belirlenir. Şu an için taahhüt edilmiş sürümümüz olmasa da privacysandbox.com adresinden herkese açık zaman çizelgemizi güncelleyeceğiz. |
| Farklı paydaşlar için yararlılık | Özel Korumalı Alan teknolojilerinin büyük geliştiricilerin lehine olduğuna ve niş (daha küçük) sitelerin, genel (daha büyük) sitelere kıyasla daha fazla katkıda bulunduğuna dair endişeler. | Bazı geliştiricilerin, Özel Korumalı Alan teknolojilerinin etkisiyle ilgili endişeleri olduğunu biliyoruz. Google, Özel Korumalı Alan tekliflerini, Google'ın kendi işletmesini tercih ederek rekabeti sarsacak şekilde tasarlamamak veya uygulamamak, dijital reklamcılıkta, yayıncılar ve reklamverenler üzerindeki rekabeti ve gizlilik ile kullanıcı deneyimi üzerindeki etkileri dikkate almak konusunda CMA'ya taahhüt verir. Çalışmalarımızın bu taahhütlere uygun olmasını sağlamak için CMA ile yakın bir şekilde çalışmaya devam ediyoruz.
Özel Korumalı Alan testleri devam ederken değerlendireceğimiz temel sorulardan biri, yeni teknolojilerin farklı paydaş türleri için nasıl performans gösterdiğidir. Bu açıdan, teknik tasarımları daha da iyileştirmemize yardımcı olabilecek spesifik ve harekete geçirici geri bildirimler geri bildirim açısından çok önemlidir. |
| Üçüncü taraf çerezleri için desteğin sonlandırılmasıyla ilgili zaman çizelgeleri | Üçüncü taraf çerezlerinin kullanımdan kaldırılmasında daha fazla gecikmeyi önlemek için istekler | Bazı paydaşlar Chrome'un üçüncü taraf çerezlerinin desteğini gecikmeden sonlandırmasını istiyor. Ayrıca, Özel Korumalı Alan teknolojilerini test etmek ve benimsemek için daha fazla zamana ihtiyacı olduğuna inanan bazı paydaşlarla da görüştük. Teknolojilerin karmaşıklığı ve işleri doğru yürütme ekosisteminin önemi göz önünde bulundurulduğunda, sorumlu bir şekilde ilerlemeyi taahhüt ediyoruz. Sektörden ve düzenleyici kurumlardan gelen geri bildirimler bu süreçte kritik önem taşıyor. |
| Üçüncü taraf çerezleri için desteğin sonlandırılmasıyla ilgili zaman çizelgeleri | Üçüncü taraf çerezlerinin kullanımdan kaldırılmasını geciktirme ve API'leri test etmek için daha fazla süre sağlama istekleri. | Bazı paydaşlar Chrome'un üçüncü taraf çerezlerinin desteğini gecikmeden sonlandırmasını istiyor. Ayrıca, Özel Korumalı Alan teknolojilerini test etmek ve benimsemek için daha fazla zamana ihtiyacı olduğuna inanan bazı paydaşlarla da görüştük. Teknolojilerin karmaşıklığı ve işleri doğru yürütme ekosisteminin önemi göz önünde bulundurulduğunda, sorumlu bir şekilde ilerlemeyi taahhüt ediyoruz. Sektörden ve düzenleyici kurumlardan gelen geri bildirimler bu süreçte kritik önem taşıyor. |
| Belge talepleri | Test, analiz ve uygulamanın nasıl yönetileceğini açıklayan daha fazla kaynak isteği. | Geliştiricilerin mevcut materyallerimizi faydalı bulmalarını takdir ediyoruz. Geliştiricilerin yeni teknolojilerin kendilerine nasıl fayda sağlayabileceğini anlamaya devam edebilmesi için önümüzdeki haftalarda ve aylarda geliştirici ofis saatleri ve teknik dokümanlar da dahil olmak üzere daha fazla materyal sağlamaya kararlıyız.
Ayrıca, en iyi uygulamaları ve demoları paylaşmak için herkese açık geliştirici Ofis Saatleri oturumları düzenledik. Ayrıca, canlı tartışma/soruların sorulması için Ürün ve Mühendislik liderleriyle Soru-Cevap oturumları da düzenledik. |
| Sektör uzmanlığı | Standartlarla ilgilenen Chrome ekibi, gizlilik ile faydayı doğru bir şekilde dengelemek için gereken reklam ekosistemi konusunda uzman değildir. | Büyük bir sorumluluğumuz olduğunun farkındayız ve bu doğrultuda geri bildirim almak için belirli geri bildirimlere ihtiyacımız var. Ayrıca gizliliğin ve etkililiğin de kritik ve gerekli tasarım kriterleri olduğunu düşünüyoruz. Web İçin Özel Korumalı Alan üzerinde çalışan ekip genelinde, reklam ekosisteminde çalışılan toplam yıl sayısı yüzlerce yılı bulmakta. |
Alakalı İçerik ve Reklamlar Gösterin
Konular
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Farklı paydaşlar için yararlılık | Siteler için oluşturulan değerin ve bu değerin trafik düzeylerine veya içeriklerinin ne kadar uzmanlaştığına bağlı olarak dağıtılmasıyla ilgili endişeler vardır. | API'nin kullanışlılığı testlerle keşfedilecektir. Chrome, sınıflandırmanın ve diğer parametrelerin test sonuçlarına göre değişmesini bekler. Sınıflandırma veya parametrelerin evrimi, geriye dönük uyumsuz değişiklikler gerektirmeyebilir. Ayrıca Chrome, üçüncü taraf çerezleri için desteğin sonlandırılmasından sonra da geri bildirimlerin Topics API'nin gelişimini etkilemeye devam etmesini beklemektedir. |
| Sınıflandırma | Sektör paydaşları taksonomiyi etkileme konusunda söz sahibi olmak ister. | Chrome, sınıflandırmayla ilgili bilgi almaya devam etmektedir. Chrome, sınıflandırmayı değiştirmeyle ilgili yönetim modeli hakkında geri bildirim almak ve taksonominin geliştirilmesinde ve sürdürülmesinde diğer endüstri kuruluşlarının nasıl daha aktif rol oynayabileceğini tartışmaktadır. |
| Tarama geçmişi yeterli değil | Kullanıcının son hafta için 5 konu oluşturmak üzere yeterli tarama geçmişi yoksa, arayanın önceki haftalarda gördüğü konuları göstermeye yönelik teklif | Mevcut tasarımımızda bunlar rastgele seçildi. Geçmiş konularla olan ilişkiyi araştıracağız ve bunun mümkün olup olmadığını değerlendireceğiz. Ancak korelasyonların dikkate alınması gereken olumsuz gizlilik değerlendirmeleri olabilir. |
| Bir yayıncı adına Topics'e çağrı yapma | Üçüncü taraf servis sağlayıcı Topics'i bir yayıncıyla paylaşabilir mi? | Evet, Topics'in bu şekilde kullanılmasını bekliyoruz. |
| Potansiyel saldırı vektörleri | Gürültülü konuları belirleme | Ekosistemdeki birçok kişiden gelen geri bildirimlere dayanarak Chrome, konuları filtrelemeyi ve fazla dikkat çekmeyi seçti. Bu kararlarda gizlilik göz önünde bulundurularak alınmıştır. Amacı, bilgilere erişimi, bu bilgilere erişimi olmayan kullanıcılarla sınırlamak ve kullanıcılara makul şekilde inkâr edilebilirlik yol açmaktır. Bu kararların, burada özetlenen saldırı vektörü gibi dezavantajları olduğunun farkındayız. Ancak değerlendirmemiz, gizlilikle ilgili avantajların potansiyel risklerden ağır bastığını gösteriyor. Bu kararla ilgili herkesin tartışılmasını rica ediyoruz. |
| Kaynak Deneme için uygunluk | Kullanıcının kaynak denemesi için uygun olup olmadığını tespit etmenin bir yolu var mı? | Geçerli bir deneme jetonu sağlayan bir web sayfasını ziyaret eden ve tarayıcısı denemenin etkin olduğu gruba dahil olan bir kullanıcı, tarayıcı ayarları veya diğer faktörler nedeniyle kaynak denemesi özelliğini kullanamayabilir.
Bu nedenle, özelliği kullanmadan önce kaynak denemesi özelliğinin olup olmadığını kontrol etmek için her zaman özellik algılama kullanılmalıdır. |
| Performansa etkileri | Topics ile ilgili genel gider ve gecikme sorunları | Pahalı ve yavaş x kaynağı iframe'lerinden kaçınmaya yönelik yaklaşımlar ve konu almanın göz atma durumunu değiştirmeyecek şekilde Topics API'nin anlaşılmasını engelleme teklifi için geri bildirim istiyoruz. |
| Split Topics API işlevi | API'nin üç farklı özelliği üzerinde daha fazla kontrol sağlama | Kullanım alanını anlıyor ve bu sorunu GitHub'da çözmek için olası bir yol önerdik. Şu anda ekosistemden, işlevin oluşturulup oluşturulmayacağı konusunda daha fazla geri bildirim bekliyoruz. Devam eden tartışmaları burada bulabilirsiniz. |
| Sınıflandırıcı zaman çizelgesi ve belgeler | Geliştiriciler sınıflandırıcı hakkında daha fazla bilgi talep ettiler. | Sınıflandırıcı hakkında herkese açık daha fazla bilgiyi burada sağladık.
Ayrıca burada da Buradan da yararlanabilirsiniz. |
| Kullanıcı kontrolleri ve güvenliği | Belirli konular, hassas gruplar için proxy olabilir ve kullanıcıların olumsuz sonuçları önlemek için daha fazla kontrole ihtiyacı olabilir. | Konular, kullanıcı kontrolü ve şeffaflık açısından atılmış önemli bir adımdır. Kullanıcılar konuların kapsamı dışında kalmayı seçebilir, kendilerine atanan konuları inceleyebilir, konuları kaldırabilir ve belirli bir sayfadaki konularla hangi şirketlerin etkileşimde bulunduğunu anlayabilir. Ayrıca, kullanıcılar tarama geçmişlerini silerek Konular'ı da etkileyebilir. Geliştiriciler tarafından önerilenler gibi daha gelişmiş kullanıcı denetimleriyle ilgili olarak devam eden tartışmalara devam ediyoruz. Ancak, bu hatada belirtilen endişelerin gerçekten riskleri ortadan kaldırdığından emin olmamız gerekiyor (örneğin, yalnızca Konu "yabancı dil çalışması"nı kaldırmak, ancak Göz Atma Geçmişi'nden Konuyu oluşturan web sitelerini kaldırmamak kullanıcıyı tam olarak korumaz). |
| Prebid.js içeren sitelerde konuların kullanımı | Topics API, prebid.js içeren web sitelerinde kullanılabilir mi? | Kısa cevap evet. Daha fazla bilgiyi burada bulabilirsiniz. |
| Öneri widget'ında Topics API kullanımı | Önerilen widget'ta (ör. Outbrain) Topics API'yi kullanabilir miyiz | API çağrıldıktan sonra alınan Topics'in kullanım alanını sınırlamayız (bu, her geliştiricinin veri politikasına bağlıdır). |
| Gizlilik / Politika | Konularını arayan kişiyle paylaşacak bazı üçüncü taraflar olduğunda yanıtları arayana göre filtreleme amacıyla sorular. | Ekosistemdeki birçok kişiden gelen geri bildirimler doğrultusunda Chrome bu tasarımı, bilgiye erişimi başka şekilde bu tür bilgilere erişemeyecek olanlarla sınırlamak için seçmiştir. Elbette Topics'i alan yayıncılar ve üçüncü taraflar, sitelerindeki taraflarla hangi bilgileri paylaşacaklarına kendileri karar verebilirler. Bu tür bir paylaşım yapmaları durumunda Chrome, bu tür paylaşımlar konusunda kullanıcılarına karşı şeffaf olmalarını kesinlikle önerir ve gerekli denetimleri kullanıcılara sunar. |
| Gürültülü sinyaller | Rastgele bir konuyu zamanın% 5'inde sunmak çok fazla parazit / yanlış sinyal oluşturabilir. | Gürültü, kullanıcı gizliliğini korumak için önemli bir yöntemdir. Konuların gürültü düzeyleri ve faydaları testlerle incelenecektir. |
FLEDGE
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Test koordinasyonu | Performans ve gelir etkisi testi | Herkese açık WICG toplantılarında, FLEDGE performansı ve Kaynak Denemeleri ve genel kullanıma sunma sırasında ekosistem testlerini en iyi nasıl destekleyebileceğimizi etkin bir şekilde tartışacağız. |
| FLEDGE için Güvenilir Sunucu | Güvenilir Sunucu test için ne zaman kullanıma sunulacak? | Bu geri bildirim bizim için çok değerlidir. FLEDGE'de güvenilir sunucuların kullanımıyla ilgili olarak paylaşabileceğimiz daha ayrıntılı bir plan üzerinde aktif olarak çalışıyoruz. |
| Protokol standartlaştırma | STP'ler ve TTP'ler arasında veri aktarımı için ortak bir protokol (ör. ilgi alanı grupları için ortak etiketler) olacak mı? | Spesifikasyonların potansiyel standartlaştırılmasıyla ilgili TTP'lerden, STP'lerden ve genel olarak reklam ekosisteminden gelen geri bildirimleri almaktan memnuniyet duyarız. Şu anda ilk testler yapmak amacıyla, farklı yaklaşımları deneme sürecinde oldukları için test iş ortaklarınızla doğrudan çalışmanızı öneririz. Ayrıca, reklam ticareti örgütlerinin, üye şirketleri için yararlı olması durumunda standartlaştırma oluşturma konusunda da fikir birliğine varmalarını teşvik ediyor ve onlarla çalışmaya devam etmeyi planlıyoruz. |
| Sıklık sınırı | Kampanya ve reklam grubundaki kullanıcı başına sıklık kontrolleri. | FLEDGE, cihaz üzerinde açık artırmalar ve içeriğe dayalı kampanyalar / marka bilinci oluşturma kampanyaları için sıklık sınırını da destekler. Ek sıklık sınırı kontrolleri için paylaşılan depolama alanı ve siteye özel sınırlar da kullanılabilir. |
| FLEDGE'in performans üzerindeki etkisi | FLEDGE açık artırmasında işlem açısından yoğun teklif verenler | Chrome, site performansı üzerindeki olası etkilerinin geliştiricilerle etkin görüşmelerine devam ediyor. Chrome, test sürecinde 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 birlikte kullanılır? | Bu konu, kısa süre önce yapılan bir WICG/conversion-measurement-api çağrısında ele alınmıştı. Ayrıntılı dakikaların bağlantısı burada yer alıyordu.
Toplantının özeti, Fenced Frames Ad Reporting'in mevcut tasarımıyla Kısıtlanmış Çerçeve içinde oluşturulan bir kimliğin bağlamsal bilgilerle ilişkilendirilebilmesini sağlar. Dolayısıyla, Kısıtlanmış Çerçeve içinde oluşturulan etkinlik düzeyindeki raporlar, sunucudaki aynı bağlamsal 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ı gerektiği veya kullanılması gerektiği | FLEDGE API, açık artırma sırasında satıcı ve alıcı arasındaki metodolojinin uyumlu hale getirilmesini zaten desteklemektedir. Mevcut tasarımımızın ekosisteme neden uygun olmadığıyla ilgili geri bildirim içermeyen alternatif uygulamalarla ilgili öneriler aldık. |
| Birden Fazla Reklam Görüntüleme | Belirli bir Kısıtlanmış Çerçeve içinde bir açık artırmada birden fazla reklam görüntülenip görüntülenemeyeceği | Bu, şu anda bileşen reklamlar aracılığıyla mümkündür (bileşen açık artırmalarıyla karıştırılmamalıdır). 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 haline gelebilir mi? | FLEDGE, yayıncının ziyaretçilerinin hangi SDA'larda olduğunu zaten bildiği ve aynı site hedeflediği durumlarda alakalı olmayan bilgi sızıntılarını önlemek için tasarlanmıştır. FLEDGE'de yerleşik olan tüm korumalar kapsamında SDA'larda satın almanın desteklenmesi önemliyse çözümlerden biri, satıcının SDA etiketlerini cihaz üzerinde açık artırmaya iletmesi ve teklif verme mantığı "X Kitlesini satın almak istiyorum" diyen kendi İlgi Alanı Grubunu oluşturmak için alıcı tarafı reklam teknolojisi olabilir. |
| ABD doları dışındaki para birimleri için destek | ABD doları dışındaki para birimleriyle FLEDGE'i test etme desteği | Bu açıklamaya değer veriyoruz ve özellik istekleri yığınımızda diğer para birimlerini desteklemeyi ekledik. Bu özelliğin çok yakında kullanıma sunulacağını umuyoruz. |
| Negatif İlgi Alanı Grubu hedefleme desteği | Negatif IG hedeflemeyi destekleyen bir API: Reklamları yalnızca kullanıcı bir IG'ye ait olmadığında gösterme. | GitHub sorununda, desteklenecek bazı seçenekler de dahil olmak üzere devam eden tartışmalar. |
| FLEDGE'de birden fazla STP | FLEDGE'de çok düzeyli açık artırmalar uygularken Google'ı tercih etme riski | Adil ve eşit bir oyun alanı sağlamak amacıyla FLEDGE'de birden fazla STP için destek eklenmiştir. Google, Taahhütler kapsamında Özel Korumalı Alan tekliflerini, kendi reklamcılık ürünlerini ve hizmetlerini tercih ederek rekabeti sarsacak şekilde tasarlamayacak, geliştirmeyecek veya uygulamayacağına dair taahhüt vermiştir. Google bu konuyu ciddiye alır ve paydaşların teknolojinin belirli yönleriyle ilgili endişelerini tartışmaya çok açıktır. Daha fazla bilgi edinmek isterseniz Chrome, bileşen açık artırma mekanizmasını burada herkese açık bir şekilde belgelemiştir. |
Dijital Reklamları Ölçme
Attribution Reporting (ve diğer API'ler)
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Çok noktalı ilişkilendirme | Çok noktalı ilişkilendirme için destek isteyen yayıncılar | Mevcut çok noktalı ilişkilendirme yöntemleri, kullanıcıların farklı web sitelerindeki gösterimlerini (ve dolayısıyla kimliklerini) belirli bir şekilde birbirine bağlamayı gerektirmektedir. Sonuç olarak bu işlev, şu anki biçimiyle siteler arası izleme olmadan temel reklam kullanım alanlarını desteklemeyi amaçlayan Özel Korumalı Alan'ın hedeflerine uymamaktadır. Bazı durumlarda, kredi ataması yaklaşık olarak (ör. ağırlıklı, rastgele öncelikler kullanılarak) kullanıcılar izlenmeden gerçekleştirilebilir. |
| Gürültü oluşturma | Raporlardaki gürültü düzeyleriyle ilgili sorular | İlk denememiz, geliştiricilerin raporlardaki parazit düzeyine göre nasıl değiştiğini görmeleri için kendi epsilon değerlerini belirlemelerine olanak tanımaktadır. Şimdilik, geliştiriciler epsilon=64 değerine kadar bir epsilon değeri seçebilir. Bunu özellikle, geliştiricilerin API'ları test etmesini ve uygun epsilon değerleriyle ilgili bize geri bildirim sağlamasını kolaylaştırmak için yaptık.
Ayrıca bu tür geri bildirimler için herkese açık talepte de bulunduk. |
| Test koordinasyonu | OT için yerel test aracı kullanılabilir mi? | Evet, yerel test aracı OT boyunca kullanılabilir. Üçüncü taraf çerezleri kullanılabildiği sürece, hata ayıklama raporlarıyla yerel test aracı kullanılabilir. |
| Sorgu Ergonomisi | Anahtarların toplamını sorgulamayı etkinleştir | Bu uygulamanın, API ergonomisini çok az veya ya da hiç gizlilik maliyeti olmadan iyileştirebileceğine karar verdik. Desteklemeye değer olduğuna dair geniş çapta bir fikir birliği olup olmadığına bakacağız. |
| 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üye dayalı gizlilik korumalarının küçük veri dilimlerinde daha büyük etkiye sahip olduğunun farkındadır. Ancak, daha uzun zaman dilimlerinde toplama gibi yöntemlerin bu sorunu çözmesi mümkündür. Ayrıca, çok küçük veri dilimlerine (örneğin, bir veya iki satın alma işlemi) dayanan sonuçların, reklamverenler için anlamlı olup olmadığı da net değildir. Kaynak denemesi sırasında Chrome, test kullanıcılarını çok çeşitli gizlilik ve parazit parametreleriyle deneme yapma olanağından yararlanmaya teşvik eder. Böylece kullanıcılar bu sorun hakkında daha net geri bildirim sağlayabilirler. |
Gizli Takibi Sınırla
Kullanıcı Aracısı Azaltma
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Bot koruması | UA-R'nin bot korumasına etkisi | Bu geri bildirim bizim için çok değerlidir. Gelecekteki tasarımlarımızı şekillendirmek için bot koruma yaklaşımları hakkında bilgi toplama sürecindeyiz. |
| Dağıtım Bağımlılıkları | Yapılandırılmış Kullanıcı Aracısı (SUA) dağıtım bağımlılıklarını ele alma | "4. Aşama"yı, yani alt sürümü düşürmeyi 101 ve sonraki sürümlerde Chrome kullanıcılarının% 100'üne sunduk. Güncellemeleri buradan inceleyebilirsiniz. |
Kullanıcı Aracısı İstemci İpuçları
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Desteklenen tüm ipuçlarını numaralandırma | Tarayıcı için desteklenen tüm ipuçlarını öğrenmek için programlı bir yöntem kullanmak isteme. | Bu geri bildirim için teşekkür ederiz ve özellik isteğini değerlendirme sürecindeyiz. Bunun yaygın bir kullanım alanı olup olmadığını öğrenmek istiyoruz. |
| UA-CH ve Kullanıcı Aracısı başlığının esnekliği | UA-CH, rfc7231'de tanımlanan kullanıcı aracısı başlığının sunduğu esneklikle karşılaştırıldığında gereğinden fazla kuralcıdır. | Chrome, UA-CH başlıklarının kuralcı yapısını, UA dizesinin esnekliğine göre önemli bir iyileştirme olarak görür. Bu açıdan, hem tarayıcılar arası birlikte çalışabilirlik hem de kullanıcı gizliliğinin korunması açısından yüksek entropili tanımlayıcıların rastgele eklenmesini önler.
Diğer kullanıcıların da bu sorunu paylaşması ve geri bildirimde bulunmak istemesi halinde sorun hâlâ açık. |
| UA-CH: Sahtekarlıkla ve Kötüye Kullanıma Karşı endişeler | UA-CH nedeniyle kaybolabilecek belirli özellikler: Tıklama yönlendirme izleyici ve sahte tıklamalar. | Ekip, sahtekarlıkla mücadele ve ölçüm paydaşlarıyla bu olası sorunları araştırıyor. |
| Performans | Kritik-CH (ilk sayfa yüklemesinde) üzerinden ipuçlarının alınmasında yaşanan gecikmeyle ilgili endişeler bulunmaktadır. | Chrome, performansı iyileştirmenin yollarını araştırıyor. |
Gnatcatcher (WIP)
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Gecikmeyle ilgili endişeler | Fazladan atlama eklemek gecikmeyi etkileyebilir | İki duraklı 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 ayrıntılı tartışmaları memnuniyetle bekliyoruz. |
| Sahtekarlık ve bot koruması | Sahtekarlık ve bot korumasına etkileri (daha az gelişmiş ülkeler dahil) | IP adreslerinde proxy kullanmak gibi anlamlı şekillerde kullanıcı gizliliğini iyileştirmenin yollarını aradığımızdan güvenlik temel bir şarttır. Saygın şirketlerle iş ortaklığı yapan iki duraklı proxy, doğrulanabilir kullanıcı gizliliği sağlar. Ayrıca, kullanıcı güvenini kaybetmemek için yeni sinyallerle ilgili fikirler üretiyoruz. |
| Yerel gizlilik yasalarına uygunluk | Ülke düzeyinde coğrafi veri raporlaması, daha ayrıntılı yerel yönetimlere uygunluğu zorlaştırır | Önerilen ilkelerimizi herkese açık olarak yayınladık. Bu ilkeler, web sitelerinin yerel şartlara uymasını sağlayacak olası yaklaşımları içerir. |
Siteler arası gizlilik sınırlarını güçlendirin
Birinci Taraf Gruplar
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Farklı paydaşlar için yararlılık | 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 dayalı olmayan çözümlerle değiştirerek kullanıcı gizliliğini artırmaktır. Bu çözümlerin farklı tür ve boyutlardaki paydaşlar için mümkün olduğunca geniş bir kapsamda yararlı olmasını istiyoruz. Bu çözümlerin nasıl iyileştirilebileceğiyle ilgili spesifik, uygulanabilir görüşleri almaktan memnuniyet duyuyoruz ve topluluk tartışmaları ve testler yoluyla gelişmeye devam edeceğini umuyoruz. |
| Gizliliği iyileştirme | Aynı grupta çok fazla site bulunması, üçüncü taraf çerezlerine benzer sonuçlar doğurabilir | Bu geri bildirim bizim için çok değerlidir. Doğru sınırların olup olmadığını veya ne olabileceğini değerlendiriyoruz. Aynı zamanda hem kullanıcılara hem de geliştiricilere, bu tür bir sınıra ulaşıldığında anlayabilecekleri değerlendirmeler veya sinyaller sunmaya çalışıyoruz. Henüz paylaşabileceğimiz belirli bir teklif yok, ancak çok yakında paylaşmayı umuyoruz. |
| FPS ekosistem desteği | Gizlilik CG'si dışında FPS'yi geliştirmeye devam etmeye yönelik destek ve endişeler | Birinci Taraf Gruplar teklifinin PrivacyCG'de kalmasını tercih etsek de, teklifi WICG'de sürdürmeyi umuyoruz. Ayrıca, Birinci Taraf Gruplar ve ele alınması amaçlanan kullanım alanları hakkında açıklamaya devam ettiğimize dair çok sayıda destek beyanı da bizi cesaretlendirdi. Google, web'in kullanıcı gizliliğini koruyup buna saygı gösterecek şekilde büyümeye ve gelişmeye devam etmesini sağlayacak çözümler bulma konusunda kararlıdır. |
| Tarayıcı birlikte çalışabilirliği | Diğer tarayıcılar tarafından uygulama | Tarayıcılarla birlikte çalışabilirliğin geliştiriciler için ne kadar önemli olduğunu biliyoruz ve FPS'nin standartlaştırılmasını sağlamak üzere diğer tarayıcılarla işbirliği yapmaya devam edeceğiz. |
| Genel gizlilik politikası şartı | Tüm ürünlerde ve aynı grubun parçası olması gereken yargı alanlarında ortak bir gizlilik politikasına sahip olmak mümkün değildir. | Chrome, politika şartlarımızı tanımlamaya devam ediyor ve bu geri bildirimi göz önünde bulunduracaktır. |
Çitli Çerçeveler API'sı
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Belge isteği | Korumalı alana alınmış iframe'lerle olan farklar | Geri bildirim ve öneriniz için teşekkür ederiz. GitHub'da bu konuyla ilgili mevcut bir tartışma var. Ardından talebi tam olarak değerlendirebilmek için bunu net bir şekilde belirlemeyi umuyoruz. Herkese açık tartışmaya buradan ulaşabilirsiniz. |
| API'ler Arası Özellikler | Kısıtlanmış Çerçevelerde İlişkilendirme Raporlaması için varsayılan destek | Attribution Reporting API'nin varsayılan olarak sınırlanmış çerçevelerin "opak reklam modunda" kullanılmasına izin verilmesine yönelik bir teklif hakkında geri bildirim istiyoruz. Bu gönderiyi değerli bulan geliştiricilerin tartışmaya da katılmasını öneririz. |
Shared Storage API'si
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Veri limitleri | Bölüm başına ne kadar veri depolanabileceği konusunda bir kısıtlama olacak mı? | Evet, sınırlar olacaktır. Daha fazla bilgi için github sorunu bölümüne bakın. Depolama alanı kotalarına ihtiyacımız olacak. Mevcut teklifimiz giriş başına boyut sınırının 4 KB olmasını, her iki anahtar ve değerin de her biri 1024 karakter16_t karakterle ve kaynak başına giriş sınırı olan 10.000 giriştir. Bu sınır, kaynakların bir kaynağın kapasitesi dolduğunda ek girişlerin yapılmasını önleyen bir mekanizmadır. Burada önerilen belirli sınırlar hakkında aktif olarak geri bildirim almak istiyoruz. |
| Kullanıcı şeffaflığı | Veri kaynakları ve veri kullanımı konusunda kullanıcı şeffaflığı ile veri kullanımı karşılaştırması | Bu geri bildirimi öğrenmek bizim için önemli ve bunun keşfetmeye değer, gelecek vadeden bir yaklaşım olduğunu düşünüyoruz. Özellikle, bunu kullanıcılara yeterli şeffaflık sağlayacak şekilde yapmanın mümkün olup olmadığını değerlendiriyoruz. |
ÇİPLER
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Benimsemenin engelleri | CHIPS'ler ana makine adına bağlı olmalı mı? (alan yok gereksinimi) | OT katılımcılarından gelen, bu koşulun daha karmaşık hale getirdiğine ve CHIPS'in benimsenmesini engellediğine dair geri bildirimlere dayanarak bu koşulu OT'dan kaldırıyoruz.
Bu koşulu, buradaki standart oluşturma sürecinin bir parçası olarak Gizlilik Topluluğu Grubu'nda ele alacağız. |
| CHIPS için reklam kullanım alanları | CHIPS, tek bir sitede Ads kullanım alanları için kullanılabilir mi? | Tek bir site içinde kullanıcı izleme izin verilen bir kullanım örneğidir. Bu kullanım alanını vurgulamak için geliştirici makalemizi güncelledik. |
| Kimliği doğrulanmış yerleştirmeler | Oturum açma durumu CHIPS ile korunur mu? | Oturum açık durumu şu anda korunmamaktadır ancak CHIPS için amaçlanan kullanım alanı değildir. Kimliği doğrulanmış yerleştirilmiş yerleştirmelerin kullanım alanının farkındayız ve çözümleri araştırmak için çalışıyoruz. |
| Test koordinasyonu | Bölümlendirmeyi test etmek için gereken başka kullanıcı işlemleri var mı? | OT jetonu geçerli olduğu ve ziyaret edilen sayfaların başlıklarında bulunduğu sürece, bu özellik herhangi bir ek kullanıcı işlemi gerektirmeden kullanıcıların kullanımına sunulmalıdır. |
| Tarayıcı uyumluluğu | Diğer tarayıcıların bölümlendirilmiş çerez özelliklerini nasıl işlediğini anlamaya yönelik ilgi. | Chrome, tarayıcılarda çalışabilecek tasarımları ve uygulamaları tanımlamak için W3C gibi genel standartlar gruplarıyla çalışmaya devam etmektedir. |
FedCM
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Potansiyel saldırı vektörleri | Bağlantı süsleme ve zamanlama saldırıları aracılığıyla potansiyel saldırı vektörleri | Etkin bir şekilde kamuoyundan görüş alıyor ve bu sorunu çözmenin olası yollarını araştırıyoruz. |
| Birden fazla IdP'ye olanak tanıyan kullanıcı deneyimi | Aynı anda yalnızca bir IdP sunulabilir | Birden fazla IdP'yi desteklememiz gerektiğine inanıyor ve |
| İfade | 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 olduğunu unutmayın. | Chrome, markalama özelleştirmeleri (ör. logolar, renkler) ve dize özelleştirmesi (örneğin, "şununla giriş yap" yerine "bu makaleye erişin") ekleme konusunu araştırmaktadır.
Chrome bu dengenin farkındadır ve hem mümkün olduğunca fazla alanı kaplamak hem de bunu mümkün olduğunca ifade edici hale getirmek için ekosistemle birlikte çalışmaya devam edecektir. |
| Uygulanabilirlik ve Birlikte Çalışabilirlik | Diğer tarayıcıların FedCM'yi benimsememesi veya uygulamamasıyla ilgili endişeler. | Chrome, FedID Topluluk Grubu'nda federasyon için ortak çözümler bulmak amacıyla diğer tarayıcı tedarikçileriyle de çalışmaktadır. |
| Kayıt akışındaki kişisel veri şartlarını kaldırma önerisi | (1) E-posta adresi, resim ve adının daha fazla gizlilik açısından paylaşılacağını belirtmeden kullanıcıya hangi IdP'yi seçtiğini gösteren bir kullanıcı deneyimi
(2) Kullanım alanı kaydında kullanıcı deneyimi seyrek olmalı ve IdP'den gelen taleplerin seçilmesi |
Geri bildirimi daha kullanıcı, gizlilik ve kullanıcı dostu bir şekilde nasıl uygulayabileceğimizi araştırıyoruz. |
| IdP ile kullanıcı etkileşimi | Risk eşiği aşılırsa kullanıcı ile IdP arasında doğrudan etkileşim gerekir | Bu geri bildirimi aktif bir şekilde araştırıyoruz. |
Ağ Durumu Bölümlendirme
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Performans | Ağ durumunun bölümlenmesi, CDN'lerde yoğun kaynak kullanan bağlantılarda artışa neden olabilir | Olası farklı anahtarlama düzenlerini ölçmek de dahil olmak üzere Ağ Durumu Bölümlemenin performans özelliklerini araştırmaya devam ediyoruz. Performans, güvenlik ve gizlilik gibi konularda henüz bir karar vermedik ve daha fazla veri toplamamız gerekiyor. |
Spam ve sahtekarlıkla mücadele edin
Güven Jetonları API'si
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Özeti | Chrome Yanıtı |
| Düzenlemelerle ilgili geri bildirim | Düzenleyici kurumların uzun vadeli geçerlilik hakkında net bir sinyali olmadan Güven Jetonlarına zaman ve kaynak yatırımı yapmayla ilgili endişeler | Amacımız, sektörden ve düzenleyici kurumlardan süreç için kritik öneme sahip geri bildirimler alarak ekosistem için işe yarayan teknolojiler geliştirmektir. Özel Korumalı Alan'ı geliştirirken ve Güven Jetonları da dahil olmak üzere geliştiricilerin tekliflerini kullanıma sunarken dünyanın dört bir yanındaki düzenleyici kurumlara danışmaya devam edeceğiz. Tüm yeni teknolojilerde olduğu gibi, şirketler de yasal gerekliliklerle ilgili kendi değerlendirmelerini temel alarak kararlar vermelidir. |
| Lansman zamanlaması | Güven Jetonları GA'da ne zaman kullanıma sunulacak? | Yayına ilişkin mevcut tahminlerimizi privacysandbox.com adresindeki herkese açık zaman çizelgemizde sağlarız. GA'ya teslim tarihiyle ilgili nihai bir karar verir vermez yayını Chrome'un sürüm süreçleri aracılığıyla herkese açık bir şekilde yayınlar ve web sitesindeki zaman çizelgesini güncelleriz. |
| Güven Jetonları ve Diğer Jetonlar | Standartlaştırma sürecinden geçen diğer jetonlar (ör. Özel Erişim Jetonları) göz önünde bulundurulduğunda, Güven Jetonları nasıl bir rol oynar? | Standartlaştırma tartışmaları gerçekleştiriyoruz. Amacımız, her bir teknolojinin elverişli olduğu farklı kullanım alanlarını mümkün kılarken diğer çalışmalara da mümkün olduğunca uyum sağlamak. Örneğin, hem Güven Jetonları hem de Özel Erişim Jetonları, Gizlilik Kartı protokolüne dayanır. |
| Veri limitleri | Sayfa başına jeton kullanımı için maksimum 2 yayıncı | Şirketlerin, kullanıcı entropisini riske atmadan jeton kullanmalarına güvenli bir şekilde izin verebileceğimiz uzun vadeli seçenekler arıyoruz. Bunun için belki de jeton kullanımlarına erişimi bölümlendirmek gerekir. |
| Erişim kısıtlamaları | Yalnızca onaylanmış (ve doğrulanmış/sahte yönlendiren olmayan) kaynaklar, jetonun varlığını doğrulayıp kullanabilir | Jetonları kimlerin görebileceğini ve kullanabileceğini belirlemeye yönelik 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 başka tür cihazlarda çalışacak şekilde genişletilebilir mi? | Bunu gelecekteki geliştirmelerde düşünebileceğimiz bir konu ve W3C forumlarındaki geliştiricilerden daha fazla geri bildirim duymak bizi mutlu edecek bir konu. Ayrıca, geri bildirim istediğimiz bir HTTP Başlığı tetiklemeli jeton kullanımını tartışmak için açık bir sorunumuz da var. |
| Kullanım alanları | Güven Jetonları için doğru kullanım alanlarının neler olduğu net değil. Amaçlanan kullanımların net olmaması | Amacımız, sahtekarlıkla mücadele alanında yeniliği kolaylaştırmak ve her şirketin güven jetonları içeren tescilli teknikler kullanabileceğini anlamaktır. Bu nedenle, amaçlanan kullanımlar konusunda kuralcı değiliz. Bununla birlikte, deneme yapmayı veya kullanmaya başlamayı düşünen iş ortakları için başlangıç noktası olarak belgelerimizi muhtemelen daha fazla örnek içerecek şekilde genişleteceğiz. |
| Güven Jetonu Kapsamı | Bu "güven jetonu kullanma" özellik politikasının kaldırılması, güven jetonu kapsamını önemli ölçüde artıracaktır. | OT'dan geri bildirim toplarken ve sonraki adımlarla ilgili kararlar alırken bunu dikkate alırız. |
| Kartı veren kuruluşun güveni | Güven jetonları yayınlayan web sitelerine neden güvenmeliyiz? | Kartı veren kuruluş olmayla ilgili bir kural yoktur. Bunu herkes yapabilir. Yayıncıların yalnızca güvendikleri kart veren kuruluşlarla çalışması beklenir. Ayrıca reklam ekosistemindeki diğer meşru taraflar, şüpheli veya bilinmeyen kuruluşlarla ilişkili trafiğe indirim yapabilir (ya da satın almayı bırakır). |
| Üçüncü taraf yerleşik hizmetler | Üçüncü taraf yerleşik hizmetler güven jetonlarını kullanabilir ve/veya isteyebilir mi? | Evet, yerleşik bir üçüncü taraf hizmeti Güven Jetonları gönderebilir ve kullanabilir. |
| Kartı veren kuruluşların ekosistemi | Güven sinyalleri diğer şirketlerle paylaşılabildiği takdirde çok daha fazla fayda sağlanabilir | Güven Jetonları, düşük seviye temel öğe olarak tasarlanmıştır ve güven/itibar sinyallerini paylaşmak için iş birliği yapan veren kuruluşlar/kullananlar tarafından kullanılabilir. |
| Bakım ek yükü | Güven Jetonu işlemlerinin altında yatan kriptografik uygulama, Google'ın tek sorumlusu olan BoringSSL'dedir. Kütüphanenin bakımı nasıl yapılacak? | Güven Jetonları, diğer kitaplıklarda da uygulanabilecek standartlaştırılmış şifreleme işlemlerine (Gizlilik Kartı protokolü başlıklı makaleye bakın) dayanır. Geliştiricilerin, tercih ettikleri kitaplıklarda bu işlemler için destek istemesini, geliştirmesini/sürdürmesini öneririz. |
| Bakım ek yükü | Protokol sürümlerinin ne kadar süre destekleneceği net değil | Protokol sürümleri için beklenen destek zaman aralıkları hakkında daha fazla ayrıntı geliştirmek ve belgelemek için çalışıyoruz. |
| Sertifika Veren Kuruluş Sınırları | Zincirin daha aşağısındaysanız Güven Jetonları yürütmeniz mümkün olmayabilir. | Daha fazla kuruluş güven jetonları kullanmaya başladıkça bu tür zamanlama dinamiklerini gittikçe daha fazla görüyoruz ve olası çözümleri araştırıyoruz. Daha önce açıklandığı gibi, şirketlerin jetonları daha fazla kullanıcı entropisi riske atmadan, sayfada konum veya sipariş yüklemenin önemini en aza indirecek şekilde kullanmalarına güvenli bir şekilde izin verebileceğimiz uzun vadeli seçenekler arıyoruz. |
Yeni Sahtekarlıkla Mücadele Çözümleri
| Geri Bildirim Teması
(Sıklığa göre sıralandı) |
Sorular ve Kaygıların Ö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 | Herkese açık tasarım ve yineleme yoluyla geri bildirim toplamaya ve teklifi takip etmeye devam edeceğiz. |
| Cihaz bütünlüğü onay sinyalleri | Yeni sinyaller aracılığıyla ne kadar kullanıcı entropisinin iletilebileceği ve belirli kullanım alanlarının (örneğin, bankasına giriş yapan bir kullanıcı) daha yüksek entropi sinyallerini haklı bulup bulmayacağı ile ilgili sorular. | Kullanıcı gizliliğini korumak için mümkün olduğunca az kullanıcı entropisiyle yüksek değerli sinyaller sağlamaya odaklanıyoruz. |
| Cihaz bütünlüğü onay sinyalleri | Bu sinyal, eski cihazlar veya açık kaynaklı/değiştirilmiş platformlar için erişimi sınırlandırır mı? | Tüm yeni sinyaller, evrensel erişimi geliştirme sürecinin temel ilkesi olarak dikkate almalıdır. Bu sorular, biz üretime devam ederken en baştan ele almamız gereken önemli sorulardır. |
| Cihaz bütünlüğü onay sinyalleri | Yeni göstergeler, güvenlik ve sahtekarlıkla mücadele şirketlerinin tarayıcı ve platformlara gereğinden fazla güvenmesine neden oluyorsa bazı endişeler vardı.
|
Tüm yeni sinyaller, ek veri olarak görülmeli ve tarayıcıdan "güven"in göstergesi olarak görülmemelidir. Güvenlik şirketlerinin, cihaz onayı ile birlikte kendi tescilli verilerini, modellerini ve karar motorlarını kullanmaya devam etmesini tamamen bekliyoruz. Tüm yeni sinyallerin ekosistem genelinde tespit çalışmalarını iyileştireceğini ve sahtekarlığın yürütülmesini zorlaştıracağını umuyoruz. |
| Çerez Yaş Sinyali | İlginç bir kavramdır ancak geçerli kullanım alanlarıyla ilgili daha fazla araştırma yapılması gerekebilir. | İlgi düzeylerine bağlı olarak Chrome, bu kavram hakkında daha ayrıntılı fikirler sunabilir ve gelecekteki ekosistem geri bildirimleri için bir açıklayıcı olarak kullanabilir. |
| Sahtekarlıkla Mücadele İçin Güvenilir Sunucular | İlginç bir kavramdır ancak geçerli kullanım alanlarıyla ilgili daha fazla araştırma yapılması gerekebilir. | İlgi düzeylerine bağlı olarak Chrome, bu kavram hakkında daha ayrıntılı fikirler sunabilir ve gelecekteki ekosistem geri bildirimleri için bir açıklayıcı olarak kullanabilir. |