Özel Korumalı Alan teklifleri ve Chrome'un yanıtları hakkında alınan ekosistem geri bildirimlerini özetleyen, 2023'ün 1. ç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 odağını yansıtmakla birlikte, özellikle Topics, FLEDGE 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, belirli bir API/Teknoloji yok
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Test etme ve deneme | Test başladığında Özel Korumalı Alan API'lerinin tamamlanmadığı durumlarda CMA'nın değerlendirmesini bildirmek için gereken testin alaka düzeyi | Özel Korumalı Alan API'leri hızla geliştiriliyor.
Bunlar, test için Kaynak Denemesi'nde zaten mevcuttur ve bu yaz genellikle trafiğin% 100'ünde kullanıma sunulacaktır. Ayrıca, 2026'dan önce etkilenmeyecek belirli özellikler (ör. FLEDGE etkinlik düzeyinde raporlama, iframe'lerle FLEDGE oluşturma) için zaman çizelgelerini netleştirdik. Ekosistemin, API'leri test etmesini ve test kullanıcılarının üçüncü taraf çerezleri kullanımdan kaldırıldığında neye güvenmek istediklerini temel alarak CMA'ya geri bildirim sağlamalarını öneririz. Bu durum, üçüncü taraf çerezlerinin kullanımdan kaldırılmasının olası etkisini değerlendirmesine katkıda bulunabilir. |
| Kullanıcı denetimleri | Özel Korumalı Alan API'lerinin kullanıcı denetimleriyle ilgili etkileri hakkında ekosisteme net rehberlik | Ekosistemin kullanabileceği kullanıcı denetimleri konusunda yasal tavsiye veremeyiz. Aynı zamanda Chrome, Özel Korumalı Alan teknolojilerini geliştirmeye yönelik sürekli çabalarımızın bir parçası olarak, güncellenmiş Özel Korumalı Alan ("Gelişmiş Reklam Gizliliği") kullanıcı kontrollerini çok küçük bir kullanıcı yüzdesine göstermek için denemeler yapmaktadır. Güncellemeler daha net, daha faydalı dil ve düzenler içeriyor. Chrome bu iyileştirmeleri değerlendirdikten ve bunları daha büyük bir kitleye genişletmeye karar verdikten sonra ekosistemle daha fazla bilgi paylaşabilir. |
| Veri sızıntısı | Tarayıcının güvenliği ihlal edilirse birinci taraf verilerinin Google'a ve diğer taraflara sızdırılma riski | FLEDGE açıklayıcımız, bir reklam teknolojisi verilerinin yalnızca aynı reklam teknolojisiyle (iş akışları veya güvenilir sunucularıyla) veya bu reklam teknolojisi tarafından açıkça paylaşıldığında (örneğin, bir alıcının görüntülemek istediği reklam URL'sini satıcıya göstermesi gibi) açıkça paylaşıldığını gösterir. Bunun tek istisnası, k-anonimlik kontrolünün önemli miktarda kaynak ayırmaya devam ettiğimiz bir merkezi global merkezi sunucu tarafından yapılmasıdır. Gizliliği nasıl ele aldığımızı ayrıntılı bir şekilde görmek için K-anonimlik açıklamasına bakın. Bunun ötesinde, k-anonimlik sunucusunun tasarımında kullanılan reklam teknolojisi korumalarının nasıl çalıştığıyla ilgili daha fazla ayrıntı sağlamaya açığız. |
| Ek tartışma forumu | Teknik olmayan ekosistem oyuncularının geri bildirim paylaşmaları için W3C'ye ek forum talebi | Özel Korumalı Alan geri bildirim formu, teknik ve teknik olmayan genel ve özel yorumlar için uygundur. Web Reklamcılığını İyileştirme İş Grubu, haftalık çağrılar ve GitHub deposu aracılığıyla tartışmalara dökülen bir forumdur. developer.chrome.com adresindeki Özel Korumalı Alan Geri Bildirim sayfasında geri bildirim sağlamak ve tartışmalara katılmak için kullanılan diğer mekanizmalar açıklanmaktadır. Chrome, soruları ve içerik paylaşımını kolaylaştırmak için herkese açık Ofis Saatleri gibi etkinlikler düzenlemeye de devam etmektedir. Ayrıca, Chrome geçtiğimiz çeyrekte bir düzineden fazla sektör etkinliğine ev sahipliği yaptı veya bu etkinliğe katıldı. |
| Zaman çizelgesi açıklaması | 2023'ün 3. çeyreğinde genel kullanıma sunulacağı tam tarihle ilgili açıklama | PrivacySandbox.com'da yayınlanan zaman çizelgesine göre Genel Kullanım, Chrome 115 sürümüyle birlikte kullanıma sunulmaya başlayacaktır. |
| reCAPTCHA | reCATPCHA'nın spam algılama kullanım alanı için Sandbox API'lerinin etkisi | Özel Korumalı Alan tekliflerinin web güvenliğini veya sahtekarlığı önemli ölçüde etkilemediğinden emin olmak için reCAPTCHA'dan düzenli olarak geri bildirim alıyoruz. Üçüncü taraf çerezlerinin kullanımdan kaldırılmasına hazırlanmak ve bu duruma uyum sağlamak için kendi planlarını geliştirmektedirler. Bu nedenle, bu sorunun cevabını onlar için en iyi şekilde belirleyebilirler. |
| Chrome Uzantıları | Gizli Korumalı Alan İzleme (ACT) önlemleri gibi Özel Korumalı Alan teknolojileri Chrome uzantıları için geçerli olur mu? | ACT'nin Chrome uzantıları için geçerli olup olmadığı konusunda herhangi bir duyuru yapmadık. Ancak bir teknoloji gizli bir şekilde kullanıcı hakkında bilgi toplarsa, bu durum gizlilik ilkelerimize uygun olmaz. |
Alakalı İçerik ve Reklamlar Gösterin
Konular
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| TAG Tasarım İncelemesi | TAG, Konularla İlgili Erken Tasarım İncelemesi'ni yayınladı. | Topics'e bağlılığımızı sürdürüyoruz. Ayrıca, en son güncellemeler sayfasında ve bu sayıda Topics'e bağlılığımızla ilgili bir güncelleme paylaştık. TAG incelemesini tek tek yanıtladık ve üst düzey vizyonumuzu burada paylaştık. Topics API, reklam ekosisteminin 2023 boyunca test etmesi gereken API koleksiyonunun bir parçası olmaya devam edecek. Aldığımız test geri bildirimlerinin ve elde ettiğimiz uygulama deneyiminin, gelecekteki tarayıcılar arası standartlara yönelik çalışmalara değerli katkılar olacağını umuyoruz. Topics API'nin tarayıcılar arası uyumluluk konusunda üzerinde anlaşmaya varılmış bir standart olabileceği olası bir geçişi nasıl kolaylaştırabileceğimiz konusunda ekosistemle etkileşimde bulunmaya devam etmeyi umuyoruz. |
| Konulara Yaklaşım | Chrome'un Topics API'yi geliştirmek için açık yaklaşım desteği | Gösterdiğiniz anlayış için teşekkür ediyor ve genel olarak ekosisteme değer sağlayan bir Topics API geliştirmek için sektör grubuyla çalışmaya devam etmeyi umuyoruz. |
| (2022'nin 3. çeyreğinde de bildirilmiştir) Konular sınıflandırması yeterince ayrıntılı değil |
Geniş konular sınıflandırması, bölgeye özel bilgiler de dahil olmak üzere daha ayrıntılı konuları içermez. | 1. Çeyrek Güncellemesi: Sınıflandırmada çalışmalarımızı sürdürüyoruz. 2. çeyrekte Topics API için güncellenmiş sınıflandırmanın duyurusunu yapacağız. Bu yeni sınıflandırmayı oluşturmak için ekosistemdeki şirketlerle yakın bir şekilde çalıştık. Ekosistem için en yararlı sınıflandırma hakkında aktif olarak geri bildirim alıyoruz. Konu sayısının artırılması veya daha ayrıntılı konuların dahil edilip edilmeyeceğini değerlendirirken, 1) olası gizlilik sonuçları (daha fazla konu için dijital parmak izi riskine yol açabilir) ve 2) önceden gözlemlenen konuları alabilmek (örneğin, daha fazla konuda, bir reklam teknolojisinin seçilen konuyu geçmişte görme olasılığı daha düşük olabilir) göz önünde bulundurulacak birkaç nokta göz önünde bulundurulur. |
| (2022'nin 4. çeyreğinde de bildirilmiştir) Birinci taraf sinyalleri üzerindeki etkisi |
Konular sinyali çok değerli olabilir ve sonuç olarak diğer birinci taraf ilgi alanına dayalı sinyallerin değerini düşürür. | İlgi alanına dayalı reklamcılığın web için önemli bir kullanım alanı olduğuna inanıyoruz ve Topics'in bu kullanım alanını destekleyecek şekilde tasarlandığına inanıyoruz. Bazı büyük yayıncıların, Topics'in birinci taraf veri stratejilerini olumsuz etkileyeceğinden endişe ettiğini biliyoruz. Topics'in yayıncılar üzerindeki etkisine ilişkin analizler sağlayacak ekosistem testlerini bekliyoruz. |
| Reklamlarla alakalı olmayan Konular'ın kullanım alanları | Topics'in ilgi alanına dayalı reklamcılık görüntüleme dışındaki amaçlarla kullanılması | Topics, ücretsiz ve açık web için kritik bir kullanım alanı olduğuna inandığımız ilgi alanına dayalı reklamcılık kullanım alanını ele alacak şekilde tasarlanmıştır. Şu anda başka kullanım alanları için geri bildirim arıyor ve değerlendirme yapıyoruz. |
| Varsayılan etkinleştirme durumu | Konular için izin varsayılanı ile ilgili bölgesel mevzuatın etkileri | Yasal görüşler hakkında yorum yapmayı kabul etmiyoruz. |
| (2022'nin 3. çeyreğinde de bildirilmiştir) Yanlış kategorize edilmiş siteler |
Belirli bir site için konular yanlış sınıflandırıldığında hedeflenen reklam sayısı | 1. Çeyrek Güncellemesi: 2. çeyrekte Topics API için güncellenen bir sınıflandırıcıyı duyuracağız ve bu sınıflandırıcıdaki ekosistemle etkileşimde bulunmayı heyecanla bekliyoruz. Mevcut geri bildirimler doğrultusunda siteler, gerçek kişiler tarafından seçilen bir geçersiz kılma listesi, en popüler siteleri ve cihaz üzerinde ML modeli kullanılarak sınıflandırılmaktadır. Chrome, Konular sınıflandırmasına katkıda bulunmak için site seçeneklerini değerlendirmeye devam ediyor. Faydayla ilgili tüm iyileştirmeler, gizlilik ve kötüye kullanım riskleri açısından değerlendirilmelidir. Söz konusu riskler arasında şunlar yer alır: Kendini etiketleme özelliğini kullanarak farklı (ve potansiyel olarak hassas) anlamları konularla ilgili kodlamaya yönelik bir yöntem olarak kullanan siteler, maddi kazanç sağlamak amacıyla konuları yanlış beyan eden siteler; başkaları açısından faydalılığını artırmak amacıyla konulara saldıran siteler (örneğin, kullanıcı konularına anlamsız bir şekilde spam gönderme). chrome://topics-internals veya bu colab aracılığıyla sunulan araçlarla bu bileşenleri herkes inceleyebilir. Test sayesinde, sınıflandırmanın zaman içinde iyileşmesini bekleriz ve yanlış kategorize edilmiş olabilecek site örnekleriyle ilgili geri bildirimlerinizi bekleriz. |
| Konu Sınıflandırıcı | Hata ayıklama amacıyla, arayan kişiye "Konu Yok" mesajının neden döndürüldüğünü gösteren ek bilgilerin döndürülmesini isteme | Topics API'yi sistemlerine entegre etmek için çalışan geliştiricilerin hata ayıklama araçlarına yardımcı olduğunu anlıyor ve bunu takdir ediyoruz. Bununla birlikte, ek bilgileri (ör. Topics'in döndürülmemesinin nedeni) açıklayarak kullanıcıların ek ayrıntıları açığa çıkarmasına olanak tanıyan bilgileri (örneğin, kullanıcı gizli moddaysa, API'yı devre dışı bırakmışsa vb.) yanlışlıkla paylaşabilir ve kullanıcı gizliliğine zarar verebiliriz. Şu anda başka hata ayıklama araçları sunmayı planlamasak da hangi araçların değerli olacağı konusunda geri bildirimlere açığız. |
| Özel Bilgi Erişimi (PIR) | Topics API'nin Özel Bilgi Erişimini benimseme isteği | PIR kullanımıyla ilgili araştırmamızı daha önce yapmış ve karşılaştırmaları burada paylaşmıştık. |
| Teklif akışı | Konular, teklif akışında Satıcı Tanımlı Kitleler'den farklı bir şekilde mi temsil edilecek? | Topics API, Chrome tarafından geliştirilen bir Özel Korumalı Alan teklifidir. IAB Tech Lab Satıcı Tarafından Tanımlanan Kitleler teklifinden farklıdır. Bu ikisinin teklif akışında farklı bir şekilde temsil edilmesini bekliyoruz. Topics'in OpenRTB teklif isteklerinde nasıl temsil edileceğini öğrenin. |
Protected Audience API (eski adıyla FLEDGE)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| FLEDGE özelliklerinin kullanılabilirliği | Fenced Frame yaptırımı, K-Anonimlik vb. FLEDGE özelliklerinin test ve uygulama zaman çizelgelerine dair açıklama. | Çeşitli kapsamlı FLEDGE özellikleri ve ne zaman desteklenecekleri hakkında bir blog yayını paylaştık. Biz FLEDGE'i geliştirmeye devam ederken, duyuruyla ilgili ek geri bildirimler almaktan memnuniyet duyarız. |
| Ürün oluşturma kısıtlamaları | FLEDGE Çitli Çerçeveler için Birden Fazla Parça kısıtlamalarından oluşan reklamları gevşetme isteği | Şubat ayında duyurduğumuz gibi, Çitli Çerçevelerin kullanımı en az 2026'ya kadar isteğe bağlı olacak ve iframe davranışı urn-iframe'ler tarafından desteklenecektir. Bu konuyla ilgili daha fazla tartışmayı hoş geldiniz. |
| Ölçeklenebilirlik sorunları | Kullanım ölçeği olarak FLEDGE performansı | Eyleme dökülebilir çözümler önerebilmek için geri bildirimleri etkin bir şekilde takip ediyor ve daha ayrıntılı bilgi ediniyoruz. İlk adımda, geri bildirimleri iki kategoriye ayırdık ve bunu şöyle yaptık:
|
| (2022'nin 3. çeyreğinde de bildirilmiştir) Teklif mantığının görünürlüğü |
TTP teklif verme mantığının JavaScript'te gösterileceğine dair endişe | 1. Çeyrek Güncellemesi: Rakiplerin keşif amaçlı (zorunlu olarak göz atma) yöntemiyle sunucudan veri isteme olanağını kısıtlayacak bir teklif paylaştık. Ayrıca ekosistem oyuncularının teklifle ilgili geri bildirimlerini veya desteğini paylaşmalarını da bekliyoruz. |
| Test zorlukları | Daha küçük TTP'lerin FLEDGE'i düzgün bir şekilde test edebilmesi ve reklamverenlerin yalnızca daha büyük TTP'lerle test etmekle ilgilenmesi riskini azaltma becerisi | Daha küçük TTP'lerle çalışmaya kararlıyız ve FLEDGE genel kullanıma sunuldukça TTP'ler ve her büyüklükteki reklamveren arasında testlerin kapsamını artırmayı önemle tavsiye ederiz. Bu kullanıcılara, FLEDGE'i ekosistemdeki diğer kişilerle birlikte test etme konusunda en iyi nasıl yardımcı olabileceğimizi öğrenmek isteriz. Ayrıca, reklamverenleri daha küçük TTP'lerle test yapmaya motive edecek fikirleri ve sektör çalışmalarını memnuniyetle karşılıyoruz. |
| Dinamik yeniden pazarlama | Üçüncü taraf çerezleri için destek sonlandırıldıktan sonra FLEDGE ile Dinamik yeniden pazarlama kullanılmaya devam edecek mi? | Bu soruya bir yanıt vermeyi değerlendiriyoruz. Ekosistem oyuncularının, Dinamik yeniden pazarlamayı kullanma amaçlarıyla ilgili ek analizler paylaşmalarını bekliyoruz. |
| Sahtekarlık/Kötüye kullanım | Ekosistem, riskleri azaltmak ve kötü niyetli kişilerin veya alıcıların kendilerini istenen bir kitle olarak konumlandırmasını nasıl engelleyebilir? | Ekosistemdeki oyuncularla sahtekarlık ve kötüye kullanım konularında daha fazla etkileşime geçmek için sabırsızlanıyoruz ve bu alanda daha fazla geri bildirim almaktan memnuniyet duyuyoruz. |
| Kullanıcı tercihleri | Kullanıcı tercihlerini kaydetme ve reklam seçiminde kullanma süreci | Belirli reklamlar için, ilgili reklam teknolojisi hangi reklam öğelerinin gösterileceği veya nasıl seçileceği konusunda kontrol olanağı sunacak en iyi konumdaki taraftır. |
| Nicel Test teklifi | Nicel Test'in adil olması için test, üçüncü taraf çerezleri olmayan trafik üzerinde mi yoksa yalnızca FLEDGE kullanan STP'ler ile mi gerçekleştirilmelidir? Üçüncü taraf çerezlerinden gelen sinyallerin birlikte kullanılması nasıl önlenebilir? | Bu geri bildirim bizim için çok değerlidir. Üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ve ekosistemde Özel Korumalı Alan tekliflerinin kullanıma sunulmasının etkisini güvenilir bir şekilde gösteren denemeler tasarlamak için CMA ile birlikte çalışıyoruz. CMA'nın Nicel Test teklifiyle ilgili daha fazla geri bildirimin CMA ile doğrudan paylaşılmasını öneririz. |
| Daha net belgeler | Açık artırma yapılandırmasıyla ilgili daha net belgeler isteme | Önümüzdeki haftalarda, FLEDGE Açık Artırma Raporları hakkında ek bilgiler içeren bir blog yayını paylaşmayı umuyoruz. |
| Paralel yapma | Teklifli Sistem ve Açık Artırma (B&A) Hizmeti, Paralelleştirmeyi destekleyecek mi? | Teklif Verme / Açık artırma sunucularını kullanan bir reklam teknolojisi, paralel olarak sonuç sunabilen birden fazla sunucu başlatabilir. |
| Kötüye kullanımı azaltma | Gizlilik Jetonlarını kullanan FLEDGE k-anonimlik sunucusu, kullanıcı gizliliğini sağlamak için yeterli midir? | K-anonimliğin motivasyonu, mikro hedeflemeye daha az odaklanmıştır. FLEDGE'in etkinlik düzeyinde raporlamaya izin verdiği ara aşama sırasında daha çok geriye odaklanılmasına odaklanmıştır. Şimdiye kadar sizinle daha fazla görüş paylaştık ve ek geri bildirimler almaktan çekinmeyin. |
| ES Modülü çakışması | ES modülüyle çakıştığından generateBid öğesini global bir işlev olarak bırakma isteği |
Bu talep üzerine tartışıyoruz ve ek geri bildirim almaktan memnuniyet duyarız. |
| Bileşen açık artırması | Yayıncılardan açık artırma tasarımları üzerinde daha fazla kontrole sahip olmalarını isteme | Cihaz üzerinde Chrome'da olduğu gibi, bileşen açık artırmasını destekleyecek teklif ve açık artırma planı. |
| Kararlar ve Cevaplar Zaman Çizelgeleri | B&A Server'ları test etmek isteyen reklam teknolojileri için zaman çizelgesine ilişkin netlik | Kısa süre önce B&A Explainer'ı güncelledik ve CMA ile işbirliği yaptıktan sonra Chrome-B&A testinin farklı aşamalarına ilişkin zaman çizelgelerinin net tanımlarını içerecek şekilde Zaman Çizelgesi bölümünü güncelledik. |
| Zaman aşımı kontrol şeması | Şu anda FLEDGE için kullanılabilen zaman aşımı kontrol şemasını geliştirme | Bu ilginç bir teklif. Bunu incelemek üzere teklifler listesine ekler ve gelişmelerimizi rapor ederiz. |
| Reklam öğesi teklif akışları | Reklam öğesine göre kazanan teklifi inceleme ve filtreleme | Bu ilginç bir teklif. Bunu incelemek üzere teklifler listesine ekler ve gelişmelerimizi rapor ederiz. |
reportWin |
reportWin işlevinde kazanan dışında farklı bir ilgi alanı grubu sahibinden gelen en yüksek puanlı teklif hakkında ek bilgiler sağlamaya yönelik teklif |
Bu ilginç bir teklif. Toplu raporlamaya başka sinyaller eklemeyi değerlendirecek ve ek geri bildirimleri burada kabul edeceğiz. |
| Etkinlik türleri | FLEDGE ile entegre edildiğinde ölçüm API'lerinde etkinlik türlerini standart hale getirme | Bu ilginç bir teklif. Bunu incelemek üzere teklifler listesine ekler ve gelişmelerimizi rapor ederiz. Bu sorun, FLEDGE dışındaki diğer Özel Korumalı Alan API'lerini etkileyeceğinden bu alandaki geniş kapsamlı çalışmalarımızla koordinasyon sağlamanız gerekecek. Buradan daha fazla geri bildirim almak isteriz. |
| Etkinlik düzeyinde raporlama için uzun vadeli çözümler | Üçüncü taraf çerezleri için destek sonlandırıldıktan sonra bile highestScoringOtherBid gibi belirli verileri kullanılabilir tutmaya yönelik ilgi |
Şubat blog yayınında belirttiğimiz gibi, etkinlik düzeyinde açık artırma kazanma raporları "en az 2026"ya kadar desteklenecektir. Şu anda paylaşacak daha fazla ayrıntımız yok, ancak üçüncü taraf çerezlerinin kullanımdan kaldırılmasından sonra belirli verileri kullanılabilir tutmanın neden önemli olduğuyla ilgili ek geri bildirimler almaktan memnuniyet duyarız. |
| İlgi alanı grubu sınırı | Bir kaynağın tek bir tarayıcı ekleyebileceği ilgi alanı grubu sayısının sınırı nedir? | Chrome, sahip başına en fazla 1.000 ilgi alanı grubuna ve 1.000'e kadar ilgi alanı grubu sahibine izin verir. Bunlar normal çalışmada darbe olmak için değil, koruyucular olarak tasarlanmıştır. |
| Etkinlik düzeyindeki sinyaller | Makine öğrenimi eğitiminde kullanılabilecek generateBid ve reportWin için etkinlik düzeyinde sinyallere sahip olma teklifi desteği |
Tarayıcı tarafından tasarlanan sinyaller ve reklam teknolojisi tanımlı sinyallerle ilgili kararımızı burada paylaştık ve ek geri bildirimler almaktan memnuniyet duyuyoruz. |
| Teklifli sistem komut dosyası | Teklifli sistem komut dosyasının URL'sine kullanıcı kimliğini ekleyin. | FLEDGE, bir reklamın gösterilmesi için ilgi alanı grubu sahibi, teklifli sistem komut dosyası URL'si ve oluşturulan reklam öğesi öğelerinin k-anonim olması şartına sahip olduğundan bu mümkün değildir. |
| K-anon yaptırımı | (componentAd, boyut) çiftinde k-anonimliği zorunlu kılınır mı? | Evet, olacak. Turtledove/issues/312 adresine bakın. |
| Teklif Verme ve Açık Artırma Hizmetleri ile ilgili gereksinimler | B&A Hizmetleri, cihaz üzerinde FLEDGE ve B&A hizmetleriyle diğer entegrasyon katılımcılarını nasıl destekler? | Tasarımı son haline getiriyoruz. Buradan ek geri bildirimlerinizi bekliyoruz. |
| Görüntüleme sonrası ilişkilendirme | Görüntüleme sonrası ilişkilendirme desteklenecek mi? | Şu anda görüntülenebilirlik için herhangi bir standart tanımımız yoktur ve bir görüntüleme etkinliğini işaretlemek için reklam öğesinin kendisini kullanırız. turtledove/issues/452 adresine bakın. |
| Benzer hedefleme | Özel Korumalı Alan "benzer hedeflemeyi" destekleyebilir mi? | Kullanım alanını burada ele alıyor ve ek görüşlerinizi bekliyoruz. |
| Gerçek zamanlı izleme API'sı | Gerçek zamanlı FLEDGE izleme yaklaşımı için teklif | Şu anda teklifi tartışıyoruz. Burada da görüşlerinizi bekliyoruz. |
| FLEDGE raporları | Fazla veya az raporlamayı önlemek için reportWin ve reportResult rastgele oluşturulmalıdır. |
reportResult() satıcı sinyallerinin reportWin() kapsamına dahil edilebilmesi için reportResult(), önce satıcı tarafından reportWin() tarihinden önce alıcı tarafından yürütülmelidir. Daha fazla bilgi için açıklayıcıya bakın. |
| Özel Anahtar Değeri (K/V) sunucuları | Özel K/V sunucuları gelecekte desteklenecek mi? | Soruyu burada tartışıyoruz. Ek görüşlerinizi de almak isteriz. |
| Üst düzey açık artırma | Üst düzey açık artırma mekaniklerini çalıştırmak için reklam sunucusu olmak zorunda mı? | FLEDGE API, hangi tarafın bunu çağırması gerektiğini belirtmez. FLEDGE'in tasarımında bu anlamda herhangi bir şart yoktur. Herkes FLEDGE açık artırmasını gerçekleştirebilir (çok satıcılı açık artırmalar dahil). 2022'nin 4. çeyreğinde belirtildiği gibi FLEDGE, her yayıncının üst düzey ve bileşen satıcılarının seçimi dahil olmak üzere açık artırma yapısını seçmesine olanak tanır. |
| API kapsamı | FLEDGE, birinci taraf verileriyle çalışmayı düşünüyor mu? | 2023'ün 2. çeyreğinde birinci taraf verilerinin, 1) ilgi alanı grubu üyeliğini belirlemek için mantık olarak kullanmak ve 2) sonraki teklif mantığı oluşturma sürecinde kullanılmak üzere kullanıcı teklif verme sinyalleri olarak sunmak için gerçekten FLEDGE ile kullanılabildiğini açıklayan içerikler yayınlayacağız. |
| Web alanları arası ilgi alanı grupları | Alanlar arası ilgi alanı grupları oluşturma olasılığı | Bir ilgi alanı grubuna tarayıcı eklenirken mevcut olan tüm bilgiler, bu kitleyi bilgilendirmek için kullanılabilir. Üçüncü taraf çerezleri kullanımdan kaldırıldığında, ilgi alanı grubu oluşturma işlemi için siteler arası verilerin kullanılabilirliği sınırlandırılacaktır. |
| İstemci tarafı teklif verme mantığı | Mevcut sunucu tarafı teklif verme mantığını istemci tarafına taşıma | Hangi alanların taşıma işleminde zorlandığı veya şu anda eksik olduğu alanlar hakkında daha fazla bilgi edinmek isteriz. Ek geri bildirim veya görüşleri almak isteriz. |
| K/V sunucu değerleri | K/V sunucu değerlerinin dize türünde olması gerekir mi? | Değerin bir dize olması gerekir ancak nesneleri JSON veya protokol arabelleğinde depolayabilir ve dize olarak serileştirebilir. |
| Reklamveren engellenenler listesi | Engellenen reklamverenler listesi için bir alıcıya sağlamak için hangi sinyaller uygun olur? | Uygun yer auctionSignals veya perBuyerSignals bölgesinde. |
| Teklif birimi | YBM ve BGBM gibi farklı teklif birimleri için destek | Mevcut tasarım göz önünde bulundurulduğunda bunun neden gerekli olduğu hakkında daha fazla bilgi edinmek ve ek geri bildirim almak isteriz. |
| Açık artırma mantığı | Açık artırmanın kazananına tarayıcı mı yoksa Reklam sunucusu mı karar verir? | Tüm kazanan seçimi korumalı alan içinde gerçekleştirilir ve tüm kararlar satıcının kodu tarafından verilir. Tarayıcı, yalnızca alıcı ve satıcı kodunun çalıştığı kapalı, özel bir ortam sağlar. |
| İzinler-Politikası | Mevcut FLEDGE Permissions-Policy, Kaynak Denemesi sona erdikten sonra da uygulanmaya devam edecek mi? | Kaynak Deneme için her iki özelliğin de mevcut varsayılan izin verilenler listeleri geçicidir ve değiştirilecek. Değişikliği uygulamaya başlamadan önce reklam teknisyenlerinin bu değişikliğe ne kadar sürede hazırlanmaları gerektiğini öğrenmek istiyoruz. |
| Sinyal boyutu kısıtlaması | Güvenilir Teklif Sinyalleri istekleri, aynı trustedBiddingSignalsUrl değerine sahip birden fazla ilgi alanı grubu arasında birleştirilir. 2 MB boyut sınırı kısıtlamadır. |
Cihaz üzerinde arayanlar için bu kısıtlama, cihazdaki kaynakların aşırı yüklenmesini önlemek içindir. Bir B&A Sunucusundan arayanlar için daha esnek bir kısıtlama uygulanır. |
| Raporlama sinyalleri | İlgi alanı grubu sahibi ve computeBid veya reportWin / reportResult başına istemci taraflı hata sayısının alınmasını sağlamak için ek bir sinyal (komut dosyası hataları) ekleyin. |
Bu teklifle ilgili olası gizlilik endişelerini göz önünde bulunduruyoruz. Ekosistem oyuncularını da bunun neden gerekli olduğuna dair ek bilgiler paylaşmalarını bekliyoruz. |
| K-Anon pencere boyutu | K-Anon pencere boyutunu mevcut 7 günlük sınırdan artırın. | Bu konu değerlendirme aşamasındadır ve şu anda ekosistemden ek girişleri bekliyoruz. |
| Cihaz performansı | Kullanıcı çok sayıda ilgi alanı grubundaysa FLEDGE cihaz performansını nasıl ele alır? | FLEDGE, STP'ler ve TTP'ler genelinde çeşitli zaman aşımı, önceliklendirme ve sınırlama seçenekleri sunar. Bu seçenekler, cihaz çok sayıda ilgi alanı grubunda olduğunda cihaz performansının açık artırma katılımını sınırlandırmak için bir neden olabileceği durumlarda reklam teknisyenlerine ayrıntılı kontrol olanağı sunar. |
| B&A Hizmetleri testi | Hata ayıklama için daha fazla günlük olması amacıyla ekosistem oyuncularından test aşamasında kendi sunucularını kullanmalarını isteyin | B&A, kullanıcıların sunucuları onaylı bulut sağlayıcılardan başlatmasına ve ölçeklendirmesine olanak tanır. Kullanıcı gizliliğini korumak için yürütmenin güvenilir bir yürütme ortamında (TEE) yapılmasını zorunlu kılarız. Yakında B&A TEE'de hata ayıklamayla ilgili bir açıklayıcı video yayınlayacağız ve bunu destekleyecek özellikler geliştireceğiz. Konuyla ilgili ek geri bildirim almak istiyoruz. |
| Yasal gereksinimler | FLEDGE, yerel yönetmelik şartlarına uygunluğu desteklemek için farklı ülkelerdeki bulut sağlayıcılarla birlikte çalışacak mı? | Diğer bulut sağlayıcılarına yönelik önerilere her zaman açığız ancak şu anda üçüncü taraf çerezlerinin kullanımdan kaldırılması zorunlu kılındığında en azından GCP ve AWS'yi desteklemeyi planlıyoruz. Daha fazla bilgi için bu açıklayıcıya bakın. |
Dijital Reklamları Ölçme
Attribution Reporting (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Gürültü etkisi veri analizi | Gürültünün etkisiyle ilgili veri analizinin nasıl yapılacağına ilişkin rehberlik | Gürültünün reklam teknolojisi verileri üzerindeki etkisini değiştirmek için kullanılabilecek gürültü ve tasarım kararlarıyla ilgili ek belgeler paylaştık. Daha ayrıntılı bir kılavuz da mevcuttur. |
| Boş raporlama | Boş raporların uygulanmasına ilişkin netlik | Şu anda boş raporların uygulanmasına yönelik bir teklif üzerinde çalışıyoruz. Yakında bu konu hakkında daha fazla bilgi paylaşacağız. Boş raporlar uygulamak, gizlilikten ödün vermeden rapor gecikmelerini azaltmamıza olanak tanır. |
| Gürültü düzeyi | İlişkilendirme dönemi uzunluğuna göre gürültü seviyesini ayarlama | Bu teklifi memnuniyetle karşılıyoruz ve özelliği spesifikasyona eklemeyi düşünüyoruz. Buradan daha fazla geri bildirim almaktan memnuniyet duyarız. |
| Tetikleyici veri boyutu | Tetikleyici veri boyutu neden 3 bit ile sınırlı? | Bir kullanıcı hakkında siteler arası/bağlam bilgileri 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 parametreleştirmenin mantıklı olup olmadığı konusunda geri bildirim göndermelerini rica ediyoruz. |
| Etkinlik düzeyinde raporlama tetikleyicileri | Tekilleştirme anahtarı içinde önceliklendirmeye izin verme | Bu soruna çözümler arıyoruz. Sunduğumuz önerileri de memnuniyetle karşılıyoruz. |
| Hata ayıklama desteği | Üçüncü taraf çerezleri için destek sonlandırıldıktan sonra hata ayıklamayla ilgili netlik | Üçüncü taraf çerezleri için desteğin sonlandırılmasından sonra hata ayıklamayı desteklemek istiyor ve seçenekleri değerlendiriyoruz. Ek geri bildirim ve fikirler almak istiyoruz. |
| Tıklama dönüşümü alternatifleri | Tıklama dönüşümlerine ilişkin alternatifler hakkında daha fazla yardım talebi | Ekosistemin, geçerli dönüşüm ölçümü kullanım alanları için Attribution Reporting API'yi dayanıklı bir özel ölçüm sistemi olarak kullanmasını öneririz. Başka alternatifler de mevcuttur ve reklam teknolojisi sağlayıcılarının istedikleri gizlilik ve hizmet ihtiyaçlarına göre uygun çözüme karar vermeleri gerekir. |
| Faturalandırma kullanım alanları | İlişkilendirme Raporları'nın dönüşüme dayalı faturalandırma kullanım alanlarını ne ölçüde destekleyeceği konusundaki netliği | Faturalandırma için Attribution Reporting API'nin kapsamını netleştirmek amacıyla herkese açık olarak yayınlama üzerinde çalışıyoruz. Attribution Reporting API, başlangıçta EBM faturalandırmasını doğrudan destekleyecek şekilde ayarlanmamıştır. Bu API, reklam teknolojileri tarafından en çok kullanılan faturalandırma yapısı olan TBM ve BGBM faturalandırmasını desteklemektedir. Ekosistem geri bildirimi sağlanırsa ileride destek verebiliriz. |
| Kullanım alanı desteği | Measurement API'si için kullanım alanı belgeleri | Tüm Özel Korumalı Alan raporlama yüzeyleriyle ilgili dokümanları netleştirmeye çalışıyoruz. |
| Tıklama kalitesi | Bir reklama yapılan kasıtlı ve istemeden yapılan tıklamaları ayırt etmek için sinyal ekleme isteğinde bulunma. | İsteği tartışıyoruz ve ek görüşlerinizi de bekliyoruz. |
| Ölçüm çözümü | Birden fazla TTP'de ölçüm çözümleri için destek | Attribution Reporting API, ölçüm sağlayıcıları tarafından birden fazla TTP arasında tekilleştirme yapmak için kullanılabilir. Buna ek olarak, DSP'lerin ölçüm sağlayıcı Attribution Reporting API isteklerini desteklemesini kolaylaştıracak şekilde attributionsrc içindeki URL'lerin listesini de sunuyoruz. Yukarıdaki teklifle ilgili başka
geri bildirim almaktan memnuniyet duyarız. |
| Etkinlik düzeyinde raporlama | Raporun doğrudan kullanılabilir olması için kaç gün önce gösterileceğini isteme | Bu istek, hâlihazırda mevcut olan bilgileri kullanarak reklam teknisyenleri tarafından zaten hesaplanabilir. Bu taleple ilgili ekosistemde başka bir geri bildirim almadık ancak bununla ilgili geri bildirimlerinizi paylaşabiliriz. |
source_registration_time |
Etkinlik düzeyindeki İlişkilendirme raporlarına source_registration_time ekleyin. |
Bu isteği değerlendiriyoruz. Ekosistem oyuncularının bunu faydalı bir özellik bulup bulmadığı hakkında ek geri bildirimler almaktan memnuniyet duyarız. |
| Gizli mod | Kullanıcı Gizli moddayken ölçüm çözümleri kullanılabilir mi? | Hayır, kullanıcı Gizli moddayken ölçüm çözümleri kullanılamaz. Gizli modda üçüncü taraf çerezleri varsayılan olarak kapalıdır. |
| Veri temizliği odaları | Measurement API'leri temiz odalarla uyumlu olacak mı? | Tipik bir temiz veri odası, temel verilerin birleştirilmesine dayanan analizler yapmak için farklı kaynaklardan gelen tanımlayıcı verilerinin bir veritabanına yüklendiği ortamdır. Özel Korumalı Alan API'leri için iki ölçüm çerçevesi, etkinlik düzeyindeki raporlar ve özet raporlardır. Etkinlik düzeyindeki raporlar, veri temizliği odasında kullanılabilecek reklam teknolojisi tarafından sağlanan bir etkinlik kimliği içerir ancak ilişkilendirilen dönüşüm tarafı bilgileri sınırlı ve gürültülü olacaktır. Şifrelenmiş, toplanabilir raporlar doğrudan temiz bir odada kullanılamaz ancak Toplama Hizmeti tarafından sağlanan özet sonuçlar, gerçekleştirdiğiniz analizlerde girdi olarak veya ek bilgi olarak kullanılabilir. |
Toplama Hizmeti
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (2022'nin 4. çeyreğinde de bildirilmiştir) Raporlama gecikmeleri |
Beklenen raporlama gecikmesi nedir? | 2023 1. Çeyrek Güncellemesi: İş ortaklarından aldığımız geri bildirimlere göre, gecikmeyi azaltmak ve gecikmenin etkisini azaltmak için öneriler paylaştık. WICG çağrıları sırasında her iki teklif de reklam teknolojileri tarafından desteklenmiştir. |
| Yinelenen kural yok | Aynı paylaşılan kimliğe sahip toplanabilir raporlar zaten işlenmişse "gecikmeli toplanabilir raporu" nasıl ele alırsınız? | Birleştirilebilir raporların paylaşılan bilgilerine fazladan rapor gecikmesi eklenmesi ve Toplam API üzerindeki gecikme kaybının etkisini kısmen ele almak amacıyla Toplama Hizmeti için paylaşılan kimliğin tanımıyla ilgili bir teklif paylaştık. Teklifle ilgili geri bildirimlerinizi almaktan memnuniyet duyarız. |
| Veri işleme | Gizlilik Bütçesi'ni kullanarak diferansiyel gizliliğe saygı gösterirken birden fazla veri aktarımı için desteği etkinleştirme isteğinde bulunma | Bu kullanım alanını etkinleştirmek için Gizlilik Bütçesi'ni tüketmek için daha esnek bir yol kullanma olasılığını tartışıyor ve ek geri bildirim almaktan bahsediyoruz. |
| (2022'nin 2. çeyreğinde de bildirilmiştir) Sorgu ergonomisi | Anahtarların toplamını sorgulamayı etkinleştirin. | 2023 1. Çeyrek Güncellemesi: Bu özellik isteği hâlâ inceleniyor ancak şu anda paylaşabileceğimiz bir teklifimiz yok. |
| Kaynak Deneme sınırlamaları | Toplama Hizmeti'nin kapsamını, örneğin şu anda kaynak denemesinde uygulanmayan "yineleme yok kuralı" gibi açık bir şekilde belirtin. | Kaynak denemesinde ve GA'da nelerin kullanılabileceğini netleştirmek için dokümanlarımızı güncellemeye çalışıyoruz. |
Private Aggregation API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Özel Toplama Katkı Bütçesi | L1 katkı bütçesi çok kısıtlayıcı. | Private Aggregation API'ye yapılan her çağrıya katkı adı verilir. Kullanıcı gizliliğini korumak amacıyla, bir kişiden toplanabilecek katkı sayısı sınırlıdır. Tüm toplama anahtarlarındaki tüm toplanabilir değerleri topladığınızda toplam, katkı bütçesinden küçük olmalıdır. Mevcut tasarımda, belirli bir raporlama kaynağı için son yaklaşık 24 saat içinde (kayan bir zaman aralığı olarak) katkılar için bir sınır belirledik. Geri bildirimde belirtilen L1 katkı bütçesi budur. Geliştiricilerin, katkıda bulundukları değerleri beklenen hacme göre (yani yalnızca 1 değerini kullanarak değil) ölçeklendirmelerini öneririz. Bu nedenle bütçenin tükenmesini önlemek amacıyla daha yaygın etkinlikler için daha küçük bir değer kullanmak mantıklı olabilir. Özel Toplama API'sinin katkı bütçesi ile ilgili olarak hem sayısal sınır hem de kapsam hakkında şu anda geri bildirim istiyoruz. Kapsamı kaynak bazında değil site bazında, mevcut sınırı ise daha geniş bir günlük sınıra sahip on dakikalık bir zaman aralığına taşımayı düşünüyoruz. |
Gizli Takibi Sınırla
Kullanıcı Aracısı Azaltma/Kullanıcı Aracısı İstemci İpuçları
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| UA-R'yi benimseme | Birleşik Krallık'taki en popüler 10.000 sitenin yalnızca %1'i programatik reklamcılık kullanan sitelerin yalnızca %1'i tarafından HTTP istemci ipuçları gönderiyor. Taşınmamış olan TTP'lerin sahtekarlıkla mücadele özellikleri üzerinde etkisi olabilir. | Aynı veri kümesi üzerinde yaptığımız analiz sonucunda, UA-CH kullanımını HTML <meta> etiketi ve JavaScript API'leri aracılığıyla hesaba katıyorsanız UA-CH'yi kullanan sitelerin sayısının, geri bildirimde sağlanan% 1'lik rakamdan önemli ölçüde daha yüksek olduğunu tespit ettik. Bu ve ekosistem geri bildirimleri dahil olmak üzere diğer gerçekler ışığında, yayınlanan zaman çizelgesine uygun olarak, UA'da Değişim Sürecinin 6. Aşaması'nın kademeli olarak kullanıma sunulmasıyla ilgili olarak CMA'yı bilgilendirmeye devam ettiğimizden eminiz. Sitelerin geçişe hazırlanmak için yaklaşık iki yıllık bir süreye sahip olduğunu ve henüz hazır olmadığını düşünen siteler için hâlâ bir kullanımdan kaldırma denemesinin sunulduğunu görüyoruz. |
| Ek form faktörleri için ipuçları | TV ve VR gibi ek form faktörleri sağlamak için UA-CH'den talep | Bu teklifi memnuniyetle karşılıyoruz ve tasarıma uygulamayı arıyoruz. Daha fazla geri bildirim almaktan memnuniyet duyarız. |
| Otomatik test | UAR 6. aşama gönderilmeden önce gözetimsiz Chrome'da UA-CH hatasının düzeltilmesi isteği | Söz konusu hata düzeltildi. |
| iOS'te UA-CH desteği | Reklam kullanım alanları için ayrıntılı UA bilgilerini kullanan bir site, iOS'te Chrome'un desteklenmediğini belirtir. | Safari dışındaki iOS tarayıcılar (iOS'teki Chrome dahil) için WebKit projesinin, UA-CH'nin etkinleştirilmesi için öncelikle ağ yığınını kontrol etmesi gerekir. |
IP Koruması (eski adıyla Gnatcatcher)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (4. çeyrekte de raporlanmıştır) Coğrafi konum kullanım alanları | IP Koruması, coğrafi konuma göre içerik kişiselleştirme gibi geçerli coğrafi konum kullanım alanlarının gelecekte işe yaramasını engelleyebilir. | 2022'nin 4. çeyreğinde vereceğimiz yanıt değişmeyecektir: "Chrome'un, IP adresleri için meşru kullanım alanlarını desteklemeye devam ettiğinden emin olmak için paydaşlarla birlikte çalışıyoruz. IP Coğrafi Konum ayrıntı düzeyi hakkında ekosistem geri bildirimi almak istiyoruz." |
| Düzenlemelere uygunluk | Nüfusu 1 milyonun altında olan bir bölgede, IP koruması için geçerli olan 1 milyonluk eşik, web sitelerinin yönetmeliklere uygunluk için IP adreslerini kullanmasını engeller. | Chrome'un, IP adresleriyle ilgili meşru kullanım alanlarını desteklemeye devam etmesini sağlamak için paydaşlarla birlikte çalışıyoruz. IP Koruması ile ilgili mevzuata uygunluk hakkında ekosistem geri bildirimi istiyoruz. |
| Kötüye kullanımı azaltma | Taraflar, maskelenmemiş IP adreslerini başkalarıyla paylaşarak IP Koruması'nı atlatabilir. | Mevcut IP Koruma teklifinin, tarafların maskelenmemiş IP adreslerini başkalarıyla paylaşmasını teknik olarak engellememesi riskinin farkındayız. Bu kötüye kullanım riskini önleyecek
risk azaltmalar üzerinde çalışıyoruz. Teklifi geliştirmeye devam ederken daha fazla geri bildirim almayı ve tartışmayı teşvik ediyoruz. Özellikle, tarafların maskelenmemiş IP adreslerini diğer taraflarla paylaşmaları gerektiğine inandığı kullanım alanlarını bilmek isteriz. |
| Ağ engelleme | Taraflar IP Koruma Proxy'lerini kullanarak ağ engellemeyi atlatabilir. | Engellemeyi gerçekleştiren tüzel kişinin bu senaryoda IP Koruması'nı devre dışı bırakması gerekir. Soruna yanıt verdik. Ek geri bildiriminizi almaktan memnuniyet duyarız. |
| IP Koruması teklifinden etkilenen IP adresi engelleme listeleri | Birçok reklam teknolojisi şirketi, büyük olasılıkla sahte (veya en azından para kazanılamayacak) olan reklam envanterine teklif verilmesini önlemek için TAG veri merkezi IP listesi gibi temel bir IP adresi engelleme listesinden yararlanır. Bir reklam teknolojisinin aynı zamanda izleyici olması ve IP Koruma teklifine tabi tutulması durumunda bu şirket, reklam envanteri satın almadan önce reklamlarla ilgili temel bir kontrol gerçekleştirme becerisini kaybedebilir. | Potansiyel sorunlar ve çözümler hakkında IP Koruma Teklifi hakkında daha fazla geri bildirim ve tartışma yapılmasını öneririz. Seçeneklerden biri, bu tür listeleri IP Koruması'na uygulamaktır. Böylece, önceden işaretlenmiş IP adreslerinden gelen istemciler için proxy uygulamayız. |
Siteler arası gizlilik sınırlarını güçlendirin
Birinci Taraf Gruplar
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (4. çeyrekte de bildirildi) Alan sınırı | İlişkilendirilmiş alan adlarının sayısını artırma isteği | 2022'nin 4. çeyreğinde vereceğimiz yanıt değişmez: "WICG çağrılarında Chrome'un, kullanıcıların gizlilik ilgi alanlarını da göz önünde bulunduran kullanılabilir bir çözüm sağlamaya karar verdiğine açıklık getirdik. Bu bağlamda, alan sınırından etkilenebilecek belirli kullanım alanları hakkındaki geri bildirimlerini almaktan memnuniyet duyarız. Böylece ekibimiz, kullanıcı gizliliğini korumaya devam ederken bu kullanım alanlarını ele almanın yollarını düşünebilir." |
| Alternatif FPS gönderme | FPS için global listeler göndermenin alternatif yolu önerisi | Şu anda Chrome'da Birinci Taraf Grupları (FPS) sunmaya hazırlanıyoruz ve grup gönderimlerini kabul etmek için merkezi bir GitHub deposu oluşturduk. Üçüncü taraf çerezleri için desteğin sonlandırılmasına hazırlık olarak FPS'nin mevcut web platformu çözümleriyle bir boşluğu dolduracağını umuyoruz. Bu nedenle, site yazarları tarafından FPS'den nasıl yararlanıldığını onlardan öğrenmeyi umuyoruz. Grup listesi zamanla büyüdükçe ve ekosistem üçüncü taraf çerez dünyasına uyum sağladıkça, süreci, önerilen gibi merkezi olmayan alternatif şemaları değerlendirebileceğimiz kadar olgunlaştırabiliriz. Mevcut süreçte belirli yaşam süreleri belirlemeyi umuyoruz. Bu da alım sürecini zaman içinde geliştirmemize olanak tanıyacaktır. Başvuru süreci tamamlandığında bu fikri tekrar gözden geçirebiliriz. |
| Depo moderasyonu | Kötüye kullanımı önlemek için FPS Gönderim deposunun topluluk moderasyonunu uygulayın. Kötü aktörler, grup önermek için yazıcı kaynaklarını kullanma süreci kolayca boğabilir ve çok fazla sayıda istek, gerçek grup teklifleri işlemlerini etkileyebilir. | Teknik doğrulama kontrollerini kullanarak denetimleri mümkün olduğunca tarafsız hale getirmeye çalışıyoruz. Gönderim sürecinde en ölçeklenebilir yaklaşımın bu olduğunu düşünüyoruz. Bu hedef doğrultusunda, sürecin spam / tarayıcı gönderimlerine karşı da dirençli olmasını sağlamayı da hedefleyeceğiz. |
| İlişkili alt kümeler | FPS, İlişkilendirilmiş alt kümeler aracılığıyla üçüncü taraf Tedarikçi/SaaS akış kullanım alanlarını destekleyebilecek mi? | Üçüncü taraf tedarikçi / SaaS akışları, şu anda Birinci Taraf Gruplar kapsamında değerlendirilen bir kullanım alanı değildir. Siteler arası çerezlerin bu kullanım alanları için nasıl kullanıldığıyla ilgili ek geri bildirimlerden de memnuniyet duyarız. |
| FPS + CHIPS entegrasyonu | A/B testi gibi kullanım alanlarını desteklemek için FPS + CHIPS entegrasyonu isteği | Şu anda bu kullanım alanını tartışıyoruz. Ayrıca bir WICG görüşmesinde bu konuyu daha ayrıntılı olarak ele alabiliriz. Buradan daha fazla görüş alabilirsiniz. |
| GDPR | GDPR kavramlarına göre modellenecek yeni FPS alt kümesi için teklif | Bu teklifi şirket içinde tartıştık ve aldığımız diğer geri bildirimler ve gizlilik hedeflerimiz ile karşılaştırarak değerlendirdik. Bu teklifi neden şu anda takip etmediğimizi açıklayan bir yanıt sağladık. |
| Bellek | FPS listesi eklendiğinde tarayıcı bellek boyutunda beklenen değişiklik | Tarayıcıların bu tür listeleri minimum düzeyde bellek etkisiyle depolaması, örneğin Bağlantıyı Kesme İzleme Koruması Listesi gibi örneği olmuştur. Birinci Taraf Gruplar listesi her bir Chrome istemcisine yerel olarak kopyalanacak olsa da dosya boyutunu izlemeye devam edeceğiz ve bellek ayak izini optimize edebileceğimizden eminiz. |
Çitli Çerçeveler API'sı
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Kısıtlanmış Çerçevelerle ilgili sınırlamalar | Kısıtlanmış Çerçevelerin uyguladığı sınırlamalar konusunda netlik | Mart ayında, işlevleri hakkında bilgi sağlayan çitli çerçevelerle ilgili açıklamacımızı güncelledik. Ek geri bildirimleri de memnuniyetle kabul ediyoruz. |
| Erişim bilgilerini genişlet | Komşu çerçevelerin etrafındaki bilgilere erişimin kapsamını genişletmeyi isteme | Bunun neden ekosistem tarafından gerekli olduğunu daha iyi anlamaya çalışıyor, ek geri bildirimleri de almaktan mutluluk duyarız. |
| Kısıtlanmış Çerçeveler ve iframe'ler | Kısıtlanmış Çerçeveler ve iframe'ler arasındaki özellik denkliğiyle ilgili sorular | Kullanılabilir tüm Özel Korumalı Alan API'leri ve raporları, iframe'ler ve FencedFrame'ler için aynı şekilde kullanılabilir. |
| Kısıtlanmış Çerçeveleri Yeniden Boyutlandırma | Çerçeve boyutu değişikliklerini kısıtlamak belirli kullanım alanlarını etkiler. | Kısıtlamadan etkilenen kullanım alanı türleri hakkında daha fazla bilgi edinmek isteriz. Ek geri bildiriminizi almaktan memnuniyet duyarız. |
Shared Storage API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Üçüncü taraf iş uygulamaları | Üçüncü taraflar, kaynağa göre bölümlendirilmiş Paylaşılan Depolama alanına yazabilir mi? Yoksa üçüncü taraf ölçüm için diğer iş uygulamalarını mı aramak istiyorsunuz? | Tarama bağlamının kodun yürütüldüğü kaynak, bu verilerin kimin paylaşılan depolama alanına yazıldığını belirler. Bir sayfaya üçüncü taraf kodu eklendiğinde, üçüncü taraf kodu kendi tarama bağlamına sahip bir iframe olarak yerleştirilebilir. Böylece, üçüncü taraf kodu kendi kaynağına yazabilir. Üçüncü taraf kodu, iframe yerine komut dosyası olarak da yerleştirilebilir. Bu işlem, göz atma bağlamını değiştirmez ve üçüncü taraf, yer tutucunun paylaşılan depolama alanına yazabilir. Yalnızca söz konusu paylaşılan depolama alanının sahibinin paylaşılan depolama alanından okuma yapabileceğini unutmayın. |
| Tekilleştirme | Tekilleştirme, Chrome ekosistemi dışındaki etkileşimler için mümkün olmaz. | Paylaşılan Depolama Alanı, Chrome'da Chrome tarayıcı tabanlı tekil erişim çıkışları sağlamak amacıyla tasarlanmıştır. Bu çıktıların daha geniş erişim modellerinin bir parçası olarak nasıl kullanılabileceğini anlamak için reklam teknolojileriyle birlikte çalışmayı düşünüyoruz. Çıktıların, etkileşimlerin yalnızca bir kısmını oluşturduğunu anlıyoruz ve üzerine katman olarak eklenebilecek ek modelleme metodolojilerini keşfetmek için reklam teknolojileriyle çalışmak istiyoruz. |
| Dönüşüm yeniden inceleme aralığı | Dönüşümde zaman içinde görülen değişiklikleri görebilmek amacıyla, dönüşüm oranı için yeniden inceleme aralığına sahip olma isteğinde bulunabilirsiniz. | Bu, güvenli bölümlendirilmemiş tarayıcı depolamasına kıyasla gelişmiş analiz için daha fazla esneklik sağlayan Paylaşılan Depolama'yı kullanarak, istemci tarafında çeşitli dönüşüm yollarının işlenmesiyle gerçekleştirilebilir. |
| Öğenin geçerlilik bitiş aralığı | Süre sonu aralığını 90 güne uzatma isteği | Veri saklama politikası Kasım 2022'de güncellenmiştir ve her anahtarın son yazma işleminden otuz gün sonra temizlendiği belirtilmektedir. Yeni politikanın ekosistem açısından faydalı olup olmayacağını anlamak için ek geri bildirimler almaktan memnuniyet duyarız. |
| Reklam öğesi rotasyonu | Reklam öğesi rotasyonu kullanım alanları, açık artırmadan sonraki gerçek işlemleri yansıtmaz. | Reklam öğesi rotasyonu belgelerinin doğru olup olmadığı konusunda daha fazla alıcı tarafı reklam teknolojisi şirketinden haber almak istiyoruz. |
ÇİPLER
Bu üç aylık dönemde geri bildirim alınmadı.
FedCM
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Kimlik onayı uç noktası | Kimlik onayı uç noktasına yapılan rastgele isteklere açıkça izin verin. | Web sitelerinin, kullanıcıları rahatsız etmeden, kaynaklar arası kimlik bilgisi içeren istekler gönderebilme özelliğini sınırlandırmak için bu geri çekme isteğinde Mozilla ile ortak çalışmalar yürütüyoruz. Diğer geri bildirimleri de inceleyip ele almaya devam edeceğiz. |
| Kimliği önceden doldur | FedCM, oturum açma formlarını FedCM listesindeki bir kimlik sağlayıcıyla önceden doldurmak için kullanılabilir mi? | Bu kullanım örneğinin endişesi, kullanıcıyla etkileşim kurmayan bir site, kullanıcı tarafından kullanılan son IdP'yi sorgulayabildiği zaman bilgi sızıntısına yol açabileceğidir. Bu konuyu daha ayrıntılı olarak ele alıyor ve ek geri bildiriminizi almaktan memnuniyet duyuyoruz. |
| Bağlamsal hesap seçimi | Hesap seçimi kullanıcı arayüzünde içerik sinyalleri ekleme teklifi | Bu teklifi değerlendiriyoruz. Ayrıca ek tartışmalara da açığız. |
Spam ve sahtekarlıkla mücadele edin
Private State Token API (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Anket toplama yetenekleri | 1. çeyreğin başlarında, sahtekarlıkla mücadele amaçlı çeşitli kullanım alanları için gereken becerilerin yer aldığı anket sonuçlarımızı toplamayı bitirdik ve bunları herkese açık bir şekilde (dakikalar, sonuçlar) paylaştık. | Sahtekarlıkla mücadele becerilerine yönelik amaca yönelik, gizliliği korumaya yönelik API'ler için yeni teklifler ve prototipler geliştirirken bu geri bildirimden de yararlanmayı planlıyoruz. Yeterli ihtiyaç olduğunda ve kullanıcı gizliliğini korurken web'e erişim özelliklerini sunmak için geliştirebileceğimiz mevcut teknolojinin bulunduğu durumlarda geliştirme işlemlerine öncelik vermemizi bekliyoruz. Örneğin, cihaz ve başlatma bütünlüğü son derece yüksek bir sıralamaya sahiptir. Birçok platformda cihaz bütünlüğü değerlendirmesini güvenli bir şekilde paylaşan API'leri bulunur. Bu nedenle, topluluk grupları içinde keşif yapmak için iyi bir adaydır. |
| PST Gönderme Amacı geri bildirimi | Gönderme amacımız doğrultusunda, Gizlilik Kartı'nın eski bir sürümünü kullandığımızdan dolayı işlem sürecinde bir sorunla karşılaştık. Ayrıca, spesifikasyonun bazı bölümlerde net olmadığı ve tarayıcı uyumluluğunu kolaylaştırmak için iyileştirilmesi gerektiği yönünde geri bildirimler aldık. | Birkaç API değişikliğinin yanı sıra, önerilen spesifikasyon değişikliklerinin çoğunu GA'ya göndermeden önce uygulamayı planlıyoruz. Geri bildirim 1. çeyreğin sonunda geldi. Bu nedenle github sorunlarını belirli ayrıntılarla ve lansman planımıza yönelik bir güncellemeyle (bu geri bildirim raporunun yayınlandığı tarih itibarıyla devam ediyor) takip ediyoruz. API'de yapılacak daha büyük değişikliklerden sonra bunları değerlendirmeye hazırız ancak bunu yapmanın en iyi yolunun genel kullanıma sunmak ve daha fazla geliştiriciden uygulamalı geri bildirim almak olduğunu düşünüyoruz. Bu tartışmaya devam etmeyi ve tarayıcı standartlaştırmayı sürdürmeyi umuyoruz. Yeni bir standart ortaya çıktığında, buna dikkatlice geçiş yapmak için bir plan benimsemeyi ve geliştirmeyi değerlendireceğiz. |