Geri Bildirim Raporu - 2025 Yılı 1. Çeyrek

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

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

Google, Taahhütler'in 17(b) paragrafına uygun olarak planlanan düzenli Durum Toplantıları'nda CMA'yı Özel Korumalı Alan önerileriyle ilgili ilerlemelerden haberdar etmektedir. Ayrıca ekip, API uygulama ve durum bilgileri ile birlikte temel gizli reklamcılık özelliklerine ve çerez değişikliklerine genel bakış sunan geliştirici belgelerini yönetir. Önemli güncellemeler, geliştirici posta listelerinde paylaşılan hedeflenmiş güncellemelerle birlikte geliştirici blogunda paylaşılır.

Kısaltmalar sözlüğü

ARA
Attribution Reporting API
CHIPS
Bağımsız Bölümlendirme Durumuna Sahip Çerezler
DSP
Talep tarafı platformu
FedCM
Federated Credential Management
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ü
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 Konsorsiyumu
WIPB
İstençli IP Körlüğü

Belirli bir API/teknolojiyle ilgili olmayan genel geri bildirimler

Geri bildirim teması Özet Chrome Yanıtı
Kullanıcının Seçimi Google'ın kullanıcı tercihini öne çıkarmaya yönelik güncellenmiş yaklaşımının nasıl görüneceği, kullanıcılara nasıl sunulacağı ve beklenen etkinleştirme/devre dışı bırakma oranları henüz net değil. Bu durumu üçüncü taraf çerezlerinin kullanımdan kaldırılmasından ayırt etmek için daha fazla bilgi gerekir. Google, Nisan 2025'te Chrome'da Özel Korumalı Alan ve izleme korumaları için sonraki adımlar başlıklı bir blog yayınlayarak Chrome'da kullanıcılara üçüncü taraf çerezleri sunma konusunda mevcut yaklaşımı sürdürmeye karar verdiğini ve üçüncü taraf çerezleri için yeni bir bağımsız istem kullanıma sunmayacağını duyurdu.
Gelişmeler oldukça sizinle paylaşacağız.
Dijital parmak izi Google, ortak eşleşme anahtarı olarak daha riskli tüketici kimliği (ör. parmak izi) kullanmadan Google'ın reklam sistemlerine alternatif olarak nasıl güvenebilecekleri konusunda yayıncılarla veya pazarlamacılarla hiçbir bilgi paylaşmamıştır. Yayıncılara ve pazarlamacılara kısmen Özel Korumalı Alan API'leri üzerine inşa edilmiş çözümler sunan Google dışı reklam sistemlerinden birkaçını öne çıkardık. Buna, pazarlar ve kanallardaki Google dışı reklam sistemleri de dahildir. Daha fazla ayrıntı ve örnek olay için privacysandbox.com'un İşletme Kaynakları bölümünü buraya göz atın.
Özel Korumalı Alan Özel Korumalı Alan API'leri, internet veri bileşenlerini Google'ın kendi bitmiş ürünleriyle değiştirecek. Google'ın alternatifi bir API olduğundan, Google'ın sahip olduğu ve kontrol ettiği bir ürüne erişim sunar. Bu ürün, Google'ın takdirine bağlı olarak hükümler ve koşullara tabidir. Bu, başkaları tarafından kendi bitmiş ürünlerini yapmak için kullanılan bileşenlerin yerine geçmez. Özel Korumalı Alan API'leri, düzenleyici kurumlar ve çok çeşitli ekosistem paydaşlarıyla kapsamlı bir etkileşimden sonra geliştirilip uygulanmıştır. Diğer platform teknolojilerinde olduğu gibi, Özel Korumalı Alan API'leri de diğerlerinin nihai ürünlerinde bileşen olarak kullanılacağını dikkate almalıdır. Özel Korumalı Alan API'leriyle birlikte çalışacak ek teknolojiler geliştirmek için ekosistemin gösterdiği çabaları memnuniyetle karşılıyoruz.
Kullanıcının Seçimi Google'ın Chrome'daki üçüncü taraf çerezlerine yönelik güncellenmiş yaklaşımının, paydaşların izin yönetim platformu deneyimini etkileyebilecek belirli yasal şartları karşılayıp karşılamayacağı hakkında bilgi isteği. Google, Nisan 2025'te Chrome'da Özel Korumalı Alan ve izleme korumaları için sonraki adımlar başlıklı bir blog yayınlayarak Chrome'da kullanıcılara üçüncü taraf çerezleri sunma konusunda mevcut yaklaşımı sürdürmeye karar verdiğini ve üçüncü taraf çerezleri için yeni bir bağımsız istem kullanıma sunmayacağını duyurdu.
Gelişmeler oldukça sizinle paylaşacağız.
Özel Korumalı Alan Zaman Çizelgesi ve Kullanımı Reklam teknolojileri, Özel Korumalı Alan API testini duraklattı ve ürün ve pazarlama etkinlikleri için bu teknolojilere yeniden yatırım yapmak üzere daha güçlü nedenler arıyor. Yeniden yatırım kararları, Kullanıcı Seçimi zaman çizelgesi konusunda daha fazla netlik elde etme ihtiyacının yanı sıra Protected Audience API (PA API) gecikmesi ve B&A yol haritasıyla ilgili endişelerden büyük ölçüde etkileniyor. Ayrıca, yaklaşan CMA Taahhütleri incelemesiyle ilgili endişeler var. Özellikle Google'ın üçüncü taraf tanımlayıcılara güvenmeden Privacy Sandbox teknolojilerinin birincil itici gücü olarak rolü ve yatırım stratejilerini bilgilendirme girişiminin genel gelecekteki yönü ile ilgili endişeler var. Google, Nisan 2025'te Chrome'da Özel Korumalı Alan ve izleme korumaları için sonraki adımlar başlıklı bir blog yayınlayarak Chrome'da kullanıcılara üçüncü taraf çerezleri sunma konusunda mevcut yaklaşımı sürdürmeye karar verdiğini ve üçüncü taraf çerezleri için yeni bir bağımsız istem kullanıma sunmayacağını duyurdu. Gelişmeler oldukça sizinle paylaşacağız.

Chrome PA API açık artırmaları, önceki yıla kıyasla% 35 daha hızlıdır. Bununla birlikte, paralelleştirilmiş açık artırmaların kullanımında önemli bir artış olduğunu gördük. Bu da söz konusu açık artırmalar için daha da büyük bir kazanç sağlıyor.

B&A ile ilgili güncel yol haritamıza buradan ulaşabilirsiniz.
Özel Korumalı Alan zaman çizelgesi Özel Korumalı Alan zaman çizelgesi sayfasında ne güncellendi? Topics API'ye dair bir genel bakış kısa süre önce Özel Korumalı Alan zaman çizelgesi sayfasına eklendi.
Özel Korumalı Alan Özel Korumalı Alan'ın gelir üzerindeki etkisini anlamamıza yardımcı olacak gizlilik ve fayda karşılaştırması konulu araştırma makaleleri var mı? Bu soruları ele alan alakalı pazarla ilgili örnek olay çalışmaları burada, Özel Korumalı Alan API'leri testinin sonuçları ise burada yer almaktadır.
Özel Korumalı Alan'ın Kullanıma Geçirilmesi Özel Korumalı Alan API'lerini erken benimseyen bir kullanıcı, büyük şirketlerin API'leri yavaş benimsemesi nedeniyle test lansmanlarını etkileyen ilk zorluklardan bahsetti. Buna rağmen, Privacy Sandbox ekibinin ortak çalışma yaklaşımı ve geri bildirimlere verdiği yanıt takdir edildi. İlk kullanıcıların geri bildirimlerini bekliyoruz. Özel Korumalı Alan teknolojilerini ilk kullananlarla birlikte çalışmaya kararlıyız. Özel Korumalı Alan teknolojilerinin ekosistemi desteklemedeki rolünü değerlendirirken ekosistemle etkileşime geçmeye ve geri bildirim toplamaya devam edeceğiz.
Chrome Testi Üçüncü taraf çerezleri devre dışı bırakılmış Chrome (B Modu) ile Chrome ayarlarında üçüncü taraf çerezlerini kişisel olarak devre dışı bırakan kullanıcılar arasındaki trafik kalitesinde önemli bir fark olduğunu vurgulayan test etiketlerinin kaldırılmasından sonra Özel Korumalı Alan testine etkili bir şekilde devam etme konusunda endişe. Yanıtımız önceki çeyreklerle benzer:

Privacy Sandbox ekibi, şirketlerin çerez desteğinin sonlandırılmasına ilişkin etiketleri kullanmaya devam etmek istediğinin farkındadır. Etiketlerin kullanılabilirliğini uzatma süreci, kaynak deneme süresini uzatma sürecine benzer. Etiketler için destek birkaç kez uzatıldı. Çerez desteğinin sonlandırılmasına dair etiketler için desteğin daha da uzatılmasını önermeyi planlıyoruz. Güncellemeleri blink-dev'de paylaşacağız.

Kayıt ve Onay

Bu çeyrekte geri bildirim alınmadı.

Alakalı İçerik ve Reklamlar Gösterme

Konular

Geri bildirim teması Özet Chrome Yanıtı
Etkinleştirme/Devre dışı bırakma Google'ın, Google Arama'nın bir sitenin Topics API'yi devre dışı bırakma kararını sıralama sinyali olarak kullanmayacağı yönündeki onayı, Google'ın bir sitenin Topics API'yi etkinleştirme kararını sıralama sinyali olarak kullanmasını kısıtlar mı? Yanıtımız önceki çeyreklerle benzer:

Özel Korumalı Alan ekibi, web sitelerinin Topics API'yi benimsemesi için bir teşvik olarak sayfa sıralamasını kullanması konusunda Arama kuruluşuyla koordinasyon kurmadı veya bu kuruluştan böyle bir talepte bulunmadı. Google Arama, bir sitenin Topics API'yi destekleme (veya desteklememe) kararını sıralama sinyali olarak kullanmaz.
Kullanım Gözlemlenebilirliği Topics API'nin uygulanıp uygulanmadığını web'de görebilmek için bir SSP veya genel reklam teknolojisi için gözlemlenebilirlik mekanizması isteme. Bu işlev için destek sunup sunmayacağımızı değerlendiriyoruz. Bu özellik sizin için önemliyse ekosistemden ek geri bildirim almaktan memnuniyet duyarız.
Gizlilik İzin ve yeniden kimlik tanımlama potansiyeli hakkında sorular. Şu anda bu sorunu burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.

Protected Audience API

Geri bildirim teması Özet Chrome Yanıtı
PA API ve GAM/AdX Google, rakip bir yayıncı reklam sunucusuna güvenmek isteyen bir yayıncıya GAM/AdX talebi göndermez. Google, nihai açık artırmayı kontrol etmek için rakip 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'den alınan bilgiler GAM tarafından kullanılabilir ancak rakip SSP'ler için kısıtlanır. Sonuç olarak yayıncılar, GAM'deki PA API kaynaklı talebin (ör. AdX'den veya PA API'ye entegre STP'lerden) performansını karşılaştıramaz. Chrome Yanıtı:
PA API standardı esnek olacak şekilde tasarlanmıştır ve farklı tarafların üst düzey açık artırmayı çalıştırmasına olanak tanır. Bu seçim, yayıncının reklam sunucusu (GAM veya başka bir sunucu) ve ekosistemdeki diğer katılımcı şirketler tarafından sunulan belirli uygulamalara ve özelliklere bağlıdır.
PA API'nin gizlilik odaklı tasarımı, tüm katılımcılar için ayrıntılı raporlamayı tutarlı bir şekilde sınırlar. PA API açık artırmasının kendisinden raporlanan belirli veriler, SSP'ler dahil tüm katılımcılar için API tarafından tanımlanan ve gizliliği koruyan aynı kurallara ve sınırlamalara tabidir.
Yayıncılar, performansı değerlendirmek için PA API'nin toplu ve gizliliği korumaya yönelik raporlarını kullanır. Bu sayede, PA API aracılığıyla sağlanan talebin genel katkısı değerlendirilebilir ve API'nin gizlilik tasarımı ilkeleriyle tutarlı olarak diğer talep kanallarıyla karşılaştırma yapılabilir.

Google Ad Manager tarafından sağlanan yanıt:
Yayıncıların, AdX talebine erişmek için GAM'ın reklam sunucusu işlevini kullanması gerekmez. Ayrıca PA API, hem tek satıcılı hem de çok satıcılı tasarımlarda açık artırmayı kimin başlattığına bakmaz.
Üst Düzey Satıcı Üst düzey satıcı (TLS), diğer bileşen satıcılarının hiçbirinin erişemediği bilgilere erişebilir. Bu durum, bilgilere eşit erişimle ilgili endişelere yol açar. TLS herhangi bir varlık olabilir ancak yayıncıların AdX talebine erişebilmesi için yayıncı reklam sunucusu olarak GAM'i kullanması gerekir. Bu, yayıncı reklam sunucusu olarak GAM'i kullanmaya yönelik bir teşvik oluşturur ve Google için rekabet avantajı sağlar. Chrome Yanıtı:
PA API'nin tasarımı, hangi öğenin TLS olarak işlev görebileceğini belirlemez. TLS rolü, açık artırmayı koordine etmeyi ve API'nin yapısına göre ilgili açık artırma bilgilerine erişmeyi gerektirir.

Google Ad Manager tarafından sağlanan yanıt:
Yıllardır açık artırma adaletine odaklanıyoruz. Bu kapsamda, garanti edilmeyen satır öğesi fiyatları da dahil olmak üzere yayıncının garanti edilmeyen reklamcılık kaynaklarından hiçbir fiyatın, açık artırmada teklif vermeden önce başka bir alıcıyla paylaşılmayacağına dair söz verdik. Bu sözümüz daha sonra Fransız Rekabet Kurumu'na verdiğimiz taahhütlerde de tekrarlandı.
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. Açıkça belirtmek gerekirse, bu güncellemede açıklandığı gibi 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. Ayrıca, kendi açık artırmamız kapsamında alıcılardan SSP'lere sağlanan sinyaller de dahil olmak üzere bileşen açık artırması yapılandırmalarıyla ilgili bilgileri kullanmayız.
Ayrıca, yukarıda belirtildiği gibi GAM, yayıncıların AdX talebine erişmek için reklam sunucusu işlevini kullanmasını gerektirmez.

Son olarak, Google'ın 2024'ün 2./3. çeyrek raporunda belirtildiği gibi, Google'ın alıcı tarafı platformları (Google Ads [eski adıyla AdWords] ve DV360), PA API aracılığıyla da dahil olmak üzere Google dışı exchange'lerden gösterim satın alır.
PA API ve GAM/AdX Seçeneğin etiketlenmesi amacı netleştirmediğinden, yayıncıların PA API'yi envanterin% 100'ünde etkinleştirmesini anlaması zordur. Envantere erişmelerinin birincil yolu genellikle TLS olarak GAM'in görev yaptığı çok seviyeli bir açık artırma olan STP'ler için GAM'e tabi olmadan PA API üzerinden test yapmanın veya para kazanmanın hiçbir yolu yoktur. Chrome Yanıtı:
PA API standardı, teknik rolleri (ör. TLS ve bileşen satıcısı) ve açık artırma sürecini tanımlayarak bu rolleri hangi platformların gerçekleştireceği konusunda esneklik sağlar.

Yapılandırma, koordinasyon ve sözleşmeler gibi operasyonel etkinlikler, PA API çerçevesini kullanarak katılımı kolaylaştırmak için uygulayıcı taraflar (yayıncılar, SSP'ler, TLS sağlayıcılar) tarafından yönetilir.

Google Ad Manager tarafından sağlanan yanıt:
Yardım Merkezimizde açıklandığı gibi, Ad Manager yayıncılara API'nin kullanılabildiği bir yayıncının envanterinin% 100'ünde Google dışı bileşen satıcılarıyla (ör. diğer SSP'ler) test yapmayı etkinleştirmek için bir denetim sunar (GAM'ın uygulayabileceği tüm örneklemeyi veya tıkanma oranını geçersiz kılar).

Bir yayıncı bu denetimi etkinleştirirse Google dışı bir bileşen satıcısı açık artırma yapılandırması sağladığında GAM, yayıncının gerekli kullanıcı iznini alması koşuluyla, sağlanan bileşen açık artırması dahil olmak üzere üst düzey bir açık artırma çalıştırmayı dener. GAM, yayıncıların bilinçli bir karar vermesi için bu denetimin performansı etkileyebileceğini açıkça belirtir.
Sunucu tarafı ve cihaz üzerinde Teklif ve Açık Artırma (T&A) gibi sunucu tarafı çözümler, gizliliği korurken trafik şekillendirme sorununu çözme potansiyeline sahiptir. Sunucu tarafı çözümler, ilerlemenin tek yoludur ve Google'ın cihaz üzerinde çözümlerden vazgeçmesi gerekir. Özel Korumalı Alan, hem sunucu tarafı (B&A hizmetleri) hem de cihaz üzerinde açık artırma çözümlerini desteklemeyi amaçlar. Böylece farklı reklam teknolojisi ihtiyaçlarını ve kullanım alanlarını karşılayacak seçenekler sunar.
Açık Artırma Güvenliği PA API tekliflerine yapılan saldırılar, cihaz üzerinde teklif verme ve açık artırmaları temel olarak geçersiz kılar. Bu sorun, paydaşlar tarafından çözülmüş olarak kabul edilmez ve PA API tekliflerinin bozulmadığından emin olmak için teknik garantiler ve gerçek zamanlı olay algılama ve verimli hata ayıklama sağlamak için kapsamlı bir hata ayıklama modu talep etmeye devam ederler. Olası saldırıları azaltmak da dahil olmak üzere PA API açık artırma bütünlüğünü sağlamak, Özel Korumalı Alan'ın odaklandığı önemli konulardan biridir. API'nin tasarımında bütünlük önlemleri yer alır. Belirli endişelerle ilgili daha fazla teknik tartışmayı memnuniyetle karşılarız.

Mayıs 2024'te düzenlenen W3C Sahtekarlık Önleme Topluluğu Grubu toplantısında, PA API'ye yönelik olası saldırıların ayrıntılı bir listesini ve bu saldırılara karşı önlemlerimizi sunduk ve tartıştık. "PA API tekliflerine yönelik olası saldırılar" konusunda endişe verici olan noktalarla ilgili daha fazla tartışma ve geri bildirim almaktan memnuniyet duyarız.
Çerezsiz Trafik PA API'yi test veya başka amaçlar için yalnızca çerezsiz trafikte etkinleştirmenin bir yolu olacak mı? Reklam teknolojileri, 3. taraf çerezlerinin mevcut olup olmadığını belirleyebilir. Bu konu burada daha ayrıntılı olarak açıklanmıştır.
SEAT kimliği Koltuk kimliği önerisi ile ilgili olarak, koltuk kimliği bilgisi çoğu teklif isteği için gereklidir. Bu da koltuk kimliğinin reklam öğesi kaydına bağlanması konusunda endişelere yol açar. Ayrıca, bu yalnızca "ana reklam" için mi yoksa bileşen reklamlar için de mi geçerli? BuyerAndSellerReportingId teklifi, ana reklam için reklam öğesi kaydı sırasında alıcının Seat kimliğinin eksik olmasıyla ilgili endişeyi giderir. Bu tanımlayıcı, alıcının koltuk kimliğini satıcıya iletmeyi amaçlar. Bileşen reklamları için desteği değerlendiriyoruz.
İzleme ve Raporlama (1) İptal edilen açık artırmalar için RTM raporları göndermek ve (2) ne tür bir iptal işleminin gerçekleştiğini netleştirmek üzere tarayıcı tarafından doldurulan yeni gruplar oluşturmak amacıyla Gerçek Zamanlı İzleme (RTM) için özellik isteği. RTM, katılım oranını incelemek için uygun bir çözüm gibi görünmüyor. RTM, kritik, ani ve geçici kesintileri yakalamak için düşük gecikmeli bir izleme API'si olarak tasarlanmıştır. Buna karşılık, katılım oranı düşük gecikmeli raporlama gerektirmez ve kritik, ani ve geçici bir kesinti değildir. Katılım oranlarıyla ilgili endişeler, alıcıların tarayıcı üzerinden araştırma yapmasıyla değil, alıcıların birlikte çalıştığı satıcılar tarafından en etkili şekilde yanıtlanır.

Ayrıca, iptal edilen açık artırmalar oldukça yaygın olduğundan, tarayıcı her iptal edilen açık artırmadan RTM raporu oluşturacak olursa gerçek kesintilerle ilgili RTM raporları gizlenebilir.
Belgeler
Açıklama		 PA API açıklayıcısında, tek seferlik kimliğin UUID dizesi olması gerektiğini belirten ancak aslında bir promise döndüren bir doküman tutarsızlığı raporu. Burada konuyla ilgili bir açıklama sunulmaktadır.
Dondurulmuş
Bağlam		 Dondurulmuş bağlamla çalışırken (1) paketleme, (2) harici kitaplıklar ve (3) desteklenmeyen veri türleriyle ilgili sorunları ve zorlukları gidermek için hangi seçenekler kullanılabilir? Bu soruya yanıtı burada bulabilirsiniz.
Özellikler Private Aggregation API'ye genel bir contributeToHistogramOnEvent işlemi eklendi. Sonuç olarak, PA API'deki tanım aşırı yüklenmiş bir işlem haline geldi ve Web IDL işlemleri "arayüzde, kısmi arayüzde [...] aşırı yüklenmemeli" olduğundan bu tanım artık geçersizdir. Bu sorun, her iki API'de de benzer değişiklikleri birleştirirken PA API ve Private Aggregation spesifikasyonları arasında geçici bir tutarsızlığa işaret etmektedir. Bu sorunu gidermek için bir pull isteğinde bulunduk.
İlgi Alanı Grupları Bir kampanya durdurulduğunda ilgi alanı grubunun (IG) teklifli sistem katılımını sonlandırmak için önerilen ve kaynak tasarrufu sağlayan yöntem hakkında yardım isteme. Sunabileceğimiz bazı öneriler:

En düşük gecikmeye, en az kalıcılığa ve en az kaynak serbest bırakma mekanizmasına sahip olanın, generateBid()'yi teklif vermeyi durdurması için bilgilendirmek amacıyla gerçek zamanlı teklif sinyallerini kullanmak olduğuna inanıyoruz.

Daha az kaynak kullanan ikinci seçenek, gerçek zamanlı teklif sinyalleri yanıtında söz konusu IG için negatif bir öncelik ayarlamaktır. Bu, generateBid()'un çağrılmasını bile engeller.

Daha da az kaynak kullanan üçüncü seçenek, reklamları IG'den kaldırmaktır. Reklam içermeyen IG'ların generateBid() çağrılmaz.

Daha da az kaynak kullanan dördüncü seçenek, biddingLogicURL'ı IG'den kaldırmaktır. Bu noktada IG, yeniden etkinleştirilmek üzere güncellenebilir/yeniden bağlanabilir.

Diğer seçenekler, leaveAdInterestGroup() veya clearOriginJoinedAdInterestGroups() aracılığıyla ya da IG'nin süresi dolduğunda IG'den ayrılmayla ilgilidir.

Yukarıda belirtildiği gibi, farklı seçeneklerin farklı gecikme etkileri ve kaynak tüketimi vardır. Reklam teknolojileri, belirli kullanım alanları için en iyi dengeyi sağlayan seçeneği belirleyebilir.
Kitleler Oluşturulan kitlelerde mantıksal işlemler çalıştıracak bir mekanizma isteğinde bulunma (ör. IG A ve B'nin kesişim noktasını hedefleme) PA API ile aynı sitedeki kitleler üzerinde mantıksal işlemler yapmak artık mümkün. Farklı sitelerdeki kitlelerin mantıksal işlemleri, gizlilik modelimizde açıklandığı üzere gizlilik nedeniyle şu anda desteklenmemektedir. Bu alanda araştırma yapmaya devam ediyoruz ve süreç boyunca güncellemeleri paylaşacağız.
Özellik İsteği TLS'nin önceden bilinmesini gerektiren ek tekliflerle ilgili kısıtlamanın kaldırılmasına yönelik öneri. Şu anda bu öneriyi burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.
Chrome'da 3 PC'ye yönelik yaklaşım güncellendi PA API gibi Özel Korumalı Alan API'leri, tüm Chrome kararlı sürüm kullanıcıları tarafından genel olarak kullanılabilir mi yoksa API'ler (veya API'lerin bir alt kümesi) yalnızca 3PC'yi reddeden kullanıcılar tarafından kullanılabilir mi? Kullanıcıların üçüncü taraf çerezlerini reddetme kararının, Chrome kararlı sürümündeki Özel Korumalı Alan API'lerinin kullanılabilirliğini etkilemesini istemiyoruz.
Gelişmiş Sinyalleşme TLS'nin PA API açık artırması yapmayı planlayıp planlamadığını belirten bir işlev ekleme planı var mı? Bu işlev için destek sunup sunmayacağımızı değerlendiriyoruz. Zaman çizelgesi hakkında daha fazla bilgiyi uygun olduğunda paylaşacağız. Bu taleple ilgili ek geri bildirimlerinizi bekliyoruz.
Anlaşma Kimliği Anlaşma kimliği teklifindeki KV sunucusu şartının pahalı ve zaman alıcı bir sunucu tarafı işlemi olabileceğiyle ilgili endişe. Anlaşma kimliği teklifi, SSP'lerin PA açık artırmaları sırasında anahtar/değer sunucusundan seçili anlaşma kimliklerinin meta verilerini sorgulamasına olanak tanır. Böylece, anlaşmayla ilgili tüm meta verilerin cihaza önceden yüklenmesi gerekmez. Bu teklif, SSP'lerden gelen talepler doğrultusunda geliştirilmektedir. Ek ekosistem geri bildirimlerinizi buradan paylaşabilirsiniz.

Anahtar/değer sunucusunu ayarlamak için çalışma gerektiğinin farkındayız ancak genel olarak bunun reklam teknolojisi şirketleri için net bir avantaj olduğunu düşünüyoruz. Bu süreci kolaylaştırmak için geri bildirimlerinizi ve önerilerinizi bekliyoruz.
IG'ler arası sıklık sınırı PA API üzerinden IG'ler arası sıklık sınırı isteği. IG'ler arası sıklık sınırlamasının, çözüm üretemediğimiz zorlu gizlilik özellikleri vardır.

Bu özellik sizin için önemliyse ek geri bildirimlerinizi bekliyoruz.
Anlaşma kimlikleri ve lisans kimliği raporlaması Toplu raporlamaya anlaşma veya koltuk kimlikleri alma özelliğini talep etme. Burada üzerinde çalıştığımız raporlama kimliği işlevleri, anlaşma ve koltuk kimliklerinin raporlanmasını mümkün kılacaktır.

selectedBuyerAndSellerReportingId, reportResult() işlevine sağlanır.Bu nedenle, en kolay raporlama yöntemi etkinlik düzeyinde raporlamadır (ör. anlaşma kimliğini sendReportTo() işlevine iletilen URL'ye kodlama). Toplu raporlama kullanılacaksa bu da yapılabilir.

Raporlama kimliği özelliği şu anda Chrome'un Mevcut Ürün kanalı trafiğinin% 10'unda kullanılmaktadır. Özelliği %100'e kadar genişletmeyi değerlendiriyoruz.
İlgi Alanı Grupları Hem IG seçiminde hem de değerlendirmede aynı öncelik sırasını kullanın ve bu öncelik sırasını tüm değerlendirme modlarında kullanın. Bu konuyu şu anda buradan tartışıyoruz ve ek geri bildirimler bekliyoruz.
İlgi Alanı Grupları Özel Korumalı Alan API'sinin kullanımını artırmak için kitle etkinleştirme ve yetkilendirmenin kullanılması önerisi. Çeşitli paydaşlardan gelen bu talebin farkındayız ve bir çözüm üzerinde çalışıyoruz.

Ekosistemden ek geri bildirimler bekliyoruz.
İlgi Alanı Grupları PA API IG'leri oluşturmayla ilgili zorluklar, özellikle birden fazla satın alma işlemi için veya yayıncılar adına hareket ederken yetkilendirme ve sahiplikle ilgilidir. Birden fazla paydaştan daha gelişmiş IG yetkilendirmelerini destekleme isteği aldık ve SSP'lerin bu sürece katkıda bulunan katma değerini görüyoruz.

Farklı tarafların kitle genişletme sürecine katılmasına olanak tanıyan en iyi çözümü bulmak için araştırma yapıyoruz. Ekosistemden ek geri bildirimler bekliyoruz.
İstemci tarafı performansı Altyapı maliyetini ve gecikmeyi optimize etmek için trustedBiddingSignals'in istemci tarafında önbelleğe alınmasını kolaylaştırma konusunda yardım isteme. Bu konuyu şu anda buradan tartışıyoruz ve ek geri bildirimler bekliyoruz.

Protected Auction (B&A Hizmetleri)

Geri bildirim teması Özet Chrome Yanıtı
Anahtar/Değer Hizmetleri Tarayıcıdan satıcının KV sunucusuna gönderilen istekler nasıl toplu olarak işlenir? Satıcılar için tarayıcıdan gelen istek GET mi yoksa POST mu şeklinde olur? Ayrıca, k-anonimlik koşullarıyla ilgili bazı açıklamalara ihtiyaç var. 1. sürümde Chrome, isteğin sorgu parametrelerindeki sinyallerle trustedScoringSignalsURL'ü almak için Satıcı'nın KV hizmetine bir GET isteği gönderir. Parametreler hostname, renderUrls, adComponentRenderUrls ve experimentGroupId'ı içerir. Şu anda reklam öğesi taraması için ek bilgiler göndermek üzere bazı uzantılarla denemeler yapıyoruz ancak bu henüz kullanıma sunulmadı.

maxTrustedScoringSignalsURLLength 0 olarak ayarlandığında Chrome, tüm sinyalleri tek bir istek halinde gruplandırabilir (sunucudaki URL uzunluğu sınırını aşabilir) ancak bu garanti edilmez. Chrome şu anda, birbirinden 10 ms içinde gönderilmeye hazır olan istekleri aynı gruba dahil etmeyi tercih ediyor. Ancak bu işlemin nasıl optimize edileceğini araştırıyoruz.

trustedScoringSignals ile çalışırken Chrome'un önbelleğe alma üstbilgilerine uyduğunu unutmayın. Stale-While-Revalidate "Cache-Control" gibi üstbilgiler, Chrome'un önbelleğe alınmış kopyayı kullanmasına (ve bir sonraki açık artırma için önbelleği güncellemesine) izin vererek ortalama gecikmeyi azaltabilir ve sinyal getirme işlemini kritik yoldan etkili bir şekilde kaldırabilir.

Son olarak, k-anonimlikle ilgili olarak açıklayıcı makalenin ilgili bölümü güncel değil. Güvenilir sinyal URL'lerinin başlangıçta k-anonim olması gerekiyordu ancak bu şart kaldırıldı. Bu cümleyi açıklama metninden kaldıracağız.
B&A Hizmetleri B&A'nın en son sürümüne yükseltme işlemi uzun sürer. Daha hızlı derleme süreleri veya önceden derlenmiş görüntüler faydalı olacaktır. Reklam teknolojileri, ikili dosyaları kendileri derleyebilir ve sağlanan karma oluşturma işlemlerini kullanarak doğrulayabilir. Gelecekte önceden oluşturulmuş yapıları sunma veya derleme sürelerini iyileştirme olasılığını araştıracağız.
API Özelliği İsteği Yerel geliştirme ve test sürecini kolaylaştırmak için Teklif Verme ve Açık Artırma Hizmetleri (B&A) derleme komut dosyaları, kapsayıcı görüntüleri ve çağırma araçları için macOS uyumluluğu isteği. Şu anda amd64'ü destekliyoruz. Bu, desteklenen bulut platformlarına (GCP ve AWS) dağıtım için yeterlidir. Gelecekte diğer mimariler için destek sunmayı araştırabiliriz.
AWS IAM rollerinin oluşturulması, üretim derlemeleri için bir şart mı? Evet, uygun izinler ve koordinatörlerle iletişim için IAM rolleri gereklidir. Anahtarlar, burada açıklandığı gibi cihazda oluşturulan ProtectedAudienceInput şifre metninin şifresini çözmek için kullanılır. Ayrıca, bu rollerin aynı koordinatörlerle üretim derlemelerinin sunucu/TEE doğrulamasını geçmesi gerekir. Bu konu self servis kılavuzumuzda daha ayrıntılı olarak ele alınmıştır.
B&A Bayrakları Mevcut B&A işaretlerinin tanımlarının dokümanda listelenmesini talep ediyoruz. Şu anda bu tanımlar Terraform kodunda, cc dosyalarında ve proto dosyalarında yer alıyor. Ancak reklam teknolojisi uzmanları, dağıtımların nasıl özelleştirileceğini anlamak için bu işaretlerle ilgili dokümanları doğru bilgi kaynağı olarak kullanabilir. Terraform işaretlerinin açıklamalarını belgeleme olasılığını araştırıyoruz. Buradan ek geri bildirimlerinizi bekliyoruz.
AWS
Bidding Hizmeti		 AWS'deki teklifli sistem hizmeti, varsayılan günlük kaydı davranışı ve yapılandırması hakkında bilgi edinmek istiyorum. TEE'deki teklifli sistem hizmetleriniz (ör. teklifli sistem hizmeti) için hata ayıklama işlemi yapmak istiyorsanız Reklam Teknolojisi izinli hata ayıklama özelliğini kullanmanızı öneririz. Bu sayede, ayrıntılı günlük kaydını etkinleştirebilir ve hata ayıklamanıza yardımcı olmak için belirli test isteklerinizle ilgili istek/yanıt verilerini doğrudan istemcinizden yakalayabilirsiniz.
TEE K/V
Belgeleri 		Geliştirici sitesinde belirtildiği gibi TKV yaptırımının başlangıcı hakkında açıklama talep ediyorum. TEE'lerin kullanılmasını zorunlu kılmadan önce yeterli süre önceden bildirim göndereceğiz. O zamana kadar anahtar/değer sinyalleri için kendi sunucunuzu kullanmaya devam edebilirsiniz.
B&A Test ve Analizi Karşılaştırmalı analiz ve testler pahalı olmaya devam ediyor ve üretime hazır görünmüyor. Konuyu daha ayrıntılı bir şekilde inceleyebilmemiz için maliyet analizi ve üretime hazır olma durumunun değerlendirilmesine yol açan faktörler hakkında daha fazla bilgiye ihtiyacımız var.
Güvenilir Sunucu Optimizasyonu Bileşen satıcılarına özgü parametreleri, değeri için bir JSON dizesi kullanılarak tek bir inputsPerSeller parametresinde birleştirme önerisi. Bu teklifi tartışıyoruz ve buradan ek geri bildirimlerinizi bekliyoruz.
Güvenlik B&A kullanılarak TKV'den kaynaklanan güvenlik riskleri nasıl azaltılır? TKV'ye yapılan harici aramaları engellemek mümkündür. Bu özellik şu anda GCP'de tam olarak desteklenmekte ve yapılandırılabilir.

AWS için, daha önce bu özelliği etkinleştiren AWS App Mesh'in desteğinin sonlandırılması nedeniyle ek destek geliştirilmesi gerekiyor. Buradan ek geri bildirim gönderebilirsiniz.
B&A Hizmetleri B&A optimizasyonu için HTTP akışının değeriyle ilgili anlatım/iletişim konusunda netlik talep etme. Özel Korumalı Alan, kullanmayı tercih eden reklam teknolojilerinin gecikmesini azaltmak için B&A verilerini aktarırken akış özelliklerini destekler. Karma modda isteğe bağlı performans optimizasyonudur.
Teklif öncesi Ekosistem için PA API B&A özelliklerini etkinleştirmek üzere açık kaynak Prebid kitaplığına katkıda bulunmayla ilgili güncelleme isteği. Mart 2025'te Chrome, B&A herkese açık yol haritasında belirtildiği gibi Prebid tercihli optimizasyonu kararlı sürümde kullanıma sundu (Mart 2025'e bakın ).
Trafik Şekillendirme IG'lerin ne zaman etkinleştirildiğini daha iyi anlamak ve bağlama dayalı yanıtta "teklif verme niyetini" iyileştirmek için B&A tarafından alınan bağlama dayalı sinyallerin günlüğe kaydedilmesini sağlayan mekanizmalar için istek. Bu sayede, "boş trafik"ten (trafik şekillendirme) kaçınmak için ağ kaynaklarının daha iyi kullanılması sağlanır. Şu anda bir teklifi burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.
Belgeler
Açıklama		 B&A test entegrasyonu kurulumunda "Hizmet/Vsock proxy'ye ulaşılamıyor" hatasıyla ilgili açıklama gerekli. Bunun nedeni minimum bellek gereksinimleridir.AWS yapılandırma açıklamaları bu koşulu yansıtacak şekilde güncellendi.

Dijital reklamları ölçme

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

Geri bildirim teması Özet Chrome Yanıtı
Gerçek Zamanlı Veriler Gerçek zamanlı verilerin olmaması sektördeki herkesi etkiler. Gerçek zamanlı verilerin gecikmesi reklamverenler için ciddi bir sorundur. Alıcılara kitlelere ulaştıklarını kanıtlayabilecekleri tek yer Google Analytics olduğundan alıcılar Google Analytics'in bulunduğu platformlara geçer. Attribution Reporting API'nin (ARA) bir parçası olan gerçek zamanlı veri gecikmeleri, reklam teknolojilerinin siteler arasında kullanıcıları izlemek için etkinlik düzeyindeki raporları kullanma kabiliyetini azaltmak amacıyla gizlilik koruma mekanizmaları olarak uygulanır. Ancak ARA, etkinlik düzeyindeki raporların minimum 1 saatlik bir rapor aralığına sahip olmasına ve toplu raporların reklam teknolojisine gecikme olmadan anında gönderilme seçeneğine sahip olmasına izin vererek ilişkilendirme raporlarının yayınlanma şekli konusunda esneklik sağlar.
API Kullanımı Özellikle web'den web'e ve web'den uygulamaya ilişkilendirmeyi paralel olarak çalıştırırken, web uygulamaları arası ilişkilendirme akışının doğru yapılandırmasıyla ilgili onay isteği. Web'den web'e ve web'den uygulamaya kampanyalar paralel olarak çalıştırıldığında, reklam teknolojisi, çift sayımı önlemek için her kaynağı veya tetikleyiciyi kaydettirmek üzere yalnızca bir platform seçmelidir. Web kaynakları ve tetikleyiciler doğru şekilde atanmış olduğu sürece hem web'den web'e hem de web'den uygulamaya ilişkilendirme gerçekleştirebildiğinden, mümkün olduğunda işletim sistemini (OS) kullanmanızı önemle tavsiye ederiz. Bu, kaynaklar için Attribution-Reporting-Register-OS-Source üstbilgisiyle ve tetikleyiciler için Attribution-Reporting-Register-OS-Trigger üstbilgisiyle yanıt vermeniz gerektiği anlamına gelir.

Attribution-Reporting-Support başlığı, Chrome ve/veya Android düzeyinde destek olup olmadığını belirlemek için kullanılabilir. Attribution-Reporting-Info başlığı, istekte Attribution-Reporting-Support başlığı olmadığında kullanışlıdır. Bu durumda tarayıcı, platform kaydı kararını kullanıcının cihazındaki platform desteğinin kullanılabilirliğine göre verir.
API Spesifikasyonu Attribution Reporting API tarafından ayarlanan Attribution-Reporting-Support HTTP istek başlığı ve başlığın platformdan bağımsız olarak hem web hem de işletim sistemi anahtarları içermesi amaçlanıp amaçlanmadığı hakkında açıklama istendi. Attribution-Reporting-Support başlığı, sunucuların spesifikasyona uygun bir yapılandırılmış başlık ayrıştırıcı kullandığından emin olmak için tarayıcı tarafından "GREASE" parametrelerinin eklenmesine tabidir. Bu başlık için yalnızca yapılandırılmış sözlük anahtarları yorumlanmalıdır. Değerler ve parametreler şu anda kullanılmamaktadır. Örnek için buraya göz atın.
Üçüncü taraf cihaza dayalı raporlama Reklam kampanyalarında ARA ile 3. taraf çerezleri arasındaki ölçüm tutarsızlıklarını giderme konusunda yardım isteme. ARA, tutarsızlıkları gidermek ve hata ayıklamak için kullanılabilecek iki tür hata ayıklama raporunu destekler. İlişkilendirme başarısı hata ayıklama raporları, ARA sonuçlarını diğer ölçüm teknolojilerinin sonuçlarıyla kolayca karşılaştırmak için kullanılabilir. Ayrıntılı hata ayıklama raporları ise daha fazla bilgi edinmek ve ilişkilendirme kayıtlarındaki olası sorunları gidermek için kullanılabilir.
API Kullanımı ARA'yı test ederken belirli sorunlar tespit edildi: Verilerin kirli olmasına ve kampanya optimizasyonunun esnek olmamasına yol açan yetersiz ayrıntılı raporlama, küçük reklamverenleri hariç tutan yüksek eşikler ve tutarsız temel performans göstergeleri nedeniyle kampanyaları karşılaştırma zorluğu. ARA, reklam teknolojilerinin belirli ölçüm kullanım alanlarına ulaşmak için özelleştirebileceği birden fazla parametre sunarak esneklik sağlar. Etkinlik düzeyindeki raporlar, reklam teknolojilerinin raporlama dönemlerini, alabilecekleri rapor sayısını ve ölçmek istedikleri tetikleyici verileri özelleştirmelerine olanak tanıyan esnek etkinlik düzeyinde raporlamayı destekler. Bu da gürültünün verileri üzerindeki etkisini değiştirebilir ve farklı kullanım alanlarına ulaşmalarına olanak tanıyabilir. Benzer şekilde, toplu raporlarda reklam teknolojilerinin yapılandırmalarını özelleştirmenin farklı yolları vardır. Örneğin, izledikleri boyutların sayısı, toplu işleme sıklıkları ve katkı bütçesinin kullanımı, gürültünün etkisini değiştirmek ve farklı kullanım alanları elde etmek için kullanılabilir.
API Spesifikasyonu ARA'nın üçüncü taraf çerezlerine bağımlılığıyla ilgili soru. Özellikle de bu üçüncü taraf çerezlerini gerektiren bir test aşamasında olup olmadığıyla ilgili. ARA, üçüncü taraf çerezlerinden bağımsız olarak etkinleştirilir ancak ARA geçişli hata ayıklama raporlamasının ARA sonuçlarını çerez tabanlı ilişkilendirme sonuçlarıyla karşılaştırmasına izin vermek için üçüncü taraf çerezlerinin etkinleştirilmesi gerekir.
API Kullanımı ARA'yı kullanarak eski Android sürümlerinde (11, 12 ve 13) uygulamadan web'e ilişkilendirme için kaynak kaydetme hakkında soru. ARA şu anda Android S ve sonraki sürümlerde (12 ve üzeri) desteklenmektedir.
API Kullanımı ARA etkinleştirme oranları ve dağıtım ayrıntıları için istekte bulunun. Yanıtımız önceki çeyreklerden farklı değil:

"Bu bilgileri ekosistemle paylaşmayı planlamıyoruz. Geliştiricilerin, Özel Korumalı Alan API'lerinin kullanılabilirliğini tahmin etmek için kodlarının dağıtıldığı API'leri çağırmaları önerilir."
API Kullanılabilirliği ARA etkinleştirildiğinde 3PC'ler etkin mi yoksa devre dışı mı? ARA, kullanıcıların tarayıcısında etkinleştirildiğinde kullanıcıların çerez ayarları üzerinde herhangi bir etkisi olmaz. ARA'nın etkin olması ve kullanıcının çerezleri etkinleştirmesi veya devre dışı bırakması mümkündür.
Raporlama "Attribution-reporting-support" başlığında alabileceğimiz önceden tanımlanmış bir değer listesi var mı? Kılavuzumuzda belirtildiği gibi, değer bir ek açıklamalı başlık sözlüğüdür. Bu sözlüğün şu anda tanımlanmış tek semantik özelliği, işletim sistemi ve web anahtarlarının varlığı veya yokluğudur. Başlığın diğer tüm bölümleri yoksayılmalıdır. Diğer bir deyişle, ayrıştırma işlemi için basit dize eşleştirme değil, ek açıklamalı başlık ayrıştırıcı kullanılması gerekir.

Aggregation Service

Geri bildirim teması Özet Chrome Yanıtı
Özellik İsteği Toplama Hizmeti için özellik istekleri:

Sunucudan sunucuya entegrasyonlar, cihazlar arası ölçüm, çoklu dokunma ilişkilendirme ve katkı raporlamasını kolaylaştırma, çok kanallı ilişkilendirme ve gelişmiş makine öğrenimi optimizasyon döngüleri (ör. Özel Model Eğitimi).		 Bu istekleri değerlendiriyoruz ve uygun olduğunda daha fazla bilgi paylaşacağız.

Bu isteklerin öncelikli olup olmadığı konusunda ekosistemden ek geri bildirim almaktan memnuniyet duyarız.
Özellik İsteği Toplama hizmet grubunu güncellerken sıfırlamayla ilgili endişeleri azaltmak için EBS delete_on_termination parametresinin terraform ortamında True olarak ayarlanması istendi. Bu isteği değerlendiriyoruz. Ayrıntılar hazır olduğunda paylaşacağız.

Bu isteğin öncelikli olup olmadığıyla ilgili ek geri bildirimleri buradan paylaşabilirsiniz.
Belgeler
Açıklama		 Nelerin değiştirilebileceği (ör. izleme eşikleri) ve nelerin değiştirilmemesi gerektiği hakkında rehberlik isteğinde bulunma. Toplama hizmeti için kullanılabilen özelleştirmeler hakkında ek dokümanlar ve rehberlik yayınlamayı değerlendiriyoruz.
Dağıtım Yeni dağıtımın bazel komutunda başarısız olmasıyla ilgili açıklama isteğinde bulunma. Dağıtım, ortamda kullanılan bazel sürümü nedeniyle başarısız olabilir.

Belgelendirme, Terraform hatalarında hata ayıklama işlemini kapsayacak ve gerekli bazel sürümünü belirtecek şekilde düzenlenecek.

Private Aggregation API

Geri bildirim teması Özet Chrome Yanıtı
API Kullanımı Bildirilen Paylaşılan Depolama alanı sınırlamaları nedeniyle olası veri kaybı, karmaşık toplama hizmeti izin listeleri gerektiren yüksek kardinaliteyle ilgili zorluklar (önerilen joker karakter) ve toplama hizmetinin "yinelenen veri yok" kuralı nedeniyle yavaşlatılmış test gibi bazı uygulama zorluklarıyla ilgili rehberlik isteği. Shared Storage sınırlamalarına gelince, 20 katkı sınırı (ayrıntılı bilgi burada) aylık değil, yürütme başınadır. Ayrıca, API çağıranlar bu sınırı geçersiz kılabilir. Bu sınır, raporlama aracını sınırlamak için değil, raporların toplama hizmetinde işlenme maliyetini yönetmeye yardımcı olmak için uygulanır.

Yıldız işareti içeren sorgularla ilgili olarak bu isteği değerlendiriyoruz. Ayrıntılar hazır olduğunda paylaşacağız.

"Yinelenen öğe yok" kuralı ile ilgili olarak, testleri etkinleştirmek için bu kuralı atlamak amacıyla hata ayıklama modunu geçici olarak destekliyoruz. Bu konu burada daha ayrıntılı olarak açıklanmıştır.
Filtreleme kimliği ve paketleri Toplama hizmetine, iki ayrı toplama çalıştırmasında iki farklı filtreleme kimliğiyle aynı paketi istemek mümkün müdür? Yani filtreleme kimliği, alanların ek bir bölümlenmesi olarak işlev görebilir mi? Evet, bu özellik desteklenir. Toplama işlemi yapılırken yalnızca iş parametrelerindeki listeyle eşleşen bir filtreleme kimliğine sahip katkılar işlenir, geri kalanlar ayrı çalıştırmalarda işlenmeye hazır kalır.
Çok noktalı ilişkilendirme Çoklu Dokunma İlişkilendirme (MTA) uygulamasıyla ilgili açıklama talepleri:

1) Toplama değeri 2^16'yı aşmıyorsa katkıların sayısıyla ilgili bir sınır var mı?

2) Belirli bir bağlam için depolanabilecek benzersiz toplama anahtarlarının (paketler) sayısıyla ilgili bir sınır var mı?

3) MTA'da olduğu gibi her kullanıcı aracısının (tarayıcı) benzersiz bir toplama anahtarı olduğunda Aggregation Service özet raporlarını nasıl işler?		 1) Varsayılan katkı sınırları belirledik ancak API çağıranın bunları geçersiz kılma seçenekleri vardır. Bu seçenekler burada açıklanmıştır. Sınırların amacı, API çağırıcılarının toplama hizmetinde raporların işlenme maliyetini yönetmesine yardımcı olmaktır.

2) Böyle bir sınır yoktur ancak reklam teknolojileri, burada daha ayrıntılı olarak açıklandığı gibi sinyal/gürültü oranını iyileştirmek için toplama anahtarlarının ayrıntı düzeyini dikkate almalıdır.

3) Lütfen bu yönergeye, özellikle de yukarıda 2. maddede belirtilen sinyal-gürültü oranı yönergesine bakın.

Gizli İzlemeyi Sınırlama

User-Agent Azaltma/User-Agent İstemci İpuçları

Geri bildirim teması Özet Chrome Yanıtı
Özellik İsteği Sunucuların içerik uyarlaması, güvenlik ve analizler için otomatik trafiği tanımlamasına olanak tanıyacağından, User-Agent Client Hints'a (UA-CH) Sec-CH-UA-Robot eklenmesini talep edin. Bu, diğer standartlar gruplarında tartışılan önemli bir kullanım alanıdır (daha fazla bilgi için buraya bakın). İlgili tarafların geri bildirimlerini paylaşarak bu sürece katılmalarını öneririz. Ancak HTTP istek başlıklarının otomatik trafik tarafından kolayca değiştirilebildiği göz önüne alındığında, UA-CH'nin uygun bir çözüm olmayabileceğini düşünüyoruz.

IP Protection (eski adıyla Gnatcatcher)

Geri bildirim teması Özet Chrome Yanıtı
IP Adresi Gizliliği IP adreslerinin Google'ın kullanımına açık bırakılması, belirtilen gizlilik hedefleriyle çelişir. Google, IP Koruması aracılığıyla verileri anonimleştirdiğini söylese de kullanıcıların IP Koruması'nı kullanabilmek için Chrome'da oturum açması gerekir. Bu nedenle Google, kullanıcıların kimliklerini öğrenir. Giriş yapmanın nedenleri, sahtekarlık ve kötüye kullanımla mücadele amaçlıdır. Bu nedenlerin başında, proxy'lere erişimi hız sınırlamasıdır.

Ayrıca, kimlik doğrulama şartı bağlamında kullanıcıların gizliliğini korumak için jeton tasarımımız kör imzalıdır. Yani, giriş sırasında verilen jeton, proxy sırasında kullanılan jetondan farklıdır. Bu nedenle, verilen jetonlar daha sonra kullanıcının Google kimliğine bağlanamaz. Bu, sahtekarlıkla mücadele amacıyla kimlik doğrulama şartına rağmen, kullanıcının trafiği gizli modda proxy'den geçtiğinde Google'ın kullanıcının kim olduğunu bilmediği anlamına gelir.
IP Adresi Gizliliği IP'lerin kullanılması yanlış bir adımdır. Çerezler gibi tarayıcıdan silinemezler ve kullanıcılar çerezlerde olduğu gibi aynı şeffaflık denetimlerine sahip değildir. Çerezler kullanımdan kaldırılırsa sektör, gizlilikten ziyade kendini korumaya öncelik vererek alternatif bir çözüm olarak IP'leri kullanmaya başlayacaktır. Chrome, bir platform olarak kullanıcılara web'de gezinme deneyimlerini iyileştiren özellikler sunmayı amaçlar. Gizli modda gezinmeyi tercih eden Chrome kullanıcıları için bu, üçüncü taraf bağlamlarında IP adresi bilgilerinin kullanılabilirliğini sınırlandırarak siteler arası izlemeye karşı gelişmiş korumalar sunmak anlamına gelir.
Maskelenmiş Alan Listesi Maskelenmiş Alan Listesi'ndeki (MDL) seçim ölçütleri nedir? Chrome, MDL'de yer alması ve bu nedenle üçüncü taraf bağlamında maskelenmiş IP adresleri alması gereken alanları belirlemek için ölçütler geliştirmiştir. Google, diğer web tarayıcılarında da işbirliği yapan, internet gizliliği alanında lider bir kuruluş olan Disconnect.me ile iş ortaklığı yaptı. Chrome, Chrome'un belirlediği ölçütlere uyan alanları belirlemek için Disconnect.me'den yararlanır. Ayrıca Chrome, kararlı ve yüksek entropili web API'lerinden tutarlı çıkışlar sağlayan ve bu nedenle yüksek entropili olasılıksal tanımlayıcı oluşturmak için kullanılabilen, yaygın olarak kullanılan JavaScript işlevlerini tanımlamak için bir metodoloji geliştirmiştir. Bu işlevler daha sonra üçüncü taraf bağlamında web sitelerine yüklendiğinde algılanır. Bu da, MDL'nin bir parçası haline gelen ve bu nedenle proxy'ye yönlendirilen bu özelliklere sahip komut dosyalarını sunan alanların bir listesini oluşturur. Bu API kötüye kullanım kalıplarını arayan algılama ardışık düzeni, Google'ın kendi alanları da dahil olmak üzere tüm alanları dikkate alır.
Sahtekarlığı Önleme Olasılıksal Açıklama Jetonları (PRT'ler) ile ilgili geri bildirimde, önerilen 24 saatlik açıklama gecikmesi ve açıklama oranlarının gerçek zamanlı sahtekarlık tespitini engellediği belirtiliyor. Daha kısa gecikmeler (1 saatlik gecikme) ve daha yüksek ücretler (en az iki haneli) talep edin. Diğer öneriler arasında risk sinyallerine (VPN'ler, otomatik tarayıcılar) göre farklı oranları etkinleştirme ve belirli jetonların hedeflenen şekilde gösterilmesine izin verme yer alır. Görüştüğümüz geliştiricilerin çoğu, müşterilerine saatlik raporlar sunuyor ve birkaçı IP engellenenler listelerini gün içinde güncelliyor. Daha kısa bir gecikme süresi, daha sık güncelleme yapılmasına olanak tanır ve bir saatten kısa bir süre içinde saatlik istatistiklerde IVT ölçümünü yeniden etkinleştirir. Ancak bu, kullanıcıların yeniden tanımlanabilir olma olasılığını da artırır. Ekosistem çalışmalarına ve paydaşlardan gelen geri bildirimlere dayanarak gecikme sürelerini azaltmayı ve gösterme oranını değiştirmeyi denemeye açığız. Burada ek geri bildirimlerinizi bekliyoruz.
Maskelenmiş Alan Listesi Reklamcılık kullanım alanı olmamasına rağmen alanın MDL'ye dahil edilmesiyle ilgili soru. Bunun, IP adreslerine dayalı profiller oluşturmak için "IP köprüleme"yi etkinleştirebileceği endişesi. Liste tabanlı yaklaşımımız için bir itiraz sürecinin uygulanmasının öneminin farkındayız. İtirazlar, şirketlerin MDL'deki alanlarının dahil edilme ölçütlerini karşılamadığı ve kaldırılması gerektiği yönünde hak talebinde bulunmasına olanak tanır. Bu sayede, söz konusu alan, gizli modda üçüncü taraf bağlamında kullanıcıların orijinal IP adreslerini almaya devam edebilir.

Chrome kararlı sürümünde gizli modda IP Koruması'nın kullanıma sunulmasından önce alan adının sahiplerine itirazda bulunmaları ve karar almaları için yeterli süre tanımak amacıyla itiraz sürecini başlattık.

İtiraz süreciyle ilgili daha fazla bilgiyi burada bulabilirsiniz.
Maskelenmiş Alan Listesi Yayıncıların, iş ortaklarının MDL'ye dahil edilmesinin sonuçlarını araştırdığına dair geri bildirim. IP Koruması Açıklayıcısı'ndaki Coğrafi IP hükümlerinden güvence aldılar. Chrome, coğrafi konuma dayalı kullanım alanlarını desteklemenin önemini kabul eder. Proxy, ülke de dahil olmak üzere kullanıcının kaba konumunu temsil eden IP adresleri atar. Daha fazla bilgiyi IP Coğrafi Konumlandırma Açıklaması'nda bulabilirsiniz.
Maskelenmiş Alan Listesi MDL ile ilgili olarak ülke düzeyinde hedeflemenin hâlâ kullanılıp kullanılamadığını soran soru. Chrome, coğrafi konuma dayalı kullanım alanlarını desteklemenin önemini kabul eder. Proxy, ülke de dahil olmak üzere kullanıcının kaba konumunu temsil eden IP adresleri atar. Daha fazla bilgiyi IP Coğrafi Konumlandırma Açıklaması'nda bulabilirsiniz.
Sahtekarlık Algılama IP Koruması'nın sahtekarlık algılama sistemleri üzerindeki etkisiyle ilgili endişeler. Kullanıcılar proxy IP'lerini mi yoksa bir üstbilgi mi görür? SSP'ler ve DSP'ler belirli bir kullanım için aynı proxy IP adresini görür mü? Tutarsızlıklar, sahtekarlık algılamayı ve OpenRTB'yi etkileyebilir. IP koruması etkinken gizli modda gezinen ve MDL'deki alanlara istek gönderen kullanıcılar, tanımlanmış bir coğrafi feed'e dayalı bir proxy IP adresi alır. Kuruluşlar, proxy'de ek bir üstbilgi olarak iletilmesini isteyebilir. Bu durumda, orijinal IP'lerin küçük bir örneği bir gecikme süresinden sonra gösterilebilir. Birçok STP'nin, sunucu tarafı teklif isteklerinde proxy IP adreslerini talep iş ortaklarına ileteceğinden şüpheleniyoruz ancak kazanan TTP'lerin gösterim sırasında aynı proxy IP adresini görmesi garanti edilmez.
Sahtekarlık Algılama IP coğrafi konumlandırma dosyasının güncellenme sıklığı, sahtekarlık amaçlı davranış ve PRT'lerin raporlanmasıyla ilgili ayrıntıların güncellenme zamanlaması ve reklam teknolojisinin sahtekarlık amaçlı etkinlikleri nasıl tespit etmesi gerektiğiyle ilgili sorular. Proxy IP adreslerinin ve eşlenen coğrafi bölgelerinin listesi ile birlikte PRT'ler hakkındaki açıklama yayında. IP adresleri zaman içinde değişeceğinden, güncelleme ve değişiklikler için bu dosyayı düzenli olarak kontrol etmenizi öneririz. Kötüye kullanımı bildirmek için kullanılacak herkese açık e-posta adresi, kullanıma sunulmasına yakın bir zamanda duyurulacaktır.
Coğrafi konum Proxy'ler için kullanılan IP adreslerinin herkese açık listesini isteme. IP adreslerini IP Koruması için yaklaşık konumlarla eşleştiren dosyayı buradan indirebilirsiniz. Bu dosyanın düzenli olarak güncellendiğini lütfen unutmayın.
API Kullanımı IP korumasının varsayılan olarak açık olduğu ve kullanıcılara devre dışı bırakma seçeneği sunulmadığı iddiası. IP Koruması, Android ve masaüstü platformlarındaki Chrome'un Gizli modundaki kullanıcılar tarafından kullanılabilir. Kullanıcılar IP korumasını devre dışı bırakabilir. Chrome'un kurumsal olarak yönetilen sürümlerinde IP koruması etkinleştirilebilir ancak varsayılan olarak devre dışıdır.
API Kullanımı Chrome Canary ve Beta sürümlerinde IP Koruması'nı etkinleştirip test etmek için bir deneme işaretinin kullanılabilirliğiyle ilgili sorgu. Şu anda IP Koruması özelliğinin tamamını test etmek için kullanabileceğiniz bir deneme işareti yok. Yaptığımız işlevsel denemeler yalnızca Google alanlarına giden proxy trafiğini içerir.
IP Adresi Gizliliği Bir tarayıcı gizli moda geçtiğinde 3. taraf istemi ayarları nasıl çalışır? 3PC'ler gizli modda varsayılan olarak engellenir.
Gizli mod Kullanıcı Chrome'da oturum açmamışken IP Koruması'nın Gizli modda çalışıp çalışmadığı konusunda açıklama istendi. Kullanıcı, gizli modu başlatmadan önce Chrome'a giriş yapmadıysa IP Koruması etkin değildir. Bunun nedeni, sahtekarlık ve kötüye kullanımla mücadele amacıyla proxy'lere erişimi hız sınırlamasıdır. IP Koruması, kötü niyetli kişilerin MDL'deki hizmetlere yönelik saldırıları artırmak için proxy'lerden yararlanma kapasitesini sınırlandırmak amacıyla istemci kimlik doğrulamasını kullanır. Bu nedenle, IP Koruması yalnızca yeni bir Gizli pencere açmadan önce Chrome tarayıcıda oturum açtıkları Google Hesabı kullanılarak kimliği doğrulanan kullanıcılar tarafından kullanılabilir.
Gizli mod Lansmandan önce IP Koruması'nın etkisini değerlendirmek için yapılan istekler:
(1) Gizli mod kullanımını ölçmek için tarayıcı durumu işareti veya toplu API raporlaması kullanma önerisi;
(2) Özelliği etkinleştirmeden önce bir süre boyunca IP Koruması başlığı gönderme ve
(3) Özelliği, ekstrapolasyon için trafiğin bilinen küçük bir yüzdesine gönderme.		 Ekosistemin, IP Koruması'nın kapsamını ve etkisini anlayıp ölçebilmenin önemini anlıyoruz. Ancak Chrome, kullanıcının Gizli modda gezinme seçimini gizli tutmaya çalışır. Chrome, Gizli modda gezinen kullanıcıları algılamak için bir yöntem sunmaz ve kullanıcının tarama modunu açığa çıkarabilecek diğer sinyalleri sınırlamak için adım atmıştır.

Gizli modda gezinen kullanıcıların gizliliğini etkilemeden bu testi kolaylaştırmanın yollarını düşünüyoruz ve ekosistemden ek geri bildirimler almayı bekliyoruz.

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

Geri bildirim teması Özet Chrome Yanıtı
Uygunluk Google'ın, veri koruma yasalarına uygun olan Hemen Çıkış İzleme Azaltma (BTM) tekniğinin kullanımına izin vermek istememesi yasal bir dayanağa sahip değildir ve Gizlilik Korumalı Alan itiraz sürecini anlamsız hale getirir. Önceki geri bildirim raporumuzda açıkladığımız gibi, uygunluk durumunun BTM uygulamasıyla hiçbir ilgisi yoktur ve Google, BTM'nin uygulanmasında uygunluk konusunda herhangi bir karar vermez. Diğer Chrome gizlilik korumaları gibi BTM de kullanıcıların verilerinin paylaşılıp paylaşılmayacağı ve nasıl paylaşılacağı konusunda daha fazla kontrol sahibi olmalarını sağlamaya odaklanır.

CMA'nın 2. Çeyrek/3. Çeyrek Raporu'nda atıfta bulunulan üçüncü taraf tarafından yönetilen itiraz süreci, Google'ın şirketlerin listelere dahil edilmesi veya hariç tutulması hakkında karar verdiği alanlara özeldir.
Uygunluk Tarayıcıların, GDPR bağlamında yasal olarak izin verilen işlemlere uygunluğu nasıl sağladığıyla ilgili tartışma. Bu tartışmada, tarayıcıların kullanıcıların açıkça izin verdiği işlemleri (yönlendirmeler veya çerez ayarları gibi) engelleyebileceği ve yasal izin ile tarayıcı gizlilik ayarları arasında bir çatışma yaratabileceği senaryolar vurgulanıyor. Tarayıcı, kullanıcı ile web sitesi arasındaki ilişkinin niteliğini göremez. Ayrıca, mevcut BTM davranışında, kullanıcının belirli bir siteden hemen çıkma izleme için açık izin vermesi için zaten geçici çözümler mevcuttur.

Uygunluk hakkında daha fazla bilgiyi Gizlilik ile ilgili uygunluk SSS sayfamızda bulabilirsiniz.
Çift Kullanımlı Siteler WebView'den veya uygulamadan web'e (Chrome) geçişlerin BTM kapsamında "çift kullanımlı siteler" olarak kabul edilip edilmeyeceği konusunda netlik mi arıyorsunuz? Tarayıcı, bir hemen çıkma zincirinin Web Görünümü'nden mi yoksa uygulamadan mı başladığını göremez.

Bu nedenle, BTM bu akışlara özel bir işlem uygulamaz. Bunun yerine, akışı "about:blank" adresinden başlayan siteler arası bir hemen çıkma olarak yorumlar ve standart davranışla devam eder.

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

Geri bildirim teması Özet Chrome Yanıtı
API Kullanımı IP korumasıyla birlikte RWS'nin kötüye kullanım olasılığıyla ilgili endişeler. IP adreslerinin bir RWS grubundaki kuruluşlara gösterilmesi, kuruluşları gizli kullanıcıları izlemek için taşınabilir IP adresi verilerine erişmek üzere birden fazla RWS grubuna katılmaya teşvik edebilir. Otomatik doğrulamalarla uygulanan ilişkili siteler, hizmet siteleri ve gruplar için ayarlanan şartlar, birden fazla grubu birleştirme girişiminde bulunmaya yönelik olası teşvikleri azaltır.

IP adresleri aracılığıyla farklı gruplardaki kullanıcı etkinliklerini birleştirmek için bir MDL alanının bir gruba eklenmesi gerekir. Bu da grup sahibi ile alan sahibi arasında koordinasyon gerektirir. Aynı risk, MDL alanlarıyla koordinasyon yapan tek siteler (ör. RWS içermeyen siteler) için de geçerlidir.

Bu soruya buradan daha ayrıntılı bir yanıt verebilirsiniz.

Fenced Frames API

Geri bildirim teması Özet Chrome Yanıtı
Doğal Reklamcılık Şu anda tasarlandığı şekliyle çitli çerçevelerin, reklamların çevredeki içeriğe esnek bir şekilde uyum sağlamasını gerektiren doğal reklamcılık iş modelleriyle uyumlu olmadığına dair geri bildirim. Ekosistem ihtiyaçlarını ve mevcut Çitli Çerçeveler teklifini değerlendirmeye devam ediyoruz. Her durumda, daha önce de belirtildiği gibi, 2026'dan önce çitli çerçeveler gerekli olacaktır.

Shared Storage API

Geri bildirim teması Özet Chrome Yanıtı
API Hatası Beklenen bir davranış olmasına rağmen, paylaşılan depolama alanı API'sinin bütçe mekanizması selectURL işleminin çalışmasını engellediğinde Chrome'un hata günlüğe kaydettiğini bildirme. Hata, arayan için işleme alınamadığından Chrome'dan günlük kaydı düzeyini hata yerine uyarı veya bilgi olarak düşürmesini isteyin. Değişiklik uygulandı ve 4 Mart 2025'ten beri kullanıma sunulan Chrome M134'e dahil edildi.

CHIPS

Geri bildirim teması Özet Chrome Yanıtı
API Dokümanları Bölünmüş çerezlerin, SameSite=Lax/Strict çerezlerine kıyasla sunduğu güvenlik korumaları hakkında açıklamaya ihtiyaç var. Ayrıştırılmış çerezlerin, XSS ve CSRF saldırılarına karşı SameSite=Lax/Strict çerezleriyle aynı düzeyde koruma sağlamadığının dokümanda açıkça belirtilmesi önerilir. Bölünmüş çerezlerin sunduğu anlamları ve korumaları netleştirmek için açıklamayı ve spesifikasyonu güncelleyeceğiz.

FedCM

Geri bildirim teması Özet Chrome Yanıtı
Kullanıcı Arayüzü ve Güvenlik FedCM kullanıcı arayüzünün Google'ın önceki tek dokunuşla giriş özelliğine çok benzediği, pasif sunum izlemenin olmaması nedeniyle FedCM performansının ölçülmesinin zor olduğu ve PKCE ile ilgili daha güçlü bir doküman dili önerisi ile ilgili geri bildirimler. Paydaşlarla aktif olarak iletişime geçerek geri bildirimlerini ele alıyoruz. Devam eden tartışma konuları arasında, FedCM performansını izleyebilmeleri için kimlik sağlayıcılara daha iyi metrikler sağlamanın yolları ve abonelik kullanım alanları ile ilgili FedCM için yeni kullanım alanlarını ele alacak olası geliştirmeler yer alıyor.
API Kullanımı Kullanıcı sayfayı yenileyip giriş yapmak için navigator.credentials.get işlevini çağrdığında, devam etmek için tıklaması gereken bir pop-up pencere gösterilir. Bu da kullanıcı deneyimini etkileyen bir gecikme oluşturur. Güvenen taraflar (RP'ler), kullanıcı deneyimini iyileştirmek için navigator.credentials.get tarafından döndürülen jetonu önbelleğe alabilir mi? RP'ler jetonu saklamak için kendi çerezlerini kullanabilir. RP'ler daha sonra navigator.credentials.get çağrısını başlatmadan önce kullanıcının oturum açıp açmadığını belirlemek için kendi çerezlerini kontrol edebilir. Bu konuyu burada daha ayrıntılı olarak ele aldık.
Çoklu kimlik sağlayıcı seçimi Tarayıcı, FedCM'de birden fazla kimlik sağlayıcının (IdP) giriş seçeneklerini nasıl gösterir? Birden fazla kimlik sağlayıcının nasıl gösterileceği hakkında bilgi edinmek için geliştirici belgelerine göz atın. Paydaşlar, chrome://flags adresinde fedcm-multi-idp işaretini etkinleştirerek bu işlevi deneyebilir.
Tarayıcılar ve kimlik sağlayıcılar Chrome gibi bir tarayıcının kimlik sağlayıcı olarak hareket etmesi mümkün mü? Tarayıcılar, depolanan hesap ve profil verilerini güvenilir bir kimlik doğrulama kaynağı olarak kullanabilir. Tarayıcılar değiştirilebildiğinden (ör. uzantılar aracılığıyla), doğrudan tarayıcı tarafından yapılan e-posta doğrulama iddialarına ek sunucu tabanlı doğrulama olmadan güvenilemez. Bu nedenle, tamamen müşteriye dayalı bir çözüm önerilmez.

Bu konuyu burada daha ayrıntılı olarak ele aldık.
API Spesifikasyonu IdentityCredential.disconnect() algoritmasının parametresinin zorunlu mu yoksa isteğe bağlı mı olması gerektiğiyle ilgili tartışma. Bu sorun artık düzeltildi. Daha fazla bilgiye buradan ulaşabilirsiniz.
API Security Bir RP'de XSS güvenlik açığı varsa FedCM giriş sürecinde jeton sızıntısı ile ilgili endişeler. Bir saldırgan, jetonu almak için kötü amaçlı kodda navigator.credentials.get'i yürütebilir. FedCM yeni XSS riskleri oluşturmaz. Bu riskler web uygulamalarına ve mevcut kimlik doğrulama protokollerine özgüdür. Bu riskleri azaltmak için RP'ler, kimlik jetonlarındaki aud iddiasını doğrulamalı ve yalnızca kendi kaynaklarında yayınlanan iddiaları kabul etmelidir. Burada da belirtildiği gibi, bu jeton alışverişini güvence altına almak için yaygın olarak kullanılan ve FedCM ile kullanılabilen en iyi uygulamalar mevcuttur.

Ayrıca Storage Access API, FedCM ile kullanılabilir ve daha önce bir FedCM çağrısı olduğunda Storage Access API çağrıları otomatik olarak verilir. Bu işlem, GitHub sorununda bahsedilen yerleşik yönlendirme akışını etkinleştirir.
API Spesifikasyonu client_metadata_endpoint, FedCM için yapılandırma uç noktası yanıtında zorunlu bir alandır. Boş bir nesne geçerli bir yanıttır ve Chromium, 404 yanıtını sessizce yoksayar. Bu da uç noktanın pratikte isteğe bağlı olarak ele alındığını gösterir. Spesifikasyonun bunu yansıtacak şekilde değiştirilebileceğini ve client_metadata_endpoint alanının isteğe bağlı bir alan haline getirilebileceğini kabul ediyoruz.
API Kullanımı DOM üzerinden erişilemeyen tarayıcı kontrollü kullanıcı arayüzleri nedeniyle FedCM uygulamalarının test edilmesinin zorluğuyla ilgili endişeler. Geriye dönük test için tarayıcı otomasyon API'lerini destekliyoruz. Bu API'ler bu endişeleri giderebilir. Bu API'ler burada açıklanmıştır.
API Spesifikasyonu config uç noktasının yanıtının zorunlu bir parçası olan login_url parametresi, spesifikasyonun 3.2 numaralı bölümünde belirtilmemiştir. 3.2 numaralı bölüme login_url parametresini eklemek için dokümanlara bir güncelleme gönderdik.
API spesifikasyonu FedCM'deki olası bir izleme vektörüyle ilgili endişe. Bir IdP, yapılandırma uç noktası yanıtında belirtilen uç noktalara (accounts_endpoint, client_metadata_endpoint) yol parametresi olarak kimlikler ekleyebilir ve hesap ile müşteri meta veri isteklerini ilişkilendirmek için bu kimlikleri kullanabilir. Kimlik sağlayıcıların bu uç noktalara kimlik eklediğine dair kanıtımız olmasa da bu sorunu buradan gidermek için aktif olarak önlemler alıyoruz.

Spam ve sahtekarlıkla mücadele

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

Bu çeyrekte geri bildirim alınmadı.