Bu sayfa, Cloud Translation API ile çevrilmiştir.

Geri Bildirim Raporu - 2023 Ç3
bookmark_border Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

Özel Korumalı Alan teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2023'ün 3. çeyreğine ait üç aylık rapor.

Google, CMA'ya verdiği taahhütler kapsamında, Özel Korumalı Alan teklifleriyle ilgili paydaş etkileşim süreciyle ilgili üç aylık raporları herkese açık olarak yayınlamayı 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, Protected Audience 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 veya teknolojiyle ilgili olmayan genel geri bildirimler

Geri Bildirim Teması	Özet	Chrome Yanıtı
Ekosisteme hazırlık durumu	STP'ler, yayıncıların hazır olmaması ve gerekli dağıtım çalışmalarını yapmamasıyla ilgili endişelerini dile getirdi.	Özel Korumalı Alan, özellikle yayıncıları eğitmeye odaklanan bir iletişime sahiptir. Bu iletişim kapsamında, yayıncıların ve SSP'lerin katılımıyla özel webinar'lar ve toplantılar düzenlenerek dağıtım çalışmalarının hızlandırılması sağlanır.
Üçüncü taraf çerez desteği sonlandırılıyor	Üçüncü taraf çerez desteğinin sonlandırılması (3PCD) ile ilgili endişeler, sektördeki teknoloji kesintisi nedeniyle 2023'ün 4. çeyreğinde arttı.	Özel Korumalı Alan'ın zaman çizelgesi CMA ile görüşüldü ve 2024'ün ikinci yarısında hazır olma hedefi belirlendi. Özel Korumalı Alan, 3PCD'yi kullanıma sunma sırası hakkında daha ayrıntılı bilgi yayınlayacaktır. Taahhütler uyarınca, 3PCD, CMA'nın rekabetle ilgili endişelerinin giderilmesine tabidir.
Google Ad Manager	Google Ad Manager, API yüzeyini göstermeyi reddederek test yapmayı zorlaştırır.	Google Ad Manager tarafından sağlanan yanıt: Google Ad Manager'ın bu yanıtında açıklanan nedenlerden dolayı, Google Ad Manager'ın Protected Audience API entegrasyonuyla ilgili planları, üst düzey açık artırmanın kontrolü olmadan Google'ın yayıncı reklam sunucusunu desteklemeyi içermez.
Google Ad Manager	Google Ad Manager'da yalnızca AdX veya Open Bidding SSP'lerine gösterilen gizli bir taban fiyat vardır.	Google Ad Manager'ın herkese açık dokümanlarında, bağlamsal açık artırmanın kazananının AdX veya Herkesin Katılabileceği Açık Artırma dahil olmak üzere herhangi bir bileşen açık artırmasına değil, üst düzey puanlama mantığına iletildiği belirtilmektedir. Ayrıca bu dokümanda üst düzey puanlama mantığıyla ilgili olarak şunlar belirtilmektedir: "Ad Manager, alıcıların ilgi alanı grubu teklifleri için Ad Manager'ın kendi bileşen açık artırması ve en iyi içeriğe dayalı reklam (dinamik ayırma aracılığıyla seçilir) dahil olmak üzere her bileşen açık artırmasının kazanan teklifini karşılaştırır ve en yüksek teklifi veren reklamı yayınlar."
Google Ad Manager	Google Ads ürünleri, üçüncü taraf reklam ürünleriyle aynı kurallara tabi olmalıdır.	Google Ads ürünleri zaten üçüncü taraflarla aynı kurallara tabidir.
Chrome tarafından desteklenen testler	A veya B'de olmayan tarayıcılar için etiketler ekleyin.	Araştırmamız, deney dışı etiketler eklemenin gizlilik endişelerini karmaşık hale getirebileceğini gösterdiğinden, şu anda bunu yapmayı düşünmüyoruz.
Reklam ajansı	Web sitelerinde JavaScript bulunmayan ajanslar veya şirketler Özel Korumalı Alan API'lerini kullanabilir mi?	Özel Korumalı Alan API'lerini herkes çağırabilir. Bir ajans veya başka bir kullanıcı doğrudan API'ler üzerinde teknoloji oluşturmak isterse bunu yapabilir. İstemci tarafı API'ler, tıpkı çerezler gibi istemciyle entegrasyon gerektirir. Çerezler gibi API'lerin çoğunda da bir HTTP üstbilgisi arayüzü bulunur. Reklam sektörü çerçevelerinden biri olan Prebid'in, API'lerle istemci tarafı entegrasyonlar oluşturduğunu daha önce görmüştük. Diğer kuruluşlar da aynısını yapabilir.
İstemci tarafı çözümler	Bir mühendis 2012'de bu tür çözümlerin ölçeklenebilirliği konusunda endişelerini dile getirdiği halde Google neden Özel Korumalı Alan için istemci tarafı çözümleri benimsiyor?	Bir çalışma alanı olarak gizlilik odaklı teknoloji (PET), 2012'den bu yana önemli ölçüde gelişti ve bununla birlikte ticari açıdan uygun uygulamalar da gelişti. Özel Korumalı Alan'ın temelinde, on yıl önce mümkün olmayan PET kombinasyonları yer alır. Ayrıca, kişisel bilgisayarların gücü arttıkça tüketicilerin tarayıcılarla ilgili beklentileri ve gizlilikle ilgili yasal beklentiler de arttı.
Makine Öğrenimi	Google'ın makine öğrenimi amacıyla Özel Korumalı Alan'ı kullanma planı nedir?	Reklam teknolojisi ekosisteminin büyük bir kısmı günümüzde makine öğreniminden yararlanıyor ve bu durumun değişmesini beklemiyoruz. Özel Korumalı Alan, reklam teknolojisi şirketlerinin veya başka herhangi bir kullanıcının makine öğrenimini kullanmaya devam etmesini engellemez. Ayrıca Özel Korumalı Alan, API'leriyle entegrasyon yapan şirketlerin makine öğrenimi kullanmasını da gerektirmez. Şirketlerin, makine öğrenimi kullanılsın veya kullanılmasın, müşterilerinin ihtiyaçlarını karşılayacak şekilde ürün ve hizmetler geliştirmeye devam etmesini beklemek makuldür. Özel Korumalı Alan entegratörlerinin oluşturduğu tüm makine öğrenimi modelleri, elbette bu entegratörler tarafından bilinir ve bu nedenle gizlenmez.
Veri doğrulama	Şirketler, Özel Korumalı Alan'ı kullanarak elde ettikleri verilerin doğru olduğunu nasıl doğrulayabilir ve Google, Media Ratings Council (MRC) gibi bir tüzel kişi aracılığıyla incelenmeye hazır mı?	Özel Korumalı Alan API'leri, Chrome'u destekleyen açık kaynak platformda geliştirilir. API'lerin Güvenilir Yürütme Ortamlarında çalıştırılması amaçlanan bölümleri de açık kaynaktır ve denetlenebilir. MRC dahil olmak üzere kodu incelemek isteyen herkes bunu yapabilir.
(Önceki çeyreklerde de raporlanmıştır) Prodüksiyon Desteği	Chrome'un, ekosistemi etkileyen Özel Korumalı Alan teknik sorunlarını ve üst birime iletilecek sorunları desteklemek için uyguladığı süreç nedir?	Google, reklam teknolojisi uzmanlarının teknik sorunları bildirmesine ve bu tür sorunların çözülmesi için gerekli üst birime iletmelerine olanak tanıyan çeşitli kanallar sunar. Ayrıca Chrome, ekosistemin sağlığını etkileyen teknik sorunları ve üst birime iletilen sorunları çözmek için bir süreç daha geliştirip ölçeklendirmeyi planlıyor. Chrome, bu çalışma için gerekli kaynakları sağlamayı taahhüt eder. Geri bildirim ve üst birime iletme için lütfen herkese açık ve özel forumlarımızı ziyaret edin.
Chrome tarafından desteklenen test modları	Chrome tarafından desteklenen test modlarının zaman çizelgeleri ve tam uygulamaları hakkında daha fazla bilgi.	Test modları hakkında bir blog yayını paylaştık ve yakında daha fazla bilgi paylaşmak için çalışıyoruz. Test modu etiketlerinin ne kadar büyük olması gerektiğine dair önerilerinizi bekliyoruz.
Diğer sektör standartlarıyla entegrasyon	Privacy Sandbox API'leri, TCF v2.* veya Consent Mode'a bağlanacak mı?	Özel Korumalı Alan API'lerini doğrudan TCF 2.0 sürümü veya izin moduyla entegre etme planımız yoktur. Ancak şirketlerin ve sektör ticaret gruplarının, ürünlerini ve çerçevelerini Özel Korumalı Alan API'leriyle birlikte çalışacak şekilde uyarlamalarına izin verilir. Örneğin, TCF gibi çerçevelerde her katılımcı, aldığı TCF sinyaline ve ilişkili TCF politikalarına göre kendi uygunluk yaklaşımını belirlemelidir. Şirketlerin, Özel Korumalı Alan yapı taşlarımızın sunduğu çeşitli işlevleri ne zaman ve nasıl kullanacağını belirlemesini bekliyoruz.

Kayıt ve Onay

Geri Bildirim Teması	Özet	Chrome Yanıtı
Kısıtlama	Kayıt süreci, Google'ın ekosistemdeki hangi şirketin Özel Korumalı Alan API'lerini kullanmasına izin verileceğine karar verebileceği anlamına gelir.	Kayıt ve Attestasyon süreci temel olarak tüzel kişinin doğrulanmasını (örneğin, tüzel kişinin bir DUNS numarası olması, gizlilik politikasının bağlantısını sağlayabilmesi vb.) gerektirir ve API'leri çağırabilmek için herkese açık attestasyonu zorunlu kılar. Kayıt şartlarını başarıyla yerine getirebilen tüzel kişiler doğrulanır. DUNS numarası olmayan şirketler için Dun & Bradstreet ile birlikte hızlı ve ücretsiz bir DUNS numarası alma süreci sunuyoruz. Amaç, API'lerin gizlilik korumalarını (az önce bahsedilen önlemlerle) iyileştirmenin yanı sıra Özel Korumalı Alan API'lerine bir şeffaflık katmanı eklemektir. Böylece, ilgili taraflar hangi API'nin kim tarafından kullanıldığını ve hangi doğrulamaların yapıldığını daha iyi anlayabilir. Bu konuda sektörden daha fazla geri bildirim almaya açığız. Bu geri bildirimler, süreci şekillendirmek için halihazırda kullanıldı.
Yeniden kayıt yükü	Onay dosyasının geçerlilik süresi 12 ayda bir dolar ve web sitelerinin yeniden kaydolması gerekir.	Ekosistemden geri bildirim aldık ve yaklaşımımızı buna göre değiştirdik. Bu, dosyaların artık 12 ay veya belirli bir süre sonra geçerliliğini yitirmeyeceği anlamına gelir. Kayıt geliştirici kılavuzumuzu ek bilgiler ekleyerek güncelliyoruz.
Onay dosyası	Onay dosyası nasıl kullanılır?	Alaka düzeyi ve ölçüm API'lerini çağıran tüm şirketlerin, yaptırım son tarihine kadar doğrulama dosyasını sitelerine yüklemeleri ve API'leri çağırmaya devam etmek istedikleri sürece herkese açık olarak tutmaları gerekecektir. Web siteleri, Özel Korumalı Alan'dan saatte yaklaşık bir istek alabilir. Diğer olası varlıklar da sorgu gönderebilir. Bu işlem, kayıtlı öğelerin sunucularını sorgulamak ve doğrulama dosyasının geçerli olduğundan emin olmak için kayıt sisteminin kendi mekanizması aracılığıyla gerçekleştirilir. Onaylar, Şeffaflık Raporları'na dahil edilir ve herkes tarafından görülebilir. Şirketlerin, ekosistemin geri kalanı ve ilgili düzenleyici kurumlar gibi beyan ettikleri onaylar doğrultusunda hareket etmesini bekleriz.
Kayıt	Kayıt site başına mı yoksa kaynak başına mı?	Kayıt site düzeyindedir.

Alakalı İçerik ve Reklamlar Gösterme

Konular

Geri Bildirim Teması	Özet	Chrome Yanıtı
Performans	Avrupa Ekonomik Alanı'nda Topics etkinleştirme oranının etkisiyle ilgili performans endişeleri.	İlgili paydaşların bu sorunla ilgili olarak ilgili Veri Koruma Kurumu ile iletişime geçmesini öneririz. Bu tür endişeleri gidermek ve gizliliği artıran teknolojilerin uygulamalarının yasalar tarafından teşvik edilip edilmeyeceğini veya izleme gibi muamele görüp görmeyeceğini (rıza için aynı yaklaşımların gerekli olduğu) etkilemek için en uygun konumdadırlar. Bu durum, Özel Korumalı Alan'daki API'lerin daha seyrek kullanılmasına neden olabilir.
Kayıt	Aşağı akıştaki teklif verenlerin, yayın öncesi SSP'lerden Topics sinyallerini kullanmak için Topics API'ye kaydolması gerekir mi?	İlk Topics API çağırıcısının dışındaki konuların yayın alıcılarının kaydolması gerekmez ancak çoğunun diğer API kullanımları için kaydolmuş olması muhtemeldir. Programdaki şeffaflık çalışmaları kapsamında, Özel Korumalı Alan'a kaydolan kullanıcıların listesi programatik olarak sağlanır. Bu sayede, Topics API'yi kullanan bir kullanıcı, isteğinde bulunursa gönderdiği konuyu alan kullanıcının programa kaydolup kaydolmamadığını kontrol edebilir.
Konu filtreleme	Yalnızca alıcıların almasına uygun olan bilgileri paylaşmak için başka bir arayanın sayfadan aldığı konulara filtre uygulama isteğinde bulunun.	Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirim almaktan memnuniyet duyarız.
Site hariç tutma	Web sitelerinin kullanıcının Konularına katkıda bulunmasını engelleme.	Konular varsayılan olarak çağrılmaz. Konuların seçilmesi sırasında sayfa içeriğinin dikkate alınmadığını ve tüm konuların hassas olmaması için özenle seçildiğini belirtmek isteriz. Web siteleri, aşağıdaki izin politikası başlığını kullanarak sitelerinin konu hesaplamasına dahil edilmesini de kısıtlayabilir: `Permissions-Policy: browsing-topics=()`
Konu gözlemi	Yayıncıların, Chrome'un sayfa içeriğine (ör. başlık veya gövde) göre konuları sınıflandırmasına izin vermesine olanak tanıyor.	Daha önce, siteleri sayfa içeriğine göre konulara ayırma işlevi sunmayı düşündük ve gizlilik ve güvenlik endişeleri nedeniyle bu planı hayata geçirmemeye karar verdik. Bu teklif, bu endişelerden bazılarını azaltabilir ancak ne ölçüde azaltacağı net değildir. Yaklaşan CMA deneme dönemi nedeniyle bu değişikliğin 3PCD'den önce gerçekleşmesini beklemiyoruz. Başka geri bildirimlerinizi buradan gönderebilirsiniz.
Konu gözlemi	Yayıncılar için daha ayrıntılı izin politikaları sağlayın.	Yayıncılar için daha ayrıntılı izin politikaları sunulması, yayıncı sitelerinin Topics API'nin site için faydasını olumsuz etkilemeden Topics API'nin ekosistem için faydasını olumsuz yönde etkilemesine olanak tanır. Konuyla ilgili daha ayrıntılı bir tartışma için Getir ve gözlemle için ayrı izinleri desteklemek üzere izin politikasını güncelleme GitHub sorununa bakın.
Tıbbi ve Sağlık Konular	Konu sınıflandırması neden Tıp veya Sağlık kategorilerindeki konuları kapsamıyor?	Tıp ve sağlık kategorileri hassas konular olarak kabul edildiğinden Konu sınıflandırmasından hariç tutulur.
Konuları getirme	DSP'lerin, başlıklardan yararlanarak getirmeden Topics'i almasının daha hızlı bir yolu.	Başlık yöntemleri, kaynakta farklı bir iframe oluşturmaktan ve bu iframe'den `document.browsingTopics()` çağrısı yapmaktan daha yüksek performanslı ve daha az maliyetlidir. (Bir konuyu gözlemlemek için üst düzey bağlam, konulara erişilen bağlamla eşleşmesi gerektiğinden, çağrı için kaynakta çapraz iFrame kullanılmalıdır.) Bu konu burada ayrıntılı olarak ele alınmıştır.
Konuları getirme	Kaynaklar arası komut dosyası etiketi isteklerinde Topics'in başlıklar aracılığıyla iletilmesini destekleme istekleri.	Güvenlik açısından bu mümkün değildir. Her doküman ve yürütme ortamı, dokümanın kaynağı olan tek bir kaynakla ilişkilendirilir. Aynı ortamda yüklenen ve çalıştırılan üçüncü taraf alt kaynaklarının, dokümanın kaynağına ait olduğu kabul edilir. Bu, bir kaynaktan diğerine izinsiz veri sızıntısını önlemek içindir. Alternatif olarak, `<script>` etiketlerinde `browsingTopics` özelliği sağlayabilirsiniz. Bu, güvenlik açısından temiz olmalı ve ek gecikme eklememelidir. İlgili taraflardan geri bildirim almaya açığız.
Bilinirlik	Topics API ve API'nin nasıl kullanılacağı hakkında kamuoyunda farkındalık oluşturma.	Bu geri bildirimi paylaşan paydaşla iletişime geçtik ve sorun GitHub'da çözüldü. Gelecekte, ekosistemin API'yi anlamasına destek olmaya devam edeceğiz ve paydaşların görüşlerini öğrenmeyi sabırsızlıkla bekliyoruz. Bu sırada, Topics API hakkında daha fazla bilgi edinmek isteyen paydaşların Chrome geliştirici kılavuzundaki dokümanları incelemesini öneririz.
Bildirim	Kullanıcıların Konuları bir web sitesi tarafından gözlemlendiğinde kullanıcıyı uyaran bildirim.	Bu geri bildirimi GitHub'da ele aldık. Kullanıcılar, Chrome Yardım Merkezi'nde Topics kontrolleri hakkında daha fazla bilgi edinebilir.
Makine Öğrenimi	Kullanıcı Topics'ini tahmin etmek için makine öğrenimi nasıl kullanılabilir?	Bu konuyu görüşüyoruz ve ek geri bildirimlerinizi bekliyoruz.
Farklı paydaş türleri için yararlı olması	Küçük reklam teknolojisi şirketleri, tarayıcıların Topics'i hesaplama şekli nedeniyle Topics'i gözlemleyemeyebilir.	Yalnızca kullanıcının son üç hafta içinde söz konusu konuyla ilgili bir sayfayı ziyaret ettiğini gözlemleyen reklam teknolojisi uzmanları bir konu alır. Reklam teknolojisi, ilgili kullanıcı için ilgili konuyla ilgili bir sitede son üç hafta içinde API'yi çağırmadıysa döndürülen değer boş olur. Bu özellik, hizmetleri daha fazla sayıda site sahibi tarafından kullanılan ve bu nedenle belirli bir kullanıcının site ziyaretini gözlemleme konusunda daha fazla fırsata sahip olan reklam teknolojilerinin diğer reklam teknolojilerinden daha fazla konu alabileceği anlamına gelir. Bu özellik, kullanıcıyla ilgili bilgilerin yalnızca temel bilgileri (şu anda üçüncü taraf çerezleri aracılığıyla) zaten gözlemleyebilen taraflarla sınırlandırdığı için API'nin gizlilik korumaları için çok önemlidir.
XHR İsteği	Topics'in `XMLHttpRequest` (XHR) isteklerine dahil edilmesi ne zaman kullanımdan kaldırılacak?	Chrome, Ağustos 2023'te duyurulduğu gibi, Kaynak Deneme sürümünden Genel Kullanım sürümüne geçişte XHR desteğini kullanımdan kaldırmaya başladı. Topics'in kullanıma sunulması devam ederken XHR desteği yalnızca OT özelliklerinin etkinleştirildiği kullanıcılar için eklendi ve bağımsız OT deneme grupları birleştirildiğinde tamamen kullanımdan kaldırıldı. Topics'i XHR ile kullanıyorsanız siteleriniz çalışmayacaktır. Bu konular, XHR istek başlıklarınıza eklenmez. İsteğiniz için `fetch`'e geçmenizi, iframe özelliğini kullanmanızı veya konuları almak için JavaScript API'yi kullanmanızı öneririz. Getirme, tüm modern tarayıcılar tarafından desteklenir ancak Internet Explorer veya Opera Mini tarafından desteklenmez.
Sınıflandırma ve sınıflandırıcı güncelleme süreci	Topics sınıflandırması ve sınıflandırıcı sürüm yayınlama sıklığı ile şirketlerin bu tür güncellemelere nasıl hazırlanabileceği hakkında daha fazla bilgi	Yanıtımız 2. çeyrekten bu yana değişmedi: Yakın tarihli blog yayınında paylaşıldığı gibi, sınıflandırmanın zaman içinde gelişeceğini ve sınıflandırmanın yönetiminin nihayetinde sektördeki paydaşları temsil eden harici bir tarafa devredileceğini umuyoruz. Ayrıca, topics-announce grubunda kullanıma sunma planını da paylaştık.
Kötüye kullanım	Yönlendirme zinciri üzerinden potansiyel saldırı.	Bu sorunu değerlendiriyoruz ve ek geri bildirimlerinizi bekliyoruz.
Yayıncı envanter türleri	Protected Audience ve Topics testi hangi yayıncı envanteri türlerini destekler?	Korunan Kitle veya Konuların, kullanılabilecekleri envanter türleri açısından doğası gereği kısıtlayıcı bir tarafı yoktur.
Artış süresi	Yeni sınıflandırmaların %100'e ulaşması için kademeli artış süresi önerilmez.	Ekosistemden gelen bu geri bildirim isteği ve PATCG toplantılarında yapılan tartışmalar sonrasında, yeni sınıflandırmanın kullanıma sunulması ile ilgili planımızı duyurduk.

Protected Audience API (eski adıyla FLEDGE)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Üst Düzey Açık Artırmalar	Google'ın yayıncı reklam sunucusunu, Google Ad Manager'a üst düzey Protected Audience API açık artırmasının kontrolünü vermeden kullanma olanağı.	Google Ad Manager tarafından sağlanan yanıt: Google Ad Manager'ın Protected Audience API ile ilgili planları, aşağıdaki nedenlerden dolayı üst düzey Protected Audience açık artırmasının kontrolü olmadan Google'ın yayıncı reklam sunucusunu desteklemeyi içermez. Yayıncı reklam sunma pazarında müşterilerimize düzgün bir şekilde hizmet sunabilmek için Google'ın yayıncı reklam sunma sunucusunun üst düzey Protected Audience açık artırmasının kontrolünü elinde tutması gerekir. Yayıncı reklam sunucusu olarak rolümüz, yayıncılara fazla rezervasyon yapmadan doğrudan satılan kampanyalar için pazarlık yapabilmeleri amacıyla tahminler sunmak ve doğrudan rezervasyonlarını optimum şekilde hızlandırıp yayınlamaktır. Bunu yapmak için tüm uygun doğrudan ve dolaylı talebi karşılaştırmak üzere nihai açık artırmayı çalıştırmanız gerekir. Tahmin ve ilerleme hızı, yayıncıların bir reklam sunucusundan beklediği temel işlevlerdir. Doğru tahminler olmadan yayıncılar envanterlerini fazla satabilir ve bu da işletme itibarlarını riske atar. Reklamverenlere verilen rezervasyon sözleşmelerini yerine getirememek, yayıncı ile reklamveren arasındaki doğrudan ilişkiye zarar verme riski de taşır. Bu da yayıncının işletmesi üzerinde önemli bir etki yaratabilir. Bu nedenle, ilerleme hızı da kritik öneme sahiptir. Bu nedenle, kısaca bir yayıncı reklam sunucusunun üst düzey Protected Audience açık artırmasını çalıştırma etkinliğini, yayıncı reklam sunucusunun diğer etkinliklerinden farklı olarak görmeyiz.
`directFrom SellerSignals`	`directFrom SellerSignals` , Google Ad Manager'ın yayıncının bağlamsal açık artırmasının fiyatını görmesini engellemesine olanak tanır.	Chrome yanıtı: Satıcı, `runAdAuction()` öğesini kendi iframe'inden çağırmadığı sürece `runAdAuction()` öğesine iletilen bilgilerin satıcıdan geldiği bilinmez. Çok satıcılı bir açık artırmada, tüm satıcıların `runAdAuction()` çağrısı yapan çerçeveyi oluşturması imkansız hale gelir. `directFromSellerSignals`, satıcının kaynağından yüklenen bir alt kaynak paketinden içerik yükleyerek bu sorunu giderdi. Bu sayede, satıcı açık artırma yapılandırmalarından açık artırmaya iletilen bilgilerin gerçekliği ve bütünlüğü değiştirilemez. Yayıncılar, teknoloji sağlayıcılarının Protected Audience açık artırmalarına ilettiği bilgilerden herhangi birini anlamak için Protected Audience API'yi kullanmak istiyorsa bu teknoloji sağlayıcılardan bu işlevi isteyebilir. Google Ad Manager tarafından sağlanan yanıt: Yıllardır açık artırma adaletine büyük önem veriyoruz. Bu kapsamda, garanti edilmeyen satır öğesi fiyatları da dahil olmak üzere yayıncının garanti edilmeyen reklamcılık kaynaklarından hiçbir fiyatın, açık artırmada teklif vermeden önce başka bir alıcıyla paylaşılmayacağına dair söz verdik. Bu sözümüz daha sonra Fransız Rekabet Kurumu'na verdiğimiz taahhütlerde de onaylanmıştı. Protected Audience açık artırmalarında, `directFromSellerSignals`'den yararlanarak sözleştiğimizi yerine getirmeyi ve çok satıcılı açık artırmalarda açık artırma tamamlanmadan önce herhangi bir açık artırma katılımcısının teklifini diğer açık artırma katılımcılarıyla paylaşmayı planlıyoruz. Üst düzey açık artırma dinamiklerini daha da netleştirme güncellemesinde açıklandığı gibi, bağlamsal açık artırmanın fiyatını kendi bileşen açık artırmamızla da paylaşmayacağız.
Bilgilerin Gösterilmesi	Tarayıcı, hassas iş mantığını ve sözleşme ayrıntılarını açığa çıkarabilir.	Web tarayıcısı kullanan kişi, tarayıcıda gerçekleşen her şeyi görebilir. Tarayıcıda bir reklam açık artırması gerçekleştiğinde, tarayıcı sahibinin bu açık artırmayı izleyebileceği doğrudur. Bu kişi, farklı tarafların ne kadar teklif verdiğini de görebilir. Tarayıcı, kullanıcının aracısı olduğundan bunu değiştirmeye çalışmanın mümkün veya istenilen bir şey olduğunu düşünmüyoruz. Ancak bu işlemleri yalnızca tarayıcıyı kullanan kişi görebilir. Protected Audience API kullanılarak çalıştırılan cihaz üzerinde açık artırmalar, Google'ınki dahil hiçbir sunucu tarafından görülemez.
`PerBuyerExperiment GroupId`	`PerBuyerExperiment GroupId` değerinin mevcut değer aralığı, alıcıların içeriğe dayalı verileri güvenilir sunucu isteğiyle ilişkilendirmesine olanak tanıyabilir.	Protected Audience API'nin bu şekilde kullanılması, API kullanıcılarının Özel Korumalı Alan korumalarını atlatmaya çalışmayacağı yönündeki zorunlu Özel Korumalı Alan beyanı ile tutarlı değildir. Gelecekte, anahtar/değer sunucularının güvenilir yürütme ortamlarında (TEE'ler) çalıştırılması şartı bu saldırıya karşı teknik koruma sağlayacaktır.
Aynı kaynak politikası	Alt alan adlarına izin vermek için aynı kaynak politikasını esnetin.	Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirim almaktan memnuniyet duyarız.
API sürümleri	Protected Audience API'deki değişiklikler için sürümlendirme ve sürüm notları isteğinde bulunun.	Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirim almaktan memnuniyet duyarız.
Çoklu SSP Açık Artırmaları	Üst düzey açık artırma sinyallerinin, bileşen sinyali `auctionSignals` ile JSON birleştirme işlemlerini gerçekleştirmesine izin verin.	Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirim almaktan memnuniyet duyarız.
Teklif sınırı	Teklifi giren reklam bileşenlerinin sayısıyla ilgili sınırı 20'den 40'a yükseltin.	Bu isteği değerlendiriyoruz ve ekosistemden bu özelliğin neden faydalı olacağına dair ek geri bildirimler almaktan memnuniyet duyarız.
(Önceki çeyreklerde de raporlanmıştır) Protected Audience Açık Artırmalarının Performansı	Test kullanıcılarının, Protected Audience açık artırmalarının gecikmesinin yüksek olduğunu bildirmesi.	Protected Audience API, gecikmeyle ilgili konularda genellikle satıcıların teklif verenlerin ne kadar zaman ve kaynak kullanabileceğine karar vermesine olanak tanıyan kontroller oluşturma ve alıcıların kendilerine sunulan kaynakları en iyi şekilde nasıl kullanacağına karar vermesine olanak tanıyan araçlar oluşturma konusunda mevcut standart paradigmayı izlemiştir. Bu denetimler ve araçlar genel olarak şu anda kullanılabilir durumdadır ancak tüm avantajlarından yalnızca alıcılar ve satıcılar tarafından kullanılmaya başlandıktan sonra yararlanılabilir. Ayrıca Chrome, açık artırma hızıyla ilgili çeşitli altyapı iyileştirmeleri üzerinde çalışmaya devam etmektedir (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Bu gecikme azaltma çalışmasının her iki yarısıyla ilgili geri bildirimlerinizi bekliyoruz: Alıcıların ve satıcıların faydalı bulacağı yeni araçlar ve Chrome mühendislerinin incelemesi gereken gözlemlenen darboğazlarla ilgili raporlar.
Alıcı tarafı filtreleme	İlgi alanı gruplarına göre alıcı tarafı filtreleme desteği eklendi.	STP'lerin ve DSP'lerin bu sorunu gidermek için tasarımlarını değiştirebilecekleri birkaç yöntem önerdik: Bazı çalışmaları DSP'nin anahtar/değer sunucusuna taşıma. SSP'ler bazı içerik sinyalleri oluşturup bunları DSP'lere verir. TTP'ler, TTP'ler için içerik sinyallerini önbelleğe alır.
Yayıncı İlgi Alanı Grubu Denetimi	Yayıncı tarafından oluşturulan ilgi alanı gruplarının kullanımını devretmek isteyen yayıncılara destek	İstekle ilgili olarak birçok tarafla görüştük. Yayıncı tarafından oluşturulan ilgi alanı gruplarının "devredilmesiyle" ilgili tüm bu kullanım alanlarının artık desteklendiğine inanıyoruz. Ayrıca, bazı kullanım alanlarının gelecekte daha sorunsuz bir şekilde işleyebilmesi için ek destek sunmamız gerektiğini düşünüyoruz.
(2. çeyrekte de raporlanır) Güvenilir Yürütme Ortamları	Herkese açık olmayan bulut ortamlarında Güvenilir Yürütme Ortamları (TEE) desteği.	Yanıtımız önceki çeyreklerle benzer: Herkese açık bulut tabanlı çözümlerin ötesindeki seçenekler için destek sunma olanaklarını keşfetmeye devam ediyoruz ancak şu anda şirket içi TEE'leri destekleme planımız bulunmuyor. Bu aşamada, Özel Korumalı Alan güvenlik şartları ve şirket içi dağıtımların sunduğu önemli zorluklar göz önüne alındığında, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye (ör. AWS'ye ek olarak Google Cloud'u desteklemeye) devam etmenin ekosistem için en yararlı seçenek olduğuna inanıyoruz. Bununla birlikte, gizlilik ve güvenlik kısıtlamaları göz önüne alındığında bu tür bir şartın neden gerekli ve uygulanabilir olduğu konusunda ek geri bildirimlerinizi bekliyoruz.
Güvenilir Yürütme Ortamı	TEE yayınlama yolundaki bileşenler (ör. yük dengeleyici) tüm trafiği gözlemleyebilir ve her isteğin IP adresi hakkında bilgi sahibi olabilir.	Şu anda IP adresi, hem teklifli sistem hem de açık artırma ve cihaz üzerinde Protected Audience açık artırmaları söz konusu olduğunda, güvenilmeyen satıcının reklam hizmetine istek başlıklarında meta veri olarak iletilmektedir. Daha fazla bilgi için Meta veri yönlendirme bölümüne bakın. Uzun vadede, reklam teknolojisi ve izleyici trafiğini bir IP proxy üzerinden proxy'lemeyi planlıyoruz. Bu, bileşenlerin yayın yolunda tüm trafiği gözlemlemesini önler.
Geçerlilik süresi (TTL)	Hizmetlerin yeni anahtar istemesi için geçerlilik süresi (TTL) ayarlanacak mı yoksa esnek (veya dinamik) olması mı amaçlanıyor?	TTL genellikle statiktir. Şu anda herkese açık için TTL 8 gündür ve rotasyon 7 günde bir gerçekleşir. Toplama Hizmeti'nde özel anahtarlar için de TTL aynıdır. Teklif ve açık artırma hizmetlerinde, gizli ve herkese açık anahtarlar istek dışı yolda N saatte bir getirilir ve bellekte önbelleğe alınır. Böylece, anahtarların dönmesi ile sunucuların bu anahtarları alması arasında en fazla N saatlik bir gecikme olur. Anahtar rotasyonu ile geçerlilik süresi sonu arasında 1 günlük bir tampon bulunur. Bu tampon, anahtar oluşturma işlemi başarısız olsa bile hizmetlerin çalışmaya devam etmesini sağlar. Kesintilere karşı daha dayanıklı olması için TTL'yi uzatmayı düşünüyoruz. Anahtar sızıntısı olması durumunda, anahtar oluşturmayı manuel olarak zorlamayı ve anahtarları daha erken geçersiz kılmayı planlıyoruz. Koordinatör kesintisi durumunda hizmetlerin çalışmaya devam edebilmesi için herkese açık anahtarların şu anda 24 saat boyunca istemcilerde önbelleğe alındığını unutmayın.
Trafik Şekillendirme	Teklif ve Açık Artırma Hizmetleri için Trafik Şekillendirme desteği.	Alıcılar, yayıncı birinci taraf verilerine veya bağlamsal verilere göre Korunan Kitle açık artırmalarına yönelik talebi belirtebilir. Satıcılar, satıcının reklam sunucusunda veya Ad Exchange sunucusunda da benzer belirlemeler yapabilir. Modeller, birinci taraf verileri ve Protected Audience açık artırmalarından elde edilen tüm toplu raporlar üzerinde eğitilebilir. Satıcılar, Protected Audience açık artırmaları için talep olmadığında Teklif Verme ve Açık Artırma sunucularına istek göndermekten kaçınmak için bu bilgileri kullanabilir. Bunun trafiği şekillendirmenin etkili bir yolu olabileceğini düşünüyoruz.
Bileşen Açık Artırması	Hangi üst düzey açık artırma sinyalleri bileşen satıcılarıyla paylaşılır?	Bileşen açık artırmasında alıcılar yalnızca bileşen satıcısından sinyal alır. Başlıktan teklif alma ve Protected Audience açık artırmasıyla birlikte açık artırmanın genel sırası hakkındaki dokümanları yakında paylaşmayı planlıyoruz.
Video oluşturma	Protected Audience ve Çitli Çerçeveler kullanılarak video oluşturma desteği.	Protected Audience API, iframe'lere dayalı bir mekanizma kullanarak video oluşturmayı destekler. Ancak henüz Çitli Çerçeveler ile uyumlu bir çözüm tasarlamadık. Çitli Çerçeveler yaptırımını 2026'ya erteleme kararımızın nedenlerinden biri de budur. Yani bir iş ortağı, korumalı çerçeveleri hemen uygulamaya karar verirse video desteği bu iş ortağı için eksik olur.
Sıklık sınırı	(Önceki çeyreklerde de raporlanmıştır) Bir kampanya ve reklam grubundaki kullanıcı başına sıklık kontrolleri.	Yanıtımız önceki raporlardan farklı değil: Protected Audience, cihaz üzerinde açık artırmalar ve bağlamsal ve marka kampanyaları için de sıklık sınırlamasını destekleyecektir. Ortak depolama alanı ve siteye özel sınırlar, ek sıklık sınırı kontrolleri için de kullanılabilir.
Reklam Tercihleri	Protected Audience, reklamveren sitelerine göre kapsam dışında kalmayı veya engellenenler listesine eklemeyi ya da aynı sahipteki tüm ilgi alanı gruplarını bırakmayı sağlıyor mu?	Kullanıcıların Protected Audience API'ye ve diğer Özel Korumalı Alan özelliklerine erişimi engellemesinin birkaç yolu vardır.
Teklif ve açık artırma komut dosyalarının kaynak URL'si için aynı kaynak politikası	Komut dosyalarını veya JSON'u yüklemek için URL'leri belirten tüm alanların, sahiple aynı kaynakta olması şartını gevşetme.	Şu anda bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirimler almaktan memnuniyet duyarız.
`forDebuggingOnly`	3. PCD'den sonra `forDebuggingOnly .reportAdAuctionWin`'ün kötüye kullanıma açık olması	Geçtiğimiz yıllarda, üçüncü taraf çerezlerinin desteği sonlandırıldıktan sonra Korunan Kitle'deki işlevsel boşluklarla ilgili olarak ekosistemden geri bildirim aldık ve Privacy Sandbox'ın hedeflerinden ödün vermeden 3PCD'den sonra bu işlevleri desteklemek için bir plan oluşturmaya çalışıyoruz. Ekosistemin görmek istediği eksik işlevlerle ilgili ek öneri ve geri bildirimleri memnuniyetle karşılıyoruz.
Birden Çok İlgi Alanı Grubu	Aynı teklifte birden fazla ilgi alanı grubu kullanma	Temel gizlilik modelinde bir değişikliğe neden olacağından bu özellik şu anda Protected Audience API'de desteklenmemektedir. Burada daha fazla tartışma yapabilirsiniz.
Cihaz üzerinde açık artırmalar	Android'deki Chrome, cihaz üzerinde Protected Audience açık artırmalarını destekleyecek mi?	Evet, Android'de Chrome'da cihaz üzerinde açık artırmalar desteklenecek.
(2023'ün 2. çeyreğinde raporlandı) Tıklamayla ilgili veriler	Tarayıcı sinyallerine tıklamayla ilgili veriler ekleyin.	Bu özellik isteğini değerlendirmeye devam ediyoruz. Bu özelliğin neden öncelikli olması gerektiğine dair ek geri bildirimler gönderebilirsiniz.
Güvenilir Yürütme Ortamı sağlayıcıları	Farklı bulut sağlayıcıların Güvenli Yürütme Ortamı tekliflerinde önemli farklılıklar var mı?	Önemli bir fark olduğunun farkında değiliz ancak ekosistemin, ihtiyaçlarına en uygun çözümü görmek için herkese açık dağıtım kılavuzlarını incelemesini öneririz. Google Cloud. AWS.
(Önceki çeyreklerde bildirilmiştir) Negatif ilgi alanı grubu hedefleme desteği	Negatif ilgi alanı grubu hedeflemeyi destekleyen bir API: Reklamları yalnızca kullanıcı bir ilgi alanı grubuna ait değilse gösterir.	Bu özelliği uygulamayı düşünüyor ve isteği tartışıyoruz.
İçerik İhlali	Kullanıcıların, Protected Audience API tarafından çitli çerçevelerde yayınlanan kötü reklamları bildirmelerine olanak tanıyan özellikleri destekleyin.	Mevcut kapalı çerçeve reklam raporlama mekanizmasının, kullanıcı tarafından oluşturulan "kötü reklamlar" raporlama akışı isteyen reklam teknolojisi uzmanları için iyi seçenekler sunduğunu düşünüyoruz. Bu sayede, kötü reklamların raporlanması, günümüzdeki endüstri standardından esasen farklı olmayan bir şekilde yapılabilir. Üçüncü taraf çerezlerinin kaldırılmasından sonra ancak Çitli Çerçeve oluşturma yaygınlaşmadan önce kalan boşluklar da dahil olmak üzere ek özellik isteklerinizi bekliyoruz.
Private Aggregation API Raporları	Kullanıcının ilgili ilgi alanı grubunda geçirdiği süreyi nasıl hesaplayabiliriz?	Chrome M116 ve sonraki sürümlerde, pull/639'da tanımlandığı şekilde yakınlığı kullanabilirsiniz.
K-anonimlik sunucusu	K-anonimlik sunucusu hakkında daha fazla bilgi.	K-anonimlik sunucuları hakkında daha fazla bilgiyi burada bulabilirsiniz. Ek geri bildirimlerinizi bekliyoruz.
Dinamik reklam öğesi URL'leri	K-anonimliğe saygı duyarken önceden beyan edilmeyen reklam öğesi URL'leri için destek.	Bu özellik isteği üzerinde tartışıyoruz ve bu özelliğin neden öncelikli olması gerektiğine dair ek geri bildirimler almaktan memnuniyet duyarız.
K-anonimlik koşulu	İlgi alanı grubu güncellemelerinde k-anonimlik şartı yeniden uygulanacak mı?	Bu GitHub yayınında belirtilen konumda değişiklik yapılmasını beklemiyoruz. Bu yayında da açıklandığı gibi, Protected Audience ilgi alanı grubu güncellemelerinde k-anonimlik şartını kaldırmaya karar verdik. Bu şart, API'nin genel gizlilik korumaları üzerinde önemli bir etkiye sahip değildir. İlgili teknolojiler daha gelişmiş, dağıtılmış ve benimsendiğinde daha doğrudan diğer korumaları (ör. IP adresi gizliliği veya güvenilir güncelleme sunucusu) değerlendirmeyi planlıyoruz.
Teklif ve Açık Artırma Hizmetleri Beta Testi	Teklif ve Açık Artırma Hizmetleri Beta testi ne zaman başlayacak?	Zaman çizelgesi ve yol haritası bölümünde belirtildiği gibi, Teklif ve Açık Artırma Hizmetleri testinin ilk aşaması Kasım 2023'te başlayacak.
Birlikte gösterme	Reklam ağları için reklam öğesi koordinasyonu desteği isteği (SSP ve DSP aynı şirkette veya mülklerdedir).	Bu kullanım örneğiyle ilgili geri bildiriminiz için teşekkür ederiz. Daha fazla reklam teknolojisinin bu özelliğin desteklenmesini isteyip istemediğini öğrenmek istiyoruz. Ek geri bildirimlerinizi bekliyoruz.
Doğal Reklamcılık	Yerel reklamcılık için çit çerçeve desteği.	Kullanım alanını desteklemeyi düşünüyoruz ve olası geçici çözümler ve çözümler üzerinde tartışıyoruz.
K-anonimliği	k-anon eşiklerini karşılayan ilgi alanı grubu reklamlarını nasıl en üst düzeye çıkarabilirim?	Bu konuyla ilgili taktiksel bazı bilgiler paylaşmıştık.
POST desteği	Açık artırma verilerini POST istekleri aracılığıyla gönderme desteği.	Bu özellik isteğini değerlendiriyoruz ve bu özelliğin neden öncelikli olması gerektiğine dair ek GitHub sorunu göndermelerini bekliyoruz.
Raporlama ayrıntı düzeyi	Birden fazla parçadan oluşan reklamlar için çitle çevrili çerçeve reklam raporlamasının raporlama ayrıntı düzeyi nedir?	Mevcut tasarım, kullanıcı gizliliğini ihlal edebileceği için ürün kimliğinin veya konumunun yakalanmasına izin vermez. Yalnızca `reserved.top_navigation` çağrılabilir. Bu, reklam bileşeni çitli çerçevesinde bir kullanıcı etkinleştirmesi (ör. tıklama) olduğunda gönderilir ve üst düzey bir gezinmeyle sonuçlanır.
Reklam açık artırması	Bir bileşen açık artırmasına katılan STP, başka bir bileşen açık artırmasını kendisi tetikleyebilir mi?	`componentSeller`, `componentAuctions` öğesini de içeremez. Çok satıcılı açık artırmanın yalnızca iki seviyesi vardır: 1. Bileşenler paralel olarak açık artırmaya girer. 2. En üst düzey açık artırma (`componentAuction`'deki kazanan reklamın rekabet ettiği yer).
Teklif ve Açık Artırma Hizmetleri'nin kullanılabilirliği	Teklif verme ve açık artırma, Chrome tarafından desteklenen test aşamasında kullanılabilecek mi?	Chrome tarafından desteklenen test aşamasında Teklif Verme ve Açık Artırma Sunucusu kullanılamaz.
Teklif verme sinyalleri	Tarayıcıların teklif sinyalleri istemesine ve silmesine izin verin.	Bu isteği görüşüyoruz ve bu isteğe neden öncelik verilmesi gerektiğiyle ilgili ek geri bildirimlerinizi bekliyoruz.
`generateBid()`	`updateURL` aracılığıyla ilgi alanı grubunun `userBiddingSignals` özelliğini güncelleme olanağı.	Bu teklifi değerlendiriyoruz ve ek geri bildirimlerinizi ve tartışmalarınızı bekliyoruz.
Yayıncı envanter türleri	Protected Audience ve TOPICS testleri hangi yayıncı envanteri türlerini destekler?	Korunan Kitle veya Konuların, kullanılabilecekleri envanter türleri açısından doğası gereği kısıtlayıcı bir tarafı yoktur.
Sunucudan sunucuya entegrasyon	Protected Audience için STP ile TTP arasında doğrudan entegrasyon gerekli mi?	DSP'nin, işlenen bilgileri cihaz üzerinde teklif verme işlevine aktarmak için kendi sunucusunda bağlamsal sinyalleri işlemesi gerekmiyorsa SSP ile DSP arasında doğrudan entegrasyon gerekmez.
B&A'da `bid_currency` alanı	Teklif ve Açık Artırma Hizmeti'nde `bid_currency` alanı desteği.	B&A henüz `bid_currency` desteklemiyor olsa da Ocak 2024'ün sonuna kadar bu özelliği desteklemeyi planlıyoruz. Buradaki zaman çizelgesine göz atın.
`perBuyerSignals`	`perBuyerSignals` için boyut sınırı var mı?	Alıcı başına sinyal sayısıyla ilgili bir sınır yoktur ancak çok fazla veri göndermek, tarayıcının performansını olumsuz yönde etkileyebilir.
Siteler arası kullanım alanları	Protected Audience API ilgi alanı gruplarını birden fazla web sitesinde kullanabilir miyiz?	Protected Audience, turtledove/issues/282 adresinde açıklandığı gibi bu tür kullanım alanları için tasarlanmamıştır.
İlgi Alanı Grubu HTTP İstekleri	HTTP üstbilgilerine İlgi Grubu Blob'unu ekleyin.	Bu isteği değerlendiriyoruz ve bu konuda daha fazla geri bildirim almamızı bekliyoruz.
Reklam kalitesi kontrolü	Siteler arası bilgilerle ilgili reklam kalitesi kontrolünün kaybedilmesi.	Bu geri bildirimi değerlendiriyoruz ve ek geri bildirimlerinizi bekliyoruz.
Chrome Geliştirici Araçları	Giden Protected Audience ağ istekleri, Chrome Geliştirici Araçları Ağ sekmesinde görünür.	Bu işlevi ağ sekmesinde etkinleştirmek için çalışmalarımızı sürdürüyoruz. Bu işleve neden öncelik verilmesi gerektiğiyle ilgili ek geri bildirimler de memnuniyetle karşılanır.
Güvenilir Yürütme Ortamı	Gizliliği etkileyen metriklerin (ve bunların derecelerinin) Güvenli Yürütme Ortamı izlemeyle ilgili açıklamaya ne zaman ekleneceği?	Açıklamayı bu bilgilerle güncelliyoruz. Güncellenen açıklama metni Kasım 2023'e kadar kullanıma sunulacaktır.
`directFrom SellerSignals`	`directFrom SellerSignals` neden web paketi olarak paketlenmiyor?	Bu kararın gerekçesini burada paylaşmıştık.
Gösterim yetkisi verme	Bir ilgi grubunun seçilmesinin sonucunun başka bir hedefleme işlemi olduğu gösterim yetkilendirmesinin uygulanabilir bir yolu var mı?	Birden fazla iç içe yerleştirilmiş açık artırma, iki nedenden dolayı gizlilik hedeflerimizle uyumlu değildir. Öncelikle, bir açık artırmanın galibi Çitli Çerçeve içinde oluşturulduğunda, Korunan Kitle için gizlilik hedeflerimiz, bağlam bilgisi olmadan oluşturulan reklam öğesini içerir: Çevredeki sayfanın URL'si veya birinci taraf çerezi gizlilik ihlalidir. Bu ortamda iç içe yerleştirilmiş açık artırma uygun değildir. İkinci olarak, Protected Audience modeli, her açık artırmanın kazananının yalnızca bir ek sitedeki verilere dayalı olması gerektiğini belirtir. İç içe yerleştirilmiş açık artırmalar, bu sorunu çözmenin bir yoludur ve reklamları birçok site profiline göre seçme olanağı sunar.
Aktif Olmayan Veriler kriteri	Anahtar/Değer hizmet güven modeli kapsamındaki Aktif Olmayan Veriler ölçütünü daha ayrıntılı şekilde açıklayın.	Anahtar/Değer Hizmeti'ndeki veriler, okuma önbelleğe alma işlemi yapılmadan belleğe yüklenir ve buradan sunulur.
Alıcı Verileri Sinyali	DSP'lerden alınan `buyer_data` sinyalleri için tanımlanmış bir boyut sınırı var mı?	DSP'lerden alınan `buyer_data` sinyalleri için şu anda tarayıcı tarafından uygulanan sınırlar yoktur.

Dijital reklamları ölçme

İlişkilendirme raporları (ve diğer API'ler)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Cihazlar arası	Attribution Reporting API için cihazlar arası destek planlayın.	Cihazlar arası, 3PC'nin yanı sıra yeni gizlilik sorunları sunar ve kullanıcının kullanabileceği cihaz ve platform yelpazesi göz önüne alındığında teknoloji dağıtımıyla ilgili sorunlar da ekler. Olası çözümleri araştırıyoruz ancak şu anda İlişkilendirme Raporlaması tarafından desteklenen kritik kullanım alanlarına odaklanıyoruz ve üçüncü taraf çerezleri kaldırılmadan önce cihazlar arası desteği kullanıma sunmayı planlamıyoruz.
(Önceki çeyreklerde de raporlanır) Tetikleyici Veri Boyutu	Tetikleyici veri boyutu neden 3 bit ile sınırlıdır?	Boyut, bir kullanıcıyla ilgili siteler arası ve bağlamlar arası bilgi miktarının sınırlı olmasını sağlamak için 3 bit ve 8 farklı değerle sınırlıdır. Ekosistemdeki oyuncuların, etkinlik düzeyinde raporlama için mevcut parametreleştirmenin yeterli olup olmadığı konusunda geri bildirim göndermelerini bekliyoruz.
Dönüşüm hunisi	Dönüşümde kullanılan birden fazla alanı raporlayın.	Bu kullanım alanı, birden fazla hedefin eklenmesi sayesinde mümkündür. Ek geri bildirimlerinizi bekliyoruz.
Farklı ülkelerde aynı alan adı desteği	İlişkilendirme raporları, aynı alan adına sahip ancak birden fazla ülke TLD'si olan web siteleriyle çalışır mı?	Bu sorun, soruyu soran paydaşla görüşülmüş ve çözüldü. Bir reklam teknolojisinin birden fazla ülke TLD'si kullanması gerekiyorsa her ülke TLD'si için bir tane olmak üzere birden fazla kayıt işlemi yapması gerekir.
Protected Audience ve İlişkilendirme Raporları	Reklam teknolojileri hem Korunan Kitle açık artırmaları için görüntüleme dönüşümlerine hem de İlişkilendirme Raporlaması için tıklama dönüşümlerine erişebilir mi?	Evet, Özel Korumalı Alan, Protected Audience'ta hem VTC'leri hem de CTC'leri desteklemelidir.
Toplanabilir rapor gecikmeleri	Toplanabilir rapor gecikmelerini daha da azaltın.	Bu konuyla ilgili son geri bildirimleri dinledik ve fikirlerimizi burada paylaştık. Ekosistemden ek geri bildirimler bekliyoruz.
Toplanabilir rapor gecikmeleri	Sunucu arabuluculuğu sunarak gecikmeleri azaltma	Bu öneriyi değerlendiriyoruz ve ek geri bildirimlerinizi bekliyoruz .
Etkinlik düzeyindeki rapor gecikmeleri	Etkinlik düzeyindeki rapor gecikmelerini azaltın.	Esnek etkinlik düzeyi yapılandırmaları bölümünde açıklanan tam esnek etkinlik düzeyi teklifi, gürültü karşılığında etkinlik düzeyinde raporlama gecikmelerini 1 saate kadar düşürebilir.
Kaynak başına kaynak raporlama kaynağı	Kaynak raporlama sitesi başına maksimum kaynak raporlama kaynağı sınırlaması, reklam teknolojilerinin tek bir yayıncı kaynağı için farklı raporlama kaynaklarından kaynak kaydettirmesini engeller.	Bu konu, sorunu gündeme getiren paydaşla görüşüldü ve yönlendirmeleri içeren diğer olası çözümleri denemeden önce kaynak raporlama sitesi başına 1 raporlama kaynağı kullanma olası çözümü test ediliyor. Bu sınırla ilgili ek ekosistem geri bildirimlerini de memnuniyetle karşılarız.
Sorun bildirme	Attribution Reporting API ile ilgili hataları veya sorunları Chrome'a nasıl bildirebiliriz?	Şu anda reklam teknolojisi uzmanlarının, karşılaştıkları tüm İlişkilendirme Raporlama API hatalarını GitHub'da sorun olarak bildirmelerini öneririz. Chrome ile ilgili bir sorunla karşılaşıyorlarsa Chromium hatası oluşturmalarını öneririz. Sorunları nasıl ve nerede işaretleyeceğinizle ilgili bağlantıları Etkileşim kurma ve geri bildirim paylaşma bölümünde bulabilirsiniz.
Tekilleştirme	Farklı ardışık düzenler ve cihazlardaki dönüşümleri nasıl tekilleştirebiliriz?	Cihazlar ve ölçüm ardışık düzenlerinde tekilleştirme, reklam teknolojilerinin günümüzde 3. taraf çerezlerle karşılaştığı bilinen ve mevcut bir zorluktur. Attribution Reporting API ile reklam teknolojisi uzmanları, belirli dönüşümleri ne zaman kaydedeceklerine karar verebilir ve dönüşümleri izlemek için hangi ölçüm ardışık düzenlerini kullandıklarını (yani toplama anahtarının bir bölümünü) belirtmek üzere belirli meta veriler ekleyebilir. Bu meta veriler, diğer ölçüm ardışık düzenleriyle karşılaştırılabilir. Bu konuyla ilgili ek ekosistem geri bildirimlerinizi bekliyoruz.
Tekilleştirme ve Öncelik	Tekilleştirmeden önce öncelikli olarak işleme alınmasını isteyin.	Bu isteği değerlendiriyoruz ve ek geri bildirimlerinizi bekliyoruz.
Sahtekarlıkla mücadele	Kötü amaçlı kullanıcıların etkinlik düzeyindeki verilerle oynama riski.	Rapor doğrulaması, Neden etkinlik düzeyindeki raporları desteklemiyor? bölümünde açıklanan nedenlerle etkinlik düzeyindeki raporlarda kullanılamaz.
Dönüşüm türü	İlişkilendirme raporlarında görüntüleme ve gezinme arasında nasıl ayrım yapabiliriz?	Aşağıdaki yerleşik filtreleme seçeneğimiz mevcuttur: `source_type`. Daha fazla bilgiyi burada bulabilirsiniz.

Aggregation Service

Geri Bildirim Teması	Özet	Chrome Yanıtı
Bütçe kurtarma	Bazı reklam teknolojisi şirketleri, raporlarında hata, silme veya başarısızlık olduğunda raporları yeniden işleyebilme olanağı istedi.	Ekip, bu sorunu gizliliği koruyacak şekilde çözmenin yollarını araştırıyor.
Siteye kayıt	Birden fazla reklam teknolojisi şirketi, verileri coğrafi bölgeye ve reklamverene göre bölme gibi kullanım alanları için aynı hesapta birden fazla kaynağı işleme konusunda destek istedi. İstemci API kaydı artık kaynağa değil siteye dayalı olduğundan reklam teknolojisi şirketleri de bu davranışı bekler. Kaynaktan siteye kayıt işlemine geçiş, istemci kayıt süreciyle tutarlılık sağlayarak reklam teknolojisi oryantasyon sürecini kolaylaştırır.	Yakında, Toplama Hizmeti için kaynak kaydından site kaydına geçişi kullanıma sunacağız. Ekosistemden geri bildirim almaktan memnuniyet duyarız.
Sürüm ve Destek Sonu Planı	Toplama Hizmeti özellikleri ve yayınlanan yamalar için sürüm ve kullanımdan kaldırma programı. Planın amacı, reklam teknolojisi uzmanlarının yaklaşan sürümlere ve desteği sonlandırılan sürümlere hazırlanmalarını sağlamak ve hizmetlerin kararlı ve güvenli sürümlerini çalıştırmalarını sağlamak için sürüm politikalarımızı görünür hale getirmektir.	Kısa süre önce, Toplama Hizmeti sürüm ve desteği sonlandırma planı için bir teklif yayınladık ve ek geri bildirimlerinizi bekliyoruz.
Koordinatörler	Koordinatörler toplama hizmetinde devre dışı kalırsa ne olur?	Sistemin düzgün çalışması için her iki koordinatörün de tam olarak kullanılabilir durumda olması gerekir. Kısa süreli hizmet dışı kalma durumları, istemci kitaplıklarımızdaki yeniden denemelerle telafi edilir. İki koordinatöründen birinin daha uzun süre hizmet dışı kalması durumunda ise toplama işleri başarısız olur. Gizlilikle ilgili bütçe henüz tüketilmemişse işler yeniden çalıştırılabilir. Herhangi bir hizmet hatası, reklam teknolojisi depolama alanına özet rapor yazılmadan bütçe tüketimine yol açtığında, şu anda yerel test aracını kullanarak sonuçları almak için hata ayıklama raporlarını kullanmalarını öneririz. Reklam teknolojilerinin işlerini yeniden çalıştırabilmesi için hata durumunda bütçenin kurtarılmasına olanak tanıyan özellikler üzerinde de çalışıyoruz.

Private Aggregation API

Geri Bildirim Teması	Özet	Chrome Yanıtı
Blob URL'si	Ortak Depolama Alanı'nda Blob URL'sinin desteklenmesi için istek.	Blob URL'si desteği Chrome M116'ya eklendi.

Gizli İzlemeyi Sınırlama

Kullanıcı Aracısı Azaltma ve Kullanıcı Aracısı İstemci İpuçları

Geri Bildirim Teması	Özet	Chrome Yanıtı
JavaScript API	User-Agent Client Hints JavaScript API'nin kullanılabilirliği.	Dondurulmuş ve azaltılmış UA'da varsayılan olarak sunulanın ötesinde yüksek entropili verilere etkin bir şekilde erişmek isteyen iş ortaklarımız için temel çözümümüz olduğundan bu işlevi kaldırmayı planlamıyoruz.
Cihaz ve Form Faktörü bilgileri	Web sitelerinin, web sitesini ziyaret eden cihazın destekleyebileceği giriş, çıkış ve diğer bilgileri anlayabilmesi.	Ekosistemden gelen geri bildirimler doğrultusunda bu istek için destek ekledik.

IP Protection (eski adıyla Gnatcatcher)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Uygun Üçüncü Taraf Trafik	Açıklayıcıdaki "uygun üçüncü taraf trafiği" neyi ifade eder?	Bu sorunun öneminin farkındayız ve hangi üçüncü taraf trafiğinin uygun olacağını, hangilerinin uygun olmayacağını belirlemek için aktif olarak çalışıyoruz. Bu konuyla ilgili geri bildirimlerinizi bekliyoruz.
Ağ Trafiği Denetlemeleri	Kuruluşların ağları için ağ trafiği denetimleri gerçekleştirmesine yönelik destek.	Yalnızca birinci taraf sitelere yerleştirilmiş üçüncü taraf trafiği etkilenecek. Bu da filtreleme gerektiren trafik miktarını sınırlayacaktır. Ayrıca, kullanıcılara IP Koruması'nı kullanıp kullanmayacakları konusunda seçenek sunmayı planlıyoruz. Kuruluş tarafından kontrol edilen Chrome için IP Koruması'nı devre dışı bırakan kurumsal politikalar da olacak. Son olarak, ağ operatörlerine IP korumasını devre dışı bırakmak için hangi denetimlerin (varsa) sunulacağını araştırıyoruz. Bu konuyla ilgili geri bildirimlerinizi bekliyoruz.
Erişim denetimi	IP Koruması, erişim kontrolü için IP adreslerini kullanan web hizmetlerini etkileyebilir.	Sahtekarlık önleme kullanım alanlarının önemini ve bu kullanım alanlarına olası etkilerini anlıyoruz. Genellikle IP adreslerine dayanan sahtekarlık önleme kullanım alanlarını nasıl daha iyi destekleyebileceğimiz konusunda ekosistemden geri bildirim istiyoruz.
2 atlamalı proxy'ler arasındaki iletişim	Proxy'ler arasında bilgi bulunmadığından emin olma	Vekil etkileşimlerini tasarlama sürecindeyiz. Amacımız, bu tür bilgilerin işletme, süreç ve teknik araçlar aracılığıyla paylaşılma olasılığını en aza indirmektir.
Google dışı kimlik doğrulamaları	Google dışı kimlik doğrulamaları için destek.	Hesap kimlik doğrulaması hakkında daha fazla bilgiyi gelecekte paylaşmayı planlıyoruz. Bununla birlikte, ilk olarak dikkate almanız gereken bazı noktaları paylaşmıştık.
İzleyici sınıflandırması	IP Koruma, bir izleyiciyi ve varyantlarını nasıl belirler?	Bu sorunun öneminin farkındayız ve hangi üçüncü taraf trafiğinin uygun olacağını, hangilerinin uygun olmayacağını belirlemek için aktif olarak çalışıyoruz. Bu konuyla ilgili geri bildirimlerinizi bekliyoruz.
Analiz	IP Koruması, analiz hizmetlerinin doğruluğunu etkileyebilir.	IP Koruması'nın etkisini daha iyi anlamak istiyoruz ve ekosistemden ek geri bildirimler ve örnekler bekliyoruz.
Proxy	Bir kullanıcı proxy kullanıyorsa veya manuel olarak proxy tanımladıysa bu durumda IP maskeleme nasıl çalışır?	IP Koruması'nın diğer proxy'ler üzerindeki etkisini anlamaya çalışıyoruz. Şu anda paylaşacak bir planımız yok. Bu konuyla ilgili geri bildirimlerinizi bekliyoruz.
Premium teklif	IP koruması ücretli bir özellik mi olacak?	IP Koruması, temel tarayıcı deneyiminin bir parçası olarak Chrome kullanıcılarına sunulacaktır. Bu özellik ücretli olmayacak.
Proxy sunucusu	Kullanıcı oturumları sırasında aynı proxy sunucuları mı kullanılacak?	HTTP/S bağlantısı tek bir proxy çifti kullanır ve kaynağa tek bir maskelenmiş IP adresi sunar. Bunun dışında, farklı HTTP/S bağlantılarının aynı sunucuları kullanması gerektiğine dair katı kısıtlamalar yoktur.
Platform desteği	IP Koruması hangi platformlarda desteklenir?	IP Koruması başlangıçta Android ve masaüstü için Chrome'da kullanıma sunulacaktır. Korumayı diğer platformlara nasıl genişleteceğimizi değerlendirmeye devam ediyoruz.
Kapsam dışında kalmayı seçme	Kullanıcılar IP korumasını devre dışı bırakabilir mi?	Kullanıcılara IP Koruması'nı kullanmak isteyip istemedikleri konusunda seçim yapma olanağı sunmayı planlıyoruz.
Anonimleştirme	IP koruması kapsamında ne tür istekler anonimleştirilir?	Uygun üçüncü taraf alan adlarına yönelik HTTP/S ve DNS istekleri, gizlilik proxy'leri aracılığıyla anonimleştirilir. Hangi alan adlarının dahil edileceğini nasıl belirleyeceğimizle ilgili daha fazla bilgiyi yakında yayınlayacağımız bir makalede bulabilirsiniz. Trafiğin geri kalanı (ör. DNS isteklerinin geri kalanı veya diğer HTTP/S trafiği) bu durumdan etkilenmez.
Veri Görünürlük	IP Koruması'nda ilk atlama sırasında ağ adreslerine erişilebilir.	İki durak proxy modelinde, ilk durak (Google tarafından kontrol edilir) yalnızca kaynak istemci IP'sini ve ikinci durağa bağlanma isteğini görür. İkinci durak (harici bir CDN tarafından kontrol edilir) ise yalnızca ilk duraktaki bir tuple'i (proxy IP + bağlantı noktası) ve hedef IP'yi görür. Kaynaktan gelen yanıt için ikinci durak, yanıtı istekle ilişkili ilk durak proxy'sine ve bağlantı noktasına iletebilir ve orijinal istemci IP'si hakkında hiçbir şey öğrenmesi gerekmez (ve ilk durak, hedef IP hakkında hiçbir şey öğrenmeden yanıtı istemciye döndürür). Bu sayede, ilk durak yalnızca istemci IP'sini ve ikinci durağı, ikinci durak ise yalnızca hedef IP'yi öğrenir.
Web Görünümü	IP koruması gelecekte Android Web Görünümü'nde kullanılabilir mi?	Şu anda paylaşabileceğimiz bir planımız yok ancak bu korumayı mümkün olduğunca geniş bir kitleye sunmayı amaçlıyoruz.

Hemen Çıkma Durumunu İzleme Çözümü

Geri Bildirim Teması	Özet	Chrome Yanıtı
Etkileşim İzleme	Kullanıcı etkileşimleri nasıl izlenir?	Hemen çıkma durumunu izleme çözümleri iki tür kullanıcı etkileşimini izler: html spesifikasyonu tarafından tanımlanan kullanıcı etkinleştirmeleri. Bunlar temel olarak tıklamalar, tuş basışları, dokunmatik ekrana dokunmalar vb.dir. Başarılı webauth iddiaları. Kullanıcının kimlik doğrulama yöntemi olarak bir güvenlik anahtarına dokunduğu veya geçiş anahtarı kullandığı durumlar Bu etkileşimler, gerçekleştikleri sayfalardaki üst düzey siteyle ilişkilendirilir. Örneğin, bir kullanıcı yerleşik bir iframe'i tıklarsa etkileşim, yerleşik siteyle değil üst düzey siteyle ilişkilendirilir. Etkileşimler, schemelessetld+1 ve etkileşimin zamanını içeren bir veritabanında saklanır. Etkileşimler, ilişkili alanı 45 gün boyunca hemen çıkma izleme azaltma durumu silme işleminden korur.
İzin verilenler listesindeki muafiyetler	Alan adları muaf tutulabilir mi?	Bu isteği değerlendiriyoruz ve ekosistemden daha fazla geri bildirim almaktan memnuniyet duyarız.

Gizli Erişim Limiti

Bu çeyrekte geri bildirim alınmadı.

Siteler arası gizlilik sınırlarını güçlendirme

İlişkili Web Sitesi Grupları (eski adıyla Birinci Taraf Gruplar)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Merkezi Yaklaşım	İlişkili Web Sitesi Gruplarını yönetmek için merkezi depolama alanı yaklaşımıyla ilgili endişeler.	Gönderimler için hesap verebilirlik sağladığı için herkese açık ve kolayca erişilebilen bir depo, RWS tasarımının temelini oluşturur. Üçüncü taraf çerez işlevi, Storage Access API veya rSAFor API'nin kullanılmasıyla sağlanır. RWS üyeliği, otomatik olarak verilen erişimi (Storage Access API'deki istemler yerine) sağlar. RWS gönderim süreci gibi bir yaklaşımın, otomatik olarak verilen üçüncü taraf çerez erişimi için uygun bir şart olduğunu düşünüyoruz.
JSON dosyasını yeniden adlandırma	API adında yapılan değişiklik nedeniyle barındırılan JSON dosyasının adının değiştirilmesi gerekiyor mu?	Evet, gönderim yönergeleri değişti ve birincil alan adı `/.well-known/related-website-set.json` adresinde bir JSON dosyası sunmalıdır. RWS listesindeki mevcut grupların değiştirilmesi gerekmez ancak mevcut gruplara gönderilen değişiklikler varsa JSON dosyasının değiştirilmesi gerekir.
(Önceki çeyreklerde de raporlanmıştır) Alan Sınırı	İlişkilendirilen alan adlarının sayısını artırma isteği	31 Ağustos'taki bir blog yayınında duyurduğumuz gibi, ekosistemden gelen geri bildirimler doğrultusunda ilişkili alan sınırını beş alana çıkardık. İlişkili alan sınırını, başka bir büyük tarayıcı tarafından sunulan en benzer uygulamayla en iyi eşleşen beş alan (ve bir birincil alan) olarak artırmaya karar verdik.
Üçüncü Taraf Çerezleri	İlgili web sitesi grupları yalnızca üçüncü taraf çerezleri devre dışıyken çalışır mı?	İlgili web sitesi grupları, kullanıcı üçüncü taraf çerezlerini engellememiş olsa bile çalışır. Ancak ilgili çerezler, İlgili Web Sitesi Grupları ve Depolama Alanı Erişimi API'sine gerek kalmadan kullanılabildiğinden, gözle görülür bir etki olmaz.
Meşru düzenlemeler	İlgili Web Sitesi Kümeleri deposu, sahip olmayan kullanıcıların kümeleri değiştirmesini nasıl engeller?	Gönderim kılavuzlarına göre, herkes GitHub'da `first_party_sets.JSON` dosyasını düzenlemek için PR gönderebilir. Ancak PR onaylanırsa (teknik doğrulamalar vb. geçerse) Google tarafından haftada bir kez (Salı günleri saat 12:00 (Doğu Saati)) standart FPS listesine manuel olarak birleştirilir. Kötü niyetli bir kullanıcı, sahip olmadığı bir grubu değiştirmeye çalışırsa `.well-known` dosyalarını değiştiremeyeceği ve doğrulamalar başarısız olacağı için bu durum sorun oluşturmaz.
Alan adı kaçakçılığı	Alan adı kaçırılması, ilgili alan adı verilerini yetkisiz taraflara açabilir.	Bu Protected Audience GitHub sorununda belirtildiği gibi bu mümkün değildir.

Fenced Frames API

Geri Bildirim Teması	Özet	Chrome Yanıtı
İçerik İhlali	Kullanıcıların şüpheli reklamları bildirmesine izin verin.	Şüpheli reklam bildirme, çitli çerçeveler tarafından engellenmez. Kullanıcılar reklamla etkileşime girmeye ve şüpheli reklamları normal şekilde reklam teknolojisine bildirmeye devam edebilir.
Çevredeki sitelerle etkileşim	Çevredeki veya üst düzey web sitesiyle etkileşime izin verin.	Bu isteğin neden gerekli olduğunu anlamak istiyoruz ve ekosistemden ek geri bildirimler bekliyoruz.
Doğal Reklamcılık	Yerel reklamcılık için çit çerçeve desteği.	Kullanım alanını desteklemeyi düşünüyor ve olası geçici çözümleri ve çözümleri tartışıyoruz.

Shared Storage API

Geri Bildirim Teması	Özet	Chrome Yanıtı
Alanlar arası	Yerel depolama alanı için alanlar arasında iletişime izin verin.	Bu kullanım alanı şu anda Paylaşılan Depolama Alanının gizliliği korumaya yönelik çıkış kapılarıyla uyumlu değil ancak bölümlenmemiş depolama alanı için teklifleri geliştirirken ek bağlam bilgilerini memnuniyetle karşılıyoruz.
Blob URL'si	Ortak Depolama Alanı'nda Blob URL'sinin desteklenmesi için istek.	Blob URL'si desteği Chrome M116'ya eklendi.

CHIPs