Geri Bildirim Raporu - 2025 2. Çeyrek

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

Google, bu üç aylık raporu 12, 17(c)(ii) ve 32(a) paragrafları uyarınca Rekabet ve Piyasalar Kurumu'na ("CMA") verdiği Taahhütler kapsamında hazırlamıştır. Bu raporda; Google'ın Özel Korumalı Alan önerileriyle ilgili ilerleme durumu, güncellenen zamanlama beklentileri, Google'ın üçüncü tarafların yaptığı gözlemleri nasıl dikkate aldığına dair önemli açıklamalar ve CMA'dan gelen geri bildirimler ile Google'ın bu geri bildirimleri ele alma yaklaşımı da dahil olmak üzere Google ile CMA arasındaki etkileşimlerin özeti yer almaktadır.

Google, Taahhütlerin 17(b) paragrafı uyarınca planlanan düzenli Durum Toplantılarında Özel Korumalı Alan önerileriyle ilgili ilerleme konusunda CMA'yı bilgilendirmektedir. Ayrıca ekip, temel özel reklamcılık özellikleri ve çerez değişiklikleri ile API uygulaması ve durum bilgileri hakkında genel bakışlar sunan geliştirici belgelerini de yönetir. Önemli güncellemeler geliştirici blogunda ve bireysel geliştirici posta listelerinde paylaşılır.

Üçüncü tarafların yaptığı gözlemleri dikkate alma

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
IAB
Interactive Advertising Bureau
IDP
Kimlik Sağlayıcı
IETF
Internet Engineering Task Force
IP
İnternet Protokolü adresi
openRTB
Gerçek zamanlı teklif verme
uzatma
Kaynak Denemesi
PA API
Protected Audience API (eski adıyla FLEDGE)
PatCG
Private Advertising Technology Community Group
RP
Bağlı Taraf
RWS
İlişkili Websitesi Grupları (eski adıyla Birinci Taraf Grupları)
SSP
Arz Tarafı Platformu
UA
Kullanıcı aracısı dizesi
UA-CH
Kullanıcı Aracısı İstemci İpuçları
W3C
World Wide Web Consortium
WIPB
Kasıtlı IP Körlüğü

Belirli bir API/teknolojiyle ilgili olmayan genel geri bildirimler

Geri Bildirim Teması Özet Chrome Response
Özel Korumalı Alan'ın geleceği Üçüncü taraf çerezleri için kullanıcı tercihi mekanizması sunma planının iptal edilmesiyle birlikte, üçüncü taraf çerezleri mevcutken bazı API'ler diğerlerinden daha kullanışlıdır ve bazılarının kullanışlı olabilmesi için geliştirilmesi gerekir. Chrome'un Özel Korumalı Alan API'lerinin dışında yatırım yapabileceği başka alanlar da var. Geri bildiriminiz için teşekkür ederiz. Google'ın, kullanıcılara Chrome'da üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın sürdürüleceğine dair Nisan 2025 duyurusu ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirmek ve gelecekteki yatırımlar için yeni alanlar keşfetmek amacıyla paydaşlarla etkileşim kurmaya devam ediyoruz.
Özel Korumalı Alan Bazı ekosistem katılımcıları, üçüncü taraf çerezleri için kullanıcı tercihi mekanizması sunma sürecine devam etmeme kararından dolayı hayal kırıklığına uğramış olsa da gerçekleştirilen çalışmalardan gurur duyuyor. Özel Korumalı Alan'daki teknik zorlukları takdir ediyorlar ve Chrome ile işbirliği içinde çalışma ilişkilerinin değerini ve pazar testi hibesinin faydasını vurguluyorlar. Geri bildiriminiz için teşekkür ederiz. Chrome'un, reklam destekli interneti korurken internetteki gizliliği artıracak teknolojiler oluşturmak için geliştiricilerle işbirliği yapabileceğini ve yapması gerektiğini kabul ediyoruz.
Tarayıcı Veri Paylaşımı Tarayıcı aracılı veri paylaşımı, piyasadaki verimsizlikleri ve güven sorunlarını giderme potansiyeline sahip ilgi çekici bir teknolojidir. Tarayıcı, işbirliği için üçüncü taraf yürütme bağlamı olarak değerlidir. Geri bildiriminiz için teşekkür ederiz. Chrome'un, iş birliği yapan geliştiriciler ve kullanıcılar arasındaki güveni artıran teknolojiler oluşturma konusunda geliştiricilere yardımcı olabileceği ve olması gerektiği konusunda sizinle aynı fikirdeyiz.
Chrome trafiği Chrome'daki çerezsiz trafiğin payı ve Gizli mod trafiğinin payı nedir? CMA'nın "Taahhütleri yayınlama niyetine ilişkin bildirim" başlıklı belgesinde belirtildiği gibi, Gizli mod yalnızca tarama etkinliğinin çok küçük bir bölümünü etkiler. Birleşik Krallık ve AEA'da Chrome Gizli modu, Android işletim sistemiyle çalışan cihazlardaki gezinmelerin% 10'undan azını ve Windows işletim sistemiyle çalışan cihazlardaki gezinmelerin %10'undan azını temsil eder. Bu metrikler yalnızca Birleşik Krallık ve AEA'daki Chromium tabanlı Chrome'da yapılan gezinmeleri ifade eder.
Üçüncü taraf çerezlerini engelleyen tarayıcılar hakkındaki verileri paylaşmayız.
Geliştiriciler, Storage Access Headers kullanarak çerezlerin ne zaman bölümleneceğini belirleyebilir ve mevcut azaltma yöntemlerini buna göre kullanabilir.
Chrome Testing Labels Chrome'un, 2024'te test için etkinleştirilen% 1'lik çerezsiz trafikle ilgili planı nedir? Şu anda paylaşabileceğimiz bir planımız yok ancak planlar hazır olduğunda bunları herkese açık olarak paylaşacağız.
Chrome Testing Mevcut test etiketi kurulumu, hem 3PC'lerin kullanılabildiği hem de Privacy Sandbox API'lerinin etkinleştirildiği senaryolar için bir işlem içeriyor mu? Mevcut test etiketi kurulumu, A modu şeklinde hem 3PC'ler hem de Privacy Sandbox API'leri için işlem içerir.
Özel Korumalı Alan Bazı reklamverenler Özel Korumalı Alan API'lerini karmaşık buluyor ve önceki hazırlık çalışmaları nedeniyle ilgisizlik yaşıyor. Ayrıca, erken kullanıma alanlar için avantajın nasıl ölçüleceğini sorguluyor ve yeniden hedefleme, yeni müşteriler kazanma ve ölçümün etkileri hakkında bilgi edinmek istiyor. Geri bildiriminiz için teşekkür ederiz. Teknoloji karmaşıklığı ve hazırlık çalışmalarıyla ilgili düşüncelerinizi anlıyoruz.
Mevcut Özel Korumalı Alan teknolojilerinin performansını anlama konusunda, test sonuçlarımız ekosistem katılımının Özel Korumalı Alan çözümlerinin performansını anlamak için kritik bir faktör olduğunu gösterdi. Düşük hacimlerde yapılan testler, pazar yeri dinamiklerini ve teknolojileri büyük ölçekte kullanmanın teşviklerini yeniden üretemeyebilir.

