Özel Korumalı Alan teklifleri ve Chrome'un yanıtları hakkında alınan ekosistem geri bildirimlerini özetleyen, 2023'ün 3. çeyreğine yönelik üç aylık rapor.
Google, CMA'ya olan taahhütlerinin bir parçası olarak, Özel Korumalı Alan teklifleri için paydaş etkileşim süreci hakkında üç aylık raporları kamuya açık bir şekilde sunmayı kabul etmiştir (Taahhütler'ün 12 ve 17(c)(ii) paragraflarına bakın). Bu Özel Korumalı Alan geri bildirim özet raporları, geri bildirim genel bakışı bölümünde listelenen ve bunlarla sınırlı olmamak üzere Chrome'un çeşitli kaynaklardan aldığı geri bildirimler toplanarak oluşturulur: GitHub Sorunları, privacysandbox.com adresinde kullanıma sunulan geri bildirim formu, sektörden paydaşlarla toplantılar ve web standartları forumları. Chrome, ekosistemden alınan geri bildirimleri memnuniyetle karşılar ve öğrendiklerini tasarım kararlarına entegre etmenin yollarını aktif olarak araştırır.
Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanmasıyla ve azalan düzende düzenleyerek yapılır. Yaygın geri bildirim temaları; herkese açık toplantılarda ele alınan tartışma konuları (W3C, PatCG, IETF), doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden sıklıkla sorulan sorular incelenerek belirlenmiştir.
Daha net açıklamak gerekirse web standardı kuruluş toplantıları için toplantı notları incelendi ve doğrudan geri bildirim sağlamak amacıyla Google'ın bire bir paydaş toplantılarıyla ilgili kayıtları, tek tek mühendisler tarafından alınan e-postalar, API posta listesi ve genel geri bildirim formu dikkate alındı. Daha sonra Google, her bir API ile ilişkili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli destek faaliyetlerinde yer alan ekipler arasında koordinasyon sağladı.
Chrome'un geri bildirimlere verdiği yanıtların açıklamaları; yayınlanan SSS'lerden, paydaşlar tarafından dile getirilen sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama alıştırmasının amaçları doğrultusunda, özel olarak bir pozisyonun belirlenmesinden alınmıştır. Geliştirme ve test çalışmalarının şu andaki odaklandığı konuları ele aldık. Özellikle Topics, Protected Audience ve Attribution Reporting API'lerle ilgili sorular ve geri bildirimler alındı.
Geçerli raporlama döneminin bitiminden sonra alınan geri bildirimde henüz Chrome yanıtı dikkate alınmamış olabilir.
Kısaltmalar sözlüğü
- ÇİPLER
- Bağımsız Bölümlendirilmiş Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Birleştirilmiş Kimlik Bilgisi Yönetimi
- FPS
- Birinci Taraf Gruplar
- IAB
- İnteraktif Reklamcılık Bürosu
- IdP
- Kimlik Sağlayıcı
- IETF
- İnternet Mühendisliği Görev Gücü
- YA
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- UZ
- Kaynak Denemesi
- PatCG
- Özel Reklamcılık Teknolojisi Topluluğu Grubu
- RP
- Bağlı Taraf
- STP
- Arz Tarafı Platformu
- TEE
- Güvenilir Yürütme Ortamı
- UA
- User Agent dizesi
- UA-CH
- Kullanıcı Aracısı İstemci İpuçları
- W3C
- World Wide Web Konsorsiyumu
- WIPB
- Hasta IP Körlüğü
Genel geri bildirim, spesifik API veya Teknoloji yok
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Ekosistemin hazırlık durumu | STP'ler, yayıncıların hazır olmaması ve gerekli dağıtım işini yapmamasıyla ilgili endişelerini vurguladı. | Özel Korumalı Alan, özellikle yayıncıları eğitmeye odaklanmıştır. Bu eğitimlerde, dağıtım çalışmalarını desteklemek için hem yayıncılar hem de STP'lerle birlikte özel web seminerleri ve toplantılar düzenlenir. |
| Üçüncü taraf çerez desteği sonlandırılıyor | Sektörde teknoloji kesintileri nedeniyle üçüncü taraf çerezlerinin kullanımdan kaldırılmasıyla (3PCD) ilgili endişeler 2023'ün 4. çeyreğinde artıyor. | Özel Korumalı Alan'ın zaman çizelgesi, CMA ile görüşüldü ve sıralama, 2024'e hazırlık sürecinin ikinci yarısına kadar sürecek. Özel Korumalı Alan, 3PCD'ye geçiş sıralaması hakkında daha ayrıntılı bilgiler yayınlar. Taahhütler kapsamında 3PCD, CMA'nın rekabetle ilgili endişelerine tabidir. |
| Google Ad Manager | Google Ad Manager, testi zorlaştıracak şekilde API yüzeyini göstermeyi reddeder. | Google Ad Manager tarafından sağlanan yanıt: Google Ad Manager'ın bu yanıtında açıklanan nedenlerden dolayı, Google Ad Manager'ın Protected Audience API entegrasyonuyla ilgili planları, üst düzey açık artırmanın kontrolü olmadan Google'ın yayıncı reklam sunucusunun desteklenmesini içermez. |
| Google Ad Manager | Google Ad Manager, yalnızca AdX veya Open Bidding STP'lerinin görebileceği bir gizli taban fiyata sahiptir. | Google Ad Manager'ın herkese açık dokümanlarında, içeriğe dayalı açık artırmanın kazananının AdX veya Open Bidding dahil herhangi bir bileşen açık artırmasına değil, üst düzey puanlama mantığına iletildiği belirtilmektedir. Ayrıca, bu dokümanlarda üst düzey puanlama mantığı şu şekildedir: "Ad Manager, alıcılarının ilgi alanı grubu teklifleri için kendi bileşen açık artırması ve en iyi içeriğe dayalı reklam (dinamik ayırma aracılığıyla seçilir) dahil her bileşen açık artırmasının kazanan teklifini karşılaştıracak ve en yüksek teklife sahip reklamı yayınlayacaktır." |
| Google Ad Manager | Google Ads ürünleri, üçüncü tarafların reklam ürünleriyle aynı kurallara tabi olmalıdır. | Google Ads ürünleri zaten üçüncü taraflarla aynı kurallara tabidir. |
| Chrome destekli test | A veya B'de olmayan tarayıcılar için etiketler ekleyin. | Araştırmamız, deneme dışı etiketler eklemenin gizli moddaki trafikle ilgili gizlilik endişelerini karmaşık hale getirebileceğini tespit ettiğinden şu anda bunu yapmayı düşünmüyoruz. |
| Reklam ajansı | Web sitelerinde JavaScript'i olmayan ajanslar veya şirketler, Özel Korumalı Alan API'lerini kullanabilir mi? | Özel Korumalı Alan API'lerini herkes çağırabilir. Bir ajans veya başka biri teknolojileri doğrudan yapabilecekleri API'ler üzerinde oluşturmak isterse, İstemci tarafı API'leri, çerezlerin yaptığı gibi istemciyle entegre edilmesini gerektirir. Çerezler gibi birçok API'nin bir HTTP başlık arayüzü de bulunur. Bir reklam sektörü çerçevesi olan Prebid'i, API'lerle istemci tarafı entegrasyonları oluşturduğunu görmüştük. Diğer kuruluşlar da aynısını yapabilir. |
| İstemci Taraflı Çözümler | Daha önce bir mühendis, 2012 yılında bu tür çözümlerin ölçeklenebilirliğiyle ilgili endişe duyduğunu belirtirken Google neden Özel Korumalı Alan için istemci taraflı çözümleri benimsiyor? | Bir çalışma alanı olarak gizliliği artıran teknoloji (PET) 2012'den beri önemli ölçüde gelişti ve bu sayede ticari olarak uygulanabilir uygulamalar geliştirdi. Özel Korumalı Alan'ın temelinde on yıldan uzun bir süre önce uygulanamayan PET kombinasyonları vardır. Buna ek olarak, tüketicilerin tarayıcılarla ilgili beklentileri ve gizlilikle ilgili yasal beklentiler gibi kişisel bilgi işlem gücü de artmıştır. |
| Makine Öğrenimi | Google'ın makine öğrenimi amacıyla Özel Korumalı Alan'ı planlı kullanımı nedir? | Günümüzde reklam teknolojisi ekosisteminin çoğunda makine öğrenimi kullanılıyor ve bunun değişmesini beklemiyoruz. Özel Korumalı Alan, reklam teknolojisi şirketlerinin veya başka kişilerin makine öğrenimini kullanmaya devam etmesini engellemez. Özel Korumalı Alan, API'leriyle entegrasyon yapan şirketlerin makine öğrenimi kullanmasını da gerektirmez. Şirketlerin, makine öğrenimi dahil olsa da olmasa da müşterilerin ihtiyaçlarını karşılayacak şekilde ürün ve hizmet geliştirmeye devam etmesini bekleyebilirsiniz. Özel Korumalı Alan entegratörlerinin oluşturduğu her makine öğrenimi kesinlikle bilir ve bu sayede diğer kullanıcılar tarafından gizlenmez. |
| Veri doğrulama | Şirketler, Özel Korumalı Alan'ı kullanarak elde ettikleri verilerin doğruluğunu ve Google'ın Medya Derecelendirme Konseyi (MRC) gibi bir tüzel kişi tarafından incelenmeye hazır olup olmadığını nasıl doğrulayabilir? | Özel Korumalı Alan API'leri, Chrome'u destekleyen açık kaynak platformda derlenmiştir. Güvenilir Yürütme Ortamları'nda çalışması amaçlanan API'lerin bölümleri de açık kaynaklıdır ve denetlenebilir. MRC dahil olmak üzere isteyen herkes kodu inceleyebilir. |
| (Önceki çeyreklerde de bildirilmiştir) Üretim Desteği | Chrome'un, ekosistemi etkileyen Özel Korumalı Alan teknik sorunları ve üst birime iletme sürecindeki süreç nasıldır? | Google, reklam teknisyenlerinin teknik sorunları bildirebilmesi ve bu tür sorunların çözümü için gerekli üst birime iletilmesini sağlayan bir dizi kanal sağlamaktadır. Ayrıca Chrome, ekosistemin durumunu etkileyen teknik sorunları ve üst birime iletme süreçlerini çözüme kavuşturacak bir süreç daha oluşturmayı ve ölçeklendirmeyi bekliyor. Chrome bu amaç için kaynak
sağlamaya büyük önem verir. Geri bildirim ve üst birime iletme için herkese açık ve özel forumlar hakkında daha fazla bilgi edinmek için lütfen geliştirici gönderimize göz atın. |
| Chrome destekli test modları | Chrome'un desteklediği test modlarının zaman çizelgeleri ve tam uygulamaları hakkında daha fazla bilgi edinin. | Test modlarıyla ilgili bir blog yayını paylaştık ve yakında daha fazla bilgi paylaşmak için çalışıyoruz. Test modu etiketlerinin ne boyutta olması gerektiğiyle ilgili önerilerinizi memnuniyetle karşılıyoruz. |
| Diğer endüstri standartlarıyla entegrasyon | Özel Korumalı Alan API'leri TCF 2.* sürümüne ve izin moduna bağlanır mı? | Özel Korumalı Alan API'lerini doğrudan TCF v2 veya İzin Modu ile entegre etmeyi planlamıyoruz. Ancak şirketler ve sektördeki ticaret grupları, ürünlerini ve çerçevelerini Özel Korumalı Alan API'leriyle birlikte çalışacak şekilde uyarlayabilir. Örneğin, TCF gibi çerçevelerle her katılımcı, aldığı TCF sinyaline ve ilişkili TCF politikalarına dayanarak kendi uygunluk yaklaşımını belirlemelidir. Şirketlerin, Özel Korumalı Alan yapı bloklarımızın sunduğu çeşitli işlevleri ne zaman ve nasıl kullanacaklarını belirlemelerini bekliyoruz. |
Kayıt ve Onay
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Kısıtlama | Kayıt işlemi, Google'ın ekosistemdeki hangi şirketin Özel Korumalı Alan API'lerini kullanmasına izin vereceğine karar verebileceği anlamına gelir. | Kayıt ve Onay süreci, temel olarak varlığın doğrulanmasını gerektirir (örneğin, varlığın bir DUN numarası olması, bir gizlilik politikasının bağlantısını sağlayabilmesi vb.) ve API'lerin çağrılması için herkese açık onayı bir gereklilik haline getirir. Kayıt gereksinimlerini başarıyla yerine getirebilen varlıklar doğrulanır. DUN numarası olmayan şirketler için Dun & Bradstreet ile daha hızlı ve ücretsiz bir süreç sağlıyoruz. Amaç, API'lerin gizlilik korumalarını iyileştirmek (az önce belirtilen ölçümlerle) ve Özel Korumalı Alan API'lerine bir şeffaflık katmanı eklemektir. Böylece ilgilenen taraflar kimin hangi API'yi kullandığını ve hangi onayları verdiklerini daha iyi anlayabilir. Süreci şekillendirmek için zaten kullanılmış olan bu konu hakkında sektördeki diğer geri bildirimlere açığız. |
| Yeniden kayıt ek yükü | Onay dosyasının süresi 12 ayda bir dolar ve web sitelerinin yeniden kaydolmasını gerektirir. | Ekosistemden geri bildirimler aldık ve yaklaşımımızı buna uygun şekilde değiştirdik. Bu, 12 ay veya belirli bir süre sonra dosyaların süresinin dolmeyeceği anlamına gelir. Ek bilgilerle kayıt geliştirici kılavuzumuzu güncelliyoruz. |
| Onay dosyası | Onay dosyası nasıl kullanılır? | Alaka düzeyi ve ölçüm API'leri çağıran tüm şirketlerin, onay dosyasını sitelerine yüklemeleri ve API'leri çağırmaya devam etmek istediğiniz sürece herkese açık olarak gösterilecek şekilde saklamaları gereken son tarihe kadar zorunlu kılınacak. Web siteleri Özel Korumalı Alan'dan saatte yaklaşık bir istek bekleyebilir. Diğer potansiyel varlıklar da sorgu gönderebilir. Bu işlem, kayıtlı varlıkların sunucularını sorgulamak ve onay dosyasının geçerli olduğundan emin olmak için kayıt sisteminin kendi mekanizması aracılığıyla gerçekleştirilir. Onaylar, Şeffaflık Raporlarına dahil edilecek ve herkes tarafından görüntülenebilir. Şirketlerin, diğer ekosistemlerin ve ilgili düzenleyici kurumların da belirttiği şekilde hareket etmelerini bekliyoruz. |
| Kayıt | Kayıt, site başına mı kaynak bazında mı? | Kayıt, site düzeyinde gerçekleştirilir. |
Alakalı İçerik ve Reklamlar Gösterin
Konular
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Performans | Avrupa Ekonomik Alanı'nda Topics'e dahil olma oranının etkisine dair performans kaygıları. | İlgili paydaşların bu konuyla ilgili olarak ilgili veri koruma yetkilinizle iletişime geçmelerini öneririz. Bu tür endişeleri gidermenin ve gizliliği artıran teknolojilerin uygulamalarının yasalarca teşvik edilip edilmediğini veya bunun yerine izleme gibi değerlendirilip aynı yaklaşımların izin alınmasını gerektirecek şekilde değerlendirilip görülmediğini belirlemenin en iyi yolu budur. Aksi takdirde, Özel Korumalı Alan'dakiler gibi API'ler çok sık kullanılamayabilir. |
| Kayıt | Aşağı akış teklif verenlerinin yukarı akış STP'lerinden gelen Topics sinyallerini kullanmak için Topics API'ye kaydolması gerekir mi? | Topics API için ilk arayanın ötesinde konuların aşağı yönlü alıcılarının kaydedilmesine gerek yoktur ancak birçok kullanıcının diğer API kullanımları için kaydolmuş olma olasılığı yüksektir. Programın şeffaflık çalışmaları kapsamında Özel Korumalı Alan'a kaydolan kişilerin listesi programatik olarak sağlanacaktır. Bu sayede, Topics API'yi arayan ilgili kişi isterse bir konuyu gönderdiği alıcının kayıtlı olup olmadığını kontrol edebilir. |
| Konu filtreleme | Yalnızca alıcıların almaya uygun olduğu bilgileri paylaşmak için başka bir arayanın filtrelemesini sayfada aldığı konulara uygulamayı isteyin. | Bu isteği değerlendiriyoruz. Ekosistemden gelen ek geri bildirimleri almaktan memnuniyet duyarız. |
| Site hariç tutma | Web sitelerinin, bir kullanıcının Konularına katkıda bulunmasını önleyin. | Konular varsayılan olarak çağrılmaz. Konular seçilirken hiçbir sayfa içeriğinin dikkate alınmadığını ve tüm konuların hassas olmadıklarından emin olmak için seçildiğini unutmamak gerekir. Bir web sitesi, aşağıdaki izin politikası başlığı aracılığıyla sitesinin konu hesaplamasına dahil edilmesini de kısıtlayabilir: Permissions-Policy:
browsing-topics=() |
| Konu gözlemi | Yayıncıların, Chrome'a sayfa içeriğine (örneğin, baş veya gövde) göre konuları sınıflandırması için izin vermesine izin verin. | Daha önce siteleri sayfa içeriğine göre konulara göre sınıflandırmak için işlevler sunmayı düşünmüştük ve gizlilik ve güvenlik endişeleri nedeniyle bu yönde ilerlememe kararı aldık. Bu teklif, söz konusu endişelerin bir kısmını hafifletebilir, ancak ne ölçüde belirsizdir. Önümüzdeki CMA deneme dönemi nedeniyle, bu değişikliğin 3PD'den önce gerçekleşmesi beklenmemektedir. Geri bildirimlerinizi burada bizimle paylaşabilirsiniz. |
| Konu gözlemi | Yayıncılar için daha ayrıntılı izin politikaları sağlar. | Yayıncılar için daha ayrıntılı izin politikaları sağlamak, yayıncı sitelerinin Topics API'nin site için kullanımını olumsuz yönde etkilemeden, Topics API'nin bir bütün olarak ekosistem için kullanımını olumsuz yönde etkilemesine imkan verir. Konuyla ilgili daha ayrıntılı bir inceleme için GitHub sorunuyla ilgili olarak almak ve gözlemlemek için ayrı izinler desteklemek amacıyla izinleri güncelleme politikasını inceleyin. |
| Tıp ve Sağlık Konuları | Konular sınıflandırması neden Tıp veya Sağlık kategorisindeki konuları kapsamıyor? | Tıbbi ve sağlık kategorileri hassas konular olarak kabul edildiğinden Topics sınıflandırmasının dışında tutulur. |
| Konu alma | TTP'lerin başlıkları kullanarak Konuları getirmeden daha hızlı almasını sağlar. | Başlık yöntemleri, çapraz kaynak iframe oluşturmak ve bundan bir document.browsingTopics() çağrısı yapmaktan daha etkili ve düşük maliyetlidir. (Bir konuyu gözlemlemek için kullanılacak üst düzey bağlam, konulara erişildiği bağlamla eşleşmelidir, çünkü çağrı için çapraz kaynak iframe'i kullanılmalıdır.) Bu konu, burada ayrıntılı olarak ele alınmıştır. |
| Konu alma | Kaynaklar arası komut dosyası etiketi isteklerinde başlıklar aracılığıyla Konuların iletilmesini destekleme istekleri. | Güvenlik açısından bu mümkün değildir. Her belge ve yürütme ortamı, belgenin tek bir kaynağıyla ilişkilendirilir. Aynı ortamda yüklenen ve yürütülen üçüncü taraf alt kaynaklarının, dokümanın kaynağına ait olduğu kabul edilir. Bunun amacı, izin alınmadan verilerin bir kaynaktan diğerine sızmasını önlemektir. Alternatif bir yöntem de <script> etiketlerinde browsingTopics özelliği sağlamaktır. Bu, güvenlik açısından net olmalı ve fazladan gecikme eklememelidir. İlgilenen tarafların
geri bildirimlerini bekliyoruz. |
| Bilinirlik | Topics API ve API'nin nasıl kullanılacağıyla ilgili genel farkındalığı artırın. | Bu geri bildirimi sağlayan paydaşla iletişime geçtik ve bu sorun GitHub'da çözüldü.
Bundan böyle, ekosistemin API'yi anlamasını desteklemeye devam edeceğiz ve paydaşların görüşlerini almayı sabırsızlıkla bekliyoruz. Bu sırada, Topics API hakkında daha fazla bilgi edinmek isteyen paydaşların Chrome geliştirici kılavuzundaki dokümanlara aşina olmasını öneririz. |
| Bildirim | Topics bir web sitesi tarafından gözlemlendiğinde kullanıcıyı uyaran bildirim. | Bu geri bildirimleri GitHub'da dikkate aldık. Kullanıcılar Chrome Yardım Merkezi'nde Konular kontrolleri hakkında daha fazla bilgi edinebilir. |
| Makine Öğrenimi | Kullanıcı Konuları hakkında bilgi edinmek için makine öğrenimi nasıl kullanılabilir? | Şu anda bu sorunu ele alıyoruz ve ek geri bildiriminizi bekliyoruz. |
| Farklı paydaşlar için yararlılık | Küçük çaplı reklam teknolojisi şirketleri, tarayıcıların Topics'i hesaplama yöntemi nedeniyle bunları gözlemleyemeyebilir. | Yalnızca son üç hafta içinde kullanıcının konuyla ilgili bir sayfayı ziyaret ettiğini gözlemleyen reklam teknisyenleri konu alır. Reklam teknolojisi bu konuyla ilgili bir sitede bu kullanıcı için önceki üç hafta içinde API'yi çağırmadıysa döndürülen değer boş kalır. Bu özellik, hizmetleri daha çok sayıda site sahibi tarafından kullanılan ve dolayısıyla belirli bir kullanıcının site ziyaretini gözlemlemek için daha fazla fırsata sahip olan reklam teknisyenlerinin, diğer reklam tekniklerinden daha fazla konu alabileceği anlamına gelir. Bu özellik, bir kullanıcı hakkındaki bilgilerin kullanılabilirliğini yalnızca aynı temel bilgileri (şu anda üçüncü taraf çerezler aracılığıyla) gözlemleyebilen taraflarla sınırlandırdığından API'nin gizlilik korumaları açısından çok önemlidir. |
| XHR İsteği | Topics'in XMLHttpRequest (XHR) isteklerine dahil edilmesi ne zaman kullanımdan kaldırılacak? |
Chrome'un Ağustos 2023'te duyurduğu gibi Chrome, Kaynak Deneme'den Genel Kullanıma Geçişe geçerken XHR desteğini kullanımdan kaldırmaya başladı. Topics'in yükselişi ilerledikçe XHR desteği yalnızca OT özelliklerinin etkinleştirildiği kullanıcılar için dahil edildi ve bağımsız OT deneme grupları birleştirildiğinde tamamen kullanımdan kaldırıldı. Topics'i XHR ile kullandıysanız siteleriniz kesintiye uğramaz. Bu durumda konular, XHR istek başlıklarınıza eklenmez. İsteğiniz için fetch ürününe geçmenizi, iframe özelliğini kullanmanızı veya konuları almak için JavaScript API'yi kullanmanızı öneririz. Getirme tüm modern tarayıcılar tarafından desteklenir ancak Internet Explorer veya Opera Mini tarafından desteklenmez. |
| Sınıflandırma ve sınıflandırıcı güncelleme süreci | Topics sınıflandırması ve sınıflandırıcı yayınlama sıklığı ile şirketlerin bu tür güncellemelere nasıl hazırlanabileceği hakkında daha fazla bilgi edinin. | 2. çeyrekteki tepkimiz değişmedi: Yakın zamanda yayınlanan blog yayınında da açıklandığı üzere sınıflandırmanın zaman içinde değişmesini ve sınıflandırma yönetiminin sonunda sektörden paydaşları temsil eden harici bir tarafa geçiş yapmasını bekliyoruz. Artış planını da konular-duyuru grubunda paylaştık. |
| Kötüye kullanım | Yönlendirme zinciri üzerinden olası saldırı. | Bu sorunu değerlendiriyoruz. Ek geri bildiriminizi almaktan memnuniyet duyarız. |
| Yayıncı Envanter Türleri | Korunan Kitle ve Konular testi hangi yayıncı envanteri türlerini destekler? | Korunan Kitle ve Konular, kullanılabilecek envanter türleri açısından doğası gereği kısıtlayıcı değildir. |
| Artış süresi | Yeni sınıflandırmaların %100'e ulaşması için artış süresi önermemesi. | Ekosistemden gelen bu geri bildirim isteği ve PATCG toplantıları sırasında yapılan tartışmalar üzerine yeni sınıflandırmanın kullanıma sunulması ile ilgili planımızı duyurduk. |
Protected Audience API (eski adıyla FLEDGE)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Üst Düzey Açık Artırmalar | Google Ad Manager'a üst düzey Protected Audience API açık artırması kontrolünü vermeden Google'ın yayıncı reklam sunucusunu kullanma olanağı. | Google Ad Manager tarafından sağlanan yanıt: Google Ad Manager'ın Protected Audience API planları, aşağıdaki nedenlerden dolayı, üst düzey Korunan Kitle açık artırmasının kontrolü olmadan Google'ın yayıncı reklam sunucusunun desteklenmesini içermez. Yayıncı reklam sunma pazarında müşterilerimize doğru şekilde hizmet verebilmemiz için Google'ın yayıncı reklam sunucusunun, üst düzey Korunan Kitle açık artırmasının kontrolünü elinde tutması gerekir. Bir yayıncı reklam sunucusu olarak rolümüz, yayıncılara çifte rezervasyon yapmadan doğrudan satılan kampanyalar için pazarlık yapabilmeleri için öngörme imkanı sunmak ve doğrudan rezervasyonlarının hızını en uygun şekilde belirleyip yayınlamaktır. Bunu yapmak için tüm uygun doğrudan ve dolaylı talebi karşılaştırmak için son açık artırma yapılması gerekir. Öngörme ve ilerleme hızı, yayıncıların bir reklam sunucusundan beklediği temel işlevlerdir. Doğru bir öngörme olmazsa yayıncılar envanterlerini fazla satarak işletme itibarlarını riske atabilir. Reklamverenlerle rezervasyon sözleşmelerini yerine getirememe, yayıncı-reklamveren doğrudan ilişkisine de zarar verme riski taşıdığından, ilerleme hızı da önemlidir. Bu durum, bir yayıncının işini önemli ölçüde etkileyebilir. Kısacası, bu nedenle bir yayıncı reklam sunucusunun üst düzey Korunan Kitle açık artırması düzenleme etkinliğini, yayıncı reklam sunucusunun diğer etkinliklerinden ayrı olarak görmeyiz. |
directFrom |
directFromGoogle Ad Manager'ın, yayıncının içeriğe dayalı açık artırma fiyatını görmesini engellemesine olanak tanır. |
Chrome yanıtı: Satıcı kendi iFrame'inden runAdAuction() çağrısı yapmadığı sürece runAdAuction() ürününe iletilen bilgilerin satıcıdan geldiği bilinmez. Çok satıcılı bir açık artırmada runAdAuction() kodunu çağıran çerçeveyi tüm satıcıların oluşturması imkansız hale gelir. directFromSellerSignals, bir satıcının kaynağından yüklenen alt kaynak paketinden içerik yükleyerek bu sorunu çözdü. Bu, satıcı açık artırma yapılandırmalarından açık artırmaya aktarılan bilgilerin özgünlüğünü ve bütünlüğünün değiştirilememesini sağlar. Teknoloji sağlayıcılarının korunan kitle açık artırmalarına ilettiği bilgileri anlamak için Protected Audience API'yi kullanmak isteyen yayıncılar bu teknoloji sağlayıcılardan bu işlevi talep edebilir.Google Ad Manager tarafından verilen yanıt: Açık artırma adilliğine odaklanmayı yıllardır sürdürüyoruz. Buna, bir yayıncının garanti edilmeyen satır öğesi fiyatları da dahil olmak üzere hiçbir reklam kaynağında hiçbir fiyatın diğer alıcılarla teklif vermeden önce paylaşılacağına dair söz verdiğimiz gibi, daha sonra da Fransa Rekabet Kurumu'na taahhütlerde yer verdik. Korunan Kitle açık artırmaları için directFromSellerSignals aracılığıyla taahhüdümüzü yerine getirmeyi ve ç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şmamayı amaçlıyoruz. Açıkça belirtmek gerekirse, Üst düzey açık artırma dinamiklerini daha fazla netleştirme başlıklı makalede açıklandığı gibi, içeriğe dayalı açık artırmanın fiyatını kendi bileşen açık artırmamızla da paylaşmayacağız. |
| Bilgi Gösterme | Tarayıcı, hassas iş mantığını ve sözleşme bilgilerini açığa çıkarabilir. | Web tarayıcısı kullanan kişi, tarayıcıda olan her şeyi görebilir. Tarayıcı içinde bir reklam açık artırması gerçekleştiğinde, ne kadar farklı tarafın teklif vermeyi seçtiği de dahil olmak üzere, tarayıcısı olan kullanıcı bu açık artırmanın gerçekleştiğini izleyebilir. Tarayıcı, kullanıcının aracısı olduğundan, bunu değiştirmenin mümkün veya istenen bir durum olmadığını düşünüyoruz. Bununla birlikte, bu işlemleri yalnızca tarayıcıyı kullanan kişi görebilir. Protected Audience API kullanılarak cihaz üzerinde yapılan bir açık artırma, Google'ınkiler de dahil olmak üzere hiçbir sunucu tarafından gözlemlenemez. |
PerBuyerExperiment |
Mevcut PerBuyerExperimentdeğer aralığı, alıcıların içerik verilerini güvenilir sunucu isteğiyle ilişkilendirmesine olanak tanıyabilir. |
Protected Audience API'nin bu şekilde kullanılması, Özel Korumalı Alan'ın API kullanıcılarının Özel Korumalı Alan korumalarını atlatmaya çalışmayacağına dair zorunlu onayına uygun değildir. Gelecekte, anahtar/değer sunucularının güvenilir yürütme ortamlarında (TEE'ler) çalıştırılması gerekliliği bu saldırıya karşı teknik koruma sağlayacaktır. |
| Aynı kaynak politikası | Alt alan adlarına izin vermek için aynı kaynak politikasını gevşetin. | Bu isteği değerlendiriyoruz. Ekosistemden gelen ek geri bildirimleri memnuniyetle karşılıyoruz. |
| API sürümü oluşturma | Protected Audience API'de yapılan değişiklikler için sürüm oluşturma ve sürüm notları isteği. | Bu isteği değerlendiriyoruz. Ekosistemden gelen ek geri bildirimleri memnuniyetle karşılıyoruz. |
| Çoklu STP Açık Artırmaları | Üst düzey açık artırma sinyallerinin, auctionSignals bileşen sinyaliyle JSON birleştirmeleri gerçekleştirmesine izin verin. |
Bu isteği değerlendiriyoruz. Ekosistemden gelen ek geri bildirimleri memnuniyetle karşılıyoruz. |
| Teklif sınırı | Teklife giren reklam bileşeni sayısı sınırını 20'den 40'a yükseltin. | Bu isteği değerlendiriyoruz. Bunun neden yararlı olabileceğine dair ekosistemden gelen ek geri bildirimleri almaktan memnuniyet duyuyoruz. |
| (Önceki çeyreklerde de bildirilmiştir) Korunan Kitle Açık Artırmalarının Performansı |
Test kullanıcılarının, Korunan Kitle açık artırmalarının yüksek gecikmeye sahip olduğunu bildirme | Protected Audience API, gecikmeyle ilgili sorularda genellikle satıcıların teklif verenlerin ne kadar zaman ve kaynak tüketebileceğine karar vermesine olanak tanıyan mevcut standart oluşturma denetimi paradigmasını izler ve alıcıların mevcut kaynakları en iyi nasıl kullanacaklarına karar vermelerini sağlayan araçlar oluşturur. Bu kontroller ve araçlar günümüzde genellikle kullanılabilir ancak tam avantajlarından, ancak alıcı ve satıcılar tarafından benimsendikten sonra yararlanılabilecektir. Ayrıca Chrome, açık artırma hızıyla ilgili çeşitli altyapı iyileştirmeleri (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323) üzerinde çalışmaya devam etmektedir. Bu gecikme çalışmasının her iki tarafı için de geri bildirim istiyoruz: Alıcıların ve satıcıların faydalı bulabileceği yeni araçlar ve Chrome mühendislerinin incelemesi gereken, gözlemlenen kesintilere ilişkin raporlar. |
| Alıcı tarafı filtreleme | İlgi alanı gruplarına göre alıcı tarafı filtreleme için destek eklendi. | STP'lerin ve TTP'lerin bu sorunu gidermek için tasarımlarını değiştirebilecekleri birkaç yol önerdik:
|
| Yayıncı İlgi Alanı Grubu Kontrolü | Yayıncı tarafından oluşturulan ilgi alanı gruplarının kullanımı için yetki vermek isteyen yayıncılar için destek. | Taleple ilgili olarak birçok tarafla görüştük. Yayıncı tarafından oluşturulan ilgi alanı gruplarının "yetkilendirilmesi" ile ilgili bu tür tüm kullanım alanlarının artık karşılanabileceğine ve ayrıca, bazı kullanım alanlarının gelecekte daha sorunsuz ilerlemesi için ek destek oluşturmamız gerektiğine inanıyoruz. |
| (2. çeyrekte de bildirilmiştir) Güvenilir Yürütme Ortamları | Herkese açık olmayan bulut ortamlarında Güvenilir Yürütme Ortamları (TEE) desteği. | Önceki çeyreklere benzer bir yaklaşımla karşınızdayız: Herkese açık bulut tabanlı çözümlerin ötesindeki seçenekler için sunduğumuz desteği araştırmaya devam ediyoruz. Bununla birlikte, şirket içi TEE'leri desteklemeyle ilgili herhangi bir planımız bulunmuyor. Bu aşamada, Özel Korumalı Alan güvenlik gereksinimleri ve şirket içi dağıtımların getirdiği önemli zorluklar göz önünde bulundurulduğunda, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye (ör. AWS'ye ek olarak Google Cloud'u desteklemenin) devam etmenin ekosisteme en faydalı yol olduğuna inanıyoruz. Ancak gizlilik ve güvenlik kısıtlamaları göz önünde bulundurulduğunda böyle bir şartın neden gerekli ve uygulanabilir olduğu konusunda ek geri bildirimler almaktan memnuniyet duyarız. |
| Güvenilir Yürütme Ortamı | TEE sunma yolundaki yük dengeleyici gibi bileşenler, tüm trafiği gözlemleyebilir ve her isteğin IP adresiyle ilgili bilgilere sahip olabilir. | Şu anda IP adresi, hem Teklif Verme hem de Açık Artırma'da ve cihaz üzerinde Korunan Kitle açık artırmalarında güvenilmeyen satıcının reklam hizmetine istek başlıklarında meta veri olarak aktarılmaktadır. Daha fazla bilgi için Meta veri yönlendirme başlıklı makaleyi inceleyin. Uzun vadede, reklam teknolojisi ve izleyici trafiğini bir IP proxy aracılığıyla proxy üzerinden yönlendirmeyi planlıyoruz. Bu, bileşenlerin sunum yolundaki tüm trafiği gözlemlemesini engelleyecektir. |
| Geçerlilik Süresi (TTL) | Hizmetlerin yeni anahtarlar istemesine gerek kalmadan geçerlilik süresi (TTL) olacak mı yoksa bu süre esnek (veya dinamik) olacak şekilde mi tasarlandı? | TTL genellikle statiktir. Şu anda herkese açık TTL 8 gündür ve rotasyon 7 günde bir gerçekleşir. TTL, Toplama Hizmeti'ndeki özel anahtarlar için de aynıdır. Teklifli Sistem ve Açık Artırma hizmetleri söz konusu olduğunda, özel ve ortak anahtarlar istek olmayan yolda N saatte bir getirilip bellekte önbelleğe alınır. Böylece, anahtar döndürme ile bu anahtarları alan sunucular arasında N saatlik bir gecikme olmaz. Anahtar rotasyonu ile süre sonu arasındaki 1 günlük arabellek, anahtar oluşturma başarısız olsa bile hizmetlerin çalışmaya devam etmesini sağlamaktır. Kesintiler karşısında daha dayanıklı olması için TTL'yi uzatmayı düşünüyoruz. Anahtar sızıntısı durumunda, anahtar oluşturmayı manuel olarak zorunlu kılmayı ve anahtarları daha erken geçersiz kılmayı planlıyoruz. Koordinatör kesintisi durumunda hizmetlerin çalışmaya devam edebilmesi için ortak anahtarların şu anda istemcilerde 24 saat süreyle önbelleğe alındığını unutmayın. |
| Trafik Şekillendirme | Teklif Verme ve Açık Artırma Hizmetleri için Trafik Şekillendirme desteği. | Alıcılar, Yayıncı birinci taraf verilerine veya içerik verilerine göre Korunan Kitle açık artırmalarına yönelik talebi belirtebilir. Satıcılar, satıcının reklam sunucusunda veya Ad Exchange sunucusunda da benzer belirlemeler yapabilir. Modeller, birinci taraf verileri ve Korunan Kitle açık artırmalarından alınan tüm toplu raporlarla ilgili eğitilebilir. Satıcılar, Korunan Kitle açık artırmalarına yönelik talep olmadığında Teklif Verme ve Açık Artırma sunucularına istek gönderilmesini önlemek için bu bilgileri kullanabilir. Bunun, trafiği şekillendirmek için etkili bir yol olabileceğine inanıyoruz. |
| Bileşen Açık Artırması | Bileşen satıcılarıyla hangi üst düzey açık artırma sinyalleri paylaşılır? | Bileşen açık artırmasındaki alıcılar, yalnızca bileşen satıcısından sinyal alır. Başlıktan teklif alma (header bidding) ve korumalı kitle açık artırması ile birleşik bir açık artırmanın genel sırasıyla ilgili belgeleri yakında paylaşmak istiyoruz. |
| Video Oluşturma | Korunan Kitle ve Kısıtlanmış Çerçeveler kullanarak video oluşturma desteği. | Protected Audience API, iframe'lere dayalı bir mekanizma kullanarak video oluşturmayı destekler. Ancak henüz Çitli Çerçevelerle uyumlu bir çözüm tasarlamadık. Çitli Çerçeveler'in uygulanmasını 2026'ya geri çekmeye karar vermemizin nedenlerinden biri de budur. Yani, bir iş ortağı şu anda Kısıtlanmış Çerçeveler'i uygulamaya karar verirse bu iş ortağı video desteğinden yararlanamaz. |
| Sıklık sınırı | (Önceki çeyreklerde de bildirilmiştir) Kampanya ve reklam grubundaki kullanıcı başına sıklık kontrolleri. |
Önceki raporlardaki yanıtımız değişmez: Protected Audience, cihaz üzerinde açık artırmalar ile içeriğe dayalı ve marka bilinci oluşturma kampanyaları için sıklık sınırını da destekleyecektir. Ek sıklık sınırı kontrolleri için paylaşılan depolama alanı ve siteye özel sınırlar da kullanılabilir. |
| Reklam Tercihleri | Korunan Kitle, reklamveren siteleri tarafından devre dışı bırakma veya engellenenler listesine ekleme yöntemi ya da tüm ilgi alanı gruplarını aynı sahipten bırakma yolu sağlıyor mu? | Kullanıcıların Protected Audience API'ye ve diğer Özel Korumalı Alan özelliklerine erişimi engellemesinin birkaç yolu vardır. |
| Teklifli sistem ve açık artırma komut dosyalarının kaynak URL'si için aynı kaynak politikası | Komut dosyalarını veya JSON yükleme URL'lerini belirten tüm alanların sahiple aynı kaynak olması şartını hafifletin. | Şu anda bu isteği değerlendiriyoruz. Ekosistemden gelen ek geri bildirimleri almaktan memnuniyet duyuyoruz. |
forDebuggingOnly |
3 PCD sonrasında kalırsa forDebuggingOnly ürününün kötüye kullanılma olasılığı. |
Geçtiğimiz yıllarda, üçüncü taraf çerezleri kullanımdan kaldırıldıktan sonra Korunan Kitledeki işlev eksiklikleriyle ilgili ekosistemden geri bildirimler alıyoruz. Bu nedenle, Özel Korumalı Alan'ın hedeflerinden ödün vermeden 3PCD sonrasında bu kitleleri destekleyecek bir plan oluşturmak için çalışıyoruz. Ekosistemin görmek istediği eksik işlevlerle ilgili ek öneri ve geri bildirimleri de almaktan memnuniyet duyarız. |
| Birden Çok İlgi Alanı Grubu | Aynı teklifte birden fazla ilgi alanı grubu kullanma. | Bu, temel gizlilik modelinde değişikliğe neden olabileceğinden Protected Audience API'de şu anda desteklenmemektedir. Buradan daha fazla bilgi edinebilirsiniz. |
| Cihaz üzerinde açık artırmalar | Android'de Chrome, cihaz üzerinde Korunan Kitle açık artırmalarını destekleyecek mi? | Evet, cihaz üzerinde açık artırmalar Android üzerinde Chrome'da desteklenecektir. |
| (2023'ün 2. çeyreğinde bildirilmiştir) Tıklamayla ilgili veriler | Tarayıcı sinyallerine tıklamayla ilgili verileri ekleyin. | Bu özellik isteğini değerlendirmeye devam ediyor ve buna neden öncelik verilmesi gerektiği konusunda ek geri bildirimler bekliyoruz. |
| Güvenilir Yürütme Ortamı sağlayıcıları | Farklı bulut sağlayıcılarının Güvenilir Yürütme Ortamı tekliflerinde önemli farklılıklar var mı? | Büyük bir farklılıktan haberdar değiliz ancak ihtiyaçlarına en uygun çözümü bulmak için ekosistemin herkese açık dağıtım kılavuzlarını incelemesini öneririz. Google Cloud. AWS. |
| (Önceki çeyreklerde bildirilmiştir ) Negatif İlgi Alanı Grubu hedefleme desteği |
Negatif ilgi alanı grubu hedeflemeyi destekleyen bir API: Reklamları yalnızca kullanıcı bir ilgi alanı grubuna ait değilse gösterme. | Bu özelliği uygulamayı düşünüyor ve talep hakkında konuşuyoruz. |
| İçerik İhlali | Kullanıcıların, Kısıtlanmış Çerçevelerde Protected Audience API tarafından yayınlanan sakıncalı reklamları bildirmesine olanak tanıyan özellikleri destekleyin. | Mevcut Çerçeveli Çerçeve Reklamları Raporlama mekanizmasının, kullanıcı tarafından oluşturulan "Kötü Reklamlar" raporlama akışı isteyen reklam teknolojileri için iyi seçenekler sunduğuna inanıyoruz. Bu, günümüzde endüstri standardından çok farklı bir şekilde kötü reklam raporlamasına izin verir. Herhangi bir boşluk kalmaması durumunda, üçüncü taraf çerezlerinin kaldırılmasından sonra ve Sınırlanmış Çerçeve oluşturmanın yaygınlaşmasından önceki süre de dahil olmak üzere ek özellik isteklerini memnuniyetle karşılarız. |
| Private Aggregation API Raporlaması | Bir kullanıcının bu ilgi alanı grubunda geçirdiği süreyi nasıl hesaplayabiliriz? | Chrome M116 ve sonraki sürümlerde yenilik özelliğini pull/639 ile tanımlanan şekilde kullanabilirsiniz. |
| K-Anonimlik sunucusu | K-Anonimlik sunucusu hakkında daha fazla bilgi edinin. | Burada K-Anonimlik sunucuları hakkında daha fazla bilgi paylaştık ve ek geri bildirimlerinizi bekliyoruz. |
| Dinamik Reklam URL'leri | k-anonimliğe uyarken önceden beyan yapılmadan reklam öğesi URL'leri için destek. | Şu anda bu özellik isteğini ele alıyoruz. Buna neden öncelik verilmesi gerektiği konusunda ek geri bildirimleriniz bulunur. |
| K-anonimlik şartı | İlgi Alanı Grubu güncellemelerinde k-anonimlik şartı yeniden sunulacak mı? | Bu GitHub yayınında belirtilen konumda bir değişiklik beklemiyoruz. Bu yayında duyurduğumuz gibi, Korunan Kitle ilgi alanı grubu güncellemelerindeki k-anonimlik şartını kaldırmaya karar verdik. Bu güncelleme, API'nin genel gizlilik korumaları üzerinde önemli bir etkisi yoktur. Ayrıca, ilgili teknolojilerin daha geliştirilip dağıtıldığı ve kullanılmaya başlandığı sonraki bir tarihte, daha doğrudan olası diğer koruma türlerini (ör. IP adresi gizliliği veya güvenilir güncelleme sunucusu) göz önünde bulundurmayı planlıyoruz. |
| Teklif Verme ve Açık Artırma Hizmetleri Beta Testi | Teklifli Sistem ve Açık Artırma Hizmetleri Beta testi ne zaman başlayacak? | Zaman çizelgesi ve yol haritasında belirtildiği gibi, Teklifli Sistem ve Açık Artırma Hizmetleri testinin ilk aşaması Kasım 2023'te başlayacaktır. |
| Eşzamanlı | Reklam Ağları için Reklam öğesi koordinasyonunu destekleme isteği (STP ve TTP aynı şirket veya mülklerdedir). | Bu kullanım alanıyla ilgili geri bildirim için teşekkür ederiz. Daha fazla reklam teknisyeninin destek sunmayla ilgilenip ilgilenmediğini anlamak istiyoruz. Geri bildirimlerinizi bekliyoruz. |
| Doğal Reklamcılık | Yerel Reklamcılık için Çitli Çerçeve desteği. | Kullanım alanını desteklemeyi düşünüyor ve olası geçici çözümleri ve çözümleri tartışıyoruz. |
| K-anonimlik | K-anon eşiklerini karşılayan ilgi alanı grubu reklamlarını nasıl en üst düzeye çıkarabilirim? | Bu konuyla ilgili bazı taktiksel rehberlik paylaştık. |
| POST desteği | Açık artırma verilerini POST istekleri aracılığıyla gönderme desteği. | Bu özellik isteğini değerlendiriyoruz. Bu konuya neden öncelik verilmesi gerektiği konusunda GitHub ile ilgili yeni sorun gönderimlerini bekliyoruz. |
| Raporlama ayrıntı düzeyi | Birden Fazla Parçadan Oluşan Reklamlarla Çerçeveli Çerçeve reklam raporlamasının raporlama ayrıntı düzeyi nedir? | Mevcut tasarım, kullanıcı gizliliğini tehlikeye atabileceği için ürün kimliğinin veya konumunun yakalanmasına izin vermiyor. Yalnızca reserved.top_navigation çağrılabilir. Reklam bileşeni sınırlanmış çerçevede kullanıcı etkinleştirmesi (ör. tıklama) olduğunda bu işlem üst düzey gezinmeyle sonuçlanır. |
| Reklam açık artırması | Bileşen açık artırmasına katılan bir STP, başka bir bileşen açık artırmasını tetikleyebilir mi? | componentSeller, componentAuctions içeremez.Çok satıcılı açık artırmaların yalnızca iki düzeyi vardır: 1. Bileşen, paralel olarak açık artırmalar yapar. 2. Üst düzey açık artırma (her componentAuction arasından kazanan reklamın rekabet ettiği). |
| Teklif Verme ve Açık Artırma Hizmetleri'nin kullanılabilirliği | Teklif Verme ve Açık Artırma, Chrome'un desteklediği test aşamasında kullanılabilir mi? | Teklifli Sistem ve Açık Artırma Sunucusu, Chrome'un desteklediği test aşamasında kullanılamayacaktır. |
| Teklif sinyalleri | Tarayıcıların teklif sinyallerini istemesine ve silmesine izin verin. | Şu anda bu isteği inceliyoruz ve buna neden öncelik verilmesi gerektiğine dair ek geri bildirimleri bekliyoruz. |
generateBid() |
interestGroup'un userBiddingSignals öğelerini updateURL tarihine kadar güncelleme olanağı. |
Bu teklifi değerlendiriyoruz; ek geri bildirimleri ve tartışmaları memnuniyetle bekliyoruz. |
| Yayıncı Envanter Türleri | Korunan Kitle ve TOPICS testleri tarafından ne tür yayıncı envanteri desteklenir? | Korunan Kitle ve Konular, kullanılabilecek envanter türleri açısından doğası gereği kısıtlayıcı değildir. |
| Sunucudan Sunucuya entegrasyon | Korunan Kitle için STP ve TTP arasında doğrudan entegrasyon gerekli midir? | DSP'nin işlenen bilgileri cihaz üzerinde teklif verme işlevine iletmek için kendi sunucusunda içerik sinyalleri işlemesi gerekmiyorsa STP ile TTP arasında doğrudan entegrasyon gerekli değildir. |
B&A bölümünde bir bid_currency alanı |
Teklif Verme ve Açık Artırma Hizmeti'nde bid_currency alanı için destek. |
B&A henüz bid_currency desteği sunmuyor ancak Ocak 2024'ün sonuna kadar desteklemeyi planlıyoruz. Zaman çizelgesine buradan göz atın. |
perBuyerSignals |
perBuyerSignals için bir boyut sınırı var mı? |
Alıcı başına sinyal sayısıyla ilgili bir sınırlama yoktur, ancak çok fazla veri göndermek tarayıcının performansını olumsuz etkileyebilir. |
| Siteler arası kullanım alanları | Protected Audience API ilgi alanı gruplarını birden fazla web sitesinde kullanabilir miyiz? | Korunan Kitle, turtledove/issues/282 adresinde açıklandığı gibi bu tür kullanım alanları için tasarlanmamıştır. |
| İlgi Grubu HTTP İstekleri | HTTP üstbilgilerine İlgi Grubu Blob'u ekleyin. | Bu isteği değerlendiriyoruz ve bu istekle ilgili daha fazla geri bildirim almaktan memnuniyet duyuyoruz. |
| Reklam kalitesi kontrolü | Siteler arası bilgilerle ilgili reklam kalitesi kontrolünün kaybedilmesi. | Bu geri bildirimi değerlendiriyor ve ek geri bildirimleri almaktan memnuniyet duyuyoruz. |
| Chrome Geliştirici Araçları | Giden Korunan Kitle ağ istekleri Chrome Geliştirici Araçları Ağ sekmesinde görünür olmalıdır. | Bu işlevi ağ sekmesinde etkinleştirmek için çalışıyoruz ve buna neden öncelik verilmesi gerektiği konusunda ek geri bildirimlerinizi bekliyoruz. |
| Güvenilir Yürütme Ortamı | Hangi metriklerin gizliliği etkilediği (ve bunların dereceleri) ile ilgili ayrıntılar, Güvenilir Yürütme Ortamı izlemesindeki açıklayıcı bilgilere ne zaman eklenecek? | Açıklayıcıyı bu bilgilerle güncelliyoruz. Güncellenen açıklayıcı, Kasım 2023'te kullanıma sunulacaktır. |
directFrom |
directFrom neden web paketi olarak paketlenmiyor? |
Bu kararın gerekçesini burada paylaştık. |
| Gösterim yetkisi | Seçilen bir ilgi alanı grubunun sonucunun başka bir hedefleme işlemi olduğu durumlarda gösterim yetkilendirmesi yapmanın uygun bir yolu var mı? | İç içe yerleştirilmiş birden çok açık artırma, iki nedenden dolayı gizlilik hedeflerimizle uyumlu değildir. İlk olarak, açık artırmanın kazananı Kısıtlanmış Çerçeve içinde oluşturulduğunda, Korunan Kitle için gizlilik hedeflerimiz bağlam bilgisi olmadan sonuçta elde edilen reklam öğesini oluşturmayı içerir: Çevredeki sayfanın URL'si veya birinci taraf çerezi gizlilik ihlaline neden olur. Bu ortamda, iç içe yerleştirilmiş bir açık artırma uygun değildir. İkincisi, Korunan Kitle modeli, her açık artırmanın kazananının yalnızca bir ek siteden alınan verilere dayalı olması gerektiğini söyler. İç içe yerleştirilmiş açık artırmalar, bu verileri birleştirerek reklamları çok siteli bir profile göre seçme imkanı sunar. |
| Aktif Olmayan Veriler ölçütü | Anahtar/Değer hizmet güven modelindeki Aktif Olmayan Veriler ölçütünü daha ayrıntılı şekilde açıklayın. | Anahtar Değeri Hizmeti'ndeki veriler belleğe yüklenir ve okuma önbelleğine alma işlemi yapmak yerine oradan sunulur. |
| Alıcı Veri Sinyali | TTP'lerden alınan buyer_data sinyalleri için tanımlanmış bir boyut sınırı var mı? |
Şu anda DSP'lerden alınan buyer_data sinyalleri için tarayıcıya uygulanan bir sınır bulunmamaktadır. |
Dijital Reklamları Ölçme
Attribution Reporting (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Cihazlar arası | Attribution Reporting API için cihazlar arası desteği planlayın. | Cihazlar arası, 3PC'nin yanı sıra yeni gizlilik zorluklarını da beraberinde getirir ve ayrıca kullanıcının kullanabileceği cihaz ve platform çeşitliliğine bağlı olarak teknoloji dağıtımına ilişkin zorlukları da beraberinde getirir. Potansiyel çözümleri araştırıyoruz, ancak şu anda Attribution Reporting'in desteklediği kritik kullanım alanlarına odaklanıyoruz ve üçüncü taraf çerezleri kaldırılmadan önce cihazlar arası destek sunmayı planlamıyoruz. |
| (Önceki çeyreklerde de bildirilmiştir) Tetikleyici Veri Boyutu |
Tetikleyici veri boyutu neden 3 bit ile sınırlı? | Bir kullanıcı hakkında siteler arası ve bağlamlar arası bilgi miktarının sınırlı olmasını sağlamak için boyut, 3 bit ve 8 farklı değerle sınırlıdır. Ekosistem oyuncularının, etkinlik düzeyinde raporlama için mevcut parametrelendirmenin yeterli olup olmadığı konusunda geri bildirim göndermesini rica ediyoruz. |
| Dönüşüm hunisi | Dönüşümde kullanılan birden fazla alanı bildirin. | Bu kullanım alanı birden fazla hedef eklendiğinden mümkündür. Daha fazla geri bildirim almaktan memnuniyet duyarız. |
| Farklı ülkede aynı alan desteği | İlişkilendirme Raporları aynı Alana ancak birden fazla ülke TLD'sine sahip web siteleriyle çalışır mı? | Bu sorun, soruyu gündeme getiren paydaşla tartışılmış ve çözülmüştür. Bir reklam teknolojisinin birden fazla ülke TLD kullanması gerekiyorsa her bir ülke TLD'si için bir tane olmak üzere birden fazla kaydı olmalıdır. |
| Korunan Kitle ve İlişkilendirme Raporları | Reklam teknolojileri, hem Korunan Kitle açık artırmaları için görüntüleme dönüşümlerine hem de İlişkilendirme Raporlama için tıklama dönüşümlerine erişebilir mi? | Evet. Özel Korumalı Alan, Korunan Kitle'de hem GD'leri hem de TD'leri desteklemelidir. |
| Birleştirilebilir rapor gecikmeleri | Birleştirilebilir rapor gecikmelerini daha da azaltın. | Yakın zamanda bu konuyla ilgili geri bildirimler aldık ve fikirlerinizi burada paylaştık. Ekosistemin geri bildirimlerini almaktan memnuniyet duyarız. |
| Birleştirilebilir rapor gecikmeleri | Sunucu uyumlulaştırmasını kullanıma sunarak gecikmeleri azaltma. | Bu teklifi değerlendiriyoruz ve ek geri bildirimlerinizi bekliyoruz . |
| Etkinlik düzeyinde rapor gecikmeleri | Etkinlik düzeyindeki rapor gecikmelerini azaltın. | Etkinlik düzeyindeki esnek yapılandırmalarda açıklanan tam esnek etkinlik düzeyinde teklif, gürültü dengesi nedeniyle etkinlik düzeyinde raporlama gecikmelerini 1 saate kadar azaltabilir. |
| Kaynak başına kaynak raporlama kaynağı | Kaynak raporlama sitesi başına maksimum kaynak raporlama kaynaklarının sınırlandırılması, reklam teknolojilerinin tek bir yayıncı kaynağı için farklı raporlama kaynaklarından kaynak kaydetmesini engeller. | Bu, sorunu dile getiren paydaşla konuşuldu ve yönlendirme içeren diğer potansiyel çözümleri denemeden önce kaynak raporlama sitesi başına 1 raporlama kaynağı kullanmaya dair olası bir çözüm test ediliyor. Bu sınırla ilgili ek ekosistem geri bildirimlerine de açığız. |
| Sorun bildirme | Attribution Reporting API ile ilgili hataları veya sorunları Chrome'a nasıl bildirebiliriz? | Şu anda reklam teknisyenlerinin, Attribution Reporting API hatalarını GitHub'da bir sorun olarak görmelerini öneririz. Chrome ile ilgili bir sorun yaşıyorlarsa bir Chromium hatası oluşturmanızı öneririz. Sorunları nasıl ve nerede işaretleyeceğinize dair bağlantıları Etkileşim ve geri bildirim paylaşma bölümünde bulabilirsiniz. |
| Tekilleştirme | Farklı ardışık düzenler ve cihazlar arasında dönüşümleri nasıl tekilleştirebiliriz? | Cihazlar ve ölçüm ardışık düzenleri arasında veri yineleme gerçekleştirmek, üçlü PC'ler söz konusu olduğunda reklam teknolojilerinin de karşılaştığı güncel ve bilinen bir zorluktur. Attribution Reporting API sayesinde reklam teknisyenleri, belirli dönüşümlerin ne zaman kaydedileceğine karar verebilir ve dönüşümleri izlemek için hangi ölçüm ardışık düzenlerini kullandıklarını (yani, toplama anahtarının bir parçası) belirtmek amacıyla belirli meta veriler ekleyebilir. Bunlar, diğer ölçüm ardışık düzenleri ile karşılaştırılabilir. Bu konuyla ilgili ek ekosistem geri bildirimlerine açığız. |
| Tekilleştirme ve Öncelik | Tekilleştirmeden önce önceliğe sahip olmayı isteyin. | Bu isteği değerlendiriyoruz ve ek geri bildiriminizi bekliyoruz. |
| Sahtekarlıkla mücadele | Kötü amaçlı kullanıcının etkinlik düzeyindeki verilerde değişiklik yapma riski vardır. | Rapor doğrulama, Bu özellik etkinlik düzeyindeki raporları neden desteklemiyor? bölümünde açıklanan nedenlerle etkinlik düzeyinde raporlama için kullanılamaz. |
| Dönüşüm türü | İlişkilendirme Raporlarında görüntüleme ile gezinme arasında nasıl ayrım yapabiliriz? | Şu yerleşik filtreleme seçeneğine sahibiz: source_type.
Diğer ayrıntıları burada bulabilirsiniz. |
Toplama Hizmeti
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Bütçe kurtarma | Bazı reklam teknolojileri, raporlarıyla ilgili hata, hata veya silinmiş olan raporların yeniden işlenebilmesini istedi. | Ekip, gizliliği korumaya yönelik bir yaklaşımla bu sorunu ele almanın yollarını arıyor. |
| Site kaydı | Birden fazla reklam teknolojisi, verileri Geo'ya ve reklamverene göre bölme gibi kullanım alanları için aynı hesaptaki birden fazla kaynağı işleme konusunda destek istedi. İstemci API kaydının artık kaynak tabanlı değil site tabanlı olduğu düşünüldüğünde, reklam teknolojileri de bu davranışı beklemektedir. Kaynaktan site kaydına geçiş, istemci kayıt süreciyle tutarlılık sağlayarak reklam teknolojisi ilk katılım sürecini kolaylaştırır. | Kaynak kaydından Toplama Hizmeti için site kaydına geçiş işlemini yakında başlatacağız. Ekosistemden geri bildirim almaktan memnuniyet duyarız. |
| Sürüm ve Kullanımdan Kaldırma Planı | Toplama Hizmeti özellikleri ve yayınlanan yamalar için sürüm ve amortisman takvimi. Bu planın amacı, reklam teknisyenlerinin yayınlanacak sürümler ve desteğin sonlandırılmasına hazırlanmalarını sağlamak ve hizmetlerin kararlı ve güvenli sürümlerini çalıştırmalarını sağlamak için sürüm politikalarımıza görmesini sağlamaktır. | Kısa süre önce Toplama Hizmeti sürüm ve kullanımdan kaldırma planı ile ilgili bir teklif yayınladık. Ayrıca, ek geri bildirimlerinizi memnuniyetle karşılıyoruz. |
| Koordinatörler | Koordinatörler toplama hizmetine devre dışı kalırsa ne olur? | Sistemin doğru çalışabilmesi için her iki koordinatörün de tam olarak kullanılabilir durumda olması gerekir. Kısa süreli kullanılamama durumu, istemci kitaplıklarımızdaki yeniden denemelerle desteklenir. İki koordinatörden birinin uzun süre kullanılamaz olması toplama işlerinin başarısız olmasına yol açar. Gizlilik bütçesi henüz tüketilmemişse işler yeniden çalıştırılabilir. Herhangi bir hizmet arızası, reklam teknolojisi depolama alanına yazılmış bir özet rapor olmadan bütçe tüketimine neden olursa sonuçları yerel test aracı ile almak için hata ayıklama raporlarının kullanılmasını öneririz. Reklam teknisyenlerinin işlerini tekrar çalıştırabilmesi için hata durumlarında bütçenin geri kazanılmasını sağlayacak özellikler üzerinde de çalışıyoruz. |
Private Aggregation API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Blob URL'si | Paylaşılan Depolama Alanında Blob URL'sini destekleme isteği. | Chrome M116'da Blob URL'si desteği eklendi. |
Gizli Takibi Sınırla
Kullanıcı Aracısı Kısaltma ve Kullanıcı Aracısı İstemci İpuçları
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| JavaScript API | Kullanıcı Aracısı İstemci İpuçları JavaScript API'sinin kullanılabilirliği. | Yüksek entropili verilere, dondurulmuş ve azaltılmış UA'da varsayılan olarak bulunanların ötesinde etkin bir şekilde erişmek isteyen iş ortakları için temel çözümümüz olduğundan bu işlevi kaldırma planımız yoktur. |
| Cihaz ve form faktörü bilgileri | Web sitelerinin, web sitesini ziyaret eden cihaz tarafından desteklenen giriş, çıkış ve diğer bilgileri anlama yeteneği. | Ekosistemden aldığımız geri bildirimler üzerine bu istek için destek ekledik. |
IP Koruması (eski adıyla Gnatcatcher)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Uygun Üçüncü Taraf Trafik | Açıklayıcıda "uygun üçüncü taraf trafiği" ne anlama gelir? | Bu sorunun öneminin farkındayız ve hangi üçüncü taraf trafiğin uygun, hangilerinin uygun olmayacağını belirlemek için aktif olarak çalışıyoruz. Bu konuyla ilgili geri bildirimlerinizi memnuniyetle karşılıyoruz. |
| Ağ Trafiği Denetimleri | Kuruluşların, ağları için ağ trafiği denetimleri gerçekleştirme desteği. | Yalnızca birinci taraf sitelere yerleştirilmiş üçüncü taraf trafiği etkilenecektir. Bu nedenle, filtreleme gerektiren trafik miktarı sınırlanacaktır. Buna ek olarak, kullanıcılara IP Koruması'nı kullanıp kullanmama seçeneği sunmayı planlıyoruz ve kurumsal denetimdeki Chrome için IP Koruması'nı devre dışı bırakacak kurumsal politikalar olacak. Son olarak, IP Koruması'nı devre dışı bırakmak için ağ operatörlerine hangi kontrollerin (varsa) sağlanacağını araştırıyoruz. Bu konuyla ilgili geri bildirimlerinizi bekliyoruz. |
| Erişim denetimi | IP Koruması, erişim denetimi için IP adresleri kullanan web hizmetlerini etkileyebilir. | Sahtekarlıkla mücadele kullanım alanlarının önemini ve bunun bu kullanım alanları üzerindeki olası etkisini biliyoruz. Genellikle IP adreslerine dayalı sahtekarlıkla mücadele kullanım alanlarını nasıl daha iyi destekleyebileceğimiz konusunda ekosistem geri bildirimleri alıyoruz. |
| 2-Hop proxy'ler arasındaki iletişim | Proxy'ler arasında bilgi olmaması nasıl sağlanır? | Proxy etkileşimlerini tasarlama sürecindeyiz. Hedefimiz, iş, süreç ve teknik yollarla bu tür bilgi paylaşımı olasılığını en aza indirmektir. |
| Google Dışı Kimlik Doğrulamaları | Google Dışı Kimlik Doğrulamaları İçin Destek. | Gelecekte hesap kimlik doğrulaması hakkında daha fazla ayrıntı yayınlamayı planlıyoruz, ancak ilk başta dikkat edilmesi gereken bazı noktaları paylaşmıştık. |
| Takip cihazı sınıflandırması | IP Koruması, izleyiciyi ve izleyicinin varyantlarını nasıl belirleyecek? | Bu sorunun öneminin farkındayız ve hangi üçüncü taraf trafiğin uygun, hangilerinin uygun olmayacağını belirlemek için aktif olarak çalışıyoruz. Bu konuyla ilgili geri bildirimlerinizi memnuniyetle karşılıyoruz. |
| Analizler | IP Koruması, analiz hizmetlerinin doğruluğunu etkileyebilir. | IP Koruması'nın etkisini daha iyi anlamak istiyoruz ve ekosistemden gelen ek geri bildirim ve örnekleri memnuniyetle karşılıyoruz. |
| Proxy | Bir kullanıcı proxy kullanıyorsa veya manuel olarak bir proxy tanımladıysa IP Maskesi bu durumda nasıl çalışır? | IP Koruması'nın diğer proxy'ler üzerindeki etkisini anlamaya çalışıyoruz. Şu anda bu konuyla ilgili herhangi bir planımız yok. Bu konuyla ilgili geri bildirimlerinizi bekliyoruz. |
| Premium çözüm | IP Koruması ücretli bir özellik olacak mı? | IP Koruması, temel tarayıcı deneyiminin bir parçası olarak Chrome kullanıcılarına sunulacaktır. Bu, ücretli bir özellik olmayacaktır. |
| Proxy sunucu | Kullanıcı oturumları sırasında aynı proxy sunucuları mı kullanılacak? | HTTP/S bağlantısı, tek bir proxy çifti kullanır ve kaynağa tek bir maskelenmiş IP adresi sunar. Bunun ötesinde, farklı HTTP/S bağlantılarında aynı sunucuları kullanması gereken katı kısıtlamalar yoktur. |
| Platform desteği | IP Koruması hangi platformda desteklenecek? | IP Koruması, başlangıçta Android ve Masaüstü için Chrome'da kullanıma sunulacaktır. Korumayı diğer platformlara nasıl genişleteceğimizi değerlendirmeye devam ediyoruz. |
| Devre dışı bırak | Kullanıcılar IP Koruması'nı devre dışı bırakabilecek mi? | Kullanıcılara IP Koruması kullanmak isteyip istemediklerine dair seçenek sunmayı planlıyoruz. |
| Anonimleştirme | IP Koruması kapsamında ne tür istekler anonimleştirilir? | Uygun üçüncü taraf alanlarına gönderilen HTTP/S ve DNS istekleri, gizlilik proxy'leri aracılığıyla anonimleştirilir. Hangi alan adlarının dahil edileceğini nasıl belirleyeceğimiz hakkında daha sonraki bir açıklamada ek bilgiler sağlayacağız. Trafiğin geri kalanı (örneğin, DNS isteklerinin geri kalanı veya diğer HTTP/S trafiği) etkilenmez. |
| Veri Görünürlüğü | Ağ adreslerine, IP Koruması'nda ilk durak sırasında erişilebilir. | İki duraklı proxy modelinde, ilk durak (Google tarafından kontrol edilir) yalnızca kaynak istemci IP'sini ve ikinci duraka bağlanma isteğini görürken ikinci durak (harici bir CDN tarafından kontrol edilir) yalnızca ilk durakta (proxy IP + bağlantı noktası) ve hedef IP'de bir unsur görür. Kaynaktan gelen yanıt için ikinci durak, yanıtı istekle ilişkili ilk durak proxy+bağlantı noktasına yönlendirebilir ve orijinal istemci IP'si hakkında hiçbir şey öğrenmesine gerek yoktur (ve ilk durak, hedef IP hakkında hiçbir şey öğrenmeden yanıtı istemciye döndürür). Bu şekilde, ilk durak yalnızca istemci IP'sini ve ikinci durağı öğrenirken ikinci durak yalnızca hedef IP'yi öğrenir. |
| WebView | IP Koruması gelecekte Android WebView için kullanılabilecek mi? | Şu anda paylaşacak herhangi bir planımız yok ancak bu korumayı mümkün olduğunca geniş bir kitlenin kullanımına sunmayı amaçlıyoruz. |
Hemen Çıkma Durumunu İzleme Çözümleri
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Etkileşim İzleme | Kullanıcı etkileşimleri nasıl izlenir? | Hemen çıkma durumunu izleme çözümleri, iki tür kullanıcı etkileşimini izler:
Bu etkileşimler, gerçekleştikleri sayfalarda üst düzey siteyle ilişkilendirilir. Örneğin, bir kullanıcı yerleştirilmiş bir iframe'i tıklarsa etkileşim, yerleştirilmiş siteyle değil, üst düzey siteyle ilişkilendirilir. Etkileşimler, şemasız etld+1 ve etkileşim zamanını içeren bir veritabanında depolanır. Etkileşimler, ilişkili alanı 45 gün boyunca hemen çıkma izleme riski azaltma durumunun silinmesine karşı korur. |
| İzin Verilenler Listesindeki Muafiyetler | Alanlar muaf tutulabilir mi? | Bu isteği değerlendiriyoruz ve ekosistemden geri bildirim almaktan memnuniyet duyarız. |
Gizlilik Bütçesi
Bu üç aylık dönemde geri bildirim alınmadı.
Siteler arası gizlilik sınırlarını güçlendirin
İlişkili Websitesi Grupları (eski adıyla Birinci Taraf Gruplar)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Merkezi Yaklaşım | İlişkili Websitesi Gruplarını yönetmeye yönelik merkezi depo yaklaşımıyla ilgili endişeler. | Herkese açık, kolayca erişilebilen bir depo, gönderimler için hesap verebilirlik sağladığından RWS'nin tasarımında kilit rol oynar. Üçüncü taraf çerezi işlevi, nihai olarak Storage Access API'nin veya rSAFor API'sinin kullanılmasıyla sağlanır. RWS üyeliği ise otomatik olarak erişim sağlar (Storage Access API'yi içeren istemlerin aksine). RWS gönderim süreci gibi bir yaklaşımın, otomatik olarak sağlanan üçüncü taraf çerezlerine erişim için uygun bir gereklilik olduğuna inanıyoruz. |
| JSON dosyası yeniden adlandırılıyor | API adı değiştirildiğinde, barındırılan JSON dosyasının adının değiştirilmesi gerekir mi? | Evet, gönderim yönergeleri değiştirildi ve birincil alan, /.well-known/related-website-set.json adresinde bir JSON dosyası sunmalıdır. RWS listesindeki mevcut grupların değiştirilmesi gerekmez ancak mevcut gruplara gönderilen değişiklikler varsa JSON dosyası değiştirilmelidir. |
| (Önceki çeyreklerde de bildirilmiştir) Alan Sınırı | İlişkilendirilmiş alan adlarının sayısını artırma isteği | 31 Ağustos'taki bir blog yayınında duyurulduğu gibi, ekosistemden gelen geri bildirimin ardından ilişkili alan sınırını beş alana yükselttik. İlişkili alan adı sınırını, başka bir büyük tarayıcının sunduğu en karşılaştırılabilir uygulamaya en uygun olan beş alan adına (artı bir birincil alan) artırmaya karar verdik. |
| Üçüncü Taraf Çerezleri | İlişkili Websitesi Grupları yalnızca üçüncü taraf çerezleri devre dışıyken mi çalışacak? | İlişkili Websitesi Grupları, kullanıcı üçüncü taraf çerezlerini engellemediğinde bile çalışır ancak ilgili çerezler İlişkili Websitesi Grupları ve Storage Access API'ye ihtiyaç olmadan kullanılabildiği için gözlemlenebilir bir etkisi olmaz. |
| Yasal düzenlemeler | İlişkili Websitesi Grupları deposu, sahip olmayan kullanıcıların grupları değiştirmesini nasıl engeller? | Gönderim kılavuzlarına göre, isteyen herkes GitHub'da first_party_sets.JSON dosyasını düzenlemek için bir PR gönderebilir. Bununla birlikte, PR onaylanırsa (teknik doğrulamalardan geçer vb.) Google tarafından haftada bir kez (Salı günleri Doğu Saati ile 12:00'de) standart FPS listesine manuel olarak birleştirilir.Kötü bir kullanıcı sahip olmadığı bir grupta değişiklik yapmaya çalışırsa .well-known dosyalarını değiştiremeyeceği ve dolayısıyla doğrulamalar başarısız olacağı için sorun yaratmayacaktır. |
| Alan adı ele geçirme | Alanın ele geçirilmesi, ilgili alan verilerinin yetkisiz taraflara devre dışı bırakılmasına neden olabilir. | Bu, Korunan Kitle GitHub sorunundaki açıklandığı gibi mümkün değildir. |
Çitli Çerçeveler API'sı
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| İçerik İhlali | Kullanıcıların şüpheli reklamları bildirmesine izin verin. | Şüpheli reklam raporları, Kısıtlanmış Çerçeveler tarafından engellenmez. Kullanıcılar her zamanki gibi reklamla etkileşimde bulunmaya devam edebilir ve şüpheli reklamları reklam teknolojisine bildirebilir. |
| Çevredeki sitelerle etkileşim | Çevredeki veya üst düzey web sitesiyle etkileşime izin verin. | Bu isteğin neden gerekli olduğunu anlamaya çalışıyor ve ekosistemden gelecek ek geri bildirimlere açığız. |
| Doğal Reklamcılık | Yerel Reklamcılık için Çitli Çerçeve desteği. | Kullanım alanını desteklemeyi düşünüyor ve olası geçici çözümleri ve çözümleri tartışıyoruz. |
Shared Storage API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Alanlar arası | Yerel depolama için alanlar arasında iletişime izin verin. | Bu kullanım alanı şu anda Shared Storage'ın gizliliği korumaya yönelik çıkış kapılarıyla uyumlu değildir ancak bölümlendirilmemiş depolama alanı için teklifleri geliştirirken ek bağlam sağlamaktan memnuniyet duyarız. |
| Blob URL'si | Paylaşılan Depolama Alanında Blob URL'sini destekleme isteği. | Chrome M116'da Blob URL'si desteği eklendi. |
ÇİPLER
Bu üç aylık dönemde geri bildirim alınmadı.
FedCM
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Üçüncü taraf çerezleri | Kullanıcılar Chrome ayarlarında "Üçüncü taraf çerezlerini engelle" seçeneğini etkinleştirdiğinde FedCM şu anda devre dışı mı? | Evet, FedCM şu anda devre dışı. Test için chrome://flags/#fedcm- özelliğini de etkinleştirmenizi öneririz.Gelecekte üçüncü taraf çerezleri olmadan FedCM'yi desteklemeyi amaçlıyoruz. |
Spam ve sahtekarlıkla mücadele edin
Private State Token API (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Jetonun son kullanma tarihi | Google Chrome kaldırıldıktan sonra Jeton kaybolur mu yoksa önbelleğe alınır mı? | Kullanıcı Google Chrome'u kaldırırsa jeton kaybolur. |
| Jeton Bilgileri | Kartı veren kuruluşlar, Gizlilik Jetonu içindeki yayınlanmış bilgileri nasıl gizli tutabilir? | Bilgiler jetonda her zaman gizli tutulur ve anahtara sahip olmayan harici taraflar tarafından şifrelenemez. |
| Demoda hata | Gizlilik Jetonu demosu çalıştırılmaya çalışılırken hata oluştu. | Demoyu güncelledik ve şu anda düzgün çalışıyor olması gerekir. |