Privacy Sandbox teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2022 4. ç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 | Özet | Chrome Yanıtı |
|---|---|---|
| (3. çeyrekte de raporlanmıştır) Farklı paydaş türleri için kullanışlılık |
Özel Korumalı Alan teknolojilerinin daha büyük geliştiricileri desteklediği ve özel (küçük) sitelerin genel (büyük) sitelerden daha fazla katkıda bulunduğuyla ilgili endişeler | Yanıtımız 3. çeyrektekinden farklı değil: "Google, Gizlilik Korumalı Alan tekliflerini Google'ın kendi işletmesini tercih ederek rekabeti bozmayacak şekilde tasarlayıp uygulamayı ve dijital reklamcılıktaki rekabeti, yayıncıları ve reklamverenleri (büyüklüklerinden bağımsız olarak) etkileyen unsurları 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ğerlendirmeye alacağımız önemli sorulardan biri olacaktır. Bu bağlamda geri bildirimler, özellikle de teknik tasarımları daha da iyileştirmemize yardımcı olabilecek spesifik ve uygulanabilir geri bildirimler çok önemlidir. Nicel teste yaklaşımımızı geliştirmek için CMA ile birlikte çalıştık ve CMA'nın pazar katılımcılarına daha fazla bilgi sağlamak ve önerilen yaklaşımlar hakkında yorum yapma fırsatı sunmak için deneme tasarımıyla ilgili bir not yayınlamasını destekliyoruz." |
| (3. çeyrekte de raporlanmıştır) Belge istekleri |
Test, analiz ve uygulamanın nasıl yönetileceğini ayrıntılı olarak açıklayan daha fazla kaynak isteğinde bulunma | 4. Çeyrek Güncellemesi: Geliştiricilerin mevcut materyalimizi faydalı bulmasından memnuniyet duyuyoruz. Geliştiricilerin yeni teknolojilerin kendileri için nasıl yararlı olabileceğini anlayabilmesi amacıyla daha fazla materyal sunmaya devam ediyoruz. Geçtiğimiz çeyrekte privacysandbox.com adresine bir "Haberler ve Güncellemeler " bölümü 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 herkese açık geliştirici ofis saatleri oturumları ve canlı tartışma/soru sorma olanağı sunan ürün ve mühendislik yöneticileriyle soru-cevap oturumları düzenledik. |
| Önemli Web Verileri | Özel Korumalı Alan API gecikmesi, Core Web Vitals'ı nasıl etkiler? | Gecikmeyi en aza indirmek, Özel Korumalı Alan API'lerinin temel tasarım hedeflerinden biridir. API'lerin çoğu web sitesinin ilk oluşturulmasından sonra çağrıldığı için API gecikmesinin, sitenin Önemli Web Verileri üzerinde minimum düzeyde bir etkisi olacağını tahmin ediyoruz. Her API için gecikmeyi daha da azaltmak amacıyla izleme ve iyileştirme yapmaya devam ediyoruz. Test ve geri bildirim sağlamaya devam etmenizi öneririz. Gerçek zamanlı teklif verme sürecindeki gecikme, "FLEDGE Açık Artırmalarının Performansı" bölümündeki FLEDGE bölümünde ele alınmıştır. |
| Birlikte çalışabilirlik | Diğer olası çözümlerle birlikte çalışabilirlik konusundaki endişeler | Özel Korumalı Alan'ın amacı, web ekosisteminin ihtiyaçlarını desteklerken kullanıcıları siteler arası izlemeye karşı korumaktır. Bunu, üçüncü taraf çerezleri gibi siteler arası izlemeyi sağlayan eski tarayıcı teknolojilerinden uzaklaşarak ve bunların yerine belirli kullanım alanlarını desteklemek için özel olarak tasarlanmış yeni teknolojiler sunarak gerçekleştirmeyi amaçlıyoruz. Özel Korumalı Alan teklifleri, kullanıcının cihazından çıkan verileri sınırlandırarak gizliliği iyileştirir. Öneriler, bir web sitesinin tarayıcıdan toplanan verileri paylaşma veya başka bir şekilde işleme özelliğine teknik kısıtlamalar getirmez. Bu nedenle, teknolojiler şirketlerin "veri yönetimi" sözleşmeleri veya benzer sözleşme ilişkileri yapmasını engellemez. Benzer şekilde, kullanıcıların verilerini başka yöntemlerle paylaşmaya izin vermelerini de kısıtlamaz. Google, Özel Korumalı Alan teknolojilerini Google ürün ve hizmetleri de dahil olmak üzere tüm web sitelerinde aynı şekilde uygulamayı taahhüt etmiştir. Chrome, üçüncü taraf çerezlerini desteklemeyi sonlandırdıktan sonra Google, dijital reklamcılığın hedeflenmesinde veya ölçülmesinde kullanıcıları izlemek için kullanıcıların senkronize edilmiş Chrome tarama geçmişi gibi diğer kişisel verileri de kullanmayacağını taahhüt eder. |
Alakalı İçerik ve Reklamlar Gösterme
Konular
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Google arama sıralaması üzerindeki etkisi | Bir web sitesinin Topics API desteğinin, Google Arama sonuçları sıralaması için potansiyel bir sinyal olarak kullanılıp kullanılmayacağıyla ilgili sorgu | Bazı web siteleri Topics API'yi devre dışı bırakmayı seçebilir. Özel Korumalı Alan ekibi, web sitelerinin Topics API'yi benimsemesi için bir teşvik olarak sayfa sıralamasını kullanması konusunda Arama kuruluşuyla koordinasyon kurmamış veya bu kuruluştan böyle bir talepte bulunmamıştır. Google, CMA'ya Google Arama'nın, bir sitenin Topics API'den kapsam dışında kalma kararını sıralama sinyali olarak kullanmayacağını 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. | Kullanıcıların tarama geçmişi şu anda web sitesinin ana makine adları kullanılarak sınıflandırılmaktadır. Chrome, Konu sınıflandırmasında sayfa düzeyindeki meta verileri (ör. sayfa URL'sinin ve/veya içeriğinin tüm veya bazı bileşenleri) dikkate alma seçeneklerini değerlendirmeye devam etmektedir. Tüm işlevsellik iyileştirmeleri, gizlilik ve kötüye kullanım riskleriyle birlikte değerlendirilmelidir. Örneğin, özellikle meta verilerle ilgili risklerden bazıları şunlardır: - Farklı (ve potansiyel olarak hassas) anlamları konulara kodlamak için sayfa düzeyinde meta verileri değiştiren siteler; - Finansal kazanç elde etmek amacıyla konularını 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 etki |
Topics sinyali oldukça değerli olabilir ve bu nedenle diğer ilgi alanına dayalı birinci taraf sinyallerinin değerini düşürür. | Yanıtımız 3. çeyrektekinden farklı değil: "İlgi alanına dayalı reklamcılığın web için önemli bir kullanım alanı olduğuna ve Topics'in bu kullanım alanını desteklemek için tasarlandığına inanıyoruz. 3. çeyrek raporumuzda açıklandığı gibi, ekosistemin diğer paydaşları, Topics'in değer sağlayacak kadar yararlı olmayabileceği konusunda endişelerini dile getirdi. Taksonomideki iyileştirmeler her durumda devam eden bir çalışmadır ve taksonominin ekosistem testleri ve girdileriyle birlikte gelişeceğini umuyoruz." |
| Sınıflandırmayı güncelleme | Sınıflandırma listesi nasıl güncellenir? | Ekosistem için en yararlı olabilecek sınıflandırma ile ilgili olarak geri bildirim istiyoruz. İlk Topics API teklifine dahil edilen sınıflandırma, işlevsel testleri etkinleştirmek için tasarlanmıştır. Chrome, sınıflandırmayı güncellemek için birden fazla yaklaşımı aktif olarak değerlendiriyor. Örneğin, Chrome gelecekteki iterasyonlara hangi kategorinin dahil edileceğini belirlemek için her konu için ticari değer kavramından yararlanabilir. |
| Konuların bölgesel sınıflandırıcı performansı | Konu sınıflandırıcı, bölgesel alanlarda düşük performans gösteriyor | Sınıflandırıcıyı iyileştirmek için sürekli çalışmalarımız devam etmektedir. Aldığımız geri bildirimler doğrultusunda, Topics geçersiz kılma listesini genişletmeyi düşünüyoruz. Analizlerimiz, bu değişikliğin küresel kapsamı artıracağını ve doğruluğu iyileştireceğini gösteriyor. Konular API sınıflandırmasının iki ilgili bileşeni vardır: (1) En popüler 10.000 siteyi ve konularını içeren bir geçersiz kılma listesi ve (2) ana makine adlarını konulara sınıflandıran cihaz üzerinde bir ML modeli. Geçersiz kılma listesini (1) genişleterek sınıflandırıcının kötü performans gösterebileceği bölgelerde sınıflandırma performansını iyileştirebiliriz. |
| Bir haftalık dönem | Bir haftalık dönem, kısa vadeli kararlar almak isteyen kullanıcılar için çok uzundur. | Uygun dönem uzunluğunun ne olması gerektiğine dair aktif olarak çalışmalarımızı sürdürüyoruz. Ekosistem için daha iyi bir dönemin ne olabileceği konusunda daha fazla geri bildirim almaktan memnuniyet duyarız. |
| HTTP üstbilgisi alma | Konuların HTTP üst bilgisinin alınmasıyla ilgili yeterli bilgi bulunmaması | Başlıklar ve fetch() için çalışmalar devam etmektedir. Burada da bilgi bulabilirsiniz. Açıklayıcıya skipObservation bilgilerini de ekledik. |
| Topics, kullanıcılara değil yalnızca reklamverenlere yardımcı olmayı amaçlar. | Topics/Privacy Sandbox, sektör odaklı bir yaklaşım gibi görünüyor. Kullanıcılar için avantaj, sektör için avantaj kadar net değil. | Topics'in kullanıcılara sağladığı avantajın, web'i özgür ve açık tutan ilgi alanına dayalı reklamları desteklemesi olduğunu düşünüyoruz. Ayrıca Topics'in, üçüncü taraf çerezlerine kıyasla gizliliği önemli ölçüde iyileştirdiğini de düşünüyoruz. Üçüncü taraf çerezlerini uygulanabilir alternatifler olmadan kaldırmak yayıncıları olumsuz yönde etkileyebilir ve daha az gizli, şeffaf olmayan ve gerçekçi bir şekilde sıfırlanamayan veya kullanıcılar tarafından kontrol edilemeyen daha kötü yaklaşımlara yol açabilir. Birçok şirket Topics ve Sandbox API'lerini etkin bir şekilde test ediyor. Biz de gizliliği ilerletecek ve web'i destekleyecek araçları sunmaya kararlıyız. W3C Teknik Mimari Grubu kısa süre önce Topics API ile ilgili ilk görüşünü yayınladı. Bu görüşe herkese açık olarak yanıt vereceğiz. Bu aşamada Google, ekosistemden bu incelemenin Topics API'nin geliştirilmesi ve kullanıma sunulması açısından ne anlama gelebileceğiyle ilgili sorular aldığından, bu API'yi bu yıl Chrome kararlı sürümünde kullanıma sunma planımızı yeniden teyit etmek isteriz. Google, W3C Teknik Mimari Grubu'nun katkılarını takdir etmekle birlikte, CMA ve ekosistemle istişare halinde Topics'i geliştirme ve test etme çalışmalarına devam etmenin son derece önemli olduğunu düşünüyor. |
| Veri sızıntısı | Konuların izinsiz olarak diğer sitelere sızdırılabileceğiyle ilgili endişe | Topics API'nin tasarımı, tek bir yayıncıdan (ve hatta daha küçük bir yayıncı grubundan) alınan verilerin herhangi bir şekilde sızma olasılığını oldukça düşük hale getirir. Yayıncı web siteleri de Topics API üzerinde tam kontrole sahiptir ve izin politikası aracılığıyla bu API'ye erişimi yasaklayabilir. |
| Test için reklamveren eksikliği | Yayıncılar, şu anda Topics'in reklamverenlere olan değerini gösterememekten endişe duyuyor. | 2023'ün ikinci yarısında, reklamlarla ilgili tüm API'lerin entegrasyon testi için kullanıma sunulmasını ve reklamverenler için Topics'in değerinin ekosistem analizini etkinleştirmeyi planlıyoruz. Test ve sonuçların yayınlanması, verileri, analizi ve metodolojiyi inceleyecek olan CMA tarafından denetlenir. Ekosistemin Google ve CMA ile geri bildirim paylaşması önerilir. |
| Topics ve FLEDGE | FLEDGE'in teklif verme mantığında Topics'in nasıl kullanılacağı hakkında daha fazla bilgi isteme | FLEDGE teklifli sistem mantığında Topics'i kullanmak mümkündür. Ayrıca, uygulamayla ilgili ek ayrıntılar içeren bir entegrasyon kılavuzu da hazırlanmaktadır. |
| Konuları arayan için özel sıralama | Sırlamaların arayana göre özelleştirilmesine izin ver | Her reklam teknolojisi için özel konu sıralaması veya değerlerinin zorluğu, bir reklam teknolojisinin döndürülen konuları etkileyebileceği bir mekanizma haline gelebileceği ve dolayısıyla parmak izi vektörü olabileceğidir. |
| Konu arayan öncelik listesi | Arayan kullanıcıların, Topics API'nin uygunluk durumuna göre döndüreceği konuların öncelikli sıralı bir listesini sağlamasına izin verin. | Şu anda bu fikri daha ayrıntılı bir şekilde tartışıyoruz ve ek görüşlerinizi bekliyoruz. |
FLEDGE
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Google Ad Manager | FLEDGE açık artırmaları için nihai kararı verenin Google Ad Manager olması ve Google Yayıncı Etiketleri ile Google Ad Manager'ın tercih edileceği endişesi. | FLEDGE, her yayıncının üst düzey ve bileşen satıcıları da dahil olmak üzere açık artırmanın yapısını seçmesine olanak tanır. Bir 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 vermeyeceğini seçebilir. |
| FLEDGE'i test eden yeterli sayıda katılımcı yok | Örneğin, API'nin işlevini iyileştirerek ve parmak izi gibi gizliliği ihlal eden alternatifleri caydırarak daha fazla şirketi FLEDGE'i test etmeye teşvik etme isteği | Özel Korumalı Alan, CMA ve ICO'nun rehberliğinde yakın iş ortaklığıyla aşamalı olarak ilerlemektedir. İşlevsel FLEDGE testi, gerekli kararlılığı ve kapasiteyi göstermiştir. Google, ekosistemi Sandbox API'lerini test etmeye teşvik etmeye devam ediyor. Kısa süre önce, FLEDGE ve diğer API'lerin üçüncü taraf çerezlerine verilen desteğin sonlandırılmasının ardından reklam sektörü için kritik kullanım alanlarını desteklemeye nasıl yardımcı olabileceğini göstermek amacıyla "Reklam Tutarlılığını Artırma" dokümanlarını yayınladı. Özel Korumalı Alan'ın diğer bölümleri, izlemeyi kapsayan azaltıcı önlemleri zaten destekliyor (UA-CH, IP Koruması ve Hemen Çıkış İzleme Azaltıcı Önlemleri'ne bakın) ve zaman içinde iyileşmeye devam edecektir. Google'ın hedefi, FLEDGE'i tek uygulanabilir hedefleme çözümü haline getirmek değil, Chrome tarayıcıda gizliliği korumaya yönelik en iyi reklam teknolojilerini sunmak için sektör ve düzenleyicilerle ortak çalışmayı sürdürmektir. |
| Makine öğrenimi kullanım alanları | Açık artırma teklifi algoritmalarını eğitmek için makine öğrenimi kullanım alanlarının FLEDGE ve İlişkilendirme Raporları'nda nasıl destekleneceği hakkında daha fazla bilgi | Test kullanıcılarının, Özel Korumalı Alan teknolojilerini uygulamanın en yararlı yollarını bulmalarına yardımcı olmanın gerekliliğini biliyoruz. Özel Korumalı Alan API'lerinin çeşitli yönlerinin makine öğrenimi girişleri olarak kullanılmasıyla ilgili özel olarak rehberlik yayınlamaya başladık. En son makalemiz olan Reklam Alakalılığını Artırma, reklam sektörünün bu sinyalleri makine öğrenimi için nasıl kullanabileceği hakkında bilgi veriyor. Bu tür rehberlik içeriklerini yayınlamaya devam etmeyi planlıyoruz. |
| FLEDGE Anahtar Değer (K/D) 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 sunucusunun bu FLEDGE açık artırmalarının yürütüldüğü yerden (kullanıcı cihazları) erişilebilir olması gerekir. Bu da sunucunun herkese açık olması gerektiğini gösterir. K/D sunucusunda depolanan bir değer yalnızca anahtarına sahip olan bir taraf tarafından alınabilir. Bu nedenle, bir reklam teknolojisi anahtarları yalnızca İlgi Alanı Grubu'ndaki tarayıcılara verirse ve rastgele tahmin edilebilecek anahtarlar kullanmazsa yalnızca açık artırmalarını çalıştırmak 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 fazla yolu vardır. Alıcılar, satıcılarından mevcut tarih ve saati paylaşmalarını isteyebilir. Satıcıların bu bilgileri tüm alıcılara iletmesi kolay olmalıdır. Alıcılar, gerçek zamanlı anahtar/değer yanıtlarında tarih ve saati de sağlayabilir. Son olarak alıcılar, alıcı başına sinyallerde bağlamsal yanıtlarının bir parçası olarak tarih ve saati sağlayabilir. Satıcı, bu bilgileri alıcının generateBid komut dosyasına iletebilir. |
| Kullanıcı tercihleri | Kullanıcıların, FLEDGE veya alternatif çözümler aracılığıyla yayınlandığında reklam öğelerini reklamverene göre engellemeyi seçme olanağı. | Kullanıcılar, Chrome'da Ads API'lerini devre dışı bırakabilir. Belirli reklamlar için ilgili reklam teknolojisi, hangi reklam öğelerinin gösterileceği veya nasıl seçileceği konusunda kontrol sunmak için en iyi konumda olan taraftır. |
| Daha net zaman çizelgeleri | FLEDGE'de gizlilik korumalarının kullanılabilirliği hakkında daha fazla bilgi isteyin (ör. çitli çerçeveler zorunluluğu). | 1. çeyrekte daha ayrıntılı zaman çizelgeleri yayınlamayı planlıyoruz. |
| Raporlamayla ilgili karışıklık | FLEDGE raporlamasının, Çitli Çerçeveler ve Private Aggregation API gibi diğer API'lerle nasıl çalışacağı konusunda daha fazla netlik isteğinde bulunun. | Önümüzdeki haftalarda Private Aggregation API, FLEDGE ve Çitli Çerçeveler arasındaki etkileşim hakkında bir açıklama yayınlamayı planlıyoruz. |
| Gerçek zamanlı teklif verme ve FLEDGE | FLEDGE'in standart gerçek zamanlı teklif vermeyle nasıl entegre edildiğiyle ilgili yol gösterici bilgiler. | Reklam teknolojisinin gerçek zamanlı teklif verme özelliğini karmaşıklaştıran iki temel faktör, etkinlik düzeyindeki verilere erişim ve ARA ile daha kolay entegrasyondur. İlk çeyrekte bu iki konu hakkında güncellemeler ve açıklamaları paylaşmayı planlıyoruz. |
| FLEDGE Açık Artırmalarının Performansı | Test kullanıcılarından FLEDGE açık artırmalarının yüksek gecikmeye sahip olduğuyla ilgili rapor | Test kullanıcılarının sonuçlarını ve kullanım alanlarını paylaştıkları raporlar için teşekkür ederiz. FLEDGE'in performansını iyileştirme hakkında bazı öneriler paylaşmıştık. Buna paralel olarak, tarayıcıya geliştiricilerin açık artırmaları yavaşlatan sorunları daha iyi teşhis etmesine olanak tanıyan araçlar ekledik ve gözlemlenen birincil gecikme kaynaklarını sistematik olarak ele aldık. 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ş parçacıklarını yeniden kullanma yöntemi ve FLEDGE başlangıç süresi ile ağ getirme işlemleriyle bağlamsal reklam isteğinin paralel olarak çalışmasına izin verme için devam eden çalışmalar yer alıyor. Gecikme optimizasyonunun, API'yi gerçek dünyadaki deneyimlerine dayanarak Chrome geliştiricileri ile FLEDGE test kullanıcıları arasında devam eden bir görüşme olarak devam etmesini bekliyoruz. |
| İlgi grubu boyutu bellek sınırı | Tek bir ilgi alanı grubunun boyutu için 50 KB olan sınırın artırılması talebi. | Talebi aktif olarak değerlendiriyoruz ve hangi sınır değerinin işe yaradığına dair geri bildirim istiyoruz. |
| FLEDGE tarafından sunulan verileri birinci taraf çereziyle birleştirme | FLEDGE, reklamverenin birinci taraf verileriyle entegrasyonu destekler mi? | FLEDGE, reklamverenin halihazırda sahip olduğu birinci taraf verilerini kullanarak reklamcılığı desteklemek için tasarlanmıştır. Ancak FLEDGE, reklamverenlerin kendi siteleri dışındaki herhangi bir web sitesinde kullanıcıların tarama davranışlarını öğrenmesini desteklemeyi amaçlamaz. Site dışı tarama davranışını birinci taraf verilerine eklemek, Özel Korumalı Alan'ın hedeflerine aykırıdır. FLEDGE'in birinci taraf verileriyle entegrasyonu nasıl destekleyeceği hakkında daha fazla ayrıntı içeren entegrasyon kılavuzlarını önümüzdeki haftalarda paylaşmayı planlıyoruz. |
| K-anonimlik değeri | "K" değerinin "k-anon" olarak ayarlanmasına nasıl karar verilir ve bu değer yayınlanır mı? | "K" değeri henüz kesinleşmedi. Planlarımız geliştikçe daha fazla bilgi paylaşacağız. Bilinmeyen bir k değerinin FLEDGE hazırlıklılığını ve kapsamlı yapay zeka model eğitimi nasıl engelleyebileceği hakkında daha fazla bilgi edinmek istiyoruz. Bu konuda ek geri bildirim gönderebilirsiniz. |
| Birden fazla SSP'yi destekleme | FLEDGE'de birden fazla SSP nasıl desteklenecek? | FLEDGE, bu teklifte belirtildiği gibi çok satıcılı açık artırmaları destekler. |
| Teklif verme mantığının görünürlüğü | DSP teklif verme mantığının JavaScript'de gösterileceğiyle ilgili endişe | Mevcut tasarım teklif verme mantığıyla JavaScript'e başkaları tarafından erişilebilir. Bunun TTP'ler için neden endişe kaynağı olabileceği konusunda daha fazla geri bildirim almaktan memnuniyet duyarız. |
| prebid.js | FLEDGE'de prebid.js desteğinin zaman çizelgesi nedir? | FLEDGE modülü yalnızca Prebid.js'nin 7.14 ve sonraki sürümlerinde desteklenir. Test yapmak isteyen tüm yayıncıların FLEDGE modülünü eklemesi ve Prebid örneğini yükseltmesi gerekir. |
| FLEDGE'de kullanıcı tanımlı işlevler | Kullanıcı tanımlı işlevler (UDF) FLEDGE'de nasıl desteklenir? Bunlar, API'nin işlevini genişletmek için son kullanıcılar tarafından programlanabilen işlevlerdir. | Açıklayıcı bilgiyi burada bulabilirsiniz. Bu özellik hâlâ geliştirilme aşamasında olduğundan kullanım alanları hakkında ek geri bildirimlerinizi bekliyoruz. |
| İlgi grubu kaynaklarında aynı kaynak kısıtlamasını gevşetme | Belirli reklam teknolojisi kullanım alanlarını etkinleştirmek için İlgi Alanı Grubu kaynaklarında aynı kaynak kısıtlamasının gevşetilmesi talebi | FLEDGE'in mevcut 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 vardır. |
| interestGroup Sahipliği | Bir reklam teknolojisinin, siteler arasında aynı ilgi alanı grupları için joinInterestGroup'ı kullanıp kullanamayacağını sınırlama isteği | Odak noktamız, kitlelerin nasıl oluşturulduğu değil, nasıl kullanıldığıdır. Olası yaklaşımları tartışıyoruz ve ek katkılarınızı bekliyoruz. |
| Key Value Sunucu Anahtarı Süre Sonu | İlgili ilgi alanı gruplarının süresi dolduktan sonra sunucu anahtarlarının kaldırılmasıyla ilgili tartışma | Anahtar süresinin sona ermesini yönetmenin yollarını araştırıyoruz ve geri bildirim istiyoruz. |
Dijital reklamları ölçme
İlişkilendirme raporları (ve diğer API'ler)
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Kaynak denemesi trafiği | Mevcut kaynak deneme trafiği, yardımcı program testi yapmak için yeterli değil. | Mevcut Kaynak Denemelerinin amacı, ekosistem oyuncularının API'nin amaçlandığı gibi çalıştığından emin olmak için işlevsel testler yapmasıdır. Çeşitli Özel Korumalı Alan API'lerinin geliştirilmesi tamamlandıktan sonra yardımcı program testini gerçekleştirmek için daha fazla trafik gerekeceğini biliyoruz. Mevcut test zaman çizelgesi, bunun 2023'ün 3. çeyreğinde genel kullanıma sunulmasıyla (yani kullanım alanlarına yönelik teknolojilerin kullanıma sunulup Chrome trafiğinin% 100'ü için kullanıma sunulduğunda) gerçekleşeceğini öngörüyor (privacysandbox.com'daki güncel zaman çizelgemize göz atın). Ek trafik gerektiren kullanım alanı testiyle ilgili ek geri bildirimler memnuniyetle karşılanır. |
| Farklı Özel Korumalı Alan ölçüm API'lerinin işlevselliğinde çakışma | Özel Korumalı Alan üzerinden birden fazla ölçüm yaklaşımının çakışması ile ilgili endişeler, karmaşıklığı artıracaktır (ör. Attribution Reporting API ve Private Aggregation API). | API'lerin farklı kullanım alanlarını açıklığa kavuşturmak için daha iyi dokümanlar üzerinde çalışıyoruz. Açıklama eksikliği olan alanlarla ilgili ek geri bildirimlerinizi bekliyoruz. Ö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 daha geniş bir siteler arası ölçüm kullanım alanını desteklemek için tasarlanmış genel amaçlı API'lerdir. |
| Başarısız rapor isteğini yeniden deneme | Başarısız olursa bir rapor isteği için kaç kez deneme yapılacağıyla ilgili açıklama. | Bu konuda yol gösterici bilgiler yayınladık. Özetlemek gerekirse, raporlar yalnızca tarayıcı çalışırken/internete bağlıyken gönderilir. İlk gönderme başarısız olduğunda rapor 5 dakika sonra tekrar gönderilmeye çalışılır. İkinci başarısızlıktan sonra rapor 15 dakika sonra tekrar denenir. Bu sürenin ardından rapor gönderilmez. |
| Raporlama Gecikmesi | Beklenen raporlama gecikmesi nedir? | Bu gecikmeleri daha ayrıntılı şekilde değerlendirmek için veri toplarken ekosistemden yaşadıkları raporlama gecikmeleriyle ilgili daha fazla geri bildirim almak istiyoruz. |
| Sayfaları önceden oluşturma | ARA ilişkilendirmesi önceden oluşturulmuş sayfalarda çalışır mı? | İlişkilendirme kaydı, etkinleştirmeye (gerçek tıklama veya görüntüleme gerçekleşene kadar) kadar ön oluşturma sayfalarında ertelenebilir. Bu, "attributionsrc" istek ping'ini erteleyeceğimiz anlamına gelir. |
| Dönüşüm artışını ölçme | Aynı alanda A/B testi ile dönüşüm artışını ölçme | Web siteleri, ilişkilendirme raporları aracılığıyla aynı alanda A/B testi yaparak dönüşüm artışını ölçebilir. Toplama API'sini kullanarak A/B parametrelerini anahtar olarak kodlayabilir ve ardından bu anahtar gruplarına göre dönüşüm değerleri için özet raporlar alabilirler. |
| (3. çeyrekte de raporlanır) Alanlar arası dönüşümler | 2 veya daha fazla hedef içeren alanlar arası dönüşümleri izleme | 4. Çeyrek Güncellemesi: Alanlar arası sohbetlerin izlenmesine olanak tanıyan açılış sayfası hedef kısıtlamasını kaldırmak için bir teklif yayınladık. Bu teklif uygulandı. |
| (3. çeyrekte de raporlanmıştır) Dönüşüm raporundaki geçerlilik bitiş tarihi ayarı |
24 saatten kısa süreli rapor filtresi / süre sonu desteği isteğinde bulunma | 4. Çeyrek Güncellemesi: Raporlama gecikmesi ile dönüşüm süresinin sona ermesi arasındaki dengeyi sağlamak için geçerlilik süresi ile raporlama aralıkları arasındaki bağlantıyı kaldıracak bu pull request 'i paylaştık. Bu özellik artık M110'da kullanıma sunulmuştur. |
| Sahtekarlık ve Kötüye Kullanım | Reklamverenler ve pazarlamacıların, reklamlarının yayınlandığı yayıncı sitelerine göre verileri dilimleyip toplayabilme isteklerini yerine getirmek. Bu sayede, olası sahtekarlık amaçlı reklam uygulamaları hakkında daha fazla bilgi edinilebilir. | Bu geri bildirim burada aktif olarak tartışılıyor. Ek katkılarınızı bekliyoruz. |
| (3. çeyrekte de bildirilmiştir) Etkinlik düzeyinde raporlama gecikmesi | Etkinlik düzeyinde raporlamada 2-30 gün olan gecikme, belirli kullanım alanları için çok uzun olabilir. | Etkinlik düzeyinde raporlamada varsayılan raporlama aralıkları 2, 7 ve 30 gündür. Bu değer, "expiry" parametresi kullanılarak değiştirilebilir. Reklam teknolojileri, potansiyel raporları 2 günden kısa sürede almak için en az 1 gün olan geçerlilik bitiş tarihini yapılandırabilir. Daha ayrıntılı raporlama zamanlama saldırılarına neden olabileceğinden, gizlilik koruma mekanizması olarak sürelerin ayrıntı düzeyini 1 günle sınırlandırırız. Ayrıca, etkinlik düzeyi ve toplu raporlar için bağımsız "son kullanma" parametreleri ayarlamanıza izin veriyoruz. Buraya bakın. Ayrıca Google Ads, diğer reklam teknolojilerinin İlişkilendirme Raporlama API'si üzerinden alamadığı özel raporlama aralıkları almaz. |
| Aynı raporlama kaynağı şartı | Kaynak kayıt kaynağının dönüşüm kaydı kaynağıyla aynı olması şartının kaldırılması talebi | Bu kullanım alanını çözmek için kaydetme işlemini devretmek üzere HTTP yönlendirmelerini kullanmanızı öneririz. Yeni yönergelerle ilgili ek geri bildirimlerinizi bekliyoruz. |
| Dönüşüm izleme | Dönüşümün, reklamveren tarafından belirlenen belirli saatlerden önce mi yoksa sonra mı gerçekleştiğini ayırt etmek gerekir. | Attribution Reporting API, kaynak ilişkilendirme için geçerlilik süresi aralığı ve öncelik belirlemeyi destekler. İkisini de kullanarak, X günlük aralıkta gerçekleşen bir dönüşümü X'den sonra gerçekleşen bir dönüşümden ayrı olarak ilişkilendirmek teknik olarak mümkün olacaktır. |
| Gürültü simülasyonu | Daha az dönüşümü olan reklamverenler üzerindeki etkiyi anlamak için grup başına farklı dönüşüm hacmini simüle edebilme isteğinde bulunma | Noise Lab'ın gelecekteki sürümlerinde bu tür sesleri simüle etmenin yollarını eklemeyi planlıyoruz. Başka geri bildirimleriniz varsa lütfen bize iletin. |
| Mobil cihazlarla ilgili rapor oluşturma | Chrome mobil cihazda arka planda çalışırken rapor gönderilmeye devam eder mi? | Şu anda mobil cihazlarda bile Chrome arka plandayken rapor gönderilmez. API, Android Özel Korumalı Alan ile entegre edildiğinde bu durum değişebilir. Buraya bakın. Android Özel Korumalı Alan'ın, CMA tarafından kabul edilen Taahhütler'in bir parçası olmadığını unutmayın. |
| Veri kullanılabilirliği | Google'ın, Privacy Sandbox API'leri aracılığıyla verilere ek erişime sahip olacağıyla ilgili endişeler | Öncelikle, Google Ads, Attribution Reporting API'den veya diğer Özel Korumalı Alan API'lerinden gelen verilere öncelikli erişim elde etmez. Bu sorun, Google'ın Taahhütleri hakkında daha fazla ayrıntı içeren"Birlikte Çalışabilirlik" bölümündeki Genel Geri Bildirim bölümünde de ele alınmıştır. İkinci olarak, Google, daha büyük ve daha küçük siteler arasındaki farkla ilgili olarak, gürültü tabanlı gizlilik korumalarının daha küçük veri dilimleri üzerinde daha büyük bir etkisi olabileceğinin farkındadır. Ancak bu sorunu azaltmak için bazı yöntemler vardır. Örneğin, daha uzun süre boyunca toplama gibi yöntemler bu sorunu çözebilir. Bununla birlikte, ç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ığı net değildir. Google, kaynak denemesi sırasında test kullanıcılarını, bu konuda daha spesifik geri bildirimde bulunabilmeleri için çeşitli gizlilik ve gürültü parametreleriyle deneme yapma olanağından yararlanmaya teşvik etti. |
Gizli İzlemeyi Sınırlama
User-Agent Üstbilgisini Kısaltma
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Web ekosistemi daha hazır olana kadar User-Agent Kısaltma özelliğini erteleme | Yaklaşan kullanıcı aracısı azaltma değişikliklerine uyum sağlamak için yeterli zaman yok. | Bu geri bildirimi, raporun tamamındaki "Google'ın CMA ile etkileşimi " başlıklı bölümdeki "Paydaş Endişeleri" bölümünde ele alıyoruz. |
| Web ekosistemi daha hazır olana kadar User-Agent Kısaltma özelliğini erteleme | Kullanıcı Aracısı Daraltması'nın kullanıma sunulması için Yapılandırılmış Kullanıcı Aracı'nın (SUA) dağıtılması beklensin | Google Ads ekibi, Ekim 2021'de OpenRTB'ye yapılandırılmış kullanıcı aracısı ekleme (özelliğe bakın) önerisinde bulundu ve bu öneri Nisan 2022'de yayınlanan 2.6 spesifikasyon güncellemesine dahil edildi. UA-CH ve WURFL API'nin, SUA oluşturmak için nasıl kullanılacağını gösteren Scientia Mobile blog yayınında gösterildiği gibi, SUA'nın dağıtıldığına ve şu anda kullanılabildiğine dair bazı kanıtlarımız var. |
###
Kullanıcı Aracısı İstemci İpuçları
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| UA-CH'yi gizli izlemeye karşı diğer tekniklerle test etme | Tüm Özel Korumalı Alan API'lerinin ve parmak izi tekniklerinin bütünsel bir yaklaşımla birlikte nasıl test edileceğine dair rehberlik | Test planımız, Özel Korumalı Alan Önerileri'nin geri kalanına kıyasla parmak izi önleme önlemlerinden bazılarının geliştirilmesiyle ilgili zaman çizelgelerinin eşzamanlı olmadığını yansıtacak şekilde tasarlanmıştır. Bazı parmak izi önleme önlemlerinin (ör. gizlilik bütçesi, IP koruması ve hemen çıkma izleme azaltmaları) yalnızca üçüncü taraf çerez desteği sonlandırıldıktan sonra tamamen geliştirilip genel kullanıma sunulmaya hazır olacağı gerçeğini ele alır. Bu parmak izi önleme önlemleri, nicel testlere dahil edilmese de, Durdurma sırasında mevcut olan bilgilere dayalı olarak niteliksel değerlendirmeye tabi tutulacaktır. |
| (2. çeyrekte de raporlanır) Performans |
Kritik-CH aracılığıyla ipucu alma gecikmesiyle ilgili endişeler (ilk sayfa yüklenmesinde) | Aşağıdaki özel UA-CH bölümüne bakın |
| Yetersiz Geri Bildirim | UA-CH değişikliğiyle ilgili olarak ekosistemden alınan geri bildirim yeterli olmayabilir. Bu da ekosistemin farkındalık eksikliğiyle ilgili endişelere yol açabilir. | Planlarımızı, kesintileri en aza indirecek şekilde dikkatli bir şekilde kullanıma sunmak için proaktif olarak paylaşıyoruz. Kullanıcı Aracısı Kısaltma ve UA-CH API planları 18 Mart 2022'de W3C Sahtekarlık Önleme Topluluğu'na, 20 Ocak 2022'de ise hem Web Ödemeleri Çalışma Grubu'na hem de Web Ödemeleri Güvenlik İlgi Alanı Grubu'na sunuldu. Sunumlar sırasında veya sonrasında önemli bir endişe dile getirilmedi. Google, geri bildirim almak için proaktif olarak 100'den fazla site operatörüyle iletişime geçti. Ayrıca Google, ekosistem paydaşlarından gelen geri bildirimler doğrultusunda kullanıcı aracısı azaltma özelliğinin kullanıma sunulduğunu herkese açık olarak duyurmak için Blink-Dev kanallarını da kullandı. |
| Zamanlama | Kullanıma sunma zamanlaması ve sektörün hazırlık durumuyla ilgili endişeler | Aşağıdaki özel UA-CH bölümüne bakın |
| Chrome Platform Durumu | UA-CH için chromestatus sayfasının güncellenmesi istendi | chromestatus girişi 19 Aralık'ta "Karışık sinyaller" olarak güncellendi. |
IP Protection (eski adıyla Gnatcatcher)
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Etkinleştirme veya devre dışı bırakma | IP Adresi Gizliliği Etkin mi Devre Dışı mı? | Hedefimiz, tüm kullanıcılara IP Koruması sunmaktır. Bu hedef doğrultusunda, şu anda IP Koruma için kullanıcı tercihi seçeneklerini değerlendiriyoruz. |
| Birinci taraf verileri için IP adresi kullanım alanı | IP koruması sonrası birinci taraf alanlarındaki kullanıcı yolculuklarını birleştirmek için IP adreslerini kullanmak mümkün mü? | Daha önce yayınlandığı gibi, IP Koruması başlangıçta üçüncü taraf bağlamında izlemeye odaklanacak. Bu, birinci taraf alan adlarının etkilenmeyeceği anlamına gelir. |
| Reklam teknolojisi kullanım alanları | Şirketler, IP koruması ile sahtekarlık önleme önlemlerini nasıl ayarlayabilir? | IP adresinin, günümüz web'inde sahtekarlık karşıtı çabalar için bir sinyal olarak önemini kabul ediyoruz. CMA'ya verdiğimiz Taahhütler (20. paragraf) kapsamında, web sitelerinin spam ve sahtekarlık karşıtı çalışmalar yürütme kapasitesini desteklemek için makul çabalar göstermeden IP Koruması'nı uygulamayacağımızı belirtmiştik. Şirketlerin web güvenliğini korumasına yardımcı olan gizliliği korumaya yönelik teknolojilere daha fazla yatırım yapabilmemiz için IP Koruması'nın sahtekarlık karşıtı kullanım alanlarını ve algılama özelliklerini nasıl etkilediğini anlamak en önemli önceliklerimizden biridir. Sinyaller zaman içinde değişse bile güvenlik ve sahtekarlık önleme şirketlerinin ihtiyaçlarını desteklemeyi amaçlayan geri bildirimleri ve yeni tekliflerle ilgili katkıları teşvik ediyoruz. |
| Sahtekarlık ve Kötüye Kullanım | IP koruması, hizmet reddi (DoS) korumasını içerir mi? | Web'i güvende tutarken gizliliği iyileştirmeye kararlıyız. Hizmet reddi saldırılarına karşı koruma, kötüye kullanıma karşı tasarlanması gereken önemli bir kullanım alanıdır. Hem IP Koruması'nın tasarımı hem de yeni kötüye kullanım karşıtı çözümler sayesinde DoS korumalarının etkisini en aza indirmeyi umuyoruz. IP Koruması başlangıçta üçüncü taraf yerleşik hizmetlere odaklandığından bazı paydaşlar, birinci taraf siteler için DoS koruması üzerinde sınırlı bir etkisi olacağını belirtmiştir. Ancak DoS kullanım alanlarına, özellikle de üçüncü taraf yerleşik hizmetlerine yönelik riski değerlendirmek için herkese açık geri bildirim almaya devam ediyoruz. Buna paralel olarak, bir sitenin veya hizmetin spam yapan bir kullanıcıyı tanımlamadan engellemesini sağlayacak kötüye kullanım geri bildirimi ve istemci engelleme mekanizmalarını araştırıyoruz. |
| İçerik Filtreleme | Fikri Mülkiyet Koruması ile içerik filtreleme | Farklı şirketlerin içerik filtreleme ve kullanıcı deneyimini özelleştirme konusunda farklı ihtiyaçları vardır. Bu tür kullanım alanlarının çoğu şu anda IP adreslerine ihtiyaç duymadığından IP Koruması'ndan etkilenmeyecektir. Ö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 daha önceki etkileşimlerini anlamak için birinci taraf çerezleri veya üçüncü taraf bölümlenmiş çerezleri (CHIP'ler) kullanabilir. Doğru kullanıcıya doğru reklamı sunmaya odaklanan bir reklam teknolojisi iş ortağı da FLEDGE ve Topics'i kullanabilir. Örneğin, üçüncü taraf çerezleri veya siteler arası diğer izleme teknolojileri ile şu anda sağladığına benzer reklam sonuçlarını sunabilir. Ayrıca, mevcut mekanizmaların yetersiz olabileceği durumlarda içerik filtrelemeyi daha da desteklemek için IP Koruması'na kaba coğrafi konum gibi gizliliği korumaya yönelik yeni özellikler ekleme konusunda da araştırmalar yapıyoruz. IP Koruması'ndan etkilenebilecek içerik filtreleme kullanım alanları hakkında ek geri bildirimlerinizi bekliyoruz. |
| (3. çeyrekte de raporlanmıştır) Coğrafi konumlandırma kullanım alanları |
IP Koruması, coğrafi konuma dayalı içerik kişiselleştirme gibi meşru coğrafi konum kullanım alanlarının gelecekte çalışmasını engelleyebilir. | 4. Çeyrek Güncellemesi: Chrome'un IP adresleri için meşru kullanım alanlarını desteklemeye devam etmesini sağlamak amacıyla paydaşlarla birlikte çalışıyoruz. IP coğrafi konum ayrıntı düzeyiyle ilgili ekosistem geri bildirimlerini buradan bekliyoruz. |
Gizli Erişim Limiti
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Daha net dokümanlar | Gizlilik bütçesi uygulandıktan sonra paydaşların neler sınırlanabileceğini tahmin edebilmesi için daha fazla örnek | Gizlilik Bütçesi önerisi hâlâ aktif olarak tartışılmakta olup herhangi bir tarayıcı tarafından uygulanmamıştır. Ölçeklendirilmiş kullanılabilirliğin en erken tarihi, Gizlilik Bütçesi'nin uygulanabileceği en erken tarihi gösterir. Bu, 2024'te üçüncü taraf çerezleri kaldırılmadan önce gerçekleşmeyecek. Şu anda paylaşabileceğimiz ek doküman bulunmuyor. Teklif daha kesinleştiğinde teklifle ilgili ek bilgiler paylaşacağız. Bu süreçte, paydaşların teklifin geliştirilmesine yardımcı olacak geri bildirimlerini paylaşmalarını bekliyoruz. |
Siteler arası gizlilik sınırlarını güçlendirme
Birinci Taraf Gruplar
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| (3. çeyrekte de bildirilmiştir) Alan sınırı | İlişkilendirilen alan adlarının sayısını artırma isteği | 4. Çeyrek Güncellemesi: GitHub'da bir örnek veri kümesi gönderme süreci ve rSA ile rSAFor'u yerel olarak test etmek için bir işaretçi de dahil olmak üzere yerel test için FPS'yi kullanıma sunduk. Ayrıca, ilişkili alt kümenin kullanım alanlarıyla ilgili soruları yanıtlamaya devam etmek için geliştiricilere yönelik iki açık FPS toplantısı düzenledik. Geliştiricilerin, ilişkili alt kümenin alan sınırının kullanım alanları için FPS'nin kullanılabilirliğini nasıl etkileyeceği konusunda geri bildirimde bulunmak üzere FPS işlevini test etmelerini öneririz. WICG toplantılarında, Chrome'un kullanıcıların gizlilik çıkarlarını da göz önünde bulunduran kullanılabilir bir çözüm sunmaya kararlı olduğunu açıkça belirttik. Bu bağlamda, alan sınırından etkilenebilecek belirli kullanım alanları hakkında topluluğun geri bildirimlerini öğrenmekten memnuniyet duyarız. Böylece, ekibimiz kullanıcı gizliliğini korumaya devam ederken bu kullanım alanlarını ele alma yollarını değerlendirebilir. |
| Kötüye kullanım azaltma önlemleri hakkında daha fazla bilgi isteme | Bir alan, izin verilmeyen bir gruba eklenirse ne olur? | 2 Aralık 2022'de birinci taraf setleriyle ilgili gönderim yönergelerini burada yayınladık. Gönderim yönergelerinde açıklandığı gibi, ayarlanan tüm değişiklik yönetimi, sahiplik doğrulaması da dahil olmak üzere GitHub'da bir doğrulama sürecini takip eder ve bu sürece uyar. Bu da 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 küme türleri için teknik kontrolleri genişletmenin yollarını arıyor ve buradan topluluktan ek görüşler alıyoruz. |
| Reklam kullanım alanları | Reklam hedeflemeyi desteklemek için birinci taraf kümelerinin kullanılması gerekip gerekmediğiyle ilgili sorular | Birinci taraf kümeleri için reklam hedefleme kullanım alanlarını desteklemeye çalışmıyoruz ve bu tür kullanım alanları için mevcut Ads API'lerini kullanmanızı öneririz. |
| (3. çeyrekte de raporlanmıştır) Politika | GDPR'de bir gruptaki site sayısı için sınır getirilmediği, FPS'de ise 3 sınırı öngörüldüğü için FPS'nin "Geçerli Veri Koruma Yasası" ile ilgili CMA Taahhütleri'ne uygun olmadığına dair endişe | Yanıtımız 3. çeyrektekinden farklı değil: "Google, Özel Korumalı Alan tekliflerini Google'ın kendi işletmesini tercih ederek rekabeti bozmayacak şekilde tasarlayıp uygulamak ve dijital reklamcılık, yayıncılar ve reklamverenlerin yanı sıra gizlilik sonuçları ve Geçerli Veri Koruma Yasası'nda belirtilen veri koruma ilkelerine uygunluk üzerindeki etkiyi dikkate almak için CMA'ya bağlılığını sürdürmektedir. Belirtilen endişe, GDPR ile uyumsuzluk olduğunu göstermiyor. Çalışmalarımızın bu taahhütlere uymasını sağlamak için CMA ile yakın bir şekilde çalışmaya devam ediyoruz." |
| Alternatif teklif | GDPR Doğrulanmış Kümeleri | "GDPR Onaylı Kümeleri" kullanma önerisi hakkında ekosistem tarafından sağlanan geri bildirime ek olarak Chrome, bu alternatif önerinin aşağıdaki sınırlamaları konusunda endişe duymaktadır:
Bu alternatif gündeme geldikten sonra Chrome, birinci taraf grupları teklifini güncelledi ve yeni gruplar oluşturmaya yönelik gönderim yönergelerini yayınladı. |
Fenced Frames API
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Fazla çalışma sırasında korumalı çerçeve kısıtlamaları | Kaynak deneme dönemi için çitli çerçevelerle ilgili mevcut kısıtlamalar nelerdir? | Kısıtlamalar ve uygulama durumuyla ilgili dokümanlar üzerinde çalışıyoruz ve bu dokümanları 2023'ün 1. çeyreğinde paylaşmayı planlıyoruz. |
| Tek bir çitli çerçevede birden fazla reklam | Tek bir açık artırmada birden fazla reklamverenin tek bir korumalı çerçevede gösterilmesi için istek | Şu anda bu istek aktif olarak geliştirilmiyor ancak ekosistemdeki oyuncular bu özelliği önemli buluyorsa ek geri bildirim gönderebilirsiniz. |
| Web Paketleri | Çitli çerçeveler içeren web paketleri için planlanan şartlar ve destek nelerdir? | Şu anda bu şartın gelecekte de geçerli olup olmayacağı konusunda bir güncelleme bulunmuyor. Herhangi bir değişiklik önceden duyurulur ve üçüncü taraf çerezlerinin desteğinin sonlandırılmasından önce uygulanmaz. Mevcut durum için lütfen bu açıklamayı inceleyin. |
Shared Storage API
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Reklam Teknolojisi İçin Paylaşılan Depolama | Reklam teknolojisi kullanım alanları için paylaşılan depolama alanının kullanımıyla ilgili belirsizlik | Ortak Depolama ve Özel Toplama API'si, siteler arası depolama alanı ölçümüne ihtiyaç duyan farklı ölçüm türleri için kullanılabilir. Bazı örnekler burada listelenmiştir. DSP ve ölçüm çözümü sağlayıcıların, reklam kullanım alanları için ana entegratör olacağını öngörüyoruz. |
CHIPs
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| (3. çeyrekte de raporlanmıştır) Bölünmüşlük koşulu | Birinci taraf çerezlerinde "Bölümlendirilmiş" özelliği için açık davranış koşulu ekleyin. | 4. Çeyrek Güncellemesi: GitHub ve PrivacyCG görüşmelerindeki tartışmalardan sonra, birinci taraf çerezlerinde ayarlanan bölümlenmiş çerezlerin "A" üst düzey sitenin olduğu (A,A) bir bölümleme anahtarı kullanacağı konusunda anlaştık. Bu davranışı açıklama ve spesifikasyonda belgeleyeceğiz. |
| Çerez Yönetimi | Birinci taraf veya üçüncü taraf çerezlerini yönetmek/yönetmek için araçlar var mı? | Chrome Geliştirici Araçları ve NetLog, üçüncü taraf çerez engelleme özelliği etkin olan siteleri test etmek için kullanılabilir. Her iki araç da çerezlerin kullanıcı yapılandırması nedeniyle engellendiğini bildirir. Web sitelerinde görmek istediğiniz ek denetim türleriyle ilgili geri bildirimlerinizi bekliyoruz. |
FedCM
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| IdP'nin oturuma izin vermesi için RP bilgisi gerekir | Kullanıcının iki farklı RP'den Feide IdP'ye giriş yapmaya çalışırken karşılaşılan sorun | Bu sorunla ilgili olası çözümleri tartışıyoruz. |
| Birlikte çalışabilirlik | FedCM'nin kullanıcılar ile FedCM'yi kullanarak giriş yaptıkları web siteleri arasındaki ilişki ve web siteleri arasındaki "birlikte çalışabilirlik" üzerindeki etkisiyle ilgili endişeler | FedCM, üçüncü taraf çerezleri Chrome'dan kaldırıldıktan sonra şu anda üçüncü taraf çerezlerine dayanan birleşik kimlik hizmetlerini desteklemeye devam etmeyi amaçlamaktadır. FedCM'nin bu tür hizmetler için kullanılabilecek tek seçenek olmasını bekleriz. Kimlik sağlayıcılar (IdP'ler) ve güvenen taraflar (RP'ler), ihtiyaçlarına daha uygun olabilecek diğer teknolojileri kullanma özgürlüğüne sahiptir. Kullanıcı-RP ilişkisi ve "uyumluluk" ile ilgili endişelerin, FedCM teklifinin yanlış anlaşılmasından kaynaklandığı anlaşılıyor. FedCM, kullanıcı ilgili RP'nin sitesinde oturum açmayı seçtikten sonra hangi bilgilerin RP ile hangi biçimde paylaşılacağına karar vermeyi kimlik sağlayıcılara bırakır. FedCM, kimlik sağlayıcıların "kullanıcı kimliğini doğruladığı her [RP] için benzersiz bir anonimleştirme tanımlayıcısı oluşturmasını" gerektirmez. Aksine, FedCM her IdP'nin kullanıcının gerçek tanımlayıcısını, bu tanımlayıcının site başına bir sürümünü veya bu bilgilerin başka bir sürümünü paylaşıp paylaşmayacağını seçmesine olanak tanır. (FedCM spesifikasyonu, siteler arası korelasyon'u API ile ilişkili bir gizlilik riski olarak tanımlar ve olası bir azaltma yöntemi olarak yönlendirilmiş (site başına) tanımlayıcılardan bahseder. Ancak yönlendirilmiş tanımlayıcıların kullanılıp kullanılmayacağına karar verme hakkı tarayıcıya değil, IdP'lere bırakılmıştır.) FedCM, kimlikle ilgili kullanıcı seçimini de zaten sağlar. Örneğin, bir kullanıcının aynı kimlik sağlayıcıda birden fazla kimliği varsa (ör. iş profili ve kişisel profil) FedCM, kullanıcının RP'nin sitesine giriş yapmak için hangisini kullanmak istediğini seçmesine olanak tanır. Bunun dışında her RP, sitesinde hangi kimlik sağlayıcıları destekleyeceğine kendisi karar verir. Bu kararın bir yönü, FedCM veya farklı bir teknoloji olsun, kimlik sağlayıcının kullandığı mekanizmayı dikkate almaktır. Yine de tarayıcı, RP'ler veya kimlik sağlayıcılar için bu seçimleri belirlemez. |
Spam ve sahtekarlıkla mücadele etme
Private State Token API
| Feedback Theme | Özet | Chrome Yanıtı |
|---|---|---|
| Bot'ları işleme | Yayınlayan, gizlilik jetonlarının botlara verildiğini fark ederse ne olur? | Bot'lara verilen jetonların ekosistemde uzun süre kalmasını önlemek için, sağlayıcılar jetonları imzalamak için kullandıkları anahtarları düzenli olarak döndürmelidir. Böylece, bozuk olabilecek yayınlama mantığıyla yayınlanan eski jetonların süresi dolar ve siteler güncellenmiş yayınlama mantığına sahip yeni jetonları kullanır. |
| Aynı sitedeki form gönderimleri | Özel durum jetonları, fetch/XMLHttpRequest API'lerinden gelen bir istek yerine tam sayfa gezinme içeren aynı sitedeki form gönderimleri için (ör. Content-Type: application/x-www-form-urlencoded) kullanılabilir mi? | Bu özellik şu anda Gizlilik Jetonlarının ilk sürümünde desteklenmiyor. Bu kullanım alanı için güçlü bir talep varsa ekosistemden geri bildirim almaya açığız. |
| Sunucu tarafı doğrulaması | Gizlilik jetonlarının sunucu tarafında doğrulanıp doğrulanamayacağıyla ilgili sorular | Jetonlar, ihraççıyla ilişkilendirilerek kullanılır. Ardından ihraççı, jetonun kendisini veya jetondan türetilen imzalı bir değeri içerebilecek bir kullanım kaydı oluşturur. Sunucular, jetonun özgünlüğünü doğrulamak için bu kullanım kaydını kullanabilir. Farklı ihraççı ekosistemlerinin, kullanım kayıtlarının nasıl yorumlanacağına dair farklı standartlar oluşturmasını bekliyoruz. |