Kaydolma ve onay

Bu çeyrekte geri bildirim alınmadı.

Alakalı İçerik ve Reklamlar Gösterme

Konular

Geri Bildirim Teması Özet Chrome Response
Geliştirmelerle Topics API'nin Performansı ve Faydası Alıcı tarafındaki paydaşlardan alınan geri bildirimler, Topics API'nin değerli bir sinyal olduğunu ve reklamveren kampanyaları için 3PC kitlelerinin BGBM'siyle rekabet edebilecek bir gösterim başına maliyet (BGBM) verisi sağladığını gösteriyor. Bazı yayıncılar, Topics API'nin sinyalini standart açık web sinyallerinden daha kaliteli olarak değerlendiriyor. Topics API'nin kullanışlılığıyla ilgili bu geri bildirimler doğrultusunda paydaşlar, daha geniş bir kullanım için sınıflandırma doğruluğunu ve tutarlılığını iyileştirme, yayıncı kontrollerini genişletme gibi geliştirmeler talep ediyor. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Farklı paydaş türleri için
<0x0x0A>yararlılık
 Topics sınıflandırıcısı şu anda ilgili konuları tanımlamak için yalnızca sayfa ana makine adını kullandığından, çeşitli içeriklere sahip büyük siteler genel konulara katkıda bulunurken küçük siteler daha fazla reklamcılık değeri olan niş konulara katkıda bulunuyor. Yanıtımız önceki çeyreklerdekiyle benzerdir:
Üçüncü taraf çerezlerinde olduğu gibi, farklı sitelerin katkıda bulunduğu bilgilerin değeri farklıdır. Niş alanlara yönelik ilgi alanları siteleri, değer katkısı açısından tutarsızdır: Niş alanlara yönelik ilgi alanları sitelerinin tümünde ticari açıdan değerli içerikler bulunmaz ve bu nedenle daha az değer katkısı sağlarlar. Topics API'den yararlanacak siteler şunlardır: Site düzeyinde sınıflandırma yerine sayfa düzeyinde sınıflandırma olasılığını değerlendirdik ancak bu tür bir sınıflandırmayla ilgili önemli gizlilik ve güvenlik endişeleri var.
Topics sınıflandırması yeterince ayrıntılı değil Topics API, tek bir alan içinde çeşitli içerik bölümleri olan haber yayıncıları için yeterli ayrıntı düzeyini sağlamaz. Bu durum, API'nin reklam hedefleme açısından kullanışlılığını sınırlayabilir. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Sınıflandırıcı İyileştirme Yayıncıların, Chrome'a sayfa içeriğine (ör. başlık, gövde) göre konuları sınıflandırma izni vermesine olanak tanır. Bu isteği değerlendiriyoruz. Ek geri bildirimlerinizi buradan iletebilirsiniz.
Politika 3PC bilgileriyle birlikte Topics API'nin kullanımıyla ilgili yönergeler hakkında açıklama isteği. Topics API, üçüncü taraf çerezlerinin işlevlerinin bir alt kümesini sağladığından hem Topics API hem de üçüncü taraf çerezleri kullanılırken herhangi bir zorluk yaşanmaz.
Observe-Browse-Topics Header Observe-Browse-Topics başlığının uygulanmasıyla ilgili açıklama isteği, özellikle başlığın sürekli olarak döndürülmesinin sorunlara neden olup olmayacağı. Sürekli olarak Observe-Browse-Topics: ?1 başlığını döndürmek herhangi bir teknik soruna neden olmaz.
Tarayıcı, bu sinyali verimli bir şekilde işler. Sayfa ziyaretinin, konu hesaplaması için uygun olduğunu, herhangi bir kopya veya hataya neden olmadan belirtir. Her sayfada zorunlu olmasa da tüm üst düzey dokümanlarda standart başlık olarak göndermek geçerli ve basit bir stratejidir.
Sınıflandırma kategorileri En son Topics sınıflandırmasının yeni konularla güncellenmesini isteyin. Bu isteği değerlendiriyoruz ve ekosistemden gelen ek geri bildirimleri buradan bekliyoruz.
Null Değerler Topics API'nin performansını artırma ve filtreleme veya hassasiyet gibi nedenlerle boş yanıtlar alma hakkında rehberlik isteği. Netlik açısından, Topics API'den gelen null veya boş yanıtların bir hata değil, beklenen bir gizlilik özelliği olduğunu belirtmek isteriz.
null yanıtının nedenleri:
• Gizlilik Kuralları:% 5 rastgele null şansı veya komut dosyanızın kullanıcıyı bu konuyla ilgili sitelerde "gözlemlememiş" olması.
• Kullanıcı durumu: Yetersiz tarama geçmişi, Gizli modun kullanılması veya kullanıcının Chrome'un reklam gizliliği ayarlarında kapsam dışında kalmayı seçmesi.
• Teknik Hatalar: Yayıncı siteleri Observe-Browse-Topics: ?1 üstbilgisini göndermelidir ve tüm çağırma iFrame'leri allow="Browse-topics" iznini gerektirir.
İncelemek için chrome://topics-internals hata ayıklama sayfasını kullanarak tarayıcınızın hangi konuları ve neden hesapladığını görün.
Gizlilik özellikleri% 100 doluluk oranını engellese de şu yöntemlerle performansı artırabilirsiniz:
• Yayıncılarla çalışma: İş ortaklarınızın sitelerinde Observe-Browse-Topics: ?1 üstbilgisini doğru şekilde gönderdiğinden emin olun.
• Kodunuzu Doğrulama: Iframe kullanıyorsanız allow="Browse-topics" politikasının uygulandığını onaylayın.

Protected Audience API

Geri Bildirim Teması Özet Chrome Response
PA API'nin Kullanımı Maliyet ve Karmaşıklık Nedeniyle Engelleniyor Erken benimseyenler, operasyonel maliyetleri, reklamveren talebinin olmamasını ve exchange'lerden gelen envanter hacminin düşük olmasını gerekçe göstererek Protected Audience API (PA API) entegrasyonlarına öncelik vermiyor veya bunları geri alıyor.
Bazı geri bildirimlerde, PA API'nin potansiyel avantajları (ör. yüksek eşleşme oranı sayesinde kalıcı kitleler ve üstün erişim sağlama) yer alıyordu. 		Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Platformlar arası işlevler Daha iyi yeniden hedefleme ve kitle hedefleme özelliklerinden yararlanmak için platformlar arası işlevler, platformlarda PA API kullanılarak desteklenmelidir. Google, Chrome'da kayıtlı ilgi alanları gruplarının (IG) yerel ortamlarda veya web görünümünde reklam yayınlarken erişilebilir olmasını sağlamalıdır. Android'de kayıtlı ilgi alanları grupları ise Chrome açık artırmalarında kullanılabilir olmalıdır. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
directFromSellerSignals Bağlamsal açık artırmada kullanılabilen bilgi miktarını sınırlayarak açık artırma katılımcıları her zaman Google'ın reklam sunucusuna yönlendirilir. Bir yayıncı, bağlamsal açık artırmayı çalıştırmak için önce tüm borsa iş ortaklarını, ardından Google Ad Manager'ı (GAM) çağırmalı ve son olarak GAM'in IG açık artırmalarını çağırmasına izin vermelidir. Bağlamsal açık artırmanın sonucunu gerçek zamanlı olarak bilmeden hiçbir rakip, üst düzey bir kararı adil bir şekilde yönetemez.

PA API'deki directFromSellerSignals özelliği, açık artırma bilgileriyle ilgili şeffaflık açısından eksik olabilir ve gerekli verilere erişimi engelleyebilir. Google, directFromSellerSignals'ı kaldırmalı veya reklam sunucusunun açık artırma sonuçlandırma fiyatını gizlemek için kullanılamayacak şekilde güncellemelidir. Örneğin, bağlamsal fiyat, tüm açık artırma katılımcılarının (ve yayıncının) erişip doğrulayabileceği şeffaf, değişmez ve imzalı bir alan aracılığıyla Chrome üzerinden iletilebilir.		 Yanıtımız önceki çeyreklerdekiyle aynıdır:
Chrome yanıtı:
Satıcı, runAdAuction() işlevini kendi iFrame'inden çağırmadığı sürece runAdAuction() işlevine iletilen bilgilerin satıcıdan geldiği bilinmez. Çok satıcılı bir açık artırmada, tüm satıcıların runAdAuction() işlevini çağıran çerçeveyi oluşturması mümkün olmaz. directFromSellerSignals, satıcının kaynağına yüklenen bir alt kaynak paketinden içerik yükleyerek bu sorunu çözdü. Bu, satıcı açık artırması yapılandırmalarından bir açık artırmaya aktarılan bilgilerin gerçekliğinin ve bütünlüğünün değiştirilememesini sağlar. Yayıncılar, teknoloji sağlayıcılarının PA açık artırmalarına ilettiği bilgileri anlamak için PA API'yi kullanmak isterse bu işlevselliği teknoloji sağlayıcılarından isteyebilir.
Google Ad Manager'ın yanıtı:
Yıllardır açık artırmanın adilliğine büyük önem veriyoruz. Bu kapsamda, yayıncının garantili olmayan reklamcılık kaynaklarından elde edilen hiçbir fiyatın (garantili olmayan 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ü Fransız Rekabet Kurumu'na verdiğimiz taahhütlerle daha sonra yeniden teyit ettik.
Protected Audience açık artırmalarında, doğrudan satıcıdan gelen sinyallerden yararlanarak sözümüzü tutmayı 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 başka bir açık artırma katılımcısıyla paylaşmamayı amaçlıyoruz. Bu güncellemede açıklandığı gibi, bağlamsal açık artırmanın fiyatını kendi bileşen açık artırmamızla da paylaşmayacağız.
Raporlama Merkezi raporlamayı etkinleştirmek için bir analiz/raporlama varlığı ekleme isteği. Bu isteği burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.
buyerReportingId üzerinde k-anonimlik Kitle seçimini ve üçüncü taraf veri sağlayıcılarla ilgili raporlama yükümlülüklerini kolaylaştırmak için "buyerReportingId"nin k-anonimliğine göre teklifleri silme olanağı. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
generateBid komut dosyasında hata ayıklama iyileştirildi Sürecin başarısız olduğu generateBid komut dosyasındaki belirli aşamayı veya "kesme noktasını" hızlı bir şekilde tanımlamak için bir mekanizma talep etme. Cihaz üzerinde açık artırmalar için Gerçek Zamanlı Ölçümler'in kesme noktası ayarlama mekanizması olarak kullanılmak istendiğinin farkındayız. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
runAdAuction durumunu izlemek için etkinlik işleyiciler Reklam açık artırması yaşam döngüsünün izlenmesini iyileştirmek için PA API'lerinin navigator.runAdAuction işlevine etkinlik işleyici desteği ekleme önerisi. Bu isteği değerlendiriyoruz. Ekosistemden gelen ek geri bildirimleri buradan iletebilirsiniz.
API Kullanımı Özellikle üçüncü taraf çerezlerini devre dışı bırakan ancak Özel Korumalı Alan API'lerini devre dışı bırakmayan kullanıcılar için ve başarısız çerez senkronizasyonlarını ve WebView'ı içeren senaryolarda, PA API ve Attribution Reporting API'nin (ARA) üçüncü taraf çerezlerinin olmadığı durumlarda web reklamcılığı kullanım alanlarını nasıl destekleyebileceği konusunda açıklama yapılması isteği. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Gecikme PA API ile ilişkili gecikme, yayıncılar gecikme çok yüksekse PA API'yi devre dışı bırakmayı tercih edebileceğinden API'nin benimsenmesini engelleyebilir. Son birkaç çeyrekte cihaz üzerindeki gecikmeyle ilgili çeşitli iyileştirmeler yapıldı. Gerekli olduğu sürece Teklif ve Açık Artırma (T&A) hizmetlerinin oluşturulması ve ölçeklendirilmesi devam eder. Gecikmeyle ilgili en iyi uygulamalar kılavuzumuz, bu özelliklerden nasıl yararlanılacağı hakkında daha fazla bilgi içerecek şekilde güncellendi. Ayrıca, bazılarını burada bulabileceğiniz yeni gecikme iyileştirmeleri geliştirmeyi de değerlendiriyoruz.
B&A'daki günlük kaydı davranışı (test ve üretim) B&A hizmetleri için test ve üretim modları arasındaki günlük kaydı davranışındaki farklılıklarla ilgili açıklama. Özellikle, bulut günlüklerinin kullanılabilirliği ve üretim modunun günlük kaydı üzerindeki etkisi. Öncelikle prod ve non_prod derlemeleri ile yalnızca sabit kodlanmış bir test şifreleme anahtarını etkinleştiren ayrı TEST_MODE parametresi arasında ayrım yapmak önemlidir. Aşağıdaki açıklamada derleme türlerine odaklanılmaktadır.
Üretim dışı derlemelerde, B&A sunucularında günlük kaydı için yapılandırılabilir ayrıntı düzeyi bulunur. Bu ayrıntılı günlükler, standart stdout/stderr akışlarına yazılır. Google Cloud'da bu verilere yerel günlük arayüzü üzerinden, Amazon Web Services'te ise ekli konsol günlüklerinden erişilebilir.
Üretim derlemelerinde, günlük kaydı davranışı daha kısıtlıdır. Ayrıntı düzeyi sabittir ve değiştirilemez. Gizlilikle ilgili olmayan bazı günlükler (ör. sunucu başlatma mesajları ve çoğu kilitlenme hatası) stdout/stderr'a yazdırılmaya devam etse de bu kanal üzerinden isteğe özel günlükler kullanılamaz. Üretim derlemesinden gelen istek başına günlükler yalnızca onaylı bir hata ayıklama jetonu içeren istekler içindir ve bunlar yalnızca OpenTelemetry aracılığıyla dışa aktarılır. Yoğun trafik sunucu performansını düşürebileceğinden ve sağlık durumu kontrolü hatalarına yol açabileceğinden, izin verilen hata ayıklamayı dikkatli bir şekilde kullanmak önemlidir.
Metrikler OpenTelemetry aracılığıyla dışa aktarılır. Gizliliğe duyarlı olmayan metrikler her zaman olduğu gibi, "gürültü" eklenmeden dışa aktarılır. Buna karşılık, gizliliğe duyarlı metrikler, üretim modunda çalışan bir sunucudan dışa aktarıldığında her zaman "gürültülenir". Bu gizliliğe duyarlı metriklerin gürültülü, gürültüsüz veya her ikisi olarak dışa aktarılıp aktarılmayacağını belirli telemetri yapılandırması belirler.
Marka güvenliği için güvenilen teklif sinyallerine tam sayfa yolunu dahil etme Güvenilir teklif sinyalleri için getirme isteğinde ana makine adına ek olarak üst düzey sayfanın tam URL yolunun da dahil edilmesi amacıyla PA API'nin güncellenmesi isteğinde bulunuldu.
Birincil kullanım alanı, daha ayrıntılı marka güvenliği denetimlerini etkinleştirmektir. Reklamverenler genellikle bir alanın belirli bölümlerinde (ör. haber-sitesi.com/siyaset) reklamların görünmesini engellemek isterken genel olarak alanla ilgili bir sorun yaşamaz. Bu engelleme listeleri milyonlarca giriş içerebileceğinden sunucu tarafında değerlendirilmelidir. Yalnızca ana makine adını gönderen mevcut spesifikasyon, trustedBiddingSignals sunucusunun bu gerekli yol düzeyinde değerlendirmeyi yapmasını imkansız hale getirerek marka güvenliği özelliklerini sınırlar.		 Bu konuyu şu anda burada tartışıyoruz. Daha önce yapılan kapsamlı tartışmalara buradan ulaşabilirsiniz. Ek geri bildirimlerinizi de bekliyoruz.
Ancak, bu bilgilerin yalnızca trustedBiddingSignals getirme işlemi, Güvenilir Yürütme Ortamı (TEE) içinde çalışan bir sunucuya gittiğinde ekleneceğini belirtmek isteriz.

Korumalı açık artırma (B&A Hizmetleri)

Geri Bildirim Teması Özet Chrome Response
Kullanılabilirlik Testi Hem Chrome hem de B&A ortamlarında test için Key/Value (KV) v2'nin kullanılabilirliğiyle ilgili bilgiler. KV v2, B&A ve Chrome'da kullanılabilir. Ek bilgileri burada bulabilirsiniz.
KV Server Implementation KV sunucusunun kullanımıyla ilgili, özellikle reklam öğesi oluşturma URL'lerinin istek verileriyle eşlenmesi, oluşturma URL'sindeki parametrelerin tanımlanması için SSP'ler ve DSP'ler arasında koordinasyonun gerekliliği ve KV modunda gerekli koordinasyon ve veri depolamayı özetleyen belgelerin kullanılabilirliği ile ilgili açıklama isteği. KV hizmeti, renderURL'yi anahtar olarak kullanır. Yeni URL'ler depolanır. Varsa değeri, scoreAd'de kullanılmak üzere döndürülür. Dönüş biçimi, kurulum şekline bağlıdır: "Kendi Sunucunu Getir" (BYOS) kurulumunda herhangi bir değere izin verilirken Trusted KV hizmeti için kullanıcı tanımlı bir işlev gerekir.
Her zaman gerekli olmasa da makro değiştirme (ör. ${AD_WIDTH}) in the renderURL, which enables dynamic ad customization and verification.
Gerekli koordinasyon düzeyini belirlemek için tek bir DSP ile basit bir test yaparak başlamanızı öneririz. Ayrıca KV dokümanlarımızı güncelleme sürecindeyiz ve kullanıma sunulduğunda herkese açık olarak paylaşacağız.
B&A için BYOS Neden B&A, KV'nin BYOS moduna benzer bir BYOS modu sunmuyor? B&A, aşağıda açıklandığı gibi gizlilik mekanizmalarının uygulanmasını gerektiren son derece hassas veri kombinasyonlarını işlediği için TEE gerektirir ve BYOS modelini engeller.
DSP'ler için:
B&A, yayıncı bağlamını (açıkça satıcı tarafından auctionSignals / perBuyerSignals aracılığıyla gönderildiyse tam URL olabilir) ayrıntılı kullanıcı IG verileriyle birlikte işler. TEE, bu kombinasyonu güvenli bir şekilde işlemek ve kullanıcıların yeniden tanımlanmasını önlemek için gereklidir. KV BYOS'ta tam URL gönderilemez.
Tedarik tarafı platformları için:
Bir açık artırmaya katılan IG'lerin (ve bunların TTP sahiplerinin) kombinasyonunu bilmek bile tanımlayıcı bir imza oluşturabilir. Bu noktada, TEE kullanımını gerektiren chaffing çözümü devreye girer.
Bu nedenle, birleştirilmiş bu hassas sinyallerin güvenli bir şekilde işlenmesi ve gizlilik mekanizmalarının uygulanması için TEE'nin kontrollü, onaylanmış ortamı gerekir.

Dijital Reklamları Ölçme

Attribution Reporting (ve diğer API'ler)

Geri Bildirim Teması Özet Chrome Response
Gürültü Politikası ARA'nın uygulanması bazı pazar katılımcıları için değerli oldu ve Google, etkinlik düzeyinde raporlamayı sürdürmelidir. Google, hem ARA hem de 3PC'lerin kullanılabildiği senaryolarda gürültü politikasını gevşetmeyi düşünmelidir. Performans reklamverenleri, ARA esnek etkinliğinin mevcut "değer" alanı uygulamasını giderek daha fazla kullanıyor. Daha az kısıtlayıcı bir gürültü politikası, gecikmeleri ve yanlış raporlamayı azaltmaya yardımcı olacaktır. Bu mekanizma, bireysel takibi önleyerek kullanıcı gizliliğini korumayı amaçlayan ARA tasarımının temel bir parçasıdır. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçme olanağı sunmaya yönelik mevcut yaklaşımın sürdürüleceğine dair Nisan 2025 duyurusu ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü ve olası iyileştirmeleri değerlendirmeye devam ederken gürültünün neden olduğu raporlama sorunlarıyla ilgili geri bildirimleri de dikkate alıyoruz.
Yol Haritası ve Uzun Süreli Destek ARA için ürün yol haritası ve 3. taraf çerezleri için kullanıcı seçimi mekanizmasının kullanıma sunulmayacağı duyurusu göz önünde bulundurulduğunda uzun vadeli yatırım ve destek onayı talep etme. Özel Korumalı Alan ekibi, Özel Korumalı Alan API'lerinin gelecekteki rolünü anlamak ve gelecekteki yatırımları değerlendirmek için ekosistemle etkileşim kuruyor.
Ortamlar Arası Ölçüm (Uygulamadan Web'e) ARA'yı kullanarak ortamlar arası ölçümü kolaylaştıran, daha temiz ve güvenilir bir veri akışı sunan, kullanıcı etkileşimlerini farklı platformlarda bağlama özelliğini geliştiren bir çözüm isteyin. Aynı cihazda uygulamadan web'e geçiş, ARA tarafından zaten desteklenmektedir. Uygulamalar arası ve web ölçümü çözümü hakkında daha fazla bilgiyi burada ve burada bulabilirsiniz.
Tarayıcılar Arası İlişkilendirme ARA'ya yönelik birleşik ve tarayıcılar arası yaklaşım, açık web'de YG'yi ölçme olanağını önemli ölçüde iyileştirir ve olası yasal değişikliklerden önce istikrarlı bir alternatif sunar. Chrome, bu tür bir çözüm için Safari ekibiyle işbirliği yapmalıdır. W3C'deki PATCG ve PATWG gruplarında diğer tarayıcı sağlayıcılarla birlikte birlikte çalışabilir bir API'yi zaten araştırıyoruz. Bu çalışmanın ön aşamada olduğunu belirtmek isteriz. Paydaşlar, ilerleme durumumuzu buradan takip edebilir.
Cihazlar Arası/Çevrimdışı Ölçüm ARA'da cihazlar arası dönüşüm ölçümünün desteklenmemesi önemli bir sınırlamadır. Online'dan offline'a dönüşümleri ölçmek de önemli bir konudur ve tarayıcı, ölçüm tedarikçileriyle işbirliği yapma konusunda rol oynayabilir. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Çok Noktalı İlişkilendirme Reklamverenlerin, mevcut ilişkilendirme modellerini doğrulamak ve kalibre etmek için Özel Korumalı Alan verilerini tarafsız bir "temel gerçek" olarak kullanmasına izin verilmesi isteği. Bu, ARA'nın tarayıcı tarafından sağlanan verilerini güvenilir bir kalibrasyon sinyali olarak kullanarak ve bir doğruluk temeli oluşturarak elde edilebilir. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
İzin alınmadan/kullanıcılar tarafından devre dışı bırakılarak yapılan trafik ölçümü Birlikte çalışabilir özel ilişkilendirme gibi gizliliği korumaya yönelik bir çözüm, izin verilmeyen trafik için ölçüm yapılmasını sağlar. Bu sayede, izlemeyi devre dışı bırakan kullanıcıların verileri de dahil edilerek kampanya performansı daha kapsamlı bir şekilde anlaşılabilir ve izin şartlarının oluşturduğu ölçümdeki büyük boşluk giderilebilir. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Sunucudan Sunucuya İlişkilendirme Gelişmiş sunucu tarafı altyapısına sahip reklam teknolojilerinin, kullanıcı gizliliğini korurken tamamen istemci tarafında yönetilmesi zor olan kullanım alanlarını destekleyecek şekilde ARA ile daha esnek bir şekilde entegre olmasına izin verilmesini talep edin. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.
Çoklu Alan Kaydı ARA'ya birden fazla alan kaydederken sınırlamalar ve uyarılar hakkında, özellikle toplama hizmeti ve kaynaklar arası ilişkilendirme ile ilgili olarak açıklama istiyoruz. Aşağıda, ARA'yı birden fazla alanla kullanırken karşılaşılan temel sınırlamalar verilmiştir:
• İlişkilendirme tek bir kaynakla sınırlıdır. Alanlarınızdan birindeki tıklamayı başka bir alandaki dönüşümle eşleştiremezsiniz. İlişkilendirme, hem kaynak hem de tetikleyici için aynı kaynakla sınırlıdır.
• Toplama Hizmeti, çok kaynaklı toplu işleme özelliğini desteklemez. Farklı kaynaklardan gelen raporlar ayrı ayrı gruplandırılmalı ve işlenmelidir. Bu özelliği gelecekte desteklemenin yollarını araştırıyoruz.
Kısaca özetlemek gerekirse bir tüzel kişi altında birden fazla alan kaydedilebilir ancak şu anda ilişkilendirme ve toplama gibi tüm ARA işlevleri kaynak bazında ele alınmalıdır.

Aggregation Service

Bu çeyrekte geri bildirim alınmadı.

Private Aggregation API

Geri Bildirim Teması Özet Chrome Response
Sınırlar ve Gürültü Düzeyleri Private Aggregation API'deki toplama anahtarı boyutları ve toplama değerleriyle ilgili sınırlamalarla ilgili endişeler. Toplama anahtarı ve değer boyutları, ağ ve depolama maliyetlerini sınırlarken yüksek ayrıntı düzeyine sahip olacak şekilde seçilmiştir. Esnekliği en üst düzeye çıkarmak için anahtarları atarken karma oluşturma işlemini kullanmanızı da öneririz.
Kullanıcı verilerini koruyan başka faktörler olsa da gürültü eklemek, Private Aggregation API'nin gizlilik korumalarının önemli bir parçasıdır.
Geri bildirimleri dikkate alıyoruz ve Google'ın Nisan 2025'te yaptığı, kullanıcılara Chrome'da 3PC seçeneği sunmaya yönelik mevcut yaklaşımın sürdürüleceği duyurusu ışığında, Özel Korumalı Alan API'lerinin gelecekte oynayacağı rolü değerlendirmenin yanı sıra uygun parametre seçimlerini değerlendirmeye devam edeceğiz.
Gizlilik ve Kullanışlılık Özel Korumalı Alan'ın yaklaşımında gizlilik, faydaya göre öncelikli olabilir ve bu durum, teknolojinin benimsenmesini engelleyebilir. Ölçümü ve reklam kişiselleştirmeyi iyileştirmek için kullanıcı rızasıyla daha ayrıntılı veri paylaşımına izin verilmesi önerilir. Toplama anahtarı ve değer boyutları, ağ ve depolama maliyetlerini sınırlarken yüksek ayrıntı düzeyine sahip olacak şekilde seçilmiştir. Esnekliği en üst düzeye çıkarmak için anahtarları atarken karma oluşturma işlemini kullanmanızı da öneririz.
Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın sürdürüleceğine dair Nisan 2025 duyurusu ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.

Gizli İzlemeyi Sınırlama

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

Geri Bildirim Teması Özet Chrome Response
Spam algılama Bir spam algılama sistemi kullanan web sitesinden gelen ilk istek, istemci ipuçlarına dayanıyorsa izleme veya algılama sistemi, isteği tanımlayamayabilir ya da doğru şekilde sınıflandıramayabilir. İlk istekte Kullanıcı Aracısı İstemci İpuçları'na (UA-CH) erişimi gerektiren kullanım alanları, önemli istemci ipuçlarını kullanmalıdır.
API Geri Bildirimi Artık modern web için geçerli olmadığından Sec-CH-USA-Wow64'ü kullanımdan kaldırmayı düşünebilirsiniz. Bu isteği değerlendiriyoruz. Ek geri bildirimlerinizi buradan iletebilirsiniz. Ayrıca, wow64'ün Windows'un ötesine genişletilmesinin faydalı olacağına dair geri bildirimler aldık.

IP Protection (eski adıyla Gnatcatcher)

Geri Bildirim Teması Özet Chrome Response
Denetimler Sitelerin Gizli mod dışında seçici olarak kullanması için IP Koruması isteği açma/kapatma düğmesi. Geri bildiriminiz için teşekkür ederiz. Bu sorunla ilgili ek görüşlerinizi buradan iletebilirsiniz.
Kusurlu davranış NULL değeriyle sonuçlanan olasılıksal açıklama jetonları (PRT'ler), polis platformdaki kötü davranışlarla ilgili IP adresi açıklamasını istediğinde failin kimliğinin belirlenmesini engeller mi? Bir alan yalnızca sahtekarlık ve kötüye kullanım tespiti için kullanılıyorsa bu alanın, Maskelenmiş Alan Listesi'ne (MDL) dahil edilme olasılığı düşüktür ve bu nedenle IP korumasından etkilenmez. Bu nedenle, bu alanlar için PRT'lere gerek duyulmaz.
Bir alan adı MDL'ye dahil edilmişse şu anda PRT'ler, proxy'li bir isteğin orijinal IP adresini öğrenmenin tek yoludur. PRT'ler, bireysel tanımlamayı değil, özellikle toplu analizi desteklemek için tasarlandığından çoğu durumda IP adresi içermez. IP koruması yalnızca üçüncü taraf bağlamında geçerli olduğundan, bu durumun açıklanan senaryoda sınırlı bir etkisi olacağını düşünüyoruz. Bu, yayıncıların, kullanıcıların bir online platformun sitesini ziyaret etmesi gibi birinci taraf etkileşimleri için proxy'siz IP adresleri almaya devam edeceği anlamına geliyor.
Sahtekarlıkla mücadele Google'ın IP Protection ile ilgili sahtekarlık önleme önlemlerinin ayrıntıları (proxy'lere erişimi sınırlama ve kimlik doğrulama jetonu verme ile ilgili ayrıntılar dahil) ve PRT'lerin kullanım alanları nelerdir? IP Protection'daki sıklık sınırlama ve kimlik doğrulama jetonlarının, botların proxy'lere aşırı erişerek reklam sahtekarlığı yapmasını önlemek için tasarlandığını onaylıyoruz. Bu konu, sahtekarlık ve spam karşıtı stratejide ayrıntılı olarak açıklanmıştır. PRT'lerin diğer kullanım alanları, PRT açıklayıcı belgelerinde burada özetlenmiştir.
Gizli mod IP Koruması'nın Gizli modda kullanıma sunulması 3. çeyrek için planlanmaya devam ediyor mu? Gizli modda IP koruması özelliğinin kullanıma sunulmasıyla ilgili 3. çeyrek takviminde şu anda herhangi bir değişiklik yoktur.

Sıçramalı İzleme Çözümleri

Geri Bildirim Teması Özet Chrome Response
API Geri Bildirimi Chrome, Safari'nin "bölümleme" yönteminden kaynaklanan istenmeyen davranış ve kafa karışıklığını gerekçe göstererek, sıçrama izlemeyi azaltma (BTM) uygularken çerez/depolama erişimini bölümlemek yerine engellemelidir. Bu öneriyi memnuniyetle karşılıyoruz. Şu anda BTM, çerez/depolama bölümleme içermez ve bunun yerine bir ek süre sonunda siler. BTM'de çerezlere yönelik acil işlem yapılmasını gerektiren sonraki tasarımlar olursa çerezleri bölmek yerine engellemeyi tercih etmeyi planlıyoruz.

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

Bu çeyrekte geri bildirim alınmadı.

Fenced Frames API

Bu çeyrekte geri bildirim alınmadı.

Shared Storage API

Geri Bildirim Teması Özet Chrome Response
API Özelliği İsteği Paylaşılan depolama alanına reklam görüntüleme ve tıklama sayısı ekleme isteği. Google'ın, Chrome'da kullanıcılara üçüncü taraf çerezleri seçeneği sunmaya yönelik mevcut yaklaşımın korunacağını duyurduğu Nisan 2025 tarihli açıklaması ışığında, Özel Korumalı Alan API'lerinin gelecekteki rolünü değerlendirirken bu geri bildirimi dikkate alıyoruz.

CHIPS

Geri Bildirim Teması Özet Chrome Response
API Sorusu Chrome'un üçüncü taraf çerezleri kontrollerinin CHIPS ile nasıl etkileşime girdiği, özellikle üçüncü taraf çerezleri devre dışı bırakıldığında bölümlenmemiş çerezlerin bölümlenmiş çerezlere dönüştürülüp dönüştürülmediği ve bölümlenmiş çerezlerin etkin kalıp kalmadığı hakkında açıklama isteği. Üçüncü taraf çerezleri devre dışı bırakıldığında, bölümlenmemiş çerezler üçüncü taraf bağlamında depolanmaz, alınmaz veya gönderilmez. Ancak, işlevleri üçüncü taraf çerezlerini devre dışı bırakan tarayıcı ayarlarından etkilenmediği için bölümlendirilmiş çerezler üçüncü taraf bağlamında depolanmaya, alınmaya ve gönderilmeye devam edecektir.
Gizlilikle İlgili Sorun Tek oturum açma gibi işlemler için kalıcı tanımlayıcıya sahip yerleştirilmiş bir tarafın, bölümlendirilmiş çerezler kullanıldığında bile hem yerleştirme hem de yerleştirilmiş tarafların genel bir dijital tanımlayıcı edinmesini sağlayabileceği endişesi. Yerleştirilmiş bir tarafın kalıcı tanımlayıcısı olabilir ancak bu tanımlayıcı, bölümlendirilmiş bir çerezde depolandığında yalnızca çerezin yerleştirme tarafından ayarlandığı sitede erişilebilir. Bu tanımlayıcının siteler arası birleştirilmesi için oturum açma işlemi gerekir. Bu işlem, bölümlendirilmiş çerezler kullanılmasa bile kimlik doğrulama jetonu biçiminde bir tanımlayıcının değiştirilmesine zaten olanak tanır.

FedCM

Geri Bildirim Teması Özet Chrome Response
API Kullanımı Birden fazla hesabı olan kullanıcılar için sessiz arabuluculuk, belirli bir hata olmadan başarısız oluyor. Sessiz arabuluculuk davranışı, yalnızca bir hesabın kullanılabildiği çok özel bir durum için tasarlandığından, tasarım gereği bir özelliktir. Bu durumda, FedCM'nin sessiz arabuluculuk mümkün olmadığında kullanıcıya bir hesap seçici sunmaya geri döndüğü "isteğe bağlı" arabuluculuğun kullanılması önerilir.
API Kullanımı navigator.credentials.get, genel hatalar döndürerek kullanıcı kapatma veya bekleme süreleri gibi belirli ret nedenlerinin yakalanmasını engelliyor. Geliştiricilerin, kullanıcının FedCM iletişim kutusunu kapatması, ağ hatası veya kullanıcının daha önce iletişim kutusunu kapatması nedeniyle FedCM'nin"bekleme süresinde" olması arasında ayrım yapamaması da kullanıcının gizliliğini korumak için tasarlanmış bir özelliktir. Bu tür bir özelliğin, web sitelerinin farklı kimlik sağlayıcılarda (IdP'ler) kullanıcının giriş durumunu tahmin etmesine olanak tanıyacağı endişesi vardır.
Oturum açma Oturum açılmış birden fazla hesapla tutarsız hesap seçimi davranışı gözlemlendi. Birden fazla hesapta oturum açma senaryosunda belirli bir hesabın aralıklı olarak seçilememesinin FedCM'deki aralıklı bir hata mı yoksa test sistemiyle ilgili bir sorun mu olduğu net değildir. Bu sorunu çözmek için bildiren kullanıcıyla birlikte çalışıyoruz ve sorunu daha iyi anlamak için daha fazla ayrıntı istedik.
API Kullanımı Kullanıcı, FedCM ile yetkilendirme yaparken iletişim kutusunu kapatırsa bekleme süresinde olduğu, yakalanabilir bir hata aracılığıyla bildirilmez. Evet, bu durumda genel hata kodu oluşturulur. Bunun amacı, kullanıcı gizliliğini korumaktır.
API Kullanımı FedCM, başarılı bir "otomatik yeniden kimlik doğrulama" işleminden sonra neden 10 dakikalık sessiz döneme giriyor? Otomatik yeniden kimlik doğrulama, kullanıcı tarafından başlatılan bir işlem olmadan gerçekleştiğinden kullanıcı web sitesine geri dönmek ancak farklı bir hesapla oturum açmak isterse FedCM'nin otomatik olarak yeniden kimlik doğrulamadığı bir süreye ihtiyacı olur. "Sessiz dönem", kullanıcıların farklı bir hesapla manuel olarak oturum açmasına olanak tanır. Bu blog yayınında bu "sessiz dönem" hakkında daha fazla bilgi verilmektedir.
Lightweight FedCM Lightweight FedCM teklifinin, iki uyumsuz uygulamanın (FedCM ve Lightweight FedCM) desteklenmesi gerektiğinden IdP'ler için ek karmaşıklık getirdiği endişeleri. Lightweight FedCM, geleneksel FedCM ile uyumludur. IdP'ler hangi uygulama yöntemini kullanacaklarını seçebilir ve her ikisini de desteklemeleri gerekmez.
Basit FedCM, FedCM için bir push mekanizmasıdır. Bir IdP bu özelliği kullanmayı seçerse kullanıcı oturum açtığında hesap bilgilerini tarayıcıya gönderebilir. Böylece, bir güvenilir taraf (RP) FedCM'yi çağırdığında hesap, IdP'nin hesap uç noktası yerine tarayıcıdan alınır.
Lightweight FedCM Ad, e-posta ve profil resmi gibi kişisel kullanıcı verilerinin Lightweight FedCM teklifinde RP'ye gösterilmesiyle ilgili endişeler. Bu geri bildirimi aldıktan sonra Lightweight FedCM teklifi güncellenerek yöntem yanıtından ad, e-posta ve profil resmi kaldırıldı.
Lightweight FedCM Lightweight FedCM teklifinde, oturum açılmış birden fazla hesabın yönetimi çok katı görünüyor. Öneri şu anda hesap başına ayrı oturum ömürlerini veya ayrıntılı giriş durumlarını desteklememektedir. Son kullanma tarihi şu anda credentials nesnesindeki IdP'ye bağlıdır. Hesap başına geçerlilik süresini açık bir soru olarak not ettik ve bu geri bildirimi gelecekteki geliştirmelerde dikkate alacağız.
Lightweight FedCM "Oturum açıldı" ve "seçilebilir" arasındaki ayrım net bir şekilde tanımlanmamıştır. Bu durum, Lightweight FedCM teklifinin kullanıcı deneyimini etkileyebilir. Şu anda FedCM kullanıcı arayüzünde (UI) bir hesabın oturumunun açık mı yoksa kapalı mı olduğunu ayırt etme özelliği desteklenmemektedir. Oturumu kapatılmış hesaplar listelenmemelidir.
Bir hesabın oturumu kapatılıp listelenirse ve kullanıcı etkin olarak oturum açılmamış hesabı seçerse kullanıcının tekrar oturum açması için Devam API'si kullanılabilir.
API Kullanımı getUserInfo içindeki given_name alanı ile FedCM kullanıcı arayüzündeki kullanımı arasındaki tutarsızlık. Bu sorun, given_name öğesinin getUserInfo içinde nasıl ele alınacağı konusunda fikir birliğine varılması için Mozilla ile burada daha ayrıntılı olarak ele alındı.
API Kullanımı IdentityProviderAccount kullanıcı arayüzünde kullanılan tüm alanlar getUserInfo ile paylaşılmaz. Özellikle tel ve username alanlarının senkronize edilmesi gerekir. Mozilla ve diğer FedID Topluluk Grubu üyeleriyle IdentityProviderAccount alanlarından hangilerinin getUserInfo. alanına gönderileceği konusundaki tartışmalar devam ediyor.
Enterprise FedCM Enterprise IdP kullanım alanları için FedCM desteği isteği. Buradaki temel sorun, kimlik sağlayıcıların yöneticilerin, kullanıcının web izleyicileri tarafından taklit edilemeyen ve/veya kötüye kullanılamayan belirli RP'lere erişmesine izin vermek için önceden izin verdiğini tarayıcılara bildirmesi için güvenilir bir mekanizmaya ihtiyaç duyulmasıdır. Bu konu, 22 Nisan'daki FedID CG toplantısında ele alındı (toplantı notlarını burada bulabilirsiniz) ve olası çözümler olarak tarayıcı uzantıları ile Kurumsal Politikalar'ın (yönetilen cihazlar için) kombinasyonları önerildi. Bu sorunla ilgili ek geri bildirimlerinizi buradan iletebilirsiniz.

Spam ve sahtekarlıkla mücadele

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

Bu çeyrekte geri bildirim alınmadı.