Geri Bildirim Raporu - 2024 2. ve 3. Çeyrek

Özel Korumalı Alan teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2024 2. ve 3. çeyrek için üç 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). Google, 22 Temmuz 2024'te Chrome'da üçüncü taraf çerezlerine (3. taraf çerezleri) yönelik desteği sonlandırmayacağını duyurdu ve bunun yerine kullanıcı tercihine öncelik veren yeni bir yaklaşımı kullanıma sunmayı önerdi. Bu nedenle Google, CMA'nın da kabulü ile Google'ın ve CMA'nın Google'ın duyurusunun sonuçlarını dikkate almaları için yeterli süre tanımak amacıyla 2024'ün 2. çeyreğine ait herkese açık bir rapor sunmadı.

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'lerin yaygınlık düzeyine 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ı olarak 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ı.

Mevcut raporlama döneminin bitiminden sonra alınan geri bildirimler henüz Chrome yanıtı olarak değerlendirilmemiş olabilir.

Kısaltmalar sözlüğü

ARA

Attribution Reporting API

CHIPS

Bağımsız Bölümlendirme Durumuna Sahip Çerezler

DSP

Talep Tarafı Platformu

FedCM

Birleşik Kimlik Bilgisi Yönetimi

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ü

PAT API'sı

Protected Audience API (eski adıyla FLEDGE)

PatCG

Private Advertising Technology Community Group

KY

Bağlı Taraf

RWS

İlgili Websitesi Grupları (eski adıyla Birinci Taraf Gruplar)

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 Consortium

WIPB

İstençli IP Körlüğü

Belirli bir API/teknolojiyle ilgili olmayan genel geri bildirimler

Geri Bildirim Teması	Özet	Chrome Yanıtı
Üçüncü taraf çerez desteğinin sonlandırılması (3PCD)	Google'ın 3PCD ile ilgili planları nelerdir ve dijital reklamcılık sektörü üzerindeki uzun vadeli etkileri değerlendirildi mi?	Kullanıcı tercihine öncelik veren güncellenmiş bir yaklaşım öneriyoruz. Burada belirtildiği gibi, 3. taraf çerezleri desteğini sonlandırmak yerine Chrome'da kullanıcıların web taramalarında geçerli olacak bilinçli bir seçim yapmalarına olanak tanıyan yeni bir deneyim sunacağız. Kullanıcılar bu seçimi istedikleri zaman değiştirebilecek. Bu yeni yolu düzenleyicilerle görüşüyoruz ve kullanıma sunmadan önce sektörle iletişime geçeceğiz.
Kullanıcının Seçimi	Kullanıcı tercihi duyurusu, ekosistemin Özel Korumalı Alan çözümlerini benimseme ilgisini etkiledi. İzleme özellikleri gibi özelliklerle ilgili istekler de dahil olmak üzere kullanıcı tercihi duyurusuyla ilgili karma geri bildirimler var.	Kullanıcı seçimini artıran güncellenmiş yaklaşımla birlikte, geliştiricilerin siteler arası tanımlayıcılara gizliliği artıran alternatiflere sahip olması önemini koruyor. Yeni deneyimin nasıl olacağına dair henüz paylaşabileceğimiz ayrıntılar olmasa da Chrome'da çerezsiz trafikte önemli bir artış bekliyoruz. Bu nedenle Özel Korumalı Alan API'leri işletmeler için hâlâ kritik öneme sahip. Gizliliği ve işlevselliği daha da artırmak için Özel Korumalı Alan teknolojilerine yatırım yapmaya devam edeceğiz.
Kullanıcı tercihi kullanıcı arayüzü	Kapsam dışında kalma/izin verme özelliklerinin zaman çizelgesi, değerlendirilen kullanıcı seçeneği türü ve kullanıcı arayüzünün otomatik test ortamlarını nasıl etkileyeceği hakkında sorular.	Şu anda paylaşabileceğimiz bir zaman çizelgesi güncellemesi bulunmuyor. Üçüncü taraf uygulama kampanyası geliştirmeyi tercih etmemeye karar verdikten sonra ekosistemi mümkün olan en kısa sürede güncellemek istedik. Kullanıcı tercihi için zaman çizelgesi hakkında bilgi edindiğimizde sizi bilgilendireceğiz.
Chrome Testi	2024'ün 1. yarısından sonra 3D Secure'in pazardaki benimsenmesini ve ekonomik etkisini ölçmek için Chrome tarafından desteklenen test etiketlerinin kullanıma sunulmaya devam etmesini talep etme.	2024'ün 1. yarısında Chrome tarafından desteklenen testin sona ermesine rağmen test kullanıcılarının test ve koordinasyon için etiketli tarayıcı gruplarını kullanmaya devam etmek isteyeceğini biliyoruz. Etiketlerle ilgili sonraki adımları kullanıcı seçimi duyurusu doğrultusunda değerlendiriyoruz. Bu süreçte Chrome ekibi, Ocak 2025'e kadar sürecek Chrome Milestone 132 aracılığıyla etiketli tarayıcı grupları için destek sunmayı planladığı bir plan yayınladı.
Android'de Özel Korumalı Alan	Android'deki Özel Korumalı Alan ile Chrome'daki Özel Korumalı Alan birbirinden bağımsızdır ve Android olmadan Özel Korumalı Alan'ı doğru şekilde değerlendiremeyiz. Cihazlar arası ve çoklu dokunma özelliklerini içeren tipik müşteri yolculuğu, hem Chrome'daki Özel Korumalı Alan hem de Android'deki Özel Korumalı Alan için kritik öneme sahiptir.	Android'de Özel Korumalı Alan'ın, Google'ın CMA'ya verdiği taahhütlerin kapsamında olmadığını lütfen unutmayın. Geri bildirim Android zaman çizelgeleri ve kullanıma sunma sürecine özelse şu anda paylaşabileceğimiz bir güncelleme yok. Gizliliği iyileştirmek için bağımsız bir çalışma akışı olarak ele aldığımız Android'de ilerlemeye devam ediyoruz. Daha önce de belirttiğimiz gibi, Android'de Özel Korumalı Alan API'lerinin kullanılabilirliği, kullanıcıların cihazlarını güncelleme hızına da bağlıdır. Bu hız, Google'ın kontrolünde değildir.
B modu Trafik sınırlı	B modunda kullanılabilen Reklam Açık Artırma Trafiği, beklenenden düşük.	Protected Audience API (PA API) açık artırma hacimlerinin beklenenden düşük olmasının birden fazla nedeni vardır. Örneğin: - PA API'yi entegre ettiğini bildiğimiz şirketler yalnızca banner biçimleri ekledi. - Satış tarafı platformları her zaman açık artırmayı başlatmayabilir. - Tarayıcılarda İlgi Alanı Grupları (İAG) bulunmayabilir. - Teklif olmayabilir. Ancak PA API'yi test etmeye çalışan ve hiç trafik almayan birilerinin farkında değiliz.
Kesinti görünürlüğü	Özel Korumalı Alan API'lerini etkileyen kesintiler ve sorunlar hakkında bilgi edinme.	Tarayıcı dışında hizmetleri olan Özel Korumalı Alan API'leri için herkese açık bir durum sayfası vardır. Chrome ekibi, platformumuzun ve web'deki büyük siteler ve hizmetler tarafından kullanılan tüm kritik API'lerin (Özel Korumalı Alan teknolojileri dahil) güvenilirliğine en yüksek önceliği verir. Şu ana kadar yalnızca bir kesinti yaşandı. Bu sorun, %1'de test için geçici bir yapılandırmayla ilgiliydi. Bu kesintiyle ilgili deneysel yapılandırma yakında gerekmeyecek. Bu nedenle, API'ler Chrome'da normal şekilde etkinleştirildikten sonra bu sorunun tekrarlanmayacağından eminiz.
Çerez Grafiği Çalışması	Chrome'un, Özel Korumalı Alan çerçevesindeki bu makalede açıklanan CookieGraph yöntemi konusunda bakış açısı nedir?	Makalede, kullanıcının ziyaret ettiği alandan farklı alanlar tarafından ayarlanan birinci taraf (1. taraf) çerezlerinin algılanması ve yaygınlığıyla ilgili bazı ilginç noktalar ele alınıyor. Makalede belirtildiği gibi, bu çerezler kullanıcıların bir web sitesiyle nasıl etkileşimde bulunduğuyla ilgili analizler ve bilgiler toplamak için son derece faydalıdır. Bu veriler, geliştiricilerin kullanıcılara daha iyi bir tarama deneyimi sunması için çok önemlidir. Makalenin ana argümanı, birinci taraf çerezleri siteler arası izleme vektörü olarak kabul ettiği için hatalıdır. Ancak bu durum yalnızca makalede belirtilen çok agresif varsayımlar altında geçerlidir: Kullanıcılar, kimliği tanımlayabilecek bilgileri (PII) siteyle paylaşmayı kabul ederler. Cihazların, kullanıcıları siteler arasında izlemek için kullanılabilecek sabit bir parmak izi vardır. Bunların, birinci taraf çerezleri kullanılmadan (ör. sunucu tarafı veri paylaşımı yoluyla) kötüye kullanılabilecek yeniden kimlik tanımlama vektörleri olduğunu ve 3PC'ler gibi durum tabanlı izleme mekanizmalarına odaklanan mevcut çalışmalarımızdan ayrı olarak ele alınması gerektiğini unutmayın. Son olarak, makalenin analiz ve reklam çerezlerini izleme çerezleriyle, kesinlikle gerekli çerezleri ise izleme dışı çerezlerle eşleştirdiğini belirtmek isteriz. Bu durum her zaman geçerli olmayabilir. Gerçekten de birinci taraf analizleri veya mağaza bulucu widget'ları, sohbet widget'ları ya da yük dengeleyici çerezleri gibi siteye göre ayrılmış tedarikçi hizmetleri genellikle yalnızca bir alanla sınırlı olabilir. Buna karşılık, kesinlikle gerekli olan bazı çerezler, sahtekarlık önleme amacıyla siteler arası izleme olabilir.
Kullanıcı Deneyimi Değişiklikleri	Chrome 112'deki kullanıcı deneyimi değişiklikleri, birinci taraf çerez denetimlerini Chrome ayarlarının "cihaz üzerindeki site verileri" bölümüne yerleştirerek kullanıcıların tüm çerezleri engellemesini zorlaştırabilir.	Bu değişiklik, 3. taraf çerezleri (veya bölümlenmemiş depolama alanı) ile ilgili kontrolleri diğer tüm site veri türlerinden ayırma ve bu kontrolleri üst düzeye çıkarma çalışmalarımızın bir parçası olarak yapılmıştır. Üçüncü Taraf Kontrolleri, Gizlilik ve Güvenlik panelinin altında vurgulanmıştır. Kritik site işlevselliğinin genellikle bağlı olduğu birinci taraf çerezlerine ve diğer tüm site verisi türlerine yönelik denetimler "Cihaz üzerindeki site verileri" altında gruplandırılır. Bu konuyla ilgili geri bildirimleri takip etmeye devam edeceğiz. Ancak mevcut ayrımın, anlamlı gizlilik denetimlerinin bulunabilirliği ile işlevsel bir tarama deneyiminin korunması arasında iyi bir denge sağladığını düşünüyoruz.
Faturalandırma ve Ödeme	Test kullanıcıları, Özel Korumalı Alan API'lerinin diğer alanlarını test etmeye daha fazla ilgi gösterdiğinden faturalandırma ve ödemeler tam olarak test edilmiyor.	Geliştiriciler ve şirketler neyi ne zaman test edeceklerini kendileri belirler. API'ler, Eylül 2023'ten beri genel olarak test için kullanılabilir durumdadır.
Test	DSP'lerin SSP'lerden aldığı deneysel trafiğin tümü etiketlenmez. Bazı TTP'ler, etiketlenmemiş deneysel gösterimlerin payının, değerlendirme ve kontrol grupları arasında farklı olabileceğini bildirmiştir.	Chrome, şirketlerin teklif isteklerinde etiketleri iletip iletmeyeceğini kontrol edemez. Tarayıcıdan etiket alma yöntemi sağlarız. Daha sonra, iş ortakları bu etiketleri doğrudan okuyamıyorsa etiketlerin iş ortaklarına iletilmesini sağlamak ekosisteme bağlıdır.
Android WebView'de 3D oyuncak	Desteği sonlandırma özelliğini test etmek için Android WebView'de "Üçüncü Taraf Çerezlerini Aşamalı Olarak Kullanımdan Kaldırma Testi" işaretini etkinleştirmeyle ilgili yardım isteği.	3PC'ler Android WebView'de varsayılan olarak engellenir.
Model Eğitiminde riskleri azaltmak için diferansiyel gizlilik	Model Eğitiminde diferansiyel gizlilik neden kullanılır?	Diferansiyel gizlilik, Güvenilir Yürütme Ortamları (TEE'ler) ile birlikte kullanıldığında, veri sızıntısını önlemek ve tehditlere karşı hassas bilgileri güvence altına almak için model eğitiminde son derece önemlidir. Bu yaklaşım, model ağırlıklarının tek tek kullanıcı verilerini açığa çıkaramamasını sağlar.

Kayıt ve Onay

Geri Bildirim Teması	Özet	Chrome Yanıtı
Kayıt	Kayıtlı kaynak ile reklam teknolojisinin www alt alan adıyla kaynağı arasındaki doğrulama kaydının işleyiş şekliyle ilgili açıklama isteği.	Reklam teknolojisinin yalnızca https://example.com'e katılması gerekir. Onaylarını https://example.com/.well-known/privacy-sandbox-attestations.json'e yerleştirdiklerinde, alt alan adı olduğu için https://www.example.com de kapsama alınır.
API Spesifikasyonu	Depoya doğrulama dosyası için bir JSON şeması ekleme önerisi.	Bu öneriyi değerlendiriyoruz. Buradan ek geri bildirimler almaktan memnuniyet duyarız.

Alakalı İçerik ve Reklamlar Gösterin

Konular

Geri Bildirim Teması	Özet	Chrome Yanıtı
Konu Ağırlıklandırma	Topics'te anlaşılması gereken en önemli şey, belirli bir sinyalin nadir olduğudur. Mevcut tasarım, gözlemlenen her konunun yanına bir ağırlık değeri eklemeye izin verecek şekilde geliştirilecektir. Ağırlık, bir tarayıcı için belirli bir konunun, konuyu kullanan tüm tarayıcılara kıyasla göreli ağırlığıdır.	Bir sinyalin nadirliğinin neden en önemli sinyal olduğunu daha ayrıntılı bir şekilde anlamak istiyoruz. Ekosistemden bu kullanım alanının faydası hakkında buradan ek geri bildirim almaktan memnuniyet duyarız.
Topics'in Güvenilirliği	Google'ın, Topics'in zaman içinde güvenilirliği konusunda daha güçlü garantiler vermesi gerekir.	API'lerimizde ekosistem geri bildirimlerine göre değişiklikler yapmaya devam edeceğiz. Bu değişikliklerden önce de değişiklikler herkese açık olarak tartışılacaktır. Düzeltilmiş bir yönetim yapısıyla ilgili önerimiz ek güvence sağlayacaktır.
Sınıflandırıcı	Yayıncıların siteleri genellikle yanlış sınıflandırılır veya anlamlı bir amaç sunamayacak kadar üst düzey konular atanır.	Konular sınıflandırması hakkındaki açıklamamızda belirtildiği gibi, siteler en popüler siteleri içeren, gerçek kişiler tarafından derlenen bir geçersiz kılma listesi ve cihaz üzerinde çalışan bir makine öğrenimi modelinin bir kombinasyonuyla sınıflandırılır. Chrome, sitelerin Topics sınıflandırmasına katkıda bulunmasına yönelik seçenekleri değerlendirmeye devam ediyor. Tüm işlevsellik iyileştirmeleri, gizlilik ve kötüye kullanım riskleriyle birlikte değerlendirilmelidir. Örneğin, risklerden bazıları şunlardır: - Farklı (ve potansiyel olarak hassas) anlamları konulara kodlamak için kendi kendine etiketleme yöntemini kullanan siteler ve - konulara fayda sağlama amacıyla diğer kullanıcılara saldıran siteler (ör. kullanıcının konularını anlamsız ifadeler kullanarak spam yapma). Herkes, chrome://topics-internals veya bu colab üzerinden kullanılabilen araçlarla bu bileşenleri inceleyebilir. Testler sayesinde sınıflandırmanın zaman içinde iyileşmesini bekliyoruz. Yanlış sınıflandırılmış olabilecek site örnekleri hakkındaki geri bildirimlerinizi bekliyoruz.
API Sorunu	Topics API'nin, kötü içerikten para kazanan SSP'lere sürekli ve rekabete aykırı avantajlar sağladığına dair endişeler.	3. taraf çerezlerinde olduğu gibi, tarayıcı da Topics'i kime döndürdüğüne bakmaz. Bunun için ilgili öğenin kayıtlı ve onaylanmış olması gerekir.
(Önceki çeyreklerde de raporlanmıştır) Farklı paydaş türleri için yararlı olma	Konular sınıflandırıcısı, ilgili konuları tanımlamak için şu anda yalnızca sayfa ana makine adını kullandığından, çeşitli içeriğe sahip büyük siteler genel konulara katkıda bulunurken, küçük siteler daha fazla reklamcılık değeri ile niş konulara katkıda bulunur.	Verdiğimiz yanıt önceki çeyreklere benzer: 3 adet satın alma işleminde olduğu gibi, farklı sitelerin sağladığı bilgilerin değeri arasında fark vardır. Niş ilgi alanı siteleri, değer katkısı açısından tutarlı değildir: Niş ilgi alanı sitelerinin tümü ticari açıdan değerli bir içeriğe sahip değildir ve bu nedenle daha az değer katarlar. Bunlar, Topics API'den yararlanacak sitelerdir. Site düzeyinde sınıflandırmalar yerine sayfa düzeyinde sınıflandırmalar yapma olasılığını değerlendirdik. Ancak bu tür bir sınıflandırmayla ilgili önemli gizlilik ve güvenlik sorunları var.
Sınıflandırıcı	Daha küçük sitelere genellikle yanlış bir sınıflandırma atanır veya sınıflandırma atanmaz. Bu nedenle, bu siteler değer değişimine katılamaz.	İddia edilen zararla ilgili olarak, yanlış sınıflandırılmış olabilecek belirli siteler bu durumdan diğer sitelerden daha fazla zarar görmez. Bunun nedeni, sitelerin bağlamsal bilgilerinin her zaman sitelerindeki açık artırmalar için kullanılabilmesidir. Bu sayede, yanlış sınıflandırma durumunda bile doğru konuyla ilgili benzer bilgiler sağlanır. Konumlar genellikle kendi siteleri yerine harici web sitelerinden yararlı olabilecek reklam bilgilerini toplamak için kullanılır.
Sınıflandırma sürümü	Geriye dönük uyumluluğu sağlamak için sınıflandırma sürümüne nasıl erişebiliriz?	Sınıflandırma sürümü, konular etkin getirme isteğiyle gönderilen istek başlığının bir parçasıdır. Örneğin, başlık "(1 2);v=chrome.1:2:5, ();p=P000000000" ise sürüm chrome.1:1:2'dir. Burada chrome.1 yapılandırma sürümü, 2 sınıflandırma sürümü ve 5 model sürümüdür. Bu konu özellikte açıklanmıştır ve açıklamaya da eklenmiştir.
Topics verileri	Topics verilerinin nasıl güncellendiğiyle ilgili açıklama isteğinde bulunun.	Sınıflandırma güncellemesi belirtilmemiş. Bu, tarayıcı tedarikçilerine uygulamada esneklik sağlar. Chrome'un V1'den V2'ye yaptığı sınıflandırma güncellemesine ait buluşsal bilgileri aşağıda bulabilirsiniz: - Hem V1 hem V2'deki konular için tek bir sınıflandırma ağacı korunur. - Aynı konu kimliği aynı anlamı temsil eder. - Ağaç yalnızca büyür. Yeni konular veya bağlantılar eklenir, hiçbir zaman küçülmez. - Ancak bazı konular veya bağlantılar bir sürümde "etkin değil" olarak ayarlanabilir. Bu da silme veya yeniden düzenleme izlenimi verebilir. Örnekler: - "Kamyonetler" artık "Kamyonlar, Kamyonetler ve SUV'ler" kategorisine dahil edildi. - "Yabancı Dil Eğitimi"nin ikinci ebeveyni artık "Eğitim"dir ve orijinal ebeveyni olan "Referans" etkinliğini kaybeder. "Etkin değil" konularının etkisi: Bu konular yeni sınıflandırma için kullanılmayacaktır. Ancak kullanıcı engellemeleri uygulanırken bu konular dikkate alınır: Bir kullanıcı V1'de bir konuyu engellediyse bu konunun alt konuları V2'de engellenmeye devam eder (alt konu V2'de farklı bir üst konu altında görünse bile).
Sınıflandırıcı	Hatalı sınıflandırmalarla ilgili nedenleri ve mevcut düzeltici seçenekleri anlamak.	Öncelikle, Chrome'un bir sitenin konularını belirlemesinin, reklamcılık amacıyla kullanıcının ilgi alanlarını belirlemek için Topics algoritmasına giriş olarak kullanılacağını belirtmek isteriz. Daha genel sınıflandırma amaçları için geliştirilmemiştir. Sınıflandırma modelimizin genel doğruluğu bizim için önemlidir ve mümkün olduğunda doğruluk/hatırlama oranını iyileştirmeye çalışırız. Ancak bunu site sınıflandırması düzeyinde değil, global düzeyde yaparız. Bunun nedeni, yanlış sınıflandırmanın yanlış sınıflandırılmış siteye zarar vermemesi, aksine diğer sitelerde reklam seçilirken Topics sinyalinin kalitesini düşürmesidir. Yanlış sınıflandırılmış sitede reklam seçilirken, sitenin gerçek konuları söz konusu site tarafından zaten bilinmektedir ve reklam sorgularına giriş olarak kullanılabilir. Burada ek geri bildirimlerinizi bekliyoruz.
API Testi	Topics ve genel olarak Özel Korumalı Alan API'leri Chromium ile test edilebilir mi?	Topics API, Chromium ile değil, Chrome ile birlikte gönderilir.
Arayan Konular	Reklam teknolojilerinin gelişmiş analiz maliyetini gizlilikle uyumlu yollarla desteklemesi için TEE hizmetlerinden yararlanarak Topics'in katma değerini artırma isteği.	Benzer bir geri bildirimi burada yanıtladık. Ters sıklığı dikkate aldık ve ters sıklığı modelledikten sonra, alıcılar ve satıcılar tarafından sağlanan değere göre konu değeriyle iyi bir ilişkisi olmadığını tespit ettik. Burada ek geri bildirimlerinizi bekliyoruz.
API Özellikleri	Tarayıcı ilgi alanı kohortu ayarı Topics API'yi engelleyebilir mi?	Bu geri bildirime buradan yanıt verdik. Topics API, FLoC'un evrim geçirmiş halidir ve FLoC'un izin politikasını uygular. Açıklayıcı bölümünde belirtildiği gibi: "Not: FLoC'den eski Permissions-Policy: Interest-cohort=(), konu hesaplamayı da yasaklayacak."
Konu Sıralaması	"En popüler 5 konu"yu alırken web sitesi ziyaretlerinin sıklığını her uygun arayana göre mi yoksa her zaman tarayıcının tüm ziyaret geçmişlerine göre mi sayarız? Ayrıca, konular her arayan için ayrı ayrı mı sıralanıyor?	Bu değer, tarama geçmişlerinin bir alt kümesinin sıklığına dayanır. Bir tarama geçmişi girişi (sayfa), yalnızca sayfada en az bir Topics çağrısı varsa programa katılmaya uygundur. Konu geçmişi depolama alanı hakkında daha fazla bilgiyi burada bulabilirsiniz. Topics API'deki geliştirmelerle ilgili duyurumuzda belirtildiği gibi, sıralama sıklık ve ikili öncelik düzeyine bağlıdır (daha fazla bilgi için buraya ve buraya bakın). Ancak, arayanların sıklığına bağlı değildir. Bunun, tüm arayanların bir sonraki dönemde en çok aranan 5 konunun tümünü alabileceği anlamına gelmediğini lütfen unutmayın. Açıklayıcıda belirtildiği gibi, "Yalnızca kullanıcıyı son üç hafta içinde söz konusu konuyla ilgili bir siteyi ziyaret eden kullanıcılar konuyu alabilir." Tarayıcının, hangi arayanın hangi ilk 5 konuyu gözlemlediğini (özellikte arayan alan adlarıyla ilk 5 konu'ya karşılık gelir) izlemesi gerekir. Bu sorunla ilgili buradan ek geri bildirim gönderebilirsiniz.

Protected Audience API (eski adıyla FLEDGE)

Geri Bildirim Teması	Özet	Chrome Yanıtı
(Önceki çeyreklerde de raporlanır.) Maliyet	TEE'leri şirket içi reklam teknolojisi veri merkezleri yerine herkese açık bulutlarda çalıştırmak daha mı pahalı?	Mevcut TEE güvenlik modelimiz, herkese açık bulut uygulamalarının uygulamalarından faydalanır (Daha fazla bilgi için herkese açık bulut TEE gereksinimleri açıklamasını inceleyin). Örneğin, mevcut donanım tabanlı TEE'ler tüm fiziksel saldırılara karşı koruma sağlamaz. Desteklenen mevcut herkese açık bulut sağlayıcılarımız AWS ve GCP, çalışanlar da dahil olmak üzere fiziksel erişim risklerine yönelik çözümler tasarlayıp uyguladı. Bazı reklam teknolojileri bulut hizmetlerini çalıştırmanın şirket içi reklam teknolojisi veri merkezlerinden daha pahalı olduğunu söylese de diğer reklam teknolojileri maliyet veya başka avantajlar için herkese açık bulutlarda çalışır. Herkese açık bulutların dışında da TEE desteğimizi genişletmeye yönelik seçenekleri değerlendirmeye devam ediyoruz. Bu kapsamda, şirket içi veri merkezlerini araştırıyoruz ve bu tür destek sunmaya yönelik olası çözümleri keşfetmek için ekosistemle etkileşime geçiyoruz. Araştırmanın bu mevcut aşamasında, bunun ekosistem için uygulanabilir bir çözümle sonuçlanacağını garanti edemeyiz.
PA API ve Google Ad Manager (GAM)	GAM adil bir pazar sonucu elde edemez. GAM, reklamları zamanında yayınlamıyor, PA API'yi kullanarak kaç reklam yayınladığını bildirmiyor ve reklam yayınlamak için hangi yöntemi seçeceği konusunda yapılandırma seçeneği sunmuyor (ör. belirli alanlar için PA API'yi kapatarak).	Google Ad Manager Yanıtı: GAM, PA API'si aracılığıyla reklam yayınlarken gecikmeyi optimize etmek için çalışmaya devam ediyor ve bu sayede PA API talebinden elde edilen ek yayıncı geliri, ek PA API açık artırma gecikmesi nedeniyle oluşan tüm maliyetlerden daha ağır basıyor. İlk testlerimiz, yayıncıların 3PC'siz trafikte PA API'den net bir gelir avantajı gördüğünü gösteriyor. Bu, PA API'sinden gelen ek talebin gecikme nedeniyle tüm maliyetlerden daha ağır bastığını gösteriyor. Yaklaşımımız hakkında daha fazla bilgiyi SSS bölümünde bulabilirsiniz. Ayrıca GAM, yayıncılara PA API aracılığıyla yayınlanan reklamlarla ilgili raporlama sağlar. Buna, GAM bir bileşen satıcısı olduğunda yayınlanan reklamlar ve GAM üst düzey bir satıcı olduğunda diğer bileşen satıcıları aracılığıyla yayınlanan reklamlar dahildir. Bildirimlerle ilgili daha fazla bilgiyi Yardım Merkezimizde bulabilirsiniz. Son olarak GAM, yayıncıların bir kullanıcı arayüzü kontrolü aracılığıyla trafiklerinde PA API'sinin kullanımını etkinleştirmesine veya devre dışı bırakmasına izin verir (ayrıntılar için Yardım Merkezimize bakın). Yayıncıların isteyebileceği diğer denetimlerle ilgili geri bildirimleri değerlendirmeye açığız ve tüm özellik isteklerine standart özellik önceliklendirme sürecimiz doğrultusunda öncelik veririz.
PA API ve GAM/AdX	Google'ın, AdWords'in yalnızca kendi mülkünden satın alması gibi, GAM'in nihai satış kararını vermediği hiçbir PA API gösterimini satın almayacağına karar verdiği anlaşılıyor. GAM/AdX, diğer exchange'ler gibi alternatif bir üst düzey satıcıya bileşen açık artırması yapılandırması gönderebileceğinden, bu durum tamamen pazar konumunun kötüye kullanılması olarak görülüyor.	Google Ads Platform'un Yönetici Yanıtı: Google'ın yaklaşımı bu değildir. Google'ın alıcı tarafı platformları (Google Ads ve DV360), Google dışı exchange'lerden gösterim satın alır. Bu, hem PA API gösterimleri hem de PA olmayan API gösterimleri için geçerlidir.
Pazar Yanıtı	Mozilla'nın endişeleri: Google'ın Protected Audience, Reklamverenleri (ve Google) Sizi Korumaktan Daha Fazla Korur.	Mozilla'nın değerlendirmesi bizim için çok değerlidir. Herkese açık standartlar forumlarında Mozilla'nın geri bildirimleriyle etkileşim kurmaya devam edeceğiz. Değerlendirmenin bir teması, PA API'nin mevcut uygulamasının planlanan tüm korumaları henüz zorunlu kılmadığı yönünde. PA API ile pazara sunma yaklaşımımız, gizlilik korumalarının mümkün olan en kısa sürede benimsenmesini teşvik etme ve uygulama arasında doğru dengeyi kurmayı amaçlamıştır. Bu kapsamda, API'lerle entegrasyonu kolaylaştırmak ve gelecekteki korumalara (ör. çitli çerçevelerdeki VAST özellikleri) dahil edebileceğimiz daha fazla geri bildirim toplamamıza zaman tanımak için zaman içinde gizlilik kısıtlamaları uygulamaya yönelik bir yol haritası oluşturduk. Mozilla'nın gizlilik ve dijital reklamcılıkla ilgili kendi yaklaşımı hakkındaki son duyurularını da memnuniyetle karşılıyoruz: "Özgür ve açık bir internet, gizliliğin pahasına olmamalıdır" ve "Ürün ve altyapı aracılığıyla online reklamcılığı iyileştirme".
(Önceki çeyreklerde de bildirildi) Açık Artırma Sonuçları	Tek bir açık artırma isteğinde bulunarak birden fazla oluşturma URL'sini ilgili puanlarıyla döndürebilirsiniz. Bu sayede yerel reklamcılık, tekilleştirmeyi kolaylaştırabilir ve kullanıcı deneyimi ile gecikme sorunlarını önleyebilir.	Yanıtımız önceki çeyreklerle benzer: Tek bir PA API açık artırmasından birden fazla renderURL'yi ve ilgili puanlarını paylaşmak, üzerinde düşündüğümüz ancak gizlilik endişeleri nedeniyle uygulamadığımız bir şeydir. Aynı reklamın tek bir sayfada bir kullanıcıya birden çok kez gösterilmesini önlemek istediğinizi anlıyoruz ve bu isteği değerlendiriyoruz. Ekosistemden, Doğal Reklamcılık kullanım alanını en iyi şekilde desteklemek için PA API'sinde hangi ek desteğe ihtiyaç duyulduğuyla ilgili ek geri bildirimleri buradan almaktan memnuniyet duyarız.
Performans	PA API'yi etkileyen gecikmeyle ilgili endişeler.	Gecikmeyle ilgili endişeleri duyduk. Bu endişeler, PA API kapsamında bir dizi özellik geliştirmemizin nedenlerinden biridir. Bu özellikler, SSP'lerin hem DSP gecikmesi için sınırlar belirlemesine hem de gecikmeyi azaltabilecek iyileştirmeler yapmasına olanak tanır. Bu özelliklerden nasıl yararlanacağınız hakkında daha fazla bilgi içeren gecikmeyle ilgili en iyi uygulamalar kılavuzumuzu kısa süre önce güncelledik. Ayrıca, gecikmeyle ilgili yeni iyileştirmeler geliştirmeye devam ediyoruz. Bunlardan bazılarını burada görebilirsiniz.
Üst düzey satıcılar	Google, yayıncıların alternatif üst düzey PA API açık artırma satıcıları seçmesine olanak tanımalıdır.	PA API, hem tek satıcılı hem de çok satıcılı tasarımlarda açık artırmayı kimin başlattığına bakmaz. Şirketlerin, PA API açık artırmalarını destekleyip desteklemeyecekleri ve nasıl destekleyecekleri konusunda kendi seçimleri vardır.
(Önceki çeyreklerde de bildirildi) Negatif Hedefleme	Reklamverenin belirli bir kitleye reklam göstermek istemediği kullanım alanına yönelik bir çözüm isteyin.	Reklamverenlerin belirli bir kitleye reklam göstermek istemediği durumlarda, ek (içeriğe dayalı) tekliflerle negatif IG hedeflemesini destekliyoruz. Ayrıntıları bu açıklama ve bu GitHub sorununda bulabilirsiniz. PA API teklifleri için negatif IG hedeflemesini destekleyecek çözümler de araştırıyoruz. Burada ek geri bildirimlerinizi bekliyoruz.
(Önceki çeyreklerde de raporlanmıştır) Doğal Reklamcılık	Doğal Reklamcılık için Kısıtlanmış Çerçeve desteği isteği.	Bu kullanım alanını desteklemeyi düşünüyoruz ve olası geçici çözümleri ve çözümleri burada tartışıyoruz.
Web Görünümü	Chrome'da katılan IG'nin WebView'de yürütülen açık artırma için kullanılamadığı senaryoda netlik istiyoruz.	Yeterli gizlilik altyapısı sağlandığında bu kullanım alanlarını desteklemek istiyoruz. Şu anda paylaşacak başka bir duyurumuz yok ancak buradan ek geri bildirimlerinizi bekliyoruz.
Negatif IG'ler	Yeni üstbilgi özelliği aracılığıyla negatif IG'leri desteklemek için URL işlemeyi güncelleme isteği.	Bu isteği değerlendiriyoruz. Burada ek geri bildirimlerinizi bekliyoruz.
Çeşitlilik Filtreleme	Çok satıcılı ve çoklu açık artırmalarla PA API'sinde yerel reklamcılık yayınlarken çeşitlilik filtrelemesinin nasıl uygulanacağı hakkında yardım isteyin.	Bu isteği burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.
(Önceki çeyreklerde de raporlanmıştır) Engelleme Filtreleri	PA API'de çoklu satıcıyla yerel reklam yayınlarken "yayıncı engelleme" (filtreler) kurallarının nasıl uygulanacağı konusunda yardım isteme.	Burada yol gösterici bilgiler paylaştığımızı hatırlatmak isteriz. Ek geri bildirimlerinizi de bekliyoruz.
Kısıtlamalar	Alt alan adı düzeyinde değil, alan adı düzeyinde kısıtlamalara izin verilmesini isteyin.	Alt alan adı veya kaynak düzeyindeki kısıtlamalar, web'in temel güvenlik modelini takip eder. Bu nedenle, varsayılan tasarımımız budur. Bu konuyu burada ve burada daha ayrıntılı olarak ele aldık.
Güvenilir Teklif	Güvenilir teklif sinyal isteklerinde kullanıcı aracısı ve ilgili istemci ipuçları için istek.	Bu özellik isteğini takip ediyoruz ve buradan ek geri bildirimler bekliyoruz.
(Önceki çeyreklerde de raporlanmıştır) Çoklu IG	Aynı teklifte birden fazla IG kullanın.	Temel gizlilik modelinde değişikliğe neden olacağı için bu özellik şu an PA API'sinde desteklenmemektedir. Bu konuyu buradan görüşebiliriz.
(Önceki çeyreklerde de raporlanır) Performans	Daha fazla mantığı istemciye taşımak sayfa performansını ve kullanıcı deneyimini olumsuz etkileyebilir, bu da web sitesinin SEO puanlarını olumsuz etkileyebilir.	Bu konuyu görüşüyoruz ve buradan ek geri bildirimlerinizi bekliyoruz.
Açık Artırma Dinamikleri	PA API'si, açık artırma dinamikleriyle (ör. kimlerin katıldığı, açık artırmayı kimin kazandığı gibi) bilgileri azaltarak yayıncıların izlenebilirliğini azaltır ve anlaşmaların saklanıp saklanmadığının anlaşılmasını zorlaştırır.	Anlaşmaların izlenmesi için bir çözümü burada önermiştik. DealID ve SeatID'leri depolamak için IG nesnesinde bazı mevcut alanları değiştirmeyi ve yeni alanlar oluşturmayı ve bunların etkinlik düzeyinde raporlama aracılığıyla generateBid'den scoreAd'a veya çıkışa yayılmasını sağlamayı planlıyoruz. Bu, anlaşmanın kullanım alanı için yeterli destek sağlamalıdır. Reklam teknolojilerinin açık artırma dinamikleri ve yayıncılar için bu izlenebilirliği sürdürmek açısından kritik olduğunu düşündüğü diğer meta verilerle ilgili geri bildirimlerinizi bekliyoruz. Reklam teknolojilerinin, kastettikleri meta verinin belirli örneklerini sağlamalarını ve bu verilerin hangi taraftan hangi tarafa aktarılması gerektiğini bildirmelerini öneririz.
GAM	AdX talebine erişmek için yayıncı reklam sunucusu olarak GAM'in kullanılması şartıyla ilgili endişeler.	Google Ad Manager tarafından sağlanan yanıt: GAM, yayıncıların exchange işlevine erişmek için reklam sunucusu işlevini kullanmasını gerektirmez.
(Önceki çeyreklerde de raporlanmıştır) Bileşen Açık Artırması	PA API bileşeni açık artırma kazananları GAM tarafından görülebilir. Bu da, bilgiye erişimin eşit olmadığı konusunda endişelerini artırır.	Verdiğimiz yanıt önceki çeyreklerde bir değişiklik olmadı: Google Ad Manager tarafından sağlanan yanıt: "Yıllardır, bir yayıncının garanti edilmeyen reklam kaynaklarının hiçbirindeki hiçbir fiyatın (garanti edilmeyen satır öğesi fiyatları dahil) açık artırmada teklif vermeden önce başka bir alıcıyla paylaşılmayacağına dair sözümüz de dahil olmak üzere açık artırma adilliğine odaklanıyoruz. PA API açık artırmalarında, sözleştiğimiz gibi, çok satıcılı açık artırmalarda açık artırma tamamlanmadan önce hiçbir açık artırma katılımcısının teklifini diğer açık artırma katılımcılarıyla paylaşmayacağız. Daha açık belirtmek gerekirse, bağlamsal açık artırmanın fiyatını kendi açık artırmamız da dahil olmak üzere hiçbir bileşen açık artırmasıyla paylaşmayacağız. Bu durum bu güncellemede açıklanmıştır. Ayrıca, kendi açık artırmamız kapsamında, alıcılar tarafından SSP'lere sağlanan sinyaller de dahil olmak üzere bileşen açık artırma yapılandırmalarıyla ilgili bilgileri kullanmayız. Aslında, PA API'de, bileşen satıcılarının bileşen açık artırma yapılandırmalarını üst düzey satıcıdan gizlenecek şekilde belirtmelerine olanak tanıyan değişiklikleri memnuniyetle karşılarız."
GAM	GAM, IG veya PA API bileşeni açık artırmasının oluşturulmasına katılmadıysa üst düzey açık artırmaların yürütülmesi/raporlanması için gelir paylaşımı isteyecek mi?	Google Ad Manager tarafından sağlanan yanıt: Yayıncılar reklam sunucusu olarak GAM'i kullanmayı seçtiğinde GAM üst düzey açık artırmayı yürütür ve reklam sunucusu işlevi için bir reklam sunma ücreti (PA API açık artırmaları dışında geçerli olan aynı reklam sunma ücreti) alır. Bununla birlikte, kazanan reklam GAM dışındaki bir bileşen satıcısından geliyorsa (yani GAM, IG veya PA API bileşeni açık artırmasının oluşturulmasına katılmadıysa) GAM faturalandırmayı üstlenmez ve yüzdelik medya ücreti almaz.
Tıklama oranı	Tıklama etkinliklerinin kaydı aynı diferansiyel gizliliğe tabi mi?	"Tıklama sayısı" yalnızca generateBid() işlevi içinde bir browserSignal olarak kullanılacağından bu özelliğin şu anda "k-anon" kısıtlamalarına tabi olması planlanmamıştır. Bu özellik, etkinlik düzeyinde raporlamada yeni bir özellik olarak kullanılamaz.
Performans	Bağlamsal teklif isteklerine koşulsuz yanıt verilmesi nedeniyle yüksek çıkış maliyetleri.	Gizlilik nedeniyle, hangi DSP'lerin IG'ye sahip olduğu hakkında doğrudan bilgi veremiyoruz. Bununla birlikte, gizliliği korurken analizler sunabilecek alternatif çözümler araştırıyoruz.
Yerel ve Yayın Dışı Reklamlar	Chrome'un doğal ve yayın dışı reklamlarla ilgili bakış açısı hakkında güncelleme isteğinde bulunma.	Chrome'un konumu, söz konusu kullanım alanına bağlıdır. Video konusunda Chrome'un amacı, ekosistemi API'lerimizi kullanarak uygulanabilir yayın içi video çözümlerine yöneltmektir. Şu ana kadar bildiğimiz tek somut teklif GAM'ın teklifi. Yerel reklamlar için buradan aktif olarak geri bildirim topluyoruz ve yakında reklam teknolojileriyle daha fazla keşif adımı paylaşmayı planlıyoruz.
Gerçek Zamanlı İzleme (RTM)	Etiketli trafik, RTM raporları göndermez.	Bu eksikliğin farkındayız ve bir çözüm üretmek için çalışıyoruz. Güncelleme olduğunda burada paylaşacağız.
Kitle Genişletme Desteği	PA API'de kitle genişletme/satıcı tarafından seçilen kitleler için destek hakkında güncelleme isteği.	Bu kullanım alanı için bir çözüm sunmak üzere çalışıyoruz. Neleri oluşturmamız ve desteklememiz gerektiği konusunda ekosistemden geri bildirim alıyoruz. Gelişme olduğunda sizi bilgilendireceğiz. Yeni geri bildirimleri buradan paylaşacağız.
Hata ayıklama	Chrome'un geliştirici aracında, PA API'nin ayrıntılı performansını izleyen bir panel yoktur. Örneğin, genel performans, IG'lerin veya alıcıların sayısından etkilenebilir.	Bu geri bildirim, Chrome Geliştirici Aracı kullanıcı arayüzünün izlemeye yardımcı olma özellikleriyle ilgili olsa da 7 Ekim'de reklam teknolojilerinin izleme ve uyarı için temel olarak kullanılabilecek özel etkinlikler yapılandırmasına olanak tanıdık. Daha ayrıntılı bilgiye buradan ulaşabilirsiniz. Bu güncellemenin, söz konusu geri bildirimin önemli bir kısmını ele aldığını umuyoruz. Desteklenen veri noktalarıyla veya geliştirici deneyimiyle ilgili olarak bu özellik hakkında daha fazla geri bildiriminizi buradaki ilgili GitHub tartışmasında paylaşabilirsiniz.
Sinyaller	DSP'lerin, perBuyerSignals'in bağlamsal açık artırma sonuçlarından bağımsız olarak SSP'lere gönderilmesini sağlayıp sağlayamayacağıyla ilgili endişeler.	İçeriğe dayalı açık artırmanın tek bir TTP'den yalnızca bir kazanan teklife sahip olduğu veya daha iyisi, sonraki bir PA API açık artırmasında geride kalmak için bir teklife sahip olduğu varsayılır. STP, PA API akışı için, gönderme talebi olup olmadığını (cihaz üzerinde IG biçiminde) görmek istediği tüm TTP'leri davet etmeye karar verir. Bağlamsal açık artırmayı kaybeden bir TTP'nin PA API açık artırmasına katılmak için "yeniden davet edilmesi" tamamen mümkündür ve aslında çok olasıdır. Bu "yeniden davet"te, TTP kabul etmeye karar verirse Reklam Doğrulayıcı'nın DSP'nin dikkate almasını istediği tüm sinyalleri (varsa) SSP'ye iletir. Diğer bir deyişle, PA API açık artırmasında, bağlama dayalı açık artırmada ne olursa olsun DSP'nin perBuyerSignals'i SSP'ye göndermesi için her zaman bir yol vardır.
Sinyaller	generatedBid() adresine iletilen browserSignals nesnesine prevClicks ekleme isteği.	Bu istek, tıklanabilirlik sinyallerini destekleme teklifimizle çözülebilir. Bu özelliği son blog yayınımızda ve ilgili açıklamada duyurmuştuk. Bu teklifle ilgili daha fazla geri bildirim almaktan memnuniyet duyarız. Buradan
(Önceki çeyreklerde de raporlanmıştır) Modelleme Sinyalleri	Modelleme sinyallerinin bit sayısının 12 bitten 30 bite çıkarılması isteğinde bulunun.	Bu geri bildirime buradaki karşı teklifimizle yanıt verdik. Teklifimiz hakkındaki görüşlerini anlamak için sektörle etkin bir şekilde etkileşim kuruyor ve şu anda sektöre yönelik avantajları, Chrome kullanıcıları ve diğer paydaşlar üzerindeki etkiyle karşılaştırarak değerlendiriyoruz.
Belgeler	Anahtar/Değer (K/D) sunucularının ve TEE'lerin nasıl kullanılacağıyla ilgili yardım isteme.	K/V bağlamında TEE'lerin kullanımıyla ilgili yönergeleri, K/V hizmeti güven modeli tasarım ayrıntıları bölümünde bulabilirsiniz.
Negatif IG'lerin kullanım ömrü	Negatif IG'lerin ömrünü 365 güne uzatma isteği.	Negatif IG'ler reklamların gösterilmesini önlemek için kullanılır ancak kötü niyetli kişiler, kullanıcılarla ilgili bilgileri ortaya çıkarmak için bu özelliği kullanmaya devam edebilir.Bu da yeniden kimlik belirleme risklerine neden olur (ör. kötü niyetli kişilerin saldırmasının bir yolu, kullanıcının belirli siteleri ziyaret edip etmediğini öğrenmek için negatif IG'ler içeren yüksek teklifleri tekrar tekrar yerleştirmektir). 365 günlük bir TTL'yi korursak kötü niyetli kişiler, negatif IG'ler hakkında çok daha fazla veriye sahip olur. Bu da önemli ölçüde daha büyük gizlilik risklerine neden olur. Bu nedenle, kullanıcı gizliliğini korumak amacıyla bu isteği destekleyemiyoruz.
API Özellikleri	perBuyerSignals kapsamında iletilecek değerler olarak neler eklenebilir? Bu, satıcı tarafından keyfi olarak tanımlanabilir mi?	perBuyerSignals, satıcıların açık artırma içinde sunmak istedikleri tüm bilgileri alıcılara sunabileceği yerdir. Buraya ne eklemek istediklerine ekosistem karar verir. Ancak buradan daha fazla tartışmaya katılmanızı bekliyoruz.
Reklam Boyutu Makro Değişimleri	Reklam boyutu makrosu değiştirmelerinin çalışmamasıyla ilgili yardım almak istiyorum.	Yakında konuyla ilgili daha fazla bilgiyi herkese açık olarak paylaşacağız.
Teklif Sonrası SSP Makrosu Değişimi: Üst Düzey URL'yi Taklit Etme	Doğrulama tedarikçilerinin Özel Korumalı Alan çerçevesinde üst düzey URL'yi doğrulamasına olanak tanımak için Chrome hangi mekanizmaları sunabilir? SSP tarafından sağlanan üst düzey URL'nin doğruluğunu sağlamak için Çitli Çerçeveler'de kullanılabilecek alternatif veri noktaları veya sinyaller var mı?	Şu anda bu hoş geldiniz ek geri bildirimi hakkında buradan bahsediyoruz.
Özellik İsteği	updateURL getirmelerinde ve gerçek zamanlı raporlama geri göndermelerinde düşük entropi UACH sağlama isteği.	Bu talepler burada ele alınmaktadır. Burada ve burada ek geri bildirimlerinizi bekliyoruz.
Özellik İsteği	Belirli bir istemci, forDebuggingOnly.reportAdAuctionWin() ve forDebuggingOnly.reportAdAuctionLoss() üzerinden Yalnızca DebuggingOnly etkinlik düzeyinde örnek raporları göndermek üzere tetiklendiğinde güvenilir sunucunun hata ayıklama tasarımının etkinleştirilmesine izin vermesini isteyin.	Şu anda takip ettiğimiz etkin bir istektir. Kullanıma sunulduğunda ekosistemde güncelleme yapacağız. Buradan ek geri bildirim gönderebilirsiniz.
API Kullanımı	Tekil kullanıcı erişiminin ve gösterim erişiminin nasıl sayılacağına dair yol gösterici bilgi isteyin.	IG'lerin paylaşılan bir depolama iş akışından nasıl okunacağına yönelik bir teklifi tartışıyoruz. Daha sonra bunun üzerine özel toplu raporlar gönderebilirsiniz. Daha fazla bilgiyi burada bulabilirsiniz. Öneri ve ekosisteme olan faydası hakkında geri bildirimlerinizi bekliyoruz.
API Kullanımı	Yayıncıların neleri test etmesi gerektiği, hangi API'lerin önemli olduğu, hangilerinin etkinleştirilmesi gerektiği ve gelecekte neler olacağı konusunda netlik eksikliği.	Yayıncıları ve ekosistemdeki rollerini daha iyi desteklemek için çalışmalarımız devam ediyor.
API Kullanımı	Reklam Açık Artırması Worklet etkinliklerine etkinlik dinleyicileri eklemek mümkün mü?	Bu, normal etkinlikler aracılığıyla mümkün değildir ancak Chrome Geliştirme Araçları Protokolü etkinlikleri bu kullanım alanını kısmen ele alır. Normal etkinliklerin izolasyon/gizlilik özelliklerini etkileme olasılığının olduğunu unutmayın. Ayrıntıları burada bulabilirsiniz.
K-Anonimliği	Reklam oluşturma koşullarının açıklığa kavuşturulması (ör. gösterilmesine izin verilseydi reklamı en az 50 kişi görecektir).	Geliştirici dokümanlarımız, gelecekteki geliştirmelerle ilgili beklentilerimize genel bir bakış sunar. Özellikle, ilk k-anonimlik eşiğinin k=10 kişi olduğunu açıklar. blink-dev posta listesi, Chrome'da canlı olarak olup bitenlerle ilgili güncellemeler sağlar. K-anonimlik posta listesi ileti dizisinde belirtildiği gibi, şu anda k-anonimlik koşulunu Chrome kararlı trafiğinin yaklaşık% 1'inde deneysel olarak uyguluyoruz ve açıkça etiketlenmiş ("A Modu" ve "B Modu") dilimlerde hiçbir zaman uygulamıyoruz.
Sürülebilir	TEE K/V chaffing geçici olarak kaldırılabilir mi veya tüm N parçasını çağırma zorunluluğundan, gizlilik korumasını yararlılıkla dengeleyen bir miktara (ör. K/V performansı/maliyeti)?	Bu tür istekler yalnızca çakışmaların kontrol edilebildiği üretim dışı örnekler için işlenir. Üretim örnekleri için hâlâ parçalama gerekir. Üretim dışı kullanımla ilgili geri bildirim aldığımızda durumu değerlendirebiliriz.
Isıtma	Hata ayıklama/üretim dışı K/V ikilisindeki chaffing'i devre dışı bırakmak için işaret ekleme isteği.	Bu işaret, 1.0.0 sürümüyle birlikte sağlanır.
API Hatası	API, ayarlarda etkinleştirilmiş olmasına rağmen Chrome 126'ya yükseltildikten sonra çalışmayı durdurdu.	Bu sorunun, kullanıcılar tarafından geliştirme amacıyla etkinleştirilen "enable-fenced-frames" Chrome işaretiyle ilgili olduğu tespit edildi. Bu işareti varsayılan ayarlara sıfırlamak sorunu çözecektir.
Raporlama	Gerçek zamanlı raporlama API'sini, alıcılar için satıcıya bağlı olmayan bir tercih yapma isteği.	Bu istek burada değerlendiriliyor. RTM çözümü kısa süre önce kullanıma sunuldu. Özellikle bu özelliğe daha önce katılan reklam teknolojisi sağlayıcılarından geri bildirim almak isteriz.
Raporlama	Üçüncü taraf raporlama isteği; DSP'ler ve SSP'ler Chrome'dan gösterim bildirimleri alırken orta katman teknik sağlayıcılar varsayılan olarak almaz.	Şu anda bu isteğinizi değerlendiriyoruz ve buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız.

Protected Auction Services

Geri Bildirim Teması	Özet	Chrome Yanıtı
TEEs	Google'ın teknik standartlar kapsamında manuel ilk katılım şartı, bulut tedarikçisi seçiminde güçlü bir kısıtlamadır. Uygulanan teknik standartlar, Google'ın aklında olduğu üzere Bulut Sağlayıcılar Bürosu'na ziyaret edilmeden uygulanabilir. Alternatif sağlayıcıların en erken 2025'te geç eklenmesi, Google'ın çözümlerine bahşiş vermeyi teşvik eden ağ etkileri getireceği için kabul edilemez.	Toplama Hizmeti, bazı reklam teknolojisi kullanım alanlarını ele almak için TEE hizmetinde çalıştırılması gereken tek hizmettir. Toplama Hizmeti, hem Amazon Web Services'ı (AWS) hem de Google Cloud Platform'u (GCP) destekler. Reklam teknolojilerinden gelen geri bildirimlere dayanarak, bu tür desteğin bu aşamada yeterli olduğunu düşünüyoruz. Ek bulut sağlayıcılar: Google, herkese açık bulut sağlayıcılardaki TEE'ler için ayrıntılı ölçütleri yayınladı. Bu testler, TEE çözümünün Özel Korumalı Alan'ın gizlilik ve güvenlik hedeflerini karşılamasını sağlamak için tasarlanmıştır. Özellikle, Özel Korumalı Alan TEE sunucuları şifrelenmemiş siteler arası kullanıcı verilerini (ör. Toplama Hizmeti için yayıncı ve reklamveren sitelerinden gelen veriler) işler. API'lerin kullanıcı gizliliği hedeflerini karşılamak için bunların güvenli olması gerekir. API'lerin şirketlerin gizli iş bilgilerini korumaya devam etmesini sağlamak için de güvenli bir ortam gereklidir (örneğin, diğer PA API açık artırma katılımcılarının bir alıcının tescilli iş verilerine erişmesini engellemek). Bilgimize göre, şu anda kullanıcı verilerini potansiyel olarak düşmanca davranan bir operatörden tamamen koruyan bir TEE teknolojisi yok. Bu nedenle, bulut sağlayıcısının güvenilirliğini doğrulamak için birden fazla koşul ekliyoruz. "Bulut Sağlayıcıları Bürosu"nun ne anlama geldiğinden emin değiliz ve bu, şartlar arasında yer almıyor. Koşullarla ilgili geri bildirimlerinizi bekliyoruz. Ayrıca, açıklayıcı bölümünde tanımlanan süreç kullanılarak gönderilen istekler de dahil olmak üzere yeni sağlayıcılara yönelik desteği değerlendirmeye devam ediyoruz. Şu ana kadar yalnızca Azure'ı destekleme isteği aldık ve bu isteği değerlendiriyoruz.
B&A	Tasarım gelişmeye devam ettiğinden, pansiyon hizmetinin teknik karmaşıklığını ve fizibilitesini değerlendirmek zordur.	Bu endişeleri gidermek için GitHub'da; pansiyonun tasarımını, kullanımla ilgili zaman çizelgelerini ve PA API'sini destekleyen özelliklerin yol haritasını açıklayan ayrıntılı açıklamalar paylaştık. B&A'yı dağıtmak isteyen reklam teknolojisi şirketlerini destekliyoruz ve GitHub'da ekosistemden geri bildirim topluyoruz.
B&A	B&A için TEE'yi kullanmaya başlamak veya cihaz üzerinde kullanmaya geçmek amacıyla TEE'yi kullanmanın maliyetini hesaplamanın daha iyi bir yolunu ve yol gösterici bilgiler arıyorum.	Yakın zamanda, maliyetleri daha doğru ölçmek için araçlar içeren K/V Sunucu Örneği Boyutlandırma Kılavuzu'nu yayınladık.
K/V sunucusu	Reklam doğrulayıcı, reklam doğrulamasını gerçekleştirmek için K/V sunucusunun tam sayfa URL'sini kullanabilmek istiyor.	Şu anda reklam doğrulama amacıyla sayfa URL'sinin tamamını TEE'de çalışan K/V sunucusuna sağlama olasılığını değerlendiriyoruz. Tam sayfa URL'si K/V BYOS'de kullanılamaz.
Açık Artırma Güvenliği	Kötü niyetli kullanıcıların hassas verilere erişmemesini veya kimliğe bürünmemesini sağlamak için açık artırma güvenlik özellikleri arıyorum. Hangi özellikler açık artırmayı yeniden oynatma saldırılarına karşı korur ve güvenlik önlemleri nasıl uygulanabilir?	B&A'nın mevcut güvenlik modeli, açık artırma bütünlüğünü koruyabilir. B&A, reklam teknolojilerinin sinyallerinin ve kodunun gizliliğini kötü amaçlı kişilerden koruyan bir TEE'de çalışır. B&A mimarisinde, şifrelenmiş bir B&A istek yükü (istek şifre metni), istemciden güvenilmeyen bir reklam sunucusu üzerinden SellerFrontEnd hizmetine (TEE'de SSP'ler tarafından çalıştırılan SFE) akar. İsteğin şifrelenmiş metni, zaman damgasına dayalı bir oluşturma kimliği içerir. SFE, isteğin zaman damgasını inceler ve sunucu zamanından +/- n saniye içinde olmayan tüm yeniden oynatılan istekleri reddeder. Buna ek olarak B&A, sunucudan sunucuya iletişim için doldurulmuş sabit boyutlu bir yanıt yükü döndürebilir. Bu çözümler, kötü amaçlı bir kullanıcı içeriği hakkında daha fazla bilgi edinmek için aynı istek yükü oynatmaya çalıştığında sistem üzerinden oynatma saldırılarını azaltmaya yardımcı olabilir. B&A, açıklayıcılardaki güvenlik modellerini belgeleme ve güncelleme sürecindedir.
üzerinden sinyaller K/V sunucusu	Chrome'dan gelen güvenilir teklif sinyalleri isteği kapsamında K/V hizmeti üzerinden gönderilen perBuyerSignals'in dahil edilmesi isteği.	Tam sayfa URL'si de dahil olmak üzere TEE'de çalışan K/V sunucusuna aktarılan perBuyerSignals'deki bilgilerin dahil edilmesinin fizibilitesini değerlendiriyoruz.
K/V Sunucusu	K/V ve otel-satın alma kapsamındaki gizlilik kısıtlamalarıyla ilgili olarak daha aşamalı bir benimseme zaman çizelgesi talep edin.	TKV'nin kullanıma sunulmasına daha aşamalı bir yaklaşımın benimsenmesini istediğinizi anlıyoruz ve K/V ile B&A ile ilgili özel taleplerinizi takdir ediyoruz. Ancak dikkatli bir değerlendirmenin ardından, bu API'lerdeki gizlilik korumalarını şu anda gevşetmemeye karar verdik. Karıştırma gibi önlemlerin, kullanıcı gizliliğini korumak ve Özel Korumalı Alan'a duyulan güveni sürdürmek için çok önemli olduğuna inanıyoruz.
K/V sunucusu	Uyumlu bir yapılandırmayla K/V mağazasının nasıl ölçeklendirileceği konusunda yardım almak istiyorum.	Yakın zamanda yayınlanan K/V Sunucu Örneği Boyutlandırma Kılavuzu bu konuda yardımcı olabilir. Araç, her parametre kombinasyonunda QPS'yi (açıklayıcı bölümünde "RPS" olarak belirtilir) sağlar.
K/V sunucusu	K/V sunucusu isteğine satıcı bilgilerini ekleyin.	Bu konuyu görüşmek üzere, buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız.
K/V + B&A Hizmetleri	K/V ve B&A için yayın zaman çizelgesinin veya yol haritasının netleştirilmesini talep edin.	Hem K/V hem de B/A için aşamalar ve zaman çizelgelerimiz vardır: Cihaz üzerindeki PA API açık artırmalarıyla birlikte K/V sunucusu için (B/A'ya kıyasla) herkese açık zaman çizelgesi burada mevcuttur. K/V için "Genel Kullanım"ın nasıl tanımlandığına dair Beta ve GA özellik grubunu tanımlayan Yol Haritası bölümüne bakın. B&A için herkese açık zaman çizelgesine buradan ve yol haritasına buradan göz atın. Ölçek testi, "tam kararlı, üretim ölçeğinde test" olarak tanımlanır. Bu aşamada kullanılabilen özellik grubu için burayı inceleyin. B&A'nın Alfa ve Beta aşamaları da vardır. Bu nedenle, ölçek testi önceki aşamaların özelliklerinin süper kümesini içerir. Hem K/V hem de B&A için bu aşama tanımlarının, nelerin ne zaman kullanılabileceği konusunda netlik sağlamaya yardımcı olup olmadığını bize bildirin. Hâlâ boşluklar varsa lütfen bize bildirin. Planlama konusunda bilgi verebilmek için bu bilgileri daha ayrıntılı hale getirmekten memnuniyet duyarız.

Dijital reklamları ölçme

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

Geri Bildirim Teması	Özet	Chrome Yanıtı
Pazar Yanıtı	Rakip ilişkilendirme sistemlerinin yalnızca etkinlik düzeyinde raporlama ve özet/toplu raporlamayı sıkı sınırlar içinde kullanması şartı, rekabet üzerinde keyfi bir kısıtlamadır. Veri korumaya uygunluğu sağlamak için güvenlik önlemleri (ör. kimliği gizleme) uygulanmış olsa bile etkinlik düzeyinde cihaza özel gerçek zamanlı yeniden hedeflemeyi ve ilişkilendirmeyi engeller.	Bahsedilen tasarım, API'nin gizlilik hedeflerine dayanmaktadır (ör. bir siteden diğerine aktarılan siteler arası bilgilerin korunması). Örneğin, ARA, etkinlik raporları aracılığıyla etkinlik düzeyinde ilişkilendirmeyi destekler. Etkinlik raporları en az bir saat geciktirilir. Bu, burada belirtildiği gibi zamanlama yan kanal saldırıları kullanılarak etkinlik düzeyindeki raporun reklamverenin sitesindeki kullanıcı kimliğiyle ilişkilendirilmesini zorlaştırmak için gereklidir. Ayrıca, ilişkilendirmeyi ARA'nın ötesinde başka yollarla da yapabilirsiniz. Örneğin, bilinçli olarak kimlik tanımlayıcı veriler sağlayan kullanıcılardan doğrudan bilgi toplayabilirsiniz. Privacy Sandbox API'lerinin mevcut gizlilik sınırlarıyla ulaşılamayacak kullanım alanları hakkında geri bildirimlere açığız.
Çoklu Yüzey	ARA ve Paylaşılan Depolama API'lerinin çok yüzeyli kullanım alanlarını destekleyip desteklemediği ve bunun kanıtı hakkında onay isteği.	ARA ve Paylaşılan Depolama şu anda çok yüzeyli (cihazlar arası) ilişkilendirmeyi desteklemiyor. Aynı cihazda uygulama ve web arasında ilişkilendirme (ARA aracılığıyla) desteklenir.
(Önceki çeyreklerde de raporlanmıştır) Cihazlar Arası	ARA, cihazlar arası dönüşümleri destekliyor mu?	Verdiğimiz yanıt önceki çeyreklere benzer: Cihazlar arası, üçüncü bilgisayar ortamında gizlilikle ilgili yeni zorlukları da beraberinde getiriyor. Ayrıca, kullanıcının kullanabileceği cihaz ve platform yelpazesine göre teknoloji dağıtımıyla ilgili zorlukları da beraberinde getiriyor. Olası çözümleri araştırıyoruz, ancak şu anda ARA tarafından desteklenen önemli kullanım alanlarına odaklanıyoruz ve cihazlar arası destek için şu anda bir zaman çizelgemiz yok.
Ölçeklendirme	Attribution Report API'nin (ARA) şu anda yapılandırılıp yapılandırılmadığı ve tüm Chrome kullanıcılarına hizmet verecek şekilde güvenilir bir şekilde kullanıma sunulup sunulamayacağıyla ilgili endişeler.	ARA şu anda tüm Chrome kullanıcıları tarafından kullanılabilir ve beklendiği gibi çalışır. Ayrıca, ARA'yı test eden reklam teknolojisi şirketlerinin sayısı artmaya devam ettikçe aracın güvenilirliğini ve ölçeklenebilirliğini test etmeye ve izlemeye devam ediyoruz. Bu konuyla ilgili ek ekosistem geri bildirimlerini buradan almaktan memnuniyet duyarız.
(Önceki çeyreklerde de bildirildi) Tekilleştirme	ARA'nın cihazlardaki ilişkilendirme mekanizmasını kısıtlamayı önermesi nedeniyle ortaya çıkan endişeler (ör. yayıncıların aynı reklam tıklaması için aynı türden birden fazla dönüşümü tekilleştirme de dahil olmak üzere özet raporlar için ilişkilendirme sonrası mantığını etkili bir şekilde gerçekleştirememesi).	Yanıtımız önceki çeyreklerden farklı değil: Cihazlar ve ölçüm ardışık düzenlerinde tekilleştirme, reklam teknolojilerinin günümüzde 3. taraf çerezlerle karşılaştığı bilinen ve güncel bir zorluktur. ARA sayesinde reklam teknolojileri, belirli dönüşümlerin ne zaman kaydedileceğine karar verebilir ve dönüşümleri izlemek için hangi ölçüm ardışık düzenlerini kullandıklarını (ör.toplama anahtarının bir parçası) belirtmek için belirli meta verileri ekleyebilir. Bu meta veriler, diğer ölçüm hatlarıyla karşılaştırılabilir. Bu konuyla ilgili ek ekosistem geri bildirimlerini buradan almaktan memnuniyet duyarız.
Dönüşüm İzleme	Birden fazla alandan gelen dönüşümlerle çalışabilme isteği.	Bu isteği burada tartışıyoruz ve ek ekosistem geri bildirimlerini memnuniyetle karşılıyoruz.
Raporlama	Tarayıcı, dönüşümü göndermek için en az iki gün ancak en fazla 30 gün bekler. Bu durum, paydaş reklamverenlerin çoğunun gerçek zamana yakın zamanlarda çalışan performans reklamverenleri olması nedeniyle endişe verici olabilir.	Etkinlik düzeyindeki raporlar için varsayılan ayarlarda aşağıdaki varsayılan raporlama aralıkları bulunur: 2 gün, 7 gün ve 30 gün. Reklam teknolojileri, etkinlik düzeyinde esnek raporlama sayesinde raporlama aralıklarının sayısını ve uzunluğunu varsayılan değerlerden farklı bir değere ayarlayabilir. Raporlama aralıkları en az 1 saat olacak şekilde değiştirilebilir. Bu, performans odaklı reklamveren kullanım alanlarına yardımcı olabilir. Bu konuyla ilgili ek ekosistem geri bildirimlerinizi buradan gönderebilirsiniz.
Dijitalden Fiziksele Geçiş İlişkilendirmesi	ARA'da online'dan çevrimdışı'ya reklamcılık için herhangi bir uygulama seçeneği olacak mı veya çevrimdışı'dan online'a ilişkilendirmeyi ölçmek için başka öneriler var mı?	Şu anda ARA'da dijitalden fiziksele geçiş ölçüm kullanım alanlarını destekleme planı yoktur. Bu tür destek için dikkate alınması gereken önemli gizlilik ve güvenlik sorunları vardır. Bu desteğin kullanım alanlarıyla ilgili ekosistem geri bildirimlerini buradan paylaşabilirsiniz.
Hata Ayıklama Raporları	AdID, uygulamadan web'e ilişkilendirme için Chrome (kaynak/tetikleyici) kayıtları için erişilebilir olacak şekilde nasıl depolanır ve/veya alınır?	Hata ayıklama raporlarını etkinleştirmek için reklam teknolojisinin, kullanıcıyı uygulama ve web'de zaten birleştirebildiğini bize kanıtlaması gerekir. Bu, hata ayıklama raporları aracılığıyla yeni bilginin açığa çıkmamasını sağlamak için yapılır. Reklam teknolojisi, kullanıcı başına benzersiz bir birleştirme anahtarı sağlayarak birleştirme işlemini kanıtlayabilir. Bu birleştirme anahtarı AdID veya birinci taraf birleştirme anahtarı olabilir. Reklam teknolojisi AdID'yi kullanıyorsa Chrome, tarayıcıdan AdID'ye erişimi doğal olarak desteklemez ve API, her reklam teknolojisinin web kaydı sırasında AdID'yi kendi yöntemiyle iletmesini bekler.
Paket ayrıntı düzeyi	Her reklamveren için farklı grup stratejileri kullanılabilir mi?	Kullanım alanlarınıza en uygun çözümü bulmak için farklı katkı bütçesi ölçeklendirme yaklaşımlarını denemenizi öneririz. ARA, çeşitli reklam teknolojisi kullanım alanlarını karşılamak için esnek ve özelleştirilebilir olacak şekilde tasarlanmıştır. Bu nedenle, reklamveren veya sektör başına farklı gruplandırma stratejilerini denemenizi öneririz. Reklamverenlerin izlemek istedikleri ölçüm değerleri ve ölçüm değerlerinin hacmi arasında farklılıklar olduğunda farklı gruplandırma stratejileri kullanmak yararlı olabilir.
Belgeler	ARA için uygulama<>web uygulamasını uygulamayla ilgili ek doküman talebi.	ARA için Uygulama<>Web ile ilgili dokümanlarımızı burada yayınladık.
Performans	ARA ile ilgili isteklerin sayısı, söz konusu siteyi desteklemek için gerekli olan keepalive isteklerinin sayısına göre yayıncının sunucularında ağır bir yük olabilir. Kaynak etkinliklerini tek bir istekte toplu olarak düzenlemek sunucudaki yükü azaltmaya yardımcı olabilir. Bir olası fikir, JSON kodlamalı nesne dizisine izin vermektir.	Kaynak etkinlikleri belirli bir mantığa göre toplu olarak göndermek, API ile birlikte JavaScript mantığı kullanılarak belirli bir ölçüde mümkün olabilir. Şu anda bu isteği değerlendiriyoruz. Ekosistemden buradan ek geri bildirimler bekliyoruz.
Özellik İsteği	Sunucudan sunucuya entegrasyon desteğinin olmadığı için geçici bir çözüm önerisi.	Şu anda ARA'da sunucudan sunucuya entegrasyon desteği sunmayı planlamıyoruz. Sunucudan sunucuya entegrasyonu desteklemek için daha fazla dikkate alınması gereken birçok gizlilik sorunu vardır. Sunucudan sunucuya destek için ek kullanım alanları hakkında ekosistemden geri bildirim almaktan memnuniyet duyarız. Buraya göz atabilirsiniz.
Belgeler	ARA'nın temel bölümlerini/birkaç basit kullanım alanıyla nasıl başlayacağınızı açıklayan bir "hızlı başlangıç" kılavuzu isteği.	ARA için hızlı başlangıç kılavuzunu burada bulabilirsiniz. Bu dokümanları bu yıl daha da iyileştirmek için çalışıyoruz. Ek dokümanlar gerektiren belirli kullanım alanları veya senaryolarla ilgili buradan geri bildirimlerinizi bekliyoruz.
API Kullanımı	Birçok küçük değer için katkıları ölçeklendirmeyle ilgili öneri isteğinde bulunma	Kullanım alanlarınıza en uygun çözümü bulmak için farklı katkı bütçesi ölçeklendirme yaklaşımlarını denemenizi öneririz. Çok sayıda küçük değer senaryosu için, epsilon'dan gelen gürültünün kullanım alanınız için kabul edilebilir olabileceği dönüm noktalarını belirlemek amacıyla farklı epsilon değerleriyle deneme yapmanızı öneririz. ARA'da özet rapor optimizasyonu hakkındaki araştırmamızda daha fazla bilgi bulabilirsiniz.
Esnek Etkinlik Düzeyi	Esnek Etkinlik Düzeyi (birden fazla tetikleyici özelliği) ne zaman uygulanacak?	Şu anda esnek etkinlik düzeyi, aşağıdaki kayıt yapılandırması özelliklerinin özelleştirilmesini destekler: kaynak başına oluşturulabilecek rapor sayısı, raporlama aralıkları sayısı ve uzunluğu ve tetikleyici verilerinin kardinalitesi. Etkinlik düzeyinde ek esnek geliştirmeler hakkında ek ekosistem geri bildirimleri topluyoruz ancak şu anda herhangi bir geliştirmeyi uygulamayı planlamıyoruz. Burada listelenen esnek etkinlik düzeyindeki geliştirmelerden bazılarından yararlanabilecek kullanım alanları hakkında ek geri bildirimlerinizi bekliyoruz.
Kova İşleme	Gruplar için toplu katkıların yanı sıra gelecekteki genişletilebilirlik ve geriye dönük uyumluluğu sınırlandırmayı değerlendirme isteğinde bulunun.	Şu anda bu isteğinizi değerlendiriyoruz ve buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız.
Epsilon	ARA genel kullanıma sunulduğunda epsilon aralığı ne olur?	ARA, 2023'ün 3. çeyreğinde Chrome'da genel kullanıma sunuldu. Şu anda epsilon değer aralığını değiştirme planı yoktur. Düzeltilmiş bir yönetim yapısı önerimiz, herhangi bir değişiklik öngörüldüğünde ek güvence sağlayacaktır.
Raporlama	Tetikleyici-bilinmeyen-hata raporları, rapor gövdesinde kaynak özellikleri içermez.	Şartnamede belirtildiği gibi, trigger-unknown-error için rapor gövdesinde başka alanların bulunması gerekmez. Rapor gövdesinde alanları açıklayan tablonun, hatanın temel nedenine bağlı olarak kaynakla ilgili alanlar mevcut olabileceği gibi olmayabileceği için potansiyel olarak yanıltıcı olduğunu kabul ediyoruz. Örneğin, kaynak eşleştirme mantığı gerçekleşmeden önce dahili bir hata oluşabilir. Bu da hata ayıklama raporunun doldurulacağı hiçbir kaynak veri olmadığı anlamına gelir. Belgeler bu konuya açıklık getirecek şekilde güncellendi.
API Kullanımı	Sayı ve değer olmak üzere iki ölçüm hedefiyle çalışırken, hem katkı bütçesini hem de epsilonu bölmeniz gerekir mi?	İki ölçüm hedefiyle çalışırken katkı bütçesini bunlar arasında bölmenizi öneririz.
Raporlama	ARA, çoklu dokunma ilişkilendirmeyi veya yardımcı raporları (diğer adıyla katkı raporları) destekliyor mu?	ARA şu anda çok noktalı ilişkilendirmeyi veya destek raporlarını desteklememektedir. Şu anda bu özelliği uygulamaya koyma gibi bir planımız bulunmuyor. Kullanım alanları ve öncelikleri hakkında buradan ek geri bildirim gönderebilirsiniz.
API Hatası	ARA için dokümanda, kaynak ve tetikleyici toplama anahtar parçalarını birleştirmek üzere XOR'un kullanıldığı belirtiliyor ancak pratikte VE kullanılıyor. Bu tutarsızlık, uygulamada karışıklığa ve olası hatalara yol açar.	Belgeler, bunun bir hata olduğunu yansıtacak şekilde güncellendi.

Aggregation Service

Geri Bildirim Teması	Özet	Chrome Yanıtı
Toplama İşleri	Toplama işlerinde birden fazla ön ek kullanılmasına izin verilmesi için istekte bulunun.	Bu geri bildirimi inceliyoruz ve burada bir teklif yayınladık. Teklif hakkındaki geri bildirimlerinizi buradan bizimle paylaşabilirsiniz.
Özellik İsteği	Terraform komut dosyasının, service_account_token_creator_list ayarlanmamışsa (veya boşsa) hesap IAM politikasının değiştirilmesinin atlanması için değiştirilmesi isteği.	Bu sorunu buradan araştırıyoruz ve ekosistemle ilgili daha fazla geri bildiriminizi bekliyoruz.
API Kullanımı	Terraform planının her zaman değişiklik göstermesi hakkında açıklamaya ihtiyaç var.	Bu sorun AgS 2.8 sürümünde düzeltilmiştir.
API Kullanımı	Esnek katkı filtrelemeyle toplama sıklığı için reklamveren başına ayarlar oluşturmayla ilgili öneriler arıyorum.	Reklamverene göre gruplandırma şu anda ARA ile mümkündür. Esnek katkı filtreleme, bir reklam teknolojisinin bir raporun katkılarını farklı sıklıklara göre daha da segmentlere ayırmak istediği daha gelişmiş durumlarda kullanılabilir. Reklam teknolojisi uzmanları, gruplandırma hakkında daha fazla bilgiyi burada, filtreleme kimliklerini ARA ile kullanma hakkında daha fazla bilgiyi ise burada bulabilir. Kimlikleri filtrelemeyle ilgili daha fazla doküman üzerinde de çalışıyoruz.
Özellik İsteği	Aggregation Service'te (AgS) "log_sum_exp" için destek isteyin.	Kullanım alanı hakkında daha fazla bilgi için bu paydaşla iletişime geçtik. Daha fazla bilgi sahibi olduğumuzda sizi bilgilendireceğiz.
Özellik İsteği	AgS'de sorun olduğunda ve dağıtılan bir AgS'de olası sorunlar olduğunda daha fazla günlük/analiz/diğer metrik görebilme isteğinde bulunun.	Daha fazla hata, azaltma yöntemi ve açıklama eklemek için dokümanlarımızda yaptığımız güncellemeleri burada bulabilirsiniz. Belgelendirilmemiş veya mevcut olmayan hatalar/metrikler/günlükler vb. ve burada yararlı olabilecek ayrıntılar hakkında ek geri bildirimlerinizi bekliyoruz.
API Testi	Test döneminden sonra epsilonun nihai değeri ne olur?	Şu anda epsilon değer penceresinde değişiklik yapma planı yoktur. Test kullanıcılarının farklı parametreleri denemelerini ve geri bildirimde bulunmalarını öneririz.
Raporlama	Rapor oluşturuluyor ancak yine de döndürülen kodda PRIVACY_BUDGET_AUTHORIZATION_ERROR hatası alınıyor.	Bu hatadan kaçınmak için doğru raporlama kaynağını ve birleştirilebilir raporları belirtmeye yönelik yol gösterici bilgiler sağladık. Sorunla ilgili ek geri bildirimlerinizi (özellikle de tekrarlanan hatalar varsa) bekliyoruz.
Anahtar Bulma	Temel keşif teklifi için planlar neler?	Önemli keşif teklifinin kullanıma sunulmasıyla ilgili henüz bir zaman çizelgemiz yok, ancak buradan teklifle ilgili olarak ekosistemden geri bildirim bekliyoruz.
Özelleştirme	Aggregation Service için özelleştirme seçenekleri arıyorum.	Toplama Hizmeti'nin özelleştirilmesi TEE içinde mümkün değildir ancak TEE dışındaki bazı bileşenler için mümkündür. Bunun nedeni, TEE'de uygulamamız gereken gizlilik ve güvenlik standartlarıdır. Reklam teknolojisi uzmanlarının mimariyi ve hangi bileşenlerin özelleştirilebileceğini anlamalarına yardımcı olmak için dokümanlarımızı güncellemeye çalışıyoruz. Belirli özelleştirmeleri destekleyemeyiz. Bu nedenle, reklam teknolojilerinin mümkün olduğunda standart yapılandırmalarımızı kullanmasını öneririz.
Spot ve İsteğe Bağlı Örneklerin Karşılaştırması	Sistem, spot örnekler ve isteğe bağlı örnekler kullanılarak test edildi mi? Spot örneklerin geçici olarak kullanılamaması dışında, bu örnekleri kullanmanın belirli dezavantajları var mı?	Reklam teknolojilerinin isteğe bağlı örnekleri kullanmasını önerdiğimiz için spot örneklerde teste öncelik vermedik. Spot örneklerin dezavantajı, bütçe tüketimi sırasında işin kesintiye uğramasıdır. Bütçe tüketiliyorsa ve reklam teknolojisi özet raporunu almadan önce iş kesintiye uğrarsa reklam teknolojileri işi yeniden denemekle kalmaz, bütçe kurtarma isteğinde de bulunmalıdır. Bütçe kurtarma yalnızca gizliliği korumak için büyük hatalar olduğunda önerilir. Reklam teknolojilerinin, maliyetleri en aza indirmek için otomatik ölçeklendirmeyi yapılandırmasını öneririz. Otomatik ölçeklendirme için 0 değerini seçerseniz bir iş istenene kadar çalışan örnek olmaz (istekte bulunulduğunda örnekler oluşturulacağından bunun gecikmeyi artırabileceğini unutmayın).
Bilinen Hatalar ve Çözümler	Toplama Hizmeti işiyle ilgili olarak "Hizmet Hatası" ifadesini gösteren açıklama gerekiyor	Bu sorun buradan çözüldü. Ayrıca hata mesajlarımızdan bazılarını daha açıklayıcı olacak şekilde güncelledik. Örneğin, bu hataların daha önce dahili hatalar olarak gösterildiğine kıyasla AWS'de daha spesifik izin/kimlik doğrulama hataları göstermeye başladık. Buradaki hata kodları ve azaltma adımları ile ilgili dokümanları güncelledik. Belgelenmemiş veya mevcut olmayan hatalar ve hangi ayrıntıların yararlı olacağı hakkında buradan ek geri bildirimlerinizi bekliyoruz.

Private Aggregation API

Geri Bildirim Teması	Özet	Chrome Yanıtı
Anahtar Tasarım	Özel Toplama anahtarı tasarım kılavuzu isteği	Özel Toplama'ya özel bir rehberimiz olmasa da hem Toplama Hizmeti yük testi çerçevesi hem de Gelişmiş anahtar yönetimi kılavuzu kaynak olarak kullanılabilir.
Katkı Bütçesi	Katkı bütçesi hangi düzeyde hesaplanır ve sınırlanır?	Katkı bütçesi, 10 dakikalık periyodik aralıkta 2^16 ve 24 saatlik periyodik aralıkta 2^20'dir.

Gizli Takibi Sınırla

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

Bu çeyrekte geri bildirim alınmadı.

IP Protection (eski adıyla Gnatcatcher)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Yapay Zeka	IP korumasının Android'de kullanıma sunulması için planlanan tarih nedir?	Android'de IP Koruması da dahil olmak üzere gizli olmayan izleme özelliklerini kullanıma sunmak için çalışmalarımızı sürdürüyoruz. Ancak şu anda resmi bir planımız bulunmuyor.
API Kullanımı	IP koruması için sahtekarlık önleme istisnası olup olmadığı veya olup olmayacağıyla ilgili soru	Kullanıcıların web'de IP adreslerine göre izlenmesini önleme ile kötüye kullanıma karşı IP adreslerinin kullanılması da dahil olmak üzere sunucuların normal işleyişindeki kesintileri en aza indirme arasında bir denge kurmaya çalışıyoruz. Şu anda daha fazla bilgi veremiyoruz ancak yakın gelecekte bunu yapmayı umuyoruz. Görüşmeye devam etmeyi bekliyoruz.
Kötü Niyetli Kullanıcı Tanımlama	Kötü amaçlı IP adreslerine karşı geleneksel güvenlik önlemlerinin etkililiği konusunda endişeler.	IP Koruması, birinci taraf isteklerini proxy olarak kullanmaz. Bu nedenle, çoğu Saldırı Algılama Sistemi'nin etkilenmeyeceğini tahmin ediyoruz. Gelecekte gizli mod kullanıcıları için sahtekarlık önleme ve sitede kesinti yaşanması ile ilgili endişeleri giderecek ek ayrıntılar paylaşmayı planlıyoruz.
IP adresi maskeleme	Haber yayıncısı sitesi (birinci taraf), reklam sitesiyle (üçüncü taraf) aynı alanı kullanıyorsa IP adresi her ikisi için de maskelenir mi? Aksi takdirde, ikisini nasıl ayırt edebiliriz?	IP Koruması şu anda hangi üçüncü taraf trafiğinin proxy'lerden geçtiğini belirlemek için liste tabanlı bir yaklaşım öneriyor. Ancak bir kaynak bu listede olsa bile birinci taraf bağlamında erişilirse proxy'ye yönlendirilmez. Başlangıçta hangi üçüncü taraf alanlara öncelik verileceğine ve IP koruması için birinci taraf ve üçüncü taraf bağlamlarının kesin bir şekilde nasıl tanımlanacağına ilişkin ayrıntıları netleştiriyoruz.
IP Adresi Maskeleme	IP koruması ve sahtekarlıkla mücadele sistemleri üzerindeki etkisiyle ilgili endişeler	1P'ler, IP Koruma planlarımızdan etkilenmez. Bu nedenle, forumlar gibi sitelerin anlaşmazlık çözümü için IP adreslerine erişimi olmalıdır. İleride reklam sahtekarlığıyla ilgili endişeleri gidermek için ek ayrıntılar sunmayı planlıyoruz.
IP adresi maskeleme	Etkilenen alanlar için IP, başlıkta maskelenmiş mi?	Kullanıcılar, mevcut konumlarını temsil eden proxy öncesi IP adreslerine göre bir coğrafi bölgeye atanır. Daha fazla bilgiye buradan ulaşabilirsiniz.

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

Geri Bildirim Teması	Özet	Chrome Yanıtı
API Özellikleri	Chrome'un, bir sekme kapatıldığında genişletilmiş gezinmeyi işleme şekliyle ilgili açıklamaya ihtiyaç var.	Bu sorunu buradan çözdük ve spesifikasyonu buna göre güncelledik.
Gezinme İzleme	Siteler arası isteklerde entropi azaltmak için sonlu bir bağlantı grubu içeren bir izleme azaltma yaklaşımının tartışılması.	Bu konuyu burada diğer tarayıcı tedarikçileriyle tartışmaya devam ediyoruz. Ek geri bildirimleri ve ekosistemden konuyla ilgili özel önerileri almaktan memnuniyet duyarız.

Gizli Erişim Limiti

GitHub'daki açıklama ve geliştirici sitesinde belirtildiği gibi, Gizlilik Bütçesi artık Özel Korumalı Alan önerilerinin bir parçası olarak aktif olarak değerlendirilmiyor.

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ı
(Önceki çeyreklerde de raporlanmıştır) İlgili Web Sitesi Grubu (RWS) Alan Sınırı	RWS'deki ilişkilendirilmiş alanların sınırını artırma isteği	Yanıtımız önceki çeyreklerle benzer: Şu anda sayısal sınırı artırmayı düşünmüyoruz. Sınır, kullanıcı gizliliğiyle ilgili hususlar, W3C'deki ekosistem paydaşlarından gelen geri bildirimler ve diğer tarayıcılardaki benzer uygulamalar dikkate alınarak belirlenmiştir. Daha fazla bilgi için lütfen blog yayınlarımızı (1, 2) inceleyin. Siteler arası çerez erişimi için sayısal sınırın ötesinde erişim gerektiren kullanım alanlarını incelemenizi ve kimlik kullanım alanları, kimliği doğrulanmış yerleşimler ve reklamcılık kullanım alanları ile ilgili yönergelerimizden yararlanmanızı öneririz. Kullanıcı oturumları giriş işlemlerine bağlıysa işlevselliği korumak için Federated Credential Management (FedCM) API'yi kullanmanızı öneririz. Burada, gerekli olabilecek diğer kullanım alanları hakkındaki geri bildirimlerinizi bekliyoruz.
Siteler arası çerez işleme	Bir alt alan adı tarafından ayarlanan siteler arası çerezler, birincil alandan gelen sonraki isteklerde iletilmiyor. Doğru CORS ve kimlik bilgisi yapılandırmaları olsa bile sorun devam ediyor.	Siteler arası çerezlerin sonraki getirme isteklerinde gönderilebilmesi için requestStorageAccessFor API'sinin doğru kullanımıyla ilgili olarak buradan yardım alabilirsiniz.Bu API'nin doğru kullanımı için tam kaynağı (ör. alt alan adlarını) belirtmeniz gerekir.
Kullanıcının Seçimi	Kullanıcı seçiminin kullanıma sunulmasından sonra RWS tarafından kullanılan requestStorageAccessFor ile ilgili daha fazla bilgi (özellikle de şu anda 3 PC'ye erişime izin veren örtülü veya açık kullanıcı hareketinin yeni sistemde nasıl işleyeceği) talep edin.	RWS'nin kullanıcının tercihine göre belirlenen modlarda (yani, kullanıcıların üçüncü taraf çerezlerini kullanmaya devam etmeyi veya sınırlamayı seçip seçmediklerinden bağımsız olarak) sergileyeceği davranışın, Chrome'da üçüncü taraf çerezlerine izin verildiğinde ve RWS etkinken ("İlgili sitelerin gruptaki etkinliğimi görmesine izin ver" ayarı) üçüncü taraf çerezleri engellendiğinde sergilenen mevcut/gönderilen davranışla tutarlı olmasını bekleriz. requestStorageAccess çağrısını yapmadan önce, yerleştirilen içeriğin bölümlenmemiş siteler arası çerezlere erişimi olup olmadığını kontrol etmek için önce hasStorageAccess çağrısını yapmanızı öneririz. Kullanıcı 3. taraf uygulamalarına izin vermeyi seçerse hasStorageAccess yöntemi doğru değerini döndürür. 3. taraf uygulamalarına izin veriliyorsa requestStorageAccessFor için şu anda kullanıcı hareketi gerekmez. Bu durumda doğru davranışın ne olması gerektiğini tartışmak ve belirtmek için yeni bir GitHub sorunu açtık. Ekosistemden ek geri bildirimler bekliyoruz.
API Kullanımı	RWS'nin "ticari" amaçlarla kullanımıyla ilgili netlik eksikliği ve bu nedenle RWS'nin benimsenmesinin engellenmesi hakkındaki endişeler. Paydaş, hedeflenen reklamcılık için yayınları gruplandırmakla ilgilendiğini belirtti.	RWS'nin amacı, temel site işlevlerini ve temel kullanıcı yolculuklarını desteklemektir. Hedefli reklamcılıkla ilgili kullanım alanları için özel olarak tasarlanmış reklamcılık API'lerimizi kullanmanızı öneririz.
API Kullanımı	requestStorageAccess ile ilgili bir sorun raporu. Bu sorunda, localStorage verilerini ayarlayabiliyor ancak çerezleri ayarlayamıyor.	Sorun, SameSite özelliğindeki bir yazım hatasından kaynaklanıyordu. Yazımının doğru olduğundan emin olun ve 3 PC için açıkça Yok olarak ayarlayın.
API Spesifikasyonu	Depodaki JSON şemalarında "contact" alanının yanlış yerleştirilmesi gibi tutarsızlıklar ve tutarlılık sağlamak için "oneOf" anahtar kelimesinin kullanılması da dahil olmak üzere iyileştirme önerileri.	Bu geri bildirimi inceliyoruz ve yakın gelecekte şemada bu iyileştirmeleri yapmayı planlıyoruz. Burada ek geri bildirimlerinizi bekliyoruz.
RWS'ye üçüncü taraf (3. taraf) erişimi	Kullanıcı izni verildiğinde, bir yayın kuruluşunun RWS API verilerine bu şekilde erişebilecek üçüncü taraf alanlarını belirtmesine izin verin.	Üçüncü tarafların kendi bölümlenmemiş verilerini RWS site verileriyle birleştirmesine izin vermek, Özel Korumalı Alan'ın siteler arası izleme korumalarını zayıflatır. Bununla birlikte, 3P'lerin verileri RWS olarak bölünmüş halde kalmasını sağlama olasılığını değerlendiriyoruz. Böyle bir çözümün tasarımıyla ilgili geri bildirimleri buradan alabiliriz.

Fenced Frames API

Geri Bildirim Teması	Özet	Chrome Yanıtı
API Sorunu	Ağ erişimi olmayan çitli çerçevelerin, reklamverenler için marka güvenliğini ve sahtekarlık korumasını nasıl ihlal edebileceğiyle ilgili endişeler.	Bu endişeyi, korumalı çerçeveleri zorunlu kılma planımız kapsamında takip ediyoruz. Kısa süre içinde, korumalı çerçeve yaptırımıyla uyumlu çözümleri incelemeye başlayacağız. Yeterince önemli öneriler olduğunda bunları paylaşacağız.
API Sorunu	Fenced Frames API'nin kullanımdan kaldırılması için planlanan tarih hâlâ 2026 mı?	Herkese açık duyurumuzda belirtildiği gibi, 2026'dan önce Çitli Çerçeveler kullanılamaz.
API Hatası	reportEvent(), kaynak alanı çapraz alt çerçeveden tıklama verilerini başarıyla gönderdiğinde setReportEventDataForAutomaticBeacons(), üst çerçevenin verilerinin üzerine yazmaz.	Bu sorunu inceliyoruz ve buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız.

Shared Storage API

Geri Bildirim Teması	Özet	Chrome Yanıtı
Uygulama Reklamcılığı	Android'deki Özel Korumalı Alan'da Paylaşılan Depolama API'sinin eşdeğeri yoktur.	Android'deki çözümleri, kullanım alanı ihtiyaçlarına ve platform kısıtlamalarına göre değerlendiriyoruz. Şu anda böyle bir planı paylaşamıyoruz. Bununla birlikte, ekosistemden bu konuda ek geri bildirim almaktan memnuniyet duyarız.
API Kullanımı	Shared Storage API'nin uygulanması için ek bir JavaScript iş parçacığının gerekliliğiyle ilgili kafa karışıklığı.	Bu geri bildirimi inceliyor ve Share Storage API için ek iş uygulaması komut dosyalarına olan ihtiyacı açıklayacak şekilde dokümanlarımızı güncellemeyi düşünüyoruz.
Güvenilir değil	Shared Storage API, gizlilikle ilgili eleştiriler nedeniyle önemli ölçüde değişebilir veya kullanımdan kaldırılabilir. Bu da API'yi güvenilir bir temel haline getirir.	Paylaşılan Depolama altyapısını önemli ölçüde değiştirme veya kullanımdan kaldırma planımız yoktur. Duyurulan başlıca değişiklikler, çitle çevrili çerçevelerin gerekli olacağı ve etkinlik düzeyinde raporlamanın desteğinin sonlandırılacağı Seçilen URL çıkış kapısında yapılanlardır. Ancak bu değişiklikler en az 2026'ya kadar yürürlüğe girmeyecektir.

CHIPS

Geri Bildirim Teması	Özet	Chrome Yanıtı
Bölünmüş Çerezler	Chrome, Firefox'un aksine bölüm anahtarlarını çerçeve atalarına göre ayırt etmez. Bu da tutarsızlıklara yol açar.	Chrome, güvenlikle ilgili endişeyi ve Firefox'un davranışıyla ilgili tutarsızlığı çözmek için"ata zinciri biti"ni benimsedi. Bu konu hakkında daha fazla bilgiyi burada bulabilirsiniz.
Bölünmüş Çerezler	Farklı depolama alanı erişim düzeylerine sahip yerleşik iFrame'ler, aynı bölümlenmiş çerezi paylaşır ve üzerine yazar. Bu da kimlik doğrulama durumlarında tutarsızlıklara neden olur.	Bu yapılandırma için önerimiz, Storage Access API çağrısı ile bölümlenmemiş çerezleri kullanmanızdır. Bu konuyu burada daha ayrıntılı olarak ele aldık.
Bölünmüş Çerezler	3. taraf çerezleri devre dışı bırakıldığında bölümlendirilmiş çerez kapları temizlenir mi? Bu davranışı test etmenin bir yolu var mı?	Şu an için bununla ilgili herhangi bir bilgi paylaşma planımız bulunmuyor. Ancak geliştiriciler, Chrome Geliştirici Araçları Uygulama>Çerezler panelinden bölümlenmiş çerezleri manuel olarak silerek bu işlevi test edebilir.

FedCM

Geri Bildirim Teması	Özet	Chrome Yanıtı
Kimlik Sağlayıcı (IdP) Kayıt Kapsamı ve Kuruluş Seçici	IdP kaydını mevcut aynı kaynak politikasından aynı site politikasına genişletmeyle ilgili soru. Bu değişiklik, daha geniş ve daha esnek kimlik yönetimi sağlar. Örneğin, bir üniversitenin karşılama sayfasının, kaynağa özgü ayrı kayıtlara gerek kalmadan birden fazla alt alan adına dayalı kimlik sağlayıcıyı kaydettirmesine olanak tanır. Hata ayıklama özelliğini iyileştirme, sessiz uyumlulaştırma için onaylanmış istemcileri işleme, çerez davranışını açıklama, pop-up metninin özelleştirilmesine izin verme ve zaman aşımı sorunlarını ele alma ile ilgili geri bildirim.	Bu geri bildirimleri dikkate alıyor ve bir kuruluş seçicinin FedCM'ye nasıl dahil edilebileceğini değerlendiriyoruz. Bu yaklaşımı hassaslaştırmaya devam ederken ekosistemden buradan ek geri bildirimler bekliyoruz.
IdP Çerezleri	Cihaz Bağlı Oturum Kimlik Bilgileri (DBSC) önerisi kapsamında kısa ömürlü oturum çerezlerinin uygulanmasının etkisi hakkında tartışma. FedCM'deki kullanıcı deneyimiyle ilgili endişeler var. Süresi dolan IdP çerezlerinin, yenileme için kullanıcının görebileceği bir kalıcı kalıcı olması gerekir.	Önerilen DBSC, kullanıcı etkileşimi olmadan çerezlerin yenilenmesine izin vererek kesintisiz bir kullanıcı deneyimi sağlar. Bu sorunu burada daha ayrıntılı olarak ele aldık.
API Spesifikasyonu	"providers" dizisinin boyutu 1'e eşit olmadığında FedCM API spesifikasyonunda "NetworkError" kullanmanın uygunluğuyla ilgili soru.	Bir ağ sorunundan ziyade bir kodlama hatasını yansıttığından, "TypeError" bu durum için daha uygun olacaktır. Bu değişikliği değerlendirip çoklu IdP desteğine doğru ilerledikçe gelecekteki güncellemelerde bu kısıtlamanın kaldırılıp kaldırılma olasılığını değerlendireceğiz. Burada ek geri bildirimlerinizi bekliyoruz.

Spam ve sahtekarlıkla mücadele

Private State Token API (ve diğer API'ler)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Sonlanan Özellik Deneme Sürümü ve B Modu	Desteği sonlandırma denemesi, B modu testi, Gizli Durum Jetonları'nın (PST'ler) kullanımdan kaldırılma olasılığı ve sahtekarlık önleme kullanım alanlarına daha uygun yeni bir API'nin kullanıma sunulması olasılığıyla ilgili endişeler.	Destek sonlandırma denemesi ve B modu testi aynı şekilde devam edecektir. Gelişmeleri geliştirici blogunda paylaşacağız. PST'leri kullanımdan kaldırma gibi bir planımız yok. Devam eden özellik geliştirme ve güncelleme çalışmaları hakkında GitHub'da bilgi veriyoruz. Yeni API'ler duyurmadık ancak PST'lerin sahtekarlık önleme kullanım alanlarını nasıl daha iyi karşılayabileceğiyle ilgili geri bildirimlerinizi bekliyoruz.
API Geri Bildirimi	Sahtekarlık önleme kullanım alanını ele almak için jetonları iptal etme özelliğini talep edin.	Yayınlayan, kullandığı anahtarları değiştirerek tüm jetonları iptal edebilir. Ancak API'de tek tek jeton iptal etmek mümkün değildir. Bunun nedeni, yayınlayanın jeton verme ve kullanma işlemlerini ilişkilendirmesine izin verilmesinin gerekmesidir. Bu da iki etkinlik arasında izlemeyi önleyen PST gizlilik modelini bozar.