Özel Korumalı Alan teklifleri ve Chrome'un yanıtları hakkında alınan ekosistem geri bildirimlerini özetleyen, 2022 4. çeyrek 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ı | Özet | Chrome Yanıtı |
|---|---|---|
| (3. çeyrekte de raporlanır) Farklı paydaşlar için faydası |
Ö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 | 3. çeyrekteki yanıtımız değişmeyecek: "Google, Özel Korumalı Alan tekliflerini, kendi işletmesini tercih ederek rekabeti sarsmayacak şekilde tasarlaması ve uygulaması ve boyutları ne olursa olsun dijital reklamcılık ile yayıncılar ve reklamverenler üzerindeki rekabeti göz önünde bulundurması için CMA'ya taahhüt verdi. Çalışmalarımızın bu taahhütlere uygun olmasını sağlamak için CMA ile yakın ç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 anlamda, teknik tasarımları daha da iyileştirmemize yardımcı olabilecek spesifik ve harekete geçirici geri bildirimler almak son derece önemlidir. Niceliksel teste yaklaşımımızı geliştirmek için CMA ile birlikte çalıştık. Pazar katılımcılarına daha fazla bilgi ve önerilen yaklaşımlarla ilgili yorum yapma fırsatı sağlamak amacıyla CMA'nın deneme tasarımı hakkında bir not yayınlamasını destekliyoruz." |
| (3. çeyrekte de bildirilmiştir) Belge istekleri |
Test, analiz ve uygulamanın nasıl yönetileceğini açıklayan daha fazla kaynak istekleri | 4. Çeyrek Güncellemesi: Mevcut materyallerimizi faydalı bulan geliştiricilerin, yeni teknolojilerin nasıl işine yarayabileceğini anlayabilmeleri için daha fazla materyal sağlama konusundaki kararlılığımızı sürdürdüğümüz için teşekkür ederiz. Geçtiğimiz üç aylık dönemde, privacysandbox.com sitesine "Haberler ve Güncellemeler " bölümünü ekledik ve Özel Korumalı Alan'ın gelecekte reklam alaka düzeyini artırmaya nasıl yardımcı olabileceğine dair kapsamlı bir inceleme yayınladık. Ayrıca en iyi uygulamaları ve demoları paylaşmak için 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ı yaptık. |
| Önemli Web Verileri | Privacy Sandbox API'deki gecikme, Core Web Vitals'ı nasıl etkiler? | Gecikmeyi minimumda tutmak, Özel Korumalı Alan API'lerinin temel tasarım hedeflerinden biridir. API'lerin çoğu, web sitesi ilk oluşturulduktan sonra çağrıldığından şu anki beklentimiz, API gecikmesinin sitenin Core Web Vitals üzerinde çok az etkiye sahip olacağı yönündedir. Her bir API'de gecikmeyi daha da azaltmak için izlemeye ve iyileştirmeler yapmaya devam ediyor, test ve geri bildirime devam etmeyi teşvik ediyoruz. Gerçek zamanlı teklif verme sürecindeki gecikme, "FLEDGE Açık Artırmalarının Performansı" altındaki FLEDGE bölümünde ele alınmaktadır |
| Birlikte çalışabilirlik | Diğer potansiyel çözümlerle birlikte çalışabilirlik hakkında endişeler | Özel Korumalı Alan'ın amacı, kullanıcıları siteler arası izlemeye karşı korurken web ekosisteminin ihtiyaçlarını desteklemektir. Bunu başarmak için, üçüncü taraf çerezler gibi siteler arası izlemeye olanak tanıyan eski tarayıcı teknolojilerinden uzaklaşıp belirli kullanım alanlarını desteklemek üzere tasarlanmış yeni teknolojiler sunmayı hedefliyoruz. Özel Korumalı Alan teklifleri, kullanıcının cihazından ayrılan verileri sınırlandırarak gizliliği artırır. Teklifler, bir web sitesinin tarayıcıdan toplandıktan sonra verileri paylaşma veya başka bir şekilde işleme özelliğine teknik kısıtlamalar getirmez. Dolayısıyla bu teknolojiler, şirketlerin "verilerin korunması" sözleşmelerine veya diğer benzer sözleşme ilişkilerine girmelerini engellemez. Benzer şekilde, kullanıcıların, verilerinin başka yollarla paylaşılmasına izin verme olanağını kısıtlamazlar. Daha net bir ifadeyle Google, Özel Korumalı Alan teknolojilerini Google ürünleri ve hizmetleri dahil tüm web sitelerinde aynı şekilde uygulamayı taahhüt eder. Chrome üçüncü taraf çerezleri desteğini sonlandırdıktan sonra bu taahhütler, dijital reklamların hedeflenmesi veya ölçümü için kullanıcıları izlemek amacıyla Google'ın, kullanıcıların senkronize edilmiş Chrome tarama geçmişi gibi diğer kişisel verileri kullanmayacağını da açıkça belirtir. |
Alakalı İçerik ve Reklamlar Gösterin
Konular
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Google arama sıralamasına etkisi | Bir web sitesinin Topics API desteğinin Google arama sonuçlarının sıralaması için potansiyel bir sinyal olarak kullanılıp kullanılmayacağıyla ilgili sorgu | Bazı web siteleri, Topics API'nin kapsamı dışında kalmayı seçebilir. Özel Korumalı Alan ekibi, Arama Ağı kuruluşundan, web sitelerinin Topics API'yi benimsemesi için bir teşvik olarak sayfa sıralamasını kullanmalarını koordine etmemiş veya aramamıştır. Google, sitelerin Topics API'nin kapsamı dışında kalma kararını Google Arama'nın bir sıralama sinyali olarak kullanmayacağını CMA'ya doğruladı. |
| Konu sınıflandırıcı | Çeşitli paydaşlar için faydayı artırmak amacıyla bir web sayfasının Konusunu belirlemek için ana makine adına ek olarak URL ve sayfa içeriği ekleyin. | Bir kullanıcının tarama geçmişi, şu anda web sitesinin ana makine adları kullanılarak sınıflandırılmaktadır. Chrome, Konular sınıflandırmasında sayfa düzeyinde meta verileri (sayfa URL'sinin ve/veya içeriğin tümü ya da bir kısmı gibi) dikkate alma seçeneklerini değerlendirmeye devam ediyor. Faydayla ilgili tüm iyileştirmeler, gizlilik ve kötüye kullanım riskleri açısından değerlendirilmelidir. Örneğin, özellikle meta verilerle ilgili risklerden bazıları şunlardır: - Sayfa düzeyinde meta verileri, farklı (ve potansiyel olarak hassas) anlamları konulara göre kodlama yöntemi olarak değiştiren siteler; - Maddi kazanç sağlamak amacıyla konuları yanlış beyan etmek için sayfa düzeyinde meta verileri değiştiren siteler; - Siteler arası izleme yöntemi olarak sayfa düzeyinde meta verileri dinamik olarak değiştiren siteler |
| (3. çeyrekte de raporlanmıştır) Birinci taraf sinyalleri üzerindeki etkisi |
Konu sinyalleri son derece değerli olabilir ve bunun sonucunda diğer birinci taraf ilgi alanına dayalı sinyallerin değerini düşürür. | 3. çeyrekteki yanıtımız değişmeyecek: "İlgi alanına dayalı reklamcılığın web için önemli bir kullanım alanı olduğuna inanıyoruz ve Topics'in bu kullanım alanını destekleyecek şekilde tasarlandığına inanıyoruz. [3. çeyrek raporumuzda] açıklandığı gibi, ekosistemin diğer paydaşları Topics'in değer sağlamak için yeterince faydalı olmayabileceğine dair endişelerini dile getirdi. Her durumda, sınıflandırmada yapılan iyileştirmeler sürekli bir çalışmadır ve sınıflandırmanın ekosistem testleri ve girdilerle gelişmesini bekliyoruz." |
| Sınıflandırmayı Güncelleme | Sınıflandırma listesi nasıl güncellenecek? | Ekosistem için en yararlı olacak sınıflandırma hakkında aktif olarak geri bildirim istiyoruz. Topics API'nin ilk teklifinde yer alan sınıflandırma, işlevsel testler yapılmasını sağlamak için tasarlanmıştır. Chrome, sınıflandırmayı güncellemek için birden fazla yaklaşımı aktif olarak değerlendirmektedir. Örneğin, Chrome gelecekteki iterasyonlara hangi kategorinin dahil edileceğini belirlemek üzere her konu için ticari değer kavramından yararlanabilir. |
| Konular bölgesel sınıflandırıcı performansı | Konu sınıflandırıcısı bölgesel alanlarda düşük performans gösteriyor | Sınıflandırıcı geliştirmek için sürekli çalışıyoruz. Aldığımız geri bildirimlere göre, değerlendirebileceğimiz bir olasılık da Topics'in geçersiz kılma listesinin genişletilmesidir. Analizlerimiz, bu listenin global kapsamı ve doğruluğunu artırır. Topics API sınıflandırmasının iki önemli bileşeni vardır: (1) En popüler 10 bin siteyi ve bunların konularını içeren bir geçersiz kılma listesi ve (2) ana makine adlarını konular halinde sınıflandıran cihaz üzerinde bir makine öğrenimi modeli. Geçersiz kılma listesini (1) genişleterek, sınıflandırıcının düşük performans gösterdiği bölgelerde sınıflandırma performansını iyileştirebiliriz. |
| Bir haftalık dönem | Bir haftalık dönem, daha kısa vadeli kararlar almak isteyen kullanıcılar için çok uzun. | Dönemin uygun uzunlukta olmasını aktif olarak araştırıyoruz. Ekosistem için daha iyi bir dönemin ne olabileceğiyle ilgili daha fazla geri bildirim almaktan memnuniyet duyarız. |
| HTTP üst bilgisi alma | Konuların HTTP üstbilgisinin alınması hakkında yeterli bilgi olmaması | Üstbilgiler veFetch() ile ilgili çalışmalar devam etmektedir. Burada da bilgi mevcuttur. Açıklayıcıya JumpObservation bilgilerini de ekledik. |
| Topics, kullanıcılara değil, yalnızca reklamverenlere yardımcı olmayı amaçlar. | Topics/Özel Korumalı Alan, sektör odaklı bir yaklaşım gibi görünüyor. Kullanıcılar için faydası sektöre sağladığı fayda kadar net değil. | Topics'in web'in ücretsiz ve açık kalmasını sağlayan ilgi alanına dayalı reklamları desteklemesi ve üçüncü taraf çerezlerine kıyasla gizliliği önemli ölçüde iyileştirdiğine inanıyoruz. Geçerli alternatifleri olmayan üçüncü taraf çerezlerinin kaldırılması, yayıncıları olumsuz etkileyebilir ve daha az gizli, şeffaf olmayan, gerçekçi olarak sıfırlanabilir veya kullanıcılar tarafından kontrol edilmeyen daha kötü yaklaşımlara yol açabilir. Birçok şirket, Topics ve Sandbox API'lerini aktif olarak test etmekte. Biz de gizliliği geliştirmek ve web'i desteklemek için gerekli araçları sağlamaya kararlıyız. W3C Teknik Mimari Grubu, kısa süre önce Topics API ile ilgili ilk görünümünü yayınladı. Bu genel bakışa herkese açık olarak yanıt vereceğiz. Google bu aşamada, ekosistemden bu yorumun Topics API'nin geliştirilmesi ve kullanıma sunulması açısından ne anlama geldiği hakkında sorular aldığı için bu yıl Chrome'un kararlı sürümünü kullanıma sunma planımızı bir kez daha teyit etmek istiyoruz. Google, W3C Teknik Mimari Grubu'nun görüşlerine değer verilse de CMA ve ekosisteme danışarak Topics'in geliştirilmesi ve test edilmesi çabalarını son derece önemli olarak görmektedir. |
| Veri sızıntısı | Konuların, izinsiz olarak başka sitelere sızdırılabileceğine dair endişeler | Topics API'nin tasarımı, tek bir yayıncıdan (ve hatta daha küçük bir yayıncı grubundan) verilerin herhangi bir şekilde sızdırılmasını pek mümkün kılmıyor. Yayıncı web siteleri de Topics API üzerinde tam kontrole sahiptir ve izin politikası aracılığıyla bu API'ye erişimi yasaklayabilirler. |
| Test yapacak reklamverenlerin olmaması | Yayıncılar, şu anda Topics'in değerini reklamverenlere gösteremediklerinden endişe duyuyor. | 2023'ün ikinci yarısında, reklamlarla ilgili tüm API'leri entegrasyon testleri için kullanıma sunmayı ve reklamverenler için Topics'in değerinin ekosistem analizini etkinleştirmeyi planlıyoruz. Sonuçların test edilmesi ve yayınlanması CMA tarafından denetlenecektir. CMA; verileri, analizi ve metodolojiyi gözden geçirecektir. Ekosistemin, Google ve CMA ile geri bildirim paylaşması teşvik ediliyor. |
| Konular ve FLEDGE | Konular'ı FLEDGE'in teklif verme mantığında kullanma hakkında daha fazla bilgi isteği | Topics'i FLEDGE'in teklif verme mantığında kullanmak mümkündür. Ayrıca uygulama ile ilgili ek ayrıntıların yer aldığı bir entegrasyon kılavuzu da yapım aşamasındadır. |
| Konu arayanlar için özel sıralama | Sıralamaların arayana göre uyarlanmasına izin ver | Her reklam teknolojisi için özel konu sıralaması veya değerleriyle ilgili zorluk, bunun bir reklam teknolojisinin döndürülen konuları etkileyebileceği bir mekanizma, yani dijital parmak izi vektörü haline gelebilmesidir. |
| Konular arayan önceliği listesi | Arayanların, Topics API'nin uygunluk durumuna göre döndüreceği konuların sıralı bir öncelik listesini sağlamasına izin verin. | Şu anda bu fikri daha ayrıntılı olarak tartışıyoruz ve sizin de diğer görüşleriniz bizim için değerlidir. |
FLEDGE
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Google Ad Manager | FLEDGE açık artırmalarında son kararı Google Ad Manager'ın belirlediği ve Google Yayıncı Etiketleri ile Google Ad Manager'ı tercih edeceği. | FLEDGE, her yayıncının açık artırmanın yapısını (üst düzey ve bileşen satıcılarının seçimi dahil) seçmesine olanak tanır. Bileşen açık artırmasındaki her alıcı ve satıcı, üst düzey satıcının kim olduğunu bilir ve teklif verip vermemeyi seçebilir. |
| FLEDGE'i test eden yeterli sayıda katılımcı yok | Daha fazla şirketi FLEDGE'i test etmeye teşvik etme (ör. API'nin işlevselliğini iyileştirme ve dijital parmak izi gibi gizliliği engelleyen alternatiflerden uzak durma) | Özel Korumalı Alan, CMA ve ICO'nun rehberliğiyle yakın iş birliği içinde aşamalı olarak ilerliyor. Ayrıca işlevsel FLEDGE testleri de gerekli kararlılık ve yeterlilik olduğunu ortaya koydu. Google, ekosistemi Korumalı Alan API'lerini test etmeye teşvik etmeye devam ediyor. Ayrıca, üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ardından FLEDGE ve diğer API'lerin reklam sektörü için kritik kullanım alanlarını desteklemeye nasıl yardımcı olabileceğini göstermek amacıyla kısa süre önce "Reklam Alaka Düzeyini En Üst Düzeye Çıkarma" belgesini yayınladı. Özel Korumalı Alan'ın diğer bölümleri izlemeyi kapsayacak çözümleri zaten desteklemektedir (UA-CH, IP Koruması ve Hemen Çıkma Durumunu İzleme Çözümleri) zamanla iyileşmeye devam edecektir. Google'ın hedefi, FLEDGE'i uygulanabilir tek hedefleme çözümü yapmak değil. Bunun yerine, Chrome Tarayıcı'da gizliliği korumaya yönelik en iyi reklam teknolojilerini kullanıma sunmak için sektör ve düzenleme kurumlarıyla iş birliği içinde çalışmaya devam etmeye devam ediyor. |
| Makine öğreniminin kullanım alanları | Açık artırma teklif verme algoritmalarını eğitmeye yönelik makine öğrenimi kullanım alanları hakkında daha fazla rehberlik, FLEDGE ve İlişkilendirme raporlarında desteklenecektir. | Test kullanıcılarının, Özel Korumalı Alan teknolojilerini uygulamanın en yararlı yollarını bulmalarına yardımcı olma ihtiyacının farkındayız. Özel Korumalı Alan API'lerinin çeşitli yönlerinin makine öğrenimi girdileri olarak kullanılmasıyla ilgili kılavuzlar yayınlamaya başladık. "Reklam Alaka Düzeyini En Üst Düzeye Çıkarma" adlı en son çalışma, reklam sektörünün makine öğrenimi için bu sinyallerden nasıl yararlanabileceğini ele alıyor ve gelecekte bu tür rehberleri yayınlamaya devam etmeyi planlıyoruz. |
| FLEDGE Anahtar Değeri (K/V) Sunucusunu Sorgulama | K/V sunucusu neden herkese açık olarak sorgulanabilir? | K/V sunucusu, FLEDGE açık artırmalarına gerçek zamanlı sinyaller sağlamayı amaçlar. Bu nedenle, K/V sunucusuna bu FLEDGE açık artırmalarının yapıldığı yerden erişilebilmelidir. Bu açık artırmalar kullanıcı cihazlarında gerçekleştirilebilir ve herkese açık olmalıdır. K/V sunucusunda depolanan bir değer, yalnızca anahtara zaten sahip olan bir tarafça alınabilir. Dolayısıyla, bir reklam teknolojisi anahtarları yalnızca İlgi Grubu'nda yer alan tarayıcılara verir ve rastgele tahmin edilebilen anahtarları kullanmazsa yalnızca açık artırmalarını yapmak için Değere ihtiyaç duyan tarayıcılar değeri alabilir. |
| Tarih/saat hedefleme nasıl yapılır? | Teklif mantığı işlevinde tarih nesneleri için destek. | Bunu yapmanın birden çok yolu vardır. Alıcılar, satıcılarından geçerli tarih ve saati sunmasını isteyebilir. Satıcılar, bu bilgiyi tüm alıcılara kolayca sağlayabilir. Alıcılar, gerçek zamanlı anahtar/değer çifti yanıtlarında tarih ve saati de sağlayabilir. Son olarak alıcılar, satıcı tarafından alıcının generateBid komut dosyasına iletebileceği alıcı başına sinyallerdeki içeriğe dayalı yanıtlarının bir parçası olarak tarih ve saati sağlayabilir. |
| Kullanıcı tercihleri | Kullanıcıların, FLEDGE veya alternatif çözümler aracılığıyla yayınlanan reklam öğelerini reklamverene göre engellemeyi seçme olanağı. | Kullanıcılar Chrome'da Ads API'lerini devre dışı bırakabilir. Belirli reklamlar söz konusu olduğunda, hangi reklam öğelerinin gösterileceği veya nasıl seçileceği konusunda kontrol sahibi olmaya en uygun taraf ilgili reklam teknolojisidir. |
| Daha net zaman çizelgeleri | FLEDGE'deki gizlilik korumalarının kullanılabilirliği (ör. Kısıtlanmış Çerçeveler'i zorunlu kılma) hakkında daha fazla bilgi isteyin. | 1. çeyrekte daha ayrıntılı zaman çizelgeleri yayınlamayı planlıyoruz. |
| Karışıklık bildirme | FLEDGE raporlarının Çitlenmiş Çerçeveler ve Private Aggregation API gibi diğer API'lerle nasıl çalışacağı hakkında daha fazla bilgi talep edin. | Önümüzdeki haftalarda Private Aggregation API, FLEDGE ve Fenced Frames arasındaki etkileşim hakkında bir açıklayıcıyı yayınlamayı planlıyoruz. |
| Gerçek zamanlı teklif verme ve FLEDGE | FLEDGE'in standart gerçek zamanlı teklif verme ile nasıl entegre olduğuna dair rehberlik. | Bir reklam teknolojisinin gerçek zamanlı teklif verme becerisini karmaşık hale getiren iki temel şey, etkinlik düzeyindeki verilere erişim ve ARA'ya daha kolay entegrasyondur. 1. çeyrekte her ikisiyle ilgili güncellemeler ve açıklayıcı bilgiler göndermeyi planlıyoruz. |
| FLEDGE Açık Artırmalarının Performansı | Test kullanıcılarının, FLEDGE açık artırmalarında gecikmenin yüksek olduğunu bildirme | Test kullanıcılarının sonuçları ile kullanım alanlarını paylaştıkları raporlar bizim için çok değerlidir. Ayrıca FLEDGE'in performansını nasıl iyileştirebileceğinizle ilgili bazı önerileri de sizinle paylaşıyoruz. Buna paralel olarak tarayıcıya, geliştiricilerin açık artırmaların yavaşlamasına neden olan unsurları daha iyi teşhis etmelerini sağlayan araçlar ekledik ve gözlemlenen başlıca gecikme kaynaklarını sistematik olarak ele alıyoruz. Son iyileştirmeler arasında yavaş açık artırmalar için zaman aşımları, hızlı teklif veren filtreleme tekniği, başlangıç maliyetlerini ödememek için FLEDGE iş uygulamalarını yeniden kullanma yöntemi ve FLEDGE başlatma süresi ve ağ getirme işlemleriyle içeriğe dayalı reklam isteğinin paralel olarak çalışmasına olanak tanımak için devam eden çalışmalar yer alır. Gecikme optimizasyonunun, Chrome geliştiricileri ile FLEDGE test kullanıcıları arasında, API'yi kullanma konusundaki gerçek deneyimlerine dayanarak devam eden bir görüşme olarak devam etmesini bekliyoruz. |
| İlgi Grubu boyutu için bellek sınırı | Tek bir ilgi alanı grubunun boyut sınırını 50 KB'tan yükseltmeyi talep edin. | İsteği aktif olarak değerlendiriyoruz ve hangi sınır değerinin işe yaradığı hakkında geri bildirim bekliyoruz. |
| FLEDGE tarafından sunulan verileri birinci taraf çereziyle birleştirme | FLEDGE, bir reklamverenin birinci taraf verileriyle entegrasyonu destekleyecek mi? | FLEDGE, reklamverenin halihazırda sahip olduğu birinci taraf verilerini kullanarak reklamcılığı desteklemek için oluşturulmuştur. Ancak FLEDGE'in amacı, bir reklamverenin kendi sitesi dışındaki herhangi bir web sitesinde gezinme davranışını öğrenmesini desteklemek değildir. Birinci taraf verilerine site dışı tarama davranışı eklemek, Özel Korumalı Alan'ın hedeflerine aykırıdır. Önümüzdeki haftalarda FLEDGE'in birinci taraf verileriyle entegrasyonu nasıl destekleyeceği hakkında daha fazla ayrıntı içeren entegrasyon kılavuzlarını paylaşmayı planlıyoruz. |
| K-anonimlik değeri | "K" ile "k-anon" değeri nasıl belirlenecek ve yayınlanacak? | "K" değeri henüz kesinleşmemiştir. Planlarımız geliştikçe daha fazla bilgi paylaşacağız. Bilinmeyen k değerinin FLEDGE'e hazırlıklılığı ve makine öğrenimi modeli eğitiminin kapsamını nasıl engelleyebileceği hakkında daha fazla bilgi edinmek isteriz. Bu konuyla ilgili ek geri bildirimler almaktan memnuniyet duyarız. |
| Birden fazla STP'yi destekleme | FLEDGE'de birden fazla STP nasıl desteklenecek? | FLEDGE, bu teklifte belirtildiği gibi çok satıcılı açık artırmaları destekler. |
| Teklif mantığının görünürlüğü | TTP teklif verme mantığının JavaScript'te gösterileceğine dair endişe | Mevcut tasarım teklifi mantığı ile JavaScript'e başkaları tarafından erişilebilir, ancak bunun TTP'ler için neden endişe kaynağı olabileceğiyle ilgili daha fazla geri bildirim almak isteriz. |
| prebid.js | FLEDGE'de prebid.js'yi desteklemeyle ilgili zaman çizelgesi nasıldır? | FLEDGE modülünü yalnızca Prebid.js'nin 7.14 ve sonraki sürümleri destekler. Test yapmak isteyen tüm yayıncılar FLEDGE modülünü eklemeli ve Prebid örneklerini yükseltmelidir. |
| FLEDGE'de kullanıcı tanımlı işlevler | FLEDGE'de kullanıcı tanımlı işlevler (UDF) nasıl desteklenecek? Bunlar, son kullanıcılar tarafından API'nin işlevselliğini genişletmek için programlanabilen işlevlerdir. | Açıklayıcıya buradan ulaşabilirsiniz. Bu çalışmalar henüz tamamlanmadığı için kullanım alanlarıyla ilgili ek geri bildirimleri almaktan memnuniyet duyarız. |
| İlgi Grubu kaynaklarında aynı kaynak kısıtlamasını gevşetme | Reklam teknolojisiyle ilgili belirli kullanım alanlarını etkinleştirmek için İlgi Grubu kaynaklarındaki aynı kaynak kısıtlamasını gevşetme isteği | Mevcut FLEDGE uygulamasında biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl ve trustedBiddingSignalsUrl, ilgi alanı grubu sahibiyle aynı kaynağa sahip olmalıdır.Kısıtlama, burada açıklandığı gibi, saldırganların belirli kötüye kullanımlarını önlemek için uygulanır. |
| ilgiGrubu Sahipliği | Bir reklam teknolojisinin sitelerde aynı İlgi Alanı Grupları için enterinterestGroup'u kullanıp kullanamayacağını sınırlandırma isteği | Kitlelerin nasıl oluşturulduğuna değil, nasıl kullanıldığına odaklanıyoruz. Olası yaklaşımları burada ele alıyor ve sizin de görüşlerinize değer veriyoruz. |
| Anahtar/Değer Sunucusu Anahtarı Geçerlilik Süresi | İlgili ilgi alanı gruplarının süresi dolduktan sonra sunucu anahtarlarının kaldırılmasıyla ilgili tartışma | Anahtar geçerlilik süresini yönetmenin yollarını araştırıyor ve buradan geri bildirim bekliyoruz. |
Dijital Reklamları Ölçme
Attribution Reporting (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Kaynak Deneme trafiği | Mevcut Kaynak Deneme trafiği, kamu hizmeti testi yapmak için yeterli değildir. | Mevcut Kaynak Denemeleri, ekosistem oyuncularının API'nin amaçlandığı şekilde çalıştığından emin olmak için işlevsel testler gerçekleştirmesine yöneliktir. Çeşitli Privacy Sandbox API'lerin geliştirilmesi daha gelişmiş hale geldikten sonra, kamu yararı testleri yapmak için daha fazla trafik gerektiğini anlıyoruz. Mevcut test zaman çizelgesinde, bu durumun 2023'ün 3.çeyreğinde (ör. kullanım alanlarına yönelik teknolojilerin Chrome trafiğinin %100'ünde kullanıma sunulacağı ve Chrome trafiğinin %100'ünde kullanıma sunulacağı zaman) gerçekleştirileceği öngörülmektedir (privacysandbox.com adresindeki güncel zaman çizelgemize bakın).Ek trafik gerektiren kullanım alanı testi hakkında ek geri bildirimleri almaktan memnuniyet duyarız. |
| Farklı Özel Korumalı Alan ölçüm API'lerinin işlevleriyle çakışma | Özel Korumalı Alan'da birden fazla ölçüm yaklaşımının çakışması konusundaki endişeler, Attribution Reporting API ve Private Aggregation API gibi karmaşıklığı artırır. | API'lerin farklı kullanım alanlarını netleştirmek için daha iyi dokümanlar üzerinde çalışıyoruz ve hangi alanların açıklama eksik kaldığına dair ek geri bildirimleri memnuniyetle karşılıyoruz. Örneğin Attribution Reporting API özellikle dönüşüm ölçümünü desteklemek için tasarlanmıştır. Private Aggregation API ve Shared Storage ise siteler arası ölçüm kullanım alanlarını desteklemeyi amaçlayan genel amaçlı API'lerdir. |
| Başarısız rapor isteğini yeniden deneme | Bir rapor isteğinin başarısız olması durumunda kaç kez denendiğine dair açıklama. | Bu konuyla ilgili yol gösterici bilgiler yayınladık. Özetlemek gerekirse, raporlar yalnızca tarayıcı çalışırken/çevrimiçi ortamda gönderilir. İlk kez gönderilemediğinde rapor 5 dakika sonra yeniden denenir. İkinci hatanın ardından rapor 15 dakika sonra yeniden denenir. Sonrasında rapor gönderilmez. |
| Raporlama Gecikmesi | Beklenen raporlama gecikmesi nedir? | Ekosistemden, bu gecikmeleri paralel olarak daha ayrıntılı bir şekilde değerlendirmek için veri toplarken yaşadıkları raporlama gecikmeleriyle ilgili daha fazla geri bildirim almak istiyoruz. |
| Sayfaları önceden oluşturma | ARA ilişkilendirmesi, önceden işleme sayfalarında çalışır mı? | İlişkilendirme kaydı, etkinleştirmeye (gerçek tıklama veya görüntüleme gerçekleşene) kadar önceden oluşturma sayfalarında ertelenir. Bu, "attributionsrc" istek ping'ini erteleyeceğimiz anlamına gelir. |
| Dönüşüm artışını ölçme | Aynı alanda AB testi ile dönüşüm artışını ölçme | Web siteleri, ilişkilendirme raporlaması aracılığıyla aynı alan üzerinde A/B testi uygulayarak dönüşüm artışını ölçebilir. Birleştirilmiş API'yi kullanarak A/B parametrelerini anahtar olarak kodlayabilir ve ardından bu anahtar paketlerine göre dönüşüm değerleri için özet raporlar alabilirler. |
| (3. çeyrekte de raporlanır) Web alanları arası dönüşümler | Alanlar arası (ör. 2 veya daha fazla hedefle) dönüşümleri izleme | 4. Çeyrek Güncellemesi: Web alanları arası görüşmelerin izlenmesini sağlayan açılış sayfası hedef kısıtlamasının kaldırılmasına yönelik bir teklif yayınladık. Bu teklif uygulandı. |
| (3. çeyrekte de raporlanır) Dönüşüm raporundaki süre sonu ayarı |
Destek raporu filtresi isteği / 24 saatten kısa bir süre için geçerlilik süresi | 4. Çeyrek Güncellemesi: Raporlama gecikmesi ve dönüşüm süresinin sona ermesinden kaynaklanan dengeyi azaltmak için geçerlilik süresini ve raporlama aralıklarını ayıracak olan bu alma isteğini paylaşmıştık. Bu özellik artık M110 sürümünde kullanıma sunulmuştur. |
| Sahtekarlık ve Kötüye Kullanım | Reklamverenlerin ve pazarlamacıların, reklamlarının sunulduğu yayıncı sitelerine göre verileri dilim ve toplama istekleri. Bu, olası sahte reklam uygulamaları hakkında daha fazla bilgi sağlar. | Bu geri bildirim burada aktif olarak tartışılmaktadır, sizin de görüşleriniz bizim için değerlidir. |
| (3. çeyrekte de raporlanır) Etkinlik düzeyinde raporlama gecikmesi | Etkinlik düzeyinde raporlamada 2-30 günlük gecikme, belirli kullanım alanları için çok uzun olabilir. | Etkinlik düzeyinde raporlamanın varsayılan raporlama aralıkları 2, 7 ve 30 gündür. Bu, "expiry" parametresi kullanılarak değiştirilebilir. Reklam teknolojileri, potansiyel raporları 2 günden kısa sürede almak için geçerlilik süresini en az 1 gün olacak şekilde yapılandırabilir. Daha ayrıntılı raporlama, zamanlama saldırılarına neden olabileceğinden gizlilik koruma mekanizması olarak geçerlilik süresinin ayrıntı düzeyini 1 günle sınırlandırıyoruz. Ayrıca, etkinlik düzeyi ve toplu raporlar için bağımsız "geçerlilik süresi" parametreleri belirlenmesine izin verilir. Buraya bakın. Ayrıca Google Ads, diğer reklam teknolojileri tarafından Attribution Reporting API aracılığıyla sunulmayan özel raporlama aralıklarından da yararlanamaz. |
| Aynı raporlama kaynağı koşulu | Kaynak kayıt kaynağının dönüşüm kaydı kaynağıyla aynı olması şartını kaldırma isteği | Bu kullanım senaryosunu çözmek üzere, kayıt yetkisi vermek için HTTP yönlendirmelerinin kullanılmasını öneriyoruz. Yeni kılavuzla ilgili ek geri bildirimlerinizi almaktan memnuniyet duyarız. |
| Dönüşüm izleme | Dönüşümün, reklamveren tarafından ayarlanan belirli saatlerden önce mi, sonra mı gerçekleştiğini ayırt etmek gerekir. | Attribution Reporting API, kaynak ilişkilendirmesi için bir süre sonu aralığı ve önceliği ayarlamayı destekler. İkisini birden kullandığınızda, X gün aralığında gerçekleşen bir dönüşümü, X tarihinden sonra gerçekleşen bir dönüşümden ayrı olarak ilişkilendirmek teknik olarak mümkün olacaktır. |
| Gürültü simülasyonu | Dönüşüm sayısının daha az olan reklamverenler üzerindeki etkisini anlamak için grup başına farklı dönüşüm hacimlerini simüle etmeyi isteyin. | Noise Lab'in gelecekteki sürümlerinde bunu simüle edecek yöntemler eklemek istiyoruz. Başka geri bildirimleriniz varsa lütfen bize bildirin. |
| Mobil cihazlarda raporlama | Chrome mobil cihazlarda arka planda çalışırken rapor yine de gönderilir mi? | Şu anda mobil cihazlarda bile, Chrome arka plandayken rapor gönderilemez. API, Android Özel Korumalı Alan ile entegre olduğunda bu durum büyük olasılıkla değişir. Buraya bakın. Android Özel Korumalı Alan'ın, CMA tarafından kabul edilen Taahhütlerin bir parçası olmadığını unutmayın. |
| Veri kullanılabilirliği | Google'ın, Özel Korumalı Alan API'leri aracılığıyla verilere ek erişimi olacağına dair endişeler | Öncelikle Google Ads, Attribution Reporting API veya diğer Privacy Sandbox API'lerinden gelen verilere herhangi bir imtiyazlı erişim hakkı elde etmez. Bu sorun, Google'ın Taahhütleri hakkında daha ayrıntılı bilgi içeren"Birlikte çalışabilirlik" başlığı altındaki Genel Geri Bildirim bölümünde de ele alınmaktadır. İkinci olarak, Google daha büyük ve daha küçük siteler arasındaki farkta, gürültüye dayalı gizlilik korumalarının daha küçük veri dilimlerinde daha fazla etkiye sahip olabileceğini kabul eder. Bununla birlikte, bazı olası hafifletmeler vardır: Örneğin, daha uzun zaman dilimlerinde toplama gibi yöntemler bu sorunu çözecektir. Bununla birlikte, çok küçük veri dilimlerine dayanan (örneğin, bir veya iki satın alma işlemi) sonuçların reklamverenler için anlamlı olup olmadığı belirsiz. Kaynak denemesi sırasında Google, test kullanıcılarını çok çeşitli gizlilik ve gürültü parametresiyle deneme yapma olanağından yararlanmaya teşvik etti. Böylece kullanıcılar bu sorun hakkında daha net geri bildirim verebilecek. |
Gizli Takibi Sınırla
Kullanıcı Aracısı Azaltma
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Web ekosistemi daha hazır olana kadar kullanıcı aracısı azaltma işlemini geciktir | Yakında yapılacak kullanıcı aracısı azaltma değişikliklerine uyum sağlamak için yeterli zaman yok. | Bu geri bildirime, "Google'ın CMA ile etkileşimi " başlıklı bölümün "Paydaş Endişeleri" başlığı altında yer alan tam raporda ele alıyoruz. |
| Web ekosistemi daha hazır olana kadar kullanıcı aracısı azaltma işlemini geciktir | Yapılandırılmış Kullanıcı Aracıları (SUA) dağıtılana kadar Kullanıcı Aracısı Kısaltma'nın kullanıma sunulmasını erteleme isteği | Google Ads ekibi, Ekim 2021'de OpenRTB'ye Yapılandırılmış Kullanıcı Aracısı eklenmesini önerdi (spesifikasyona bakın). Bu özellik, Nisan 2022'de yayınlanan 2.6 spesifikasyon güncellemesine dahil edilmiştir. SUA oluşturmak için UA-CH ve WURFL API'nin nasıl kullanılacağını gösteren Scientia Mobile blog yayınında gösterildiği üzere SUA'nın şu anda dağıtıldığına ve kullanıma sunulduğuna dair bazı kanıtlar elde ediyoruz. |
###
Kullanıcı Aracısı İstemci İpuçları
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| UA-CH'yi diğer gizli izleme teknikleriyle test etmek | Tüm Özel Korumalı Alan API'lerinin ve dijital parmak izi tekniklerinin bütüncül bir yaklaşımla birlikte test edilmesiyle ilgili rehberlik | Test planımız, Korumalı Alan Teklifleri'nin geri kalanına karşı, parmak izi karşıtı önlemlerin bazılarını geliştirmeyle ilgili eşzamansız zaman çizelgelerini yansıtacak şekilde tasarlanmıştır. Bu politikada, parmak izi etkisiyle ilgili bazı önlemlerin (ör. Gizlilik Bütçesi, IP Koruması ve Hemen Çıkma Durumunu İzleme Çözümleri) tam olarak geliştirildiği ve ancak üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ardından Genel Kullanım için kullanıma hazır olacağı gerçeği ele alınmaktadır. Bu parmak izi önleyici tedbirler niceliksel testlere dahil edilmeyecektir. Ancak duruşma sırasında elde edilen bilgilere dayalı niteliksel değerlendirmeye tabi tutulacaktır. |
| (2. çeyrekte de raporlanır) Performans |
Critical-CH (ilk sayfa yüklemesinde) üzerinden ipuçları almanın gecikmesiyle ilgili endişeler | Aşağıdaki UA-CH ile ilgili bölümü inceleyin |
| Yetersiz Geri Bildirim | UA-CH değişikliğiyle ilgili olarak ekosistemden alınan geri bildirimler yeterli olmayabilir. Bu durum, ekosistemden farkındalık eksikliği olduğu konusunda endişelere yol açmaktadır. | Ürünlerimizi dikkatli bir şekilde kullanıma sunarak kesintiyi en aza indirebilmek için planlarımızı proaktif olarak paylaşıyoruz. Kullanıcı Aracısı Azaltma ve UA-CH API ile ilgili planlar, 18 Mart 2022'de W3C Sahtekarlıkla Mücadele Topluluk Grubu'na, 20 Ocak 2022'de ise hem Web Ödemeleri Çalışma Grubu hem de Web Ödemeleri Güvenlik İlgi Grubu'na sunuldu. Sunumlar sırasında veya sonrasında önemli bir endişe duyulmamıştır. Google, geri bildirim almak için 100'ü aşkın site operatörüyle proaktif olarak etkileşime geçti. Dahası Google, ekosistem paydaşlarından gelen geri bildirimlere dayanarak kullanıcı aracısının azaltılma sürecini herkese duyurmak için Blink-Dev kanallarını da kullandı. |
| Zamanlama | Kullanıma sunma sürecinin zamanlaması ve sektörün hazırlıklılığı ile ilgili endişeler var | Aşağıdaki UA-CH ile ilgili bölümü inceleyin |
| Chrome Platformu Durumu | UA-CH chromestatus sayfasının güncellenmesi istendi | chromestatus girişi 19 Aralık'ta "Karma sinyaller" olarak güncellendi. |
IP Koruması (eski adıyla Gnatcatcher)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Etkinleştirme veya Devre Dışı Bırakma | IP Adresi Gizliliği Etkinleştirilsin mi, Etkinleştirilsin mi? | Amacımız tüm kullanıcılara IP Koruması sunmaktır. Bu hedefi göz önünde bulundurarak, şu anda IP Koruması için kullanıcı seçimlerini değerlendiriyoruz. |
| Birinci taraf verileri için IP Adresi kullanım alanı | IP Koruması sonrasında birinci taraf alanlarındaki kullanıcı yolculuklarını birleştirmek için IP adresleri kullanılabilir mi? | Daha önce yayında olduğu gibi, IP Koruması başlangıçta üçüncü taraf bağlamında izlemeye odaklanacaktır. Diğer bir deyişle, birinci taraf alanlar etkilenmeyecektir. |
| Reklam teknolojisi kullanım alanları | Şirketler, IP Koruması ile sahtekarlıkla mücadele önlemlerini nasıl alabilir? | IP adresinin, günümüzde web'deki sahtekarlıkla mücadele çalışmaları için bir işaret olarak önemli olduğunun farkındayız. CMA Taahhütlerimizin bir parçası olarak (paragraf 20), web sitelerinin spam ile ve sahtekarlıkla mücadele çabalarını desteklemek için makul çaba göstermeden IP Koruması'nı uygulamayacağımızı belirttik. En önemli önceliklerimizden biri, şirketlerin web güvenliğini korumalarına yardımcı olan gizliliği korumaya yönelik teknolojilere daha fazla yatırım yapabilmek için IP korumasının sahtekarlıkla mücadele kullanım alanlarını ve tespit özelliklerini nasıl etkilediğini anlamaktır. Sinyaller zaman içinde değişse bile güvenlik ve sahtekarlıkla mücadele şirketlerinin ihtiyaçlarını desteklemeyi amaçlayan geri bildirimleri ve yeni tekliflere katkıda bulunuruz. |
| Sahtekarlık ve Kötüye Kullanım | IP koruması, Hizmet Reddi (DoS) Koruması'nı içerir mi? | Web'i güvenli bir şekilde tutarken gizliliği artırmaya büyük önem veriyoruz. Hizmet reddi saldırılarına karşı koruma sağlamak, kötüye kullanıma karşı tasarlanması gereken önemli bir kullanım alanıdır. Hem IP Koruması'nın kendisinin tasarımı hem de kötüye kullanım karşıtı yeni çözümler aracılığıyla DoS korumaları üzerindeki etkiyi en aza indirmeyi umuyoruz. IP Koruması başlangıçta üçüncü taraf yerleşik hizmetlere odaklandığından bazı paydaşlar, birinci taraf sitelerin DoS koruması üzerindeki etkisinin sınırlı olacağını belirtmiştir. Ancak DoS kullanım alanları (özellikle de üçüncü taraf yerleşik hizmetler) üzerindeki riski değerlendirmek için herkese açık geri bildirim istemeye devam ediyoruz. Buna paralel olarak, bir site veya hizmetin spam içerikli kullanıcıları kimliğini tanımlamadan engellemesine olanak tanıyan kötüye kullanım geri bildirimi ve istemci engelleme mekanizmalarını araştırıyoruz. |
| İçerik Filtreleme | IP Koruması ile içerik filtreleme | Farklı şirketlerin, içerik filtreleme ve kullanıcı deneyimini özelleştirme konusunda farklı gereksinimleri vardır. Bu tür pek çok kullanım alanı şu anda IP adreslerine dayanmadığından IP Koruması'ndan da etkilenmemelidir. Örneğin, içeriğini özelleştirmek ve daha fazla etkileşim elde etmek isteyen bir yayıncı, kullanıcının ilgi alanlarını ve yayıncıyla önceki etkileşimlerini anlamak için birinci taraf çerezleri veya üçüncü taraf bölümlendirilmiş çerezleri (ÇIP'ler) kullanabilir. Veya doğru kullanıcıya doğru reklamı sunmaya odaklanan bir reklam teknolojisi iş ortağı, örneğin üçüncü taraf çerezleri veya diğer siteler arası izleme teknolojileriyle bugünkü gibi reklam sonuçları elde etmek için FLEDGE ve Topics'i kullanabilir. Ayrıca, mevcut mekanizmaların yetersiz olabileceği durumlarda içerik filtrelemeyi daha da desteklemek için IP Koruma'da gizliliği korumaya yönelik yeni özellikler (ör. kaba coğrafi konum) geliştirmeyi de araştırıyoruz. IP Koruması'ndan etkilenebilecek içerik filtreleme kullanım alanları hakkında ek geri bildirimler almaktan memnuniyet duyarız. |
| (3. çeyrekte de raporlanmıştır) Coğrafi konum kullanım alanları |
IP Koruması, gelecekte coğrafi konuma göre içerik kişiselleştirme gibi geçerli coğrafi konum kullanım alanlarının işe yaramasını önleyebilir. | 4. Çeyrek Güncellemesi: Chrome'un, IP adresleriyle ilgili meşru kullanım alanlarını desteklemeye devam ettiğinden emin olmak için paydaşlarla birlikte çalışıyoruz. Burada, IP Coğrafi Konum ayrıntı düzeyiyle ilgili ekosistem geri bildirimlerini öğrenmek istiyoruz. |
Gizlilik Bütçesi
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Daha net belgeler | Paydaşların, Gizlilik Bütçesi uygulandığında nasıl sınırlanabileceğini öngörmek için daha fazla örnek | Gizlilik Bütçesi teklifi hâlâ aktif olarak tartışılmaktadır ve herhangi bir tarayıcı tarafından uygulanmamıştır. Ölçeklenebilirliğin en erken tarihi, Gizlilik Bütçesinin uygulanabileceği en erken tarihi temsil eder. Bu değişiklik, 2024'te üçüncü taraf çerezlerinin kaldırılmasından önce gerçekleşmeyecek. Şu anda paylaşabileceğimiz başka doküman bulunmuyor. Kesinleşmiş teklifle ilgili daha fazla ayrıntıyı sizinle paylaşacağız. Bu esnada, teklifin geliştirilmesine yardımcı olacak geri bildirimlerinizi paylaşmak konusunda paydaşlardan memnuniyet duyarız. |
Siteler arası gizlilik sınırlarını güçlendirin
Birinci Taraf Gruplar
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (3. çeyrekte de raporlanır) Alan sınırı | İlişkilendirilmiş alan adlarının sayısını artırma isteği | 4. Çeyrek Güncellemesi: GitHub'da bir örnek grubu gönderme işlemi ve rSA ile rSAFor'u yerel olarak test etmek için bir işaret de dahil olmak üzere yerel test için FPS'yi kullanıma sunduk. İlgili alt grubun kullanım alanlarıyla ilgili soruları yanıtlamaya devam etmek amacıyla FPS'de geliştiriciler için iki açık toplantı da düzenledik. İlgili alt kümeye yönelik alan sınırının kendi kullanım alanları için FPS'nin kullanılabilirliğini nasıl etkileyebileceği konusunda geri bildirim sağlamak üzere geliştiricilerin FPS işlevini test etmelerini öneririz. WICG çağrılarında Chrome'un, kullanıcıların gizlilik çıkarlarını da dikkate alan kullanılabilir bir çözüm sunmayı taahhüt ettiğini netleştirdik. Bu bağlamda, alan sınırından etkilenebilecek belirli kullanım alanlarıyla ilgili topluluktan geri bildirim almak isteriz. Böylece ekibimiz, kullanıcı gizliliğini korumaya devam ederken bu kullanım alanlarını ele almanın yollarını düşünebilir. |
| Kötüye kullanımı azaltma önlemleri hakkında daha fazla bilgi isteği | Bir alan, kullanıcının izin vermediği bir gruba eklenirse ne olur? | Birinci Taraf Gruplar ile ilgili gönderim yönergelerini 2 Aralık 2022'de burada yayınladık. Gönderim yönergelerinde açıklandığı gibi tüm değişiklik yönetimi, GitHub'daki doğrulama sürecini (sahipliği doğrulama dahil) takip eder ve yerine getirir. Bu süreç, riski azaltır. |
| Kötüye kullanımı azaltma | Birinci Taraf Grup oluşumlarının kötüye kullanılabileceğine dair endişe | Alt grup türleri için teknik kontrollerin kapsamını genişletmenin yollarını araştırıyor ve buradaki topluluktan ek bilgiler almak istiyoruz. |
| Reklamların kullanım alanları | Reklam hedeflemeyi desteklemek için Birinci Taraf Gruplar'ın kullanılıp kullanılmayacağıyla ilgili sorular | Birinci Taraf Gruplar için reklam hedefleme kullanım alanlarını desteklemeye çalışmıyoruz. Bu tür kullanım alanları için mevcut Ads API'lerini kullanmanızı öneririz. |
| (3. çeyrekte de bildirilmiştir) Politika | GDPR'nin bir kümedeki site sayısına sınır getirmediği ve FPS'de 3 adetlik sınır öngördüğü için FPS'nin "Geçerli Veri Koruma Mevzuatı"na ilişkin CMA Taahhütleri ile tutarlı olmadığına dair endişe | 3. çeyrekteki yanıtımız değişmeyecek: "Google, Özel Korumalı Alan tekliflerini, kendi işletmesini tercih ederek rekabeti bozmayacak şekilde tasarlamak ve uygulamak, ayrıca dijital reklamcılık, yayıncılar ve reklamverenler üzerindeki rekabeti, ayrıca Geçerli Veri Koruma Mevzuatı'nda belirtilen gizlilik sonuçları ve veri koruma ilkelerine uygunluk üzerindeki etkiyi dikkate almak amacıyla CMA'ya uymayı sürdürmektedir. İfade edilen endişede, GDPR ile herhangi bir uyumsuzluk açıklanmamaktadır. Çalışmalarımızın bu taahhütlere uygun olmasını sağlamak için CMA ile yakın işbirliği içinde çalışmaya devam ediyoruz." |
| Alternatif teklif | GDPR Onaylı Kümeler | "GDPR Tarafından Doğrulanmış Kümeler"i kullanmaya başlama teklifiyle ilgili ekosistem tarafından sağlanan geri bildirimin yanı sıra Chrome, bu alternatif teklifin aşağıdaki sınırlamalarıyla ilgili endişeler de taşımaktadır:
Bu alternatif kullanıma sunulduğundan beri Chrome, Birinci Taraf Grup teklifini güncelledi ve yeni gruplar oluşturmak için gönderim yönergelerini yayınladı. |
Çitli Çerçeveler API'sı
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| OT sırasında sınırlı çerçeveler ile ilgili kısıtlamalar | Kaynak Deneme süresi için Özel Çerçeveler ile ilgili mevcut kısıtlamalar nelerdir? | Kısıtlamalar ve uygulama durumu ile ilgili dokümanlar üzerinde çalışıyoruz ve bunları 2023'ün 1. çeyreğinde paylaşmayı planlıyoruz. |
| Tek bir sınırlı çerçevede birden çok reklam | Bir açık artırmada bir Kısıtlanmış Çerçeve içinde birden çok reklamvereni görüntüleme isteğinde bulunma | Şu anda bu istek aktif olarak geliştirilmese de ekosistem oyuncuları bu özelliği önemli bulursa ek geri bildirimler almaktan memnuniyet duyarız. |
| Web Paketleri | Kısıtlanmış Çerçevelere Sahip Web Paketleri için hangi gereksinimler ve destek planlanmaktadır? | Bunun gelecekte gerekli olup olmayacağıyla ilgili bir güncelleme bulunmuyor. Yapılan değişiklikler önceden duyurulur ve üçüncü taraf çerezleri kullanımdan kaldırılmadan önce bunlar zorunlu kılınmaz. Mevcut durum için lütfen bu açıklayıcıyı inceleyin. |
Shared Storage API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Reklam Teknolojileri için Paylaşılan Depolama Alanı | Reklam teknolojisi kullanım alanları için paylaşılan depolama alanının kullanımıyla ilgili belirsizlik | Shared Storage ve Private Aggregation API, siteler arası depolama ölçümü gerektiren farklı ölçüm amaçları için kullanılabilir. Bazı örnekler burada listelenmiştir. TTP ve Ölçüm çözümü sağlayıcılarının, reklam kullanım alanları için ana entegratör olacağını öngörüyoruz. |
ÇİPLER
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (3. çeyrekte de raporlanır) Bölümlendirilmiş gereksinim | Birinci taraf çerezlerde "Bölümlendirilmiş" özellik için açık davranış şartı ekleyin. | 4. Çeyrek Güncellemesi: GitHub ve PrivacyCG çağrılarıyla ilgili tartışmalardan sonra, birinci taraf çerezlerde ayarlanan Bölümlendirilmiş çerezler için (A, A) bölüm anahtarı kullanılacak, burada "A" üst düzey site olacaktır. Bu davranışı açıklayıcıda ve spesifikasyonda belgeleyeceğiz. |
| Çerez Yönetimi | Birinci taraf veya üçüncü taraf çerezlerini yönetmek/yönetmek için kullanılan araçlar var mı? | Chrome Geliştirici Araçları ve NetLog, üçüncü taraf çerez engellemenin etkinleştirildiği siteleri test etmek için kullanılabilir. Her iki araç da kullanıcı yapılandırması nedeniyle çerezler engellendiğinde bunu bildirir. Web sitelerinin ne tür ilave denetlemeler görmek istediği konusunda geri bildirimlerinizi almaktan memnuniyet duyarız. |
FedCM
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| IdP'nin bir oturuma izin verebilmesi için RP hakkında bilgi sahibi olması gerekir | Kullanıcının iki farklı RP'den Feide IdP'ye giriş yapmaya çalışmasıyla ilgili sorun | Bu sorunun olası çözümlerini burada tartışıyoruz. |
| Birlikte çalışabilirlik | Kullanıcılar ile FedCM'yi kullanarak giriş yaptıkları web siteleri arasındaki ilişki ve web siteleri arasında "birlikte çalışabilirlik" FedCM'nin etkisine ilişkin endişeler | FedCM, üçüncü taraf çerezleri Chrome'dan kaldırıldıktan sonra şu anda üçüncü taraf çerezlerini kullanan birleşik kimlik hizmetlerini desteklemeye devam etmeyi hedeflemektedir. FedCM'nin bu tür hizmetler için yalnızca bir seçenek olmasını bekliyoruz. Kimlik sağlayıcılar (IdP'ler) ve bağlı taraflar (RP'ler), ihtiyaçlarına daha uygun olabilecek diğer teknolojileri ücretsiz olarak kullanabilecektir. Kullanıcı-RP ilişkisi ve "birlikte çalışabilirlik" hakkındaki endişelerin FedCM teklifinin yanlış anlaşılmasından kaynaklandığı anlaşılıyor. FedCM, söz konusu RP'nin sitesinde oturum açmayı seçtiğinde, RP ile hangi bilgilerin hangi biçimde paylaşılacağına karar vermesi için bunu IdP'lere bırakır. FedCM, IdP'lerin "kullanıcının kimlik doğrulaması yaptığı her [RP] için benzersiz bir anonimleştirme tanımlayıcısı oluşturmasını" zorunlu kılmaz. Bunun yerine, FedCM her IdP için kullanıcının gerçek tanımlayıcısının, bu tanımlayıcının site başına sürümünün veya bu bilgilerin başka bir sürümünün paylaşılıp paylaşılmayacağını seçmek üzere açıktır. (FedCM spesifikasyonu, siteler arası korelasyonu API ile ilişkili bir gizlilik riski olarak tanımlar ve olası bir çözüm olarak yönlendirilmiş (site başına) tanımlayıcıları ele alır. Bununla birlikte, yönlendirilen tanımlayıcıların kullanılıp kullanılmayacağına karar verme yetkisi tarayıcı tarafından değil, IdP'lere aittir.) FedCM ayrıca, kimlik konusunda da kullanıcılara seçim imkanı tanıyor. Örneğin, bir kullanıcının aynı IdP'de birden çok kimliği varsa (ör. iş profili ve kişisel profil) FedCM, kullanıcıya RP'nin sitesine giriş yapmak için kullanmak istediği kimliği seçmesi için bir yol sunar. Bunun ötesinde, her RP, sitesinde hangi IdP'lerin destekleneceğine kendi karar verir. Bu kararın bir tarafı da IdP'nin kullandığı mekanizma (FedCM veya farklı bir teknoloji) dikkate alınır. Aynı şekilde tarayıcı, RP'ler veya IdP'ler için bu seçimleri belirtmez. |
Spam ve sahtekarlıkla mücadele edin
Private State Token API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Botları Yönetme | Kartı veren kuruluş, botlara Gizlilik Jetonları verildiğini tespit ederse ne olur? | Botlara verilen jetonların uzun süre ekosistemde kalmasını önlemek amacıyla, kart veren kuruluşlar, jetonları imzalamak için kullandıkları anahtarları düzenli olarak değiştirmelidir. Böylece, sorun teşkil edebilecek eski jetonların geçerlilik süresi sona erer ve siteler, yeni jetonları güncellenmiş düzenleme mantığıyla kullanır. |
| Aynı siteden form gönderimleri | Gizlilik Jetonları, fetch/XMLHttpRequest API'lerinden gelen bir istek yerine tam sayfa gezinme içeren (ör. Content-Type: application/x-www-form-urlcoding) aynı site formu gönderimleri için kullanılabilir mi? | Bu özellik şu anda Gizlilik Jetonlarının ilk sürümünde desteklenmemektedir. Bu kullanım alanına yönelik yoğun bir talep varsa ekosistemden gelen geri bildirimleri memnuniyetle karşılarız. |
| Sunucu tarafı doğrulama | Gizlilik Jetonlarının sunucu tarafında doğrulanıp doğrulanamayacağıyla ilgili sorular | Jetonlar, kartı veren kuruluşa karşı kullanılır. Ardından kartı veren kuruluş, jetonun kendisini veya jetondan türetilmiş bazı imzalanmış değerleri içerebilen bir teklif kullanma kaydı oluşturur. Sunucular, jetonun doğruluğunu doğrulamak için bu teklif kullanma kaydını kullanabilir. Tekliften yararlanan farklı ekosistemlerin, kullanım kayıtlarını yorumlama konusunda farklı standartlar ortaya koymasını bekliyoruz. |