Privacy Sandbox teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2023 1. çeyreğine ait üç aylık rapor.
Google, CMA'ya verdiği taahhütler kapsamında, Özel Korumalı Alan teklifleriyle ilgili paydaş etkileşim süreciyle ilgili üç aylık raporları herkese açık olarak yayınlamayı kabul etmiştir (Taahhütler'in 12. ve 17(c)(ii) paragraflarına bakın). Bu Gizlilik Korumalı Alan geri bildirim özet raporları, Chrome'un geri bildirime genel bakış bölümünde listelenen çeşitli kaynaklardan aldığı geri bildirimler (GitHub Issues, privacysandbox.com adresinde kullanıma sunulan geri bildirim formu, sektör paydaşlarıyla yapılan toplantılar ve web standartları forumları dahil ancak bunlarla sınırlı olmamak üzere) toplanarak oluşturulur. Chrome, ekosistemden gelen geri bildirimleri memnuniyetle karşılar ve edinilen bilgileri tasarım kararlarına entegre etmenin yollarını etkin bir şekilde araştırır.
Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu işlem, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanması ve miktara göre azalan düzende düzenlenmesiyle yapılır. Ortak geri bildirim temaları, herkese açık toplantılardaki (W3C, PatCG, IETF) tartışma konuları, doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden gelen sık sorulan sorular incelenerek belirlendi.
Daha ayrıntılı belirtmek gerekirse, web standardı kuruluş toplantılarının tutanakları incelendi ve doğrudan geri bildirim için Google'ın paydaşlarla bire bir toplantı kayıtları, mühendislerin aldığı e-postalar, API posta listesi ve herkese açık geri bildirim formu dikkate alındı. Ardından Google, her API ile ilgili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli tanıtım etkinliklerine katılan ekipler arasında koordinasyon sağladı.
Chrome'un geri bildirimlere verdiği yanıtlarla ilgili açıklamalar, yayınlanan SSS'lerden, paydaşların gündeme getirdiği sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama çalışması için özel olarak belirlenen bir duruştan geliştirilmiştir. Geliştirme ve testin mevcut odağını yansıtan sorular ve geri bildirimler özellikle Topics, FLEDGE ve Attribution Reporting API'leri ile ilgili olarak alındı.
Geçerli raporlama döneminin sona ermesinden sonra alınan geri bildirimler henüz Chrome yanıtı olarak değerlendirilmeyebilir.
Kısaltmalar sözlüğü
- CHIPS
- Bağımsız Bölümlendirme Durumuna Sahip Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Federated Credential Management
- FPS
- Birinci Taraf Gruplar
- IAB
- Interactive Advertising Bureau
- IDP
- Kimlik Sağlayıcı
- IETF
- Internet Mühendisliği Görev Gücü
- IP
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- uzatma
- Origin Deneme Sürümü
- PatCG
- Private Advertising Technology Community Group
- RP
- Bağlı Taraf
- SSP
- Arz tarafı platformu
- TEE
- Güvenilir Yürütme Ortamı
- UA
- Kullanıcı aracısı dizesi
- UA-CH
- Kullanıcı Aracısı İstemci İpuçları
- W3C
- World Wide Web Konsorsiyumu
- WIPB
- İstençli IP Körlüğü
Belirli bir API/teknolojiyle ilgili olmayan genel geri bildirimler
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Test ve deneme | Özel Korumalı Alan API'leri testin başladığı tarihe kadar tamamlanmazsa testin, CMA'nın değerlendirmesini bilgilendirmedeki alaka düzeyi | Özel Korumalı Alan API'lerinin geliştirilmesi hızla devam etmektedir.
Bu reklam biçimleri, test için Origin denemesinde zaten kullanılabilir durumdadır ve bu yaz trafiğin% 100'ü için genel kullanıma sunulacaktır. Ayrıca, 2026'dan önce etkilenmeyecek belirli özelliklerin (ör. FLEDGE etkinlik düzeyinde raporlama, FLEDGE'i iframe'lerle oluşturma) zaman çizelgelerini netleştirdik. Ekosistemin, API'leri test etmesini ve üçüncü taraf çerez desteği sonlandırıldıktan sonra test kullanıcılarının hangi kaynaklardan yararlanmayı beklediğini temel alarak CMA'ya geri bildirim göndermesini öneririz. Bu, üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasının olası etkisini değerlendirmelerine yardımcı olabilir. |
| Kullanıcı denetimleri | Özel Korumalı Alan API'lerinin kullanıcı kontrolleri üzerindeki etkileriyle ilgili ekosisteme net bir rehberlik | Ekosistemi kontrol eden kullanıcıların neleri kullanabileceği konusunda yasal tavsiyede bulunamayız. Aynı zamanda Chrome, Özel Korumalı Alan teknolojilerini iyileştirmeye yönelik devam eden çalışmalarımızın bir parçası olarak güncellenmiş Özel Korumalı Alan ("Gelişmiş Reklam Gizliliği") kullanıcı denetimlerini kullanıcıların çok küçük bir yüzdesine göstermeyi denemektedir. Güncellemeler arasında daha net ve daha faydalı dil ve düzenler yer alıyor. Chrome bu iyileştirmeleri değerlendirip daha geniş bir kullanıcı grubuna sunup sunmayacağına karar verdikten sonra ekosistemle daha fazla bilgi paylaşabilir. |
| Veri sızıntısı | Tarayıcı güvenliğinin ihlal edilmesi durumunda birinci taraf verilerinin Google'a ve diğer taraflara sızma riski | FLEDGE açıklamamızda, bir reklam teknolojisinin verilerinin yalnızca aynı reklam teknolojisiyle (worklet'leriyle veya güvenilir sunucularıyla) paylaşıldığını ya da bu reklam teknolojisi tarafından açıkça paylaşıldığını (ör. bir alıcı, satıcıya göstermek istediği reklam URL'sini gösterir) açıkça belirtiyoruz. Tek istisna, k-anonimlik kontrolünün küresel merkezi bir sunucu tarafından yapılması gerektiğidir. Bu alana önemli kaynaklar ayırmaya devam ediyoruz. Gizlilik konusundaki yaklaşımımız hakkında ayrıntılı bilgi için K-anonimliği hakkındaki açıklamaya göz atın. Bunun dışında, k-anonimlik sunucusunun tasarımında kullanılan reklam teknolojisi korumalarının işleyiş şekli hakkında daha fazla bilgi verebiliriz. |
| Tartışma için ek forum | Teknik olmayan ekosistem oyuncularının geri bildirim paylaşabileceği W3C'de ek bir forum oluşturulması için istek | Gizlilik Korumalı Alan geri bildirim formu, genel ve spesifik yorumlar, teknik ve teknik olmayan yorumlar için uygundur. Web Reklamcılığını Geliştirme İş Grubu, haftalık toplantılar ve GitHub deposu üzerinden tartışmalara olanak tanıyan bir forumdur. Özel Korumalı Alan Geri Bildirim sayfasında, geri bildirim verme ve tartışmaya katılmayla ilgili diğer mekanizmalar açıklanmaktadır. Chrome, soru sorma ve içerik paylaşımını kolaylaştırmak için herkese açık ofis saatleri gibi etkinlikler düzenlemeye de devam ediyor. Ayrıca Chrome, geçtiğimiz üç aylık dönemde on ikiden fazla sektör etkinliği düzenledi veya bu etkinliklere katıldı. |
| Zaman çizelgesi açıklaması | 2023'ün 3. çeyreğinde genel kullanıma sunulacak sürümün tam tarihiyle ilgili açıklama | PrivacySandbox.com'da yayınlanan zaman çizelgesine göre, genel kullanıma sunma sürecinin Chrome 115 sürümünün yayınlanmasıyla başlaması planlanmaktadır. |
| reCAPTCHA | reCAPTCHA'nın spam algılama kullanım alanı için Özel Korumalı Alan 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ırız. Üçüncü taraf çerezlerinin kullanımdan kaldırılmasına hazırlanmak ve buna uyum sağlamak için kendi planlarını geliştiriyorlar. Bu nedenle, bu soruyu en iyi yanıtlayacak kişiler onlardır. |
| Chrome uzantıları | Gizli İzleme Önleme (ACT) önlemleri gibi Özel Korumalı Alan teknolojileri Chrome uzantıları için geçerli olacak mı? | ACT'nin Chrome uzantıları için geçerli olup olmadığı konusunda herhangi bir duyuru yapmadık. Ancak bir teknoloji, kullanıcı hakkında gizlice bilgi toplarsa bu durum gizlilik ilkelerimize uygun olmaz. |
Alakalı İçerik ve Reklamlar Gösterme
Konular
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| TAG Tasarım İncelemesi | TAG, Topics için Erken Tasarım İncelemesi'ni yayınladı. | Topics'a olan bağlılığımızı sürdürüyoruz. En son güncellemeler sayfasında ve bu sayfada bağlılığımızla ilgili bir güncelleme paylaştık. TAG incelemesine madde madde yanıt verdik ve genel bakışımızı burada paylaştık. Topics API, reklam ekosisteminin 2023'te test etmesi gereken API koleksiyonunun bir parçası olmaya devam edecek. Aldığımız test geri bildirimlerinin ve edindiğimiz uygulayıcı deneyiminin, bu alandaki tarayıcılar arası standartlar çalışmalarına yönelik gelecekteki çabalara değerli katkılar sağlayacağını umuyoruz. Topics API'nin tarayıcılar arası uyumluluğu olan ve üzerinde anlaşmaya varılmış bir standart olabileceği olası geçişi kolaylaştırmak için ekosistemle çalışmaya devam etmeyi umuyoruz. |
| Konulara Yaklaşım | Chrome'un Topics API'yi geliştirme konusundaki açık yaklaşımını destekleme | Bu görüş için teşekkür ederiz. 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 bildirildi) Konular sınıflandırması yeterince ayrıntılı değil |
Geniş konular sınıflandırması, bölgeye özel olanlar da dahil olmak üzere daha ayrıntılı konuları içermez. | 1. Çeyrek Güncellemesi: Sınıflandırmada sürekli olarak iyileştirmeler yapıyoruz. 2. çeyrekte Topics API için güncellenmiş bir sınıflandırmayı duyuracağı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ı olacak sınıflandırmayla ilgili geri bildirimlerinizi bekliyoruz. Konu sayısının genişletilip genişletilmeyeceğini veya daha ayrıntılı konular eklenip eklenmeyeceğini değerlendirirken 1) olası gizlilik etkileri (daha fazla konu, parmak izi riski oluşturabilir) ve 2) daha önce gözlemlenen konuları alma olanağı (ör. daha fazla konu olduğunda bir reklam teknolojisinin geçmişte seçilen konuyu görme olasılığı daha düşük olabilir) gibi birkaç husus göz önünde bulundurulmalıdır. |
| (2022'nin 4. çeyreğinde de raporlanmıştır) Birinci taraf sinyalleri üzerindeki etki |
Topics sinyali oldukça değerli olabilir ve bu nedenle diğer birinci taraf ilgi alanına dayalı sinyallerin değerini düşürebilir. | İlgi alanına dayalı reklamcılığın web için önemli bir kullanım alanı olduğuna inanıyoruz. Topics, bu kullanım alanını desteklemek için tasarlanmıştır. Bazı büyük yayıncıların, Topics'in birinci taraf veri stratejilerini olumsuz yönde etkileyeceğinden endişe duyduğunun farkındayız. Topics'in yayıncılar üzerindeki etkisi hakkında bilgi edinmemizi sağlayacak ekosistem testini heyecanla bekliyoruz. |
| Reklamlarla ilgili olmayan konularla ilgili kullanım alanları | İlgi alanına dayalı reklam göstermek dışındaki amaçlar için Topics'in kullanımı | 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 diğer kullanım alanları hakkında geri bildirim alıp değerlendirme yapıyoruz. |
| Varsayılan olarak dahil etme durumu | Konu izinleri için varsayılan ayarların bölgesel yasalar üzerindeki etkileri | Yasal görüşler hakkında yorum yapmamız uygun değildir. |
| (2022'nin 3. çeyreğinde de bildirilmiştir) Yanlış kategorize edilmiş siteler |
Belirli bir site için konuların yanlış kategorize edildiği durumlarda reklam hedefleme | 1. Çeyrek Güncellemesi: 2. çeyrekte, Topics API için güncellenmiş bir sınıflandırıcıyı duyuracağız ve ekosistemle bu konuda etkileşime geçmeyi umuyoruz. Mevcut geri bildirime yanıt olarak siteler, en popüler siteleri içeren ve gerçek kişiler tarafından derlenen bir geçersiz kılma listesi ile cihaz üzerinde bir ML modelinin bir kombinasyonu kullanılarak sınıflandırılır. Chrome, sitelerin Topics sınıflandırmasına katkıda bulunmasına yönelik seçenekleri değerlendirmeye devam ediyor. Tüm işlevsellik iyileştirmeleri, gizlilik ve kötüye kullanım riskleriyle birlikte değerlendirilmelidir. Örneğin, risklerden bazıları şunlardır: Kendi kendini etiketlemeyi konulara farklı (ve potansiyel olarak hassas) anlamlar kodlamak için kullanan siteler; finansal kazanç elde etmek için konularını yanlış beyan eden siteler; konuların diğer kullanıcılar için faydasını azaltmak amacıyla konulara saldıran siteler (ör. kullanıcının konularını anlamsız içeriklerle spam'leyen siteler). Herkes, chrome://topics-internals veya bu colab üzerinden kullanılabilen araçlarla bu bileşenleri inceleyebilir. Testler sayesinde sınıflandırmanın zaman içinde iyileşmesini bekliyoruz. Yanlış kategorize edilmiş olabilecek site örnekleri hakkında geri bildirimlerinizi bekliyoruz. |
| Konu Sınıflandırıcı | Hata ayıklama amacıyla arayana "No Topics" döndürüldüğünde nedenleri gösteren ek bilgilerin döndürülmesini isteme | Topics API'yi sistemlerine entegre etmeye çalışan geliştiricilerin hata ayıklama araçlarından yararlandığının farkındayız ve bu araçlardan yararlandıkları için geliştiricilere teşekkür ederiz. Ancak ek bilgiler (ör. hiçbir Konu döndürülmemesinin nedeni) paylaşarak, tarafların amaçlanandan daha fazla ayrıntı (ör. kullanıcı gizli moddaysa, API'yi devre dışı bıraktıysa vb.) keşfetmesine olanak tanıyan bilgileri yanlışlıkla paylaşabilir ve kullanıcı gizliliğini ihlal edebiliriz. Şu anda ek hata ayıklama araçları sunmayı planlamasak da hangi araçların yararlı olacağıyla ilgili geri bildirimlerinizi bekliyoruz. |
| Özel Bilgi Erişimi (PIR) | Topics API'nin Özel Bilgi Erişimi'ni benimsemesi için talep | PIR'yi daha önce araştırdık ve ödül ve riskleri burada paylaştık. |
| Teklif akışı | Topics, teklif akışında satıcı tanımlı kitlelerden farklı olarak mı temsil edilecek? | Topics API, Chrome tarafından geliştirilen bir Özel Korumalı Alan teklifidir ve IAB Tech Lab'in Satıcı Tanımlı Kitleler teklifinden farklıdır. Bu iki öğenin teklif akışında ayrı ayrı temsil edilmesini bekleriz. Konuların OpenRTB teklif isteklerinde nasıl temsil edileceğini öğrenin. |
Protected Audience API (eski adıyla FLEDGE)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| FLEDGE özelliğinin kullanılabilirliği | Çitli çerçeve yaptırımı, k-anonimlik vb. FLEDGE özellikleri için test ve uygulama zaman çizelgeleriyle ilgili açıklama. | Çeşitli kapsamlı FLEDGE özellikleri ve ne zaman desteklenecekleri hakkında durum bilgisini paylaştık. FLEDGE'i geliştirmeye devam ederken duyuruyla ilgili ek geri bildirimlerinizi bekliyoruz. |
| Ürün oluşturma kısıtlamaları | FLEDGE Çitli Çerçeveler için Birden Çok Parçadan Oluşan Reklamlar kısıtlamalarının gevşetilmesi talebi | Şubat ayında duyurduğumuz gibi, çitle çevrili çerçevelerin kullanımı en az 2026'ya kadar isteğe bağlı olarak kalacak ve iframe davranışı urn-iframes tarafından desteklenecektir. Bu konuyla ilgili daha fazla tartışmaya açığız. |
| Ölçeklenebilirlik sorunları | Kullanım ölçeği büyüdükçe FLEDGE performansı | Uygulanabilir çözümler önerebilmek için geri bildirimleri aktif olarak takip ediyor ve daha fazla bağlam bilgisi ediniyoruz. İlk adım olarak geri bildirimleri iki kategoriye ayırdık:
|
| (2022'nin 3. çeyreğinde de bildirilmiştir) Teklif verme mantığının görünürlüğü |
DSP teklif verme mantığının JavaScript'de gösterileceğiyle ilgili endişe | 1. Çeyrek Güncellemesi: Düşmanların, keşif amaçlı (zorunlu tarama) bir şekilde sunucudan veri isteme yeteneğini sınırlayacak bir öneri paylaştık. Ekosistem oyuncularının öneriyle ilgili geri bildirimlerini veya desteklerini paylaşmalarını bekliyoruz. |
| Test zorlukları | Daha küçük DSP'lerin FLEDGE'i düzgün bir şekilde test edebilmesi ve reklamverenlerin yalnızca daha büyük DSP'lerle test yapmak isteme riskini azaltması | Daha küçük TTP'lerle çalışmaya kararlıyız ve FLEDGE genel kullanıma sunulduğunda tüm büyüklüklerdeki TTP'ler ve reklamverenler arasında kapsamlı test yapılmasını önemle tavsiye ediyoruz. FLEDGE'i ekosistemdeki diğer satıcılarla test ederken onlara en iyi şekilde nasıl yardımcı olabileceğimizi öğrenmek isteriz. Ayrıca reklamverenleri daha küçük DSP'lerle test yapmaya teşvik etmek için sektördeki fikir ve çabaları memnuniyetle karşılarız. |
| Dinamik yeniden pazarlama | Üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasından sonra FLEDGE ile dinamik yeniden pazarlama mümkün olacak mı? | Bu soruya yanıt vermeyi düşünüyoruz ve ekosistemdeki oyuncuların Dinamik Yeniden Pazarlama'yı nasıl kullanmayı planladıklarıyla ilgili ek analizler paylaşmalarını bekliyoruz. |
| Sahtekarlık/Kötüye Kullanım | Ekosistem, riskleri nasıl azaltabilir ve kötü niyetli kişilerin veya alıcıların kendilerini arzu edilen bir kitle olarak konumlandırmasını nasıl engelleyebilir? | Ekosistemdeki oyuncularla sahtekarlık ve kötüye kullanım konusunda daha fazla etkileşime geçmeyi umuyor ve bu alanda daha fazla geri bildirim almayı bekliyoruz. |
| 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 sunmak için en iyi konumda olan taraftır. |
| Nicel Test teklifi | Nicel testin adil olması için test, üçüncü taraf çerezleri olmayan trafikte mi yoksa yalnızca FLEDGE kullanan SSP'lerde mi yapılmalıdır? Üçüncü taraf çerezlerinden gelen sinyallerin karışmasını nasıl önleyebilirim? | Bu geri bildirim için teşekkür ederiz. Üçüncü taraf çerezleri için desteğin sonlandırılmasının ve Özel Korumalı Alan önerilerinin ekosistem üzerindeki etkisini güvenilir bir şekilde gösteren denemeler tasarlamak için CMA ile birlikte çalışıyoruz. CMA'nın Kantitatif Test önerisi hakkındaki ek geri bildirimlerin doğrudan CMA ile paylaşılmasını öneririz. |
| Daha net dokümanlar | Açık artırma yapılandırması hakkında daha net dokümanlar isteğinde bulunma | Önümüzdeki haftalarda FLEDGE Açık Artırma Raporlaması hakkında daha fazla genel bakış içeren bir blog yayını paylaşmayı umuyoruz. |
| Paralelleştirme | Teklif ve Açık Artırma (B&A) Hizmeti paralelleştirmeyi destekleyecek mi? | Teklif verme / açık artırma sunucuları kullanan bir reklam teknolojisi, sonuçları paralel olarak yayınlayabilecek birden fazla sunucu başlatabilir. |
| Kötüye kullanım azaltma | Gizli Durum Jetonları kullanan FLEDGE k-anonimlik sunucusu, kullanıcı gizliliğini sağlamak için yeterli mi? | K-anonimlik, mikro hedeflemeye değil, FLEDGE'in etkinlik düzeyinde raporlamaya izin verdiği ara aşamada bir destekleyiciye sahip olmaya odaklanır. Daha fazla düşüncemizi paylaştık ve ek geri bildirimlerinizi bekliyoruz. |
| ES modülü uyuşmazlığı | ES modülüyle çakıştığı için generateBid işlevinin genel işlev olarak kaldırılması isteği |
Bu isteği görüşüyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Bileşen açık artırması | Yayıncıların açık artırma tasarımları üzerinde daha fazla kontrole sahip olması için istek | Cihaz üzerinde Chrome ile aynı şekilde bileşen açık artırmasını desteklemek için teklif verme ve açık artırma planı. |
| B&A Zaman Çizelgeleri | B&A sunucularını test etmek isteyen reklam teknolojisi şirketleri için zaman çizelgesi netliği | Karşılaştırmalı test açıklama sayfasını ve zaman çizelgesi bölümünü, CMA ile uyumlu hale getirdikten sonra Chrome karşılaştırmalı testinin farklı aşamalarına ait zaman çizelgelerinin net tanımlarını içerecek şekilde güncelledik. |
| Zaman aşımı kontrol şeması | FLEDGE için şu anda kullanılabilen zaman aşımı kontrol şemasını iyileştirme | Bu ilginç bir teklif. Bu öneriyi, incelenecek öneriler kuyruğuna ekleyeceğiz ve gelişmeleri bildireceğiz. |
| Reklam öğesi teklif akışları | Reklam öğesine göre kazanan teklifi inceleme ve filtreleme olanağı | Bu ilginç bir teklif. Bu öneriyi, incelenecek öneriler kuyruğuna ekleyeceğiz ve gelişmeleri bildireceğiz. |
reportWin |
reportWin işlevinde kazanan dışındaki farklı bir ilgi alanı grubu sahibinden en yüksek puan alan teklifle ilgili ek bilgi sağlama önerisi |
Bu ilginç bir teklif. Toplu raporlamaya ek sinyaller eklemeyi değerlendireceğiz ve buradan ek geri bildirimlerinizi bekliyoruz. |
| Etkinlik türleri | FLEDGE ile entegre edildiğinde ölçüm API'leri genelinde etkinlik türlerini standartlaştırma | Bu ilginç bir teklif. Bu öneriyi, incelenecek öneriler kuyruğuna ekleyeceğiz ve gelişmeleri bildireceğiz. FLEDGE'in ötesinde diğer Özel Korumalı Alan API'lerini etkileyeceğinden, bu alandaki daha kapsamlı çalışmalarımızla koordinasyon gerektirecektir. Burada ek geri bildirimlerinizi bekliyoruz. |
| Etkinlik düzeyinde raporlama için uzun vadeli çözümler | Üçüncü taraf çerezleri desteğinin sonlandırılmasından sonra bile highestScoringOtherBid gibi belirli verileri kullanmaya devam etme isteği |
Şubat ayı blog yayınımızda paylaştığımız gibi, etkinlik düzeyinde açık artırma kazancı raporlaması "en az 2026" yılına kadar desteklenecek. Şu anda paylaşabileceğimiz başka ayrıntılar yok ancak üçüncü taraf çerezlerinin desteğinin sonlandırılmasından sonra belirli verilerin neden kullanılabildiğiyle ilgili ek geri bildirimlerinizi bekliyoruz. |
| İlgi alanı grubu sınırı | Bir kaynağın tek bir tarayıcıya ekleyebileceği ilgi alanı grubunun sayısıyla ilgili sınır nedir? | Chrome, sahip başına en fazla 1.000 ilgi alanı grubuna ve en fazla 1.000 ilgi alanı grubu sahibine izin verir. Bunlar, normal çalışma sırasında aşılmaması gereken sınırlar olarak tasarlanmıştır. |
| Etkinlik düzeyindeki sinyaller | Makine öğrenimi eğitiminde kullanılabilecek generateBid ve reportWin için etkinlik düzeyinde sinyaller sunma önerisi için destek |
Tarayıcı tarafından tasarlanan sinyaller ve reklam teknolojisi tarafından tanımlanan sinyaller ile ilgili kararımızı burada paylaştık ve ek geri bildirimler almaya hazırız. |
| Teklif verme komut dosyası | Kullanıcı kimliğini teklif verme komut dosyasının URL'sine ekleyin. | FLEDGE, bir reklamın gösterilebilmesi için ilgi alanı grubu sahibinin, teklifli sistem komut dosyası URL'sinin ve oluşturulan reklam öğesinin k-anonim olması gerektiği ek koşuluna sahip olduğundan bu mümkün olmayacaktır. |
| K-anon yaptırımı | (componentAd, size) çiftinde k-anonimlik zorunlu mu? | Evet, olacak. turtledove/issues/312 adresine bakın. |
| Teklif ve Açık Artırma Hizmetleri şartları | B&A Hizmetleri, cihaz üzerinde FLEDGE ile entegrasyon yapan katılımcıları ve B&A hizmetleriyle entegrasyon yapan diğer katılımcıları nasıl destekler? | Tasarım üzerinde çalışmalarımız devam ediyor. Bu konudaki geri bildirimlerinizi buradan gönderebilirsiniz. |
| Görüntüleme sonrası ilişkilendirme | Görüntüleme sonrası ilişkilendirme desteklenecek mi? | Şu anda görüntülenebilirlik için standart bir tanımımız yok ve görüntüleme etkinliğini işaretlemek için reklam öğesinin kendisine güveniyoruz. turtledove/issues/452 adresine bakın. |
| Benzer hedefleme | Özel Korumalı Alan "benzer hedeflemeyi" destekleyebilir mi? | Kullanım alanı hakkında buradan konuşuyoruz ve ek katkılarınızı bekliyoruz. |
| Gerçek zamanlı izleme API'si | Gerçek zamanlı FLEDGE izleme yaklaşımı önerisi | Teklifi görüşüyoruz ve buradan ek görüşlerinizi bekliyoruz. |
| FLEDGE raporlaması | Aşırı veya eksik raporlamayı önlemek için reportWin ve reportResult rastgele sırayla yapılmalıdır. |
reportResult()'teki satıcı sinyallerinin reportWin()'e dahil edilebilmesi için reportResult()'in önce satıcı tarafından, ardından alıcı tarafından yürütülmesi gerekir.reportWin() Daha fazla bilgi için açıklamayı inceleyin. |
| Özel anahtar/değer (K/D) sunucuları | Gelecekte özel K/V sunucuları desteklenecek mi? | Soruyu burada tartışıyoruz ve ek katkılarınızı bekliyoruz. |
| Üst düzey açık artırma | Üst düzey açık artırma mekanizmalarını çalıştırmak için reklam sunucusu olmam gerekir mi? | FLEDGE API, hangi tarafın çağırması gerektiğini belirtmez. FLEDGE'in tasarımında bu anlamda herhangi bir şart yoktur. Herkes FLEDGE açık artırmasını (çok satıcılı açık artırmalar dahil) çalıştırabilir. 2022 4. çeyrek raporunda belirtildiği gibi FLEDGE, her yayıncının üst düzey ve bileşen satıcıları da dahil olmak üzere açık artırmanın yapısını seçmesine olanak tanır. |
| API kapsamı | FLEDGE, birinci taraf verileriyle çalışmayı amaçlıyor mu? | 2023'ün 2. çeyreğinde, birinci taraf verilerinin FLEDGE ile hem 1) ilgi alanı grubu üyeliğini belirlemek için mantık olarak hem de 2) sonraki teklif verme mantığı oluşturma aşamasında kullanılmak üzere kullanıcı teklif verme sinyalleri olarak kullanılabileceğini açıklayan bir içerik yayınlayacağız. |
| Alanlar arası ilgi grupları | Alanlar arası ilgi alanı grupları oluşturma imkanı | Bir tarayıcı ilgi alanı grubuna eklenirken mevcut olan tüm bilgiler, ilgili kitleyi bilgilendirmek için kullanılabilir. Üçüncü taraf çerezleri kullanımdan kaldırıldığında, ilgi alanı grubu oluşturma sürecini bilgilendirmek için siteler arası verilerin kullanılabilirliği sınırlı olacaktır. |
| İstemci tarafı teklif verme mantığı | Mevcut sunucu tarafı teklif verme mantığını istemci tarafına taşıma | Uygulamanızı taşıma sürecinde hangi alanların zor olduğu veya hangi alanlarda eksiklik olduğu hakkında daha fazla bilgi edinmek istiyoruz. Ek geri bildirimlerinizi veya görüşlerinizi bekliyoruz. |
| K/V sunucusu değerleri | K/V sunucu değerlerinin dize türüne sahip olması gerekir mi? | Değerin dize olması gerekir ancak nesneleri JSON'da veya protokol arabelleğinde saklayabilir ve dize olarak serileştirebilirler. |
| Reklamveren engellenenler listesi | Bir reklamveren engellenenler listesi için alıcıya hangi sinyaller sağlanmalıdır? | Uygun yer auctionSignals veya perBuyerSignals'dadır. |
| Teklif verme birimi | YBM ve BGBM gibi farklı teklif birimleri için destek | Mevcut tasarım göz önüne alındığında 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 mu karar verir? | Tüm kazanan seçimleri korumalı alanda gerçekleştirilir ve tüm kararlar satıcının kodu tarafından alınır. Tarayıcı, alıcı ve satıcı kodunun çalıştığı kapalı ve özel bir ortam sağlar. |
| İzinler Politikası | Kaynak denemesi sona erdikten sonra mevcut FLEDGE izin politikası uygulanmaya devam edecek mi? | Kaynak denemesi için her iki özelliğin de mevcut varsayılan izin verilenler listeleri geçicidir ve değiştirilecektir. Değişikliği uygulamaya başlamadan önce reklam teknolojisi uzmanlarının bu değişikliğe hazırlanması için ne kadar süreye ihtiyaç duyduğunu öğrenmek istiyoruz. |
| Sinyal boyutu kısıtlaması | Güvenilir Teklif Sinyalleri istekleri, aynı trustedBiddingSignalsUrl ile birden fazla ilgi alanı grubunda birleştirilir; 2 MB boyut sınırı bir kısıtlamadır. |
Bu kısıtlama, cihaz üzerinde arayanların cihazdaki kaynakların aşırı yüklenmesini önlemek için vardır. B&A sunucusundan arayanlar için daha gevşek bir kısıtlama uygulanır. |
| Raporlama sinyalleri | İlgi alanı grubu sahibi ve computeBid veya reportWin / reportResult başına istemci tarafı hata sayısının alınmasına olanak tanımak için script-errors adlı ek bir sinyal ekleyin. |
Bu teklifle ilgili olası gizlilik endişelerini değerlendiriyoruz ve ekosistemdeki oyuncuların bu değişikliğin neden gerekli olduğuna dair ek analizler paylaşmasını bekliyoruz. |
| K-Anon pencere boyutu | K-Anon aralığı boyutunu mevcut 7 günlük sınırdan artırın. | Bu konu üzerinde çalışılıyor ve şu anda ekosistemden ek katkı bekliyoruz. |
| Cihaz performansı | Kullanıcı çok sayıda ilgi alanı grubundaysa FLEDGE cihaz performansını nasıl yönetir? | FLEDGE, SSP'ler ve DSP'ler genelinde cihaz performansının, cihaz çok sayıda ilgi alanı grubundayken açık artırma katılımını sınırlamanın nedenlerinden biri olabileceği durumlarda reklam teknolojisi uzmanlarına ayrıntılı kontrol sağlayan çeşitli zaman aşımı, önceliklendirme ve sınır seçenekleri sunar. |
| B&A Hizmetleri testleri | Hata ayıklama için daha fazla günlük elde etmek amacıyla ekosistem oyuncularının test aşamasında kendi sunucularını kullanmalarını isteme | B&A, kullanıcıların onaylanmış bulut sağlayıcılardan sunucular 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ılıyoruz. Yakında B&A TEE'de hata ayıklama hakkında bir açıklama yayınlayacağız ve bunu destekleyecek özellikler geliştiriyoruz. Konuyla ilgili ek geri bildirim almak istiyoruz. |
| Yasal şartlar | FLEDGE, yerel yasal şartlara uygunluğu desteklemek için farklı ülkelerdeki bulut sağlayıcılarla çalışacak mı? | Diğer bulut sağlayıcılarla ilgili önerilere her zaman açığız ancak şu anda üçüncü taraf çerezleri desteğinin sonlandırılması uygulandığında en azından GCP ve AWS'yi desteklemeyi planlıyoruz. Daha fazla bilgi için bu açıklamayı inceleyin. |
Dijital reklamları ölçme
İlişkilendirme raporları (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 analizi yapma hakkında yol gösterici bilgiler | Gürültü ve 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 dokümanlar paylaştık. Daha ayrıntılı bir kılavuz da mevcuttur. |
| Boş raporlama | Boş raporların uygulanmasıyla ilgili netlik | Şu anda boş raporları uygulamaya yönelik bir teklif üzerinde çalışıyoruz ve yakında daha fazla ayrıntıyı paylaşacağız. Boş raporları uygulamak, gizlilikten ödün vermeden rapor gecikmelerini azaltmamıza olanak tanır. |
| Gürültü seviyesi | İlişkilendirme aralığı uzunluğuna göre gürültü seviyesini ayarlama | Bu öneriyi memnuniyetle karşılıyoruz ve spesifikasyona eklemeyi düşünüyoruz. Buradaki ek geri bildirimlerinizi bekliyoruz. |
| Tetikleyici veri boyutu | Tetikleyici veri boyutu neden 3 bit ile sınırlıdır? | Boyut, bir kullanıcıyla ilgili siteler arası/bağlam bilgisi miktarının sınırlı olmasını sağlamak için 3 bit ve 8 farklı değerle sınırlıdır. Ekosistemdeki oyuncuların, etkinlik düzeyinde raporlama için mevcut parametrelendirmenin mantıklı olup olmadığı konusunda geri bildirim göndermelerini bekliyoruz. |
| Etkinlik düzeyinde raporlama tetikleyicileri | Tekilleştirme anahtarında önceliklendirmeye izin verme | Bu soruna çözümler arıyoruz ve ek katkılarınızı bekliyoruz. |
| Hata ayıklama desteği | Üçüncü taraf çerez desteğinin sonlandırılmasının ardından hata ayıklamayla ilgili netlik | Üçüncü taraf çerezlerinin desteğinin sonlandırılmasından sonra hata ayıklama özelliğini desteklemek istiyoruz ve seçenekleri değerlendiriyoruz. Ek geri bildirim ve fikirler almak istiyoruz. |
| Tıklama dönüşümü alternatifleri | Tıklama dönüşümleri için alternatifler hakkında daha fazla bilgi isteyin | Ekosistemin, geçerli dönüşüm ölçümü kullanım alanları için kalıcı bir özel ölçüm sistemi olarak Attribution Reporting API'yi kullanmasını öneririz. Diğer alternatifler de mevcuttur ve reklam teknolojisi sağlayıcıların, istedikleri gizlilik ve yardımcı program ihtiyaçlarına göre uygun çözüme karar vermesi gerekir. |
| Faturalandırma kullanım alanları | Attribution Reporting'in dönüşüme dayalı faturalandırma kullanım alanlarını ne ölçüde destekleyeceği konusunda netlik | Faturalandırma için Attribution Reporting API'nin kapsamını netleştirmek üzere herkese açık bir yayın üzerinde çalışıyoruz. İlişkilendirme Raporlama API'si başlangıçta doğrudan EBM faturalandırmasını destekleyecek şekilde kapsamlandırılmamıştı. Reklam teknolojilerinin çoğunun kullandığı faturalandırma yapısı olan TBM ve BGBM faturalandırmasını destekler. Ekosistemle ilgili başka geri bildirimler olursa bu özelliği gelecekte destekleyebiliriz. |
| Kullanım alanı desteği | Measurement API için kullanım alanı dokümanları | Tüm Özel Korumalı Alan raporlama platformlarının dokümanlarını daha anlaşılır hale getirmek için çalışıyoruz. |
| Tıklama kalitesi | Bir reklama yapılan kasıtlı ve kasıtsız tıklamaları ayırt etmek için sinyal ekleme isteğinde bulunma | İsteği görüşüyoruz ve ek görüşlerinizi bekliyoruz. |
| Ölçüm çözümü | Birden fazla DSP'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. Ayrıca, attributionsrc içinde bir URL listesi için destek öneriyoruz. Bu, DSP'lerin ölçüm sağlayıcı Attribution Reporting API isteklerini desteklemesini kolaylaştıracaktır. Yukarıdaki teklifle ilgili ek geri bildirimlerinizi bekliyoruz. |
| Etkinlik düzeyinde raporlama | Raporun gönderilmesinden önceki gün sayısının doğrudan gösterilmesini isteyin | Bu istek, reklam teknolojileri tarafından halihazırda mevcut bilgiler kullanılarak hesaplanabilir. Bu istekle ilgili başka bir ekosistem geri bildirimi almadık ancak bu konuda geri bildirim almaya açığız. |
source_registration_time |
Etkinlik düzeyinde İlişkilendirme Raporlaması'na source_registration_time ekleyin. |
Bu isteği değerlendiriyoruz ve ekosistemdeki oyuncuların bu özelliği kullanışlı bulup bulmadıklarıyla ilgili ek geri bildirimleri memnuniyetle karşılıyoruz. |
| 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 devre dışıdır. |
| Veri temizleme odaları | Measurement API'leri temiz odalarla uyumlu olacak mı? | Tipik bir veri temizleme odası, farklı kaynaklardan gelen tekil tanımlayıcı verilerinin, temel verileri birleştirerek analizler çalıştırmak için bir veritabanına yüklendiği bir ortamdır. Özel Korumalı Alan API'leri için iki ölçüm çerçevesi vardır: etkinlik düzeyindeki raporlar ve özet raporlar. Etkinlik düzeyindeki raporlar, veri temizleme odasında kullanılabilecek reklam teknolojisi tarafından sağlanan bir etkinlik kimliği içerir ancak ilişkili dönüşüm tarafı bilgileri sınırlı ve gürültülü olacaktır. Şifrelenmiş birleştirilebilir raporlar doğrudan temiz bir odada kullanılamaz ancak Toplama Hizmeti tarafından sağlanan özet sonuçlar, gerçekleştirdiğiniz analizlere giriş olarak veya ek bilgi olarak kullanılabilir. |
Aggregation Service
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| (2022'nin 4. çeyreğinde de bildirilmiştir) Raporlama gecikmeleri |
Beklenen raporlama gecikmesi nedir? | 2023'ün 1. Çeyreğine Ait Güncelleme: İş ortağı geri bildirimlerini dikkate alarak gecikmeyi azaltma ve gecikmenin etkisini azaltma ile ilgili önerilerimizi paylaştık. Her iki teklif de WICG görüşmeleri sırasında reklam teknolojileri tarafından desteklendi. |
| Yinelenen öğe yok kuralı | Aynı paylaşılan kimliğe sahip toplu raporlar zaten işlenmişse "gecikmeli toplu rapor"u nasıl ele alırsınız? | Toplu API'deki gecikme kaybının etkisini kısmen ele almak için toplanabilir raporların paylaşılan bilgilerine ek rapor gecikmesi ekleme ve Toplama Hizmeti için paylaşılan kimliğin tanımı hakkında bir teklif paylaştık. Teklif hakkındaki geri bildirimlerinizi bekliyoruz. |
| Veri işleme | Gizlilik bütçesini kullanarak diferansiyel gizliliğe saygı duyarken birden fazla veri geçişi desteğini etkinleştirme isteğinde bulunma | Bu kullanım alanını etkinleştirmek için gizlilik bütçesini daha esnek bir şekilde kullanma olasılığını tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| (2022'nin 2. çeyreğinde de raporlanmıştır) Sorgu ergonomisi | Anahtarların toplu olarak sorgulanması etkinleştirilmelidir. | 2023'ün 1. Çeyreğine Ait Güncelleme: Özellik isteği hâlâ değerlendiriliyor ancak şu anda paylaşabileceğimiz bir önerimiz yok. |
| Origin deneme sürümü sınırlamaları | Şu anda kaynak denemede uygulanmayan "yinelenen öğe yok kuralı" gibi Toplama Hizmeti'nin kapsamını açıklayın. | Kaynak deneme sürümünde ve genel kullanım sürümünde hangi özelliklerin kullanılabileceğini açıklayacak şekilde dokümanlarımızı güncellemeyi planlıyoruz. |
Private Aggregation API
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Özel Toplama Katkı Bütçesi | L1 katkı bütçesi çok kısıtlayıcı. | Özel Toplama API'sine yapılan her çağrıya katkı adı verilir. Kullanıcı gizliliğini korumak için bir kişiden alınabilecek katkıların 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 az olmalıdır. Mevcut tasarımda, son yaklaşık 24 saat içinde belirli bir raporlama kaynağının katkıları için bir sınır belirleriz (devirli bir pencere olarak). Bu, geri bildirimde bahsedilen L1 katkı bütçesidir. Geliştiricilerin, katkıda bulundukları değerleri beklenen hacme göre ölçeklendirmesini öneririz (yani yalnızca 1 değerini kullanmamalarını öneririz). Bu nedenle, bütçenin tükenmesini önlemek için daha yaygın etkinlikler için daha küçük bir değer kullanmak mantıklı olabilir. Şu anda Private Aggregation API'nin hem sayısal sınır hem de kapsam açısından katkı bütçesi hakkında geri bildirim almak istiyoruz. Kapsamı kaynak başına yerine site başına taşımayı ve mevcut sınırı daha büyük bir günlük sınıra sahip on dakikalık bir aralığa taşımayı düşünüyoruz. |
Gizli İzlemeyi Sınırlama
User-Agent Kısaltma/User-Agent İstemci İpuçları
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| UA-R kullanımı | Birleşik Krallık'taki en popüler 10.000 siteden programatik reklamcılık kullanan sitelerin yalnızca% 1'i HTTP istemci ipuçları gönderiyor. Taşıma işlemini gerçekleştirmeyen DSP'ler, sahtekarlık önleme özelliklerini etkileyebilir. | Aynı veri kümesi üzerinde bir analiz çalıştırdıktan sonra, HTML <meta> etiketini ve JavaScript API'lerini kullanarak UA-CH kullanımını hesaba katarsanız UA-CH kullanan site sayısının, geri bildirimde verilen% 1'den çok daha yüksek olduğunu tespit ettik. Bu bilgilere ve ekosistemden gelen geri bildirimler de dahil olmak üzere diğer gerçeklere dayanarak, UA azaltma sürecinin 6. aşamasını yayınlanan zaman çizelgesine uygun şekilde kademeli olarak kullanıma sunma konusunda kararlıyız. Bu süreçte CMA'yı da bilgilendireceğiz. Sitelerin geçişe hazırlanmak için yaklaşık iki yıl süre tanıdığını ve hazır olmadığını düşünen siteler için desteğin sonlandırılmasına ilişkin deneme sürümünün hâlâ kullanılabildiğini hatırlatmak isteriz. |
| Ek form faktörleriyle ilgili ipuçları | UA-CH'nin TV, VR gibi ek form faktörleri sağlaması için istek | Bu öneriyi memnuniyetle karşılıyoruz ve tasarıma dahil etmeyi düşünüyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| Otomatik test | UAR 6. Aşama yayınlanmadan önce gözetimsiz Chrome'daki UA-CH hatasının çözülmesi için istek | Söz konusu hata düzeltildi. |
| iOS'te UA-CH desteği | Reklam kullanım alanları için ayrıntılı UA bilgilerinden yararlanan bir site, iOS'teki Chrome'un desteklenmediğini belirtir. | Safari dışındaki iOS tarayıcıların (iOS'teki Chrome dahil) etkinleştirilebilmesi için WebKit projesinin UA-CH desteğini eklemesi gerekir (ağ yığınını kontrol ettikleri için). |
IP Protection (eski adıyla Gnatcatcher)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| (4. çeyrekte de raporlanmıştır) Coğrafi konumlandırma kullanım alanları | IP Koruması, coğrafi konuma dayalı içerik kişiselleştirme gibi meşru coğrafi konum kullanım alanlarının gelecekte çalışmasını engelleyebilir. | Yanıtımız 2022'nin 4. çeyreğinden bu yana değişmedi: "Chrome'un IP adresleri için meşru kullanım alanlarını desteklemeye devam etmesini sağlamak amacıyla paydaşlarla birlikte çalışıyoruz. IP coğrafi konum ayrıntı düzeyi hakkında ekosistem geri bildirimi istiyoruz." |
| Düzenlemelere uygunluk | Bir bölgenin nüfusu 1 milyonun altındaysa IP koruması için geçerli olan 1 milyonluk eşik, web sitelerinin yasal uygunluk için IP adreslerini kullanmasını engeller. | Chrome'un IP adresleri için meşru kullanım alanlarını desteklemeye devam etmesini sağlamak amacıyla paydaşlarla birlikte çalışıyoruz. IP korumasıyla ilgili yasal uygunluk konusunda ekosistemden geri bildirim almak istiyoruz. |
| Kötüye kullanım azaltma | Taraflar, maskesiz IP adreslerini başkalarıyla paylaşarak IP Koruması'nı atlatabilir. | Mevcut IP koruması önerisinin, tarafların maskesiz IP adreslerini başkalarıyla paylaşmasını teknik olarak engelleyemeyebileceği riskinin farkındayız. Bu kötüye kullanım riskini önleyecek önlemler üzerinde çalışıyoruz. Teklifi tekrar tekrar ele alırken daha fazla geri bildirim ve tartışmaya davet ediyoruz. Özellikle, tarafların maskesiz IP adreslerini diğer taraflarla paylaşmaları gerektiğini düşündükleri tüm kullanım alanlarını öğrenmek isteriz. |
| Ağ engelleme | Taraflar, IP koruma proxy'lerini kullanarak ağ engellemesini atlayabilir. | Engellemeyi gerçekleştiren tüzel kişinin bu senaryoda IP korumasını devre dışı bırakması gerekir. Soruna yanıt verdik ve ek geri bildirimlerinizi bekliyoruz. |
| IP koruma önerisinden etkilenen IP adresi engellenenler listeleri | Birçok reklam teknolojisi şirketi, sahtekarlık (veya en azından para kazanılamayacak) olma olasılığı yüksek reklam envanteri için teklif vermeyi önlemek amacıyla TAG veri merkezi IP listesi gibi temel bir IP adresi engelleme listesi kullanır. Bir reklam teknolojisi aynı zamanda izleyiciyse ve IP Koruma teklifine tabi olabilecekse bu şirket, reklam envanteri satın almadan önce reklamlarla ilgili temel bir kontrol gerçekleştirme özelliğini kaybedebilir. | Olası sorunlar ve çözümler hakkında daha fazla geri bildirim ve fikri mülk koruma teklifi hakkında daha fazla tartışma yapmanızı öneririz. Bir seçenek, daha önce işaretlenmiş IP adreslerinden gelen istemcilerin proxy'sini yapmamak için IP Koruması'na benzer listeler uygulamaktır. |
Siteler arası gizlilik sınırlarını güçlendirme
Birinci Taraf Gruplar
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| (4. çeyrekte de raporlanır) Alan sınırı | İlişkilendirilen alan adlarının sayısını artırma isteği | Yanıtımız 2022'nin 4. çeyreğinden bu yana değişmemiştir: "WICG toplantılarında, Chrome'un kullanıcıların gizlilik çıkarlarını da gözeterek kullanılabilir bir çözüm sunmaya kararlı olduğunu açıkça belirtmiştik. Bu bağlamda, alan sınırından etkilenebilecek belirli kullanım alanları hakkında topluluğun geri bildirimlerini memnuniyetle karşılarız. Böylece ekip, kullanıcı gizliliğini korumaya devam ederken bu kullanım alanlarını ele alma yollarını değerlendirebilir." |
| Alternatif FPS gönderimi | FPS için küresel listeleri göndermenin alternatif bir yolu | Şu anda Chrome'da birinci taraf gruplarını (FPS) kullanıma sunmaya hazırlanıyoruz ve grup gönderimlerini kabul etmek için merkezi bir GitHub deposu oluşturduk. FPS'nin, üçüncü taraf çerez desteğinin sonlandırılmasına hazırlanırken mevcut web platformu çözümleriyle ilgili bir boşluğu doldurmasını umduğumuzdan, site yazarlarının FPS'den nasıl yararlandığını öğrenmeyi umuyoruz. Zaman içinde grup listesi büyüdükçe ve ekosistem üçüncü taraf çerezleri sonrası bir dünyaya uyum sağladıkça süreci, önerilen gibi alternatif merkezi olmayan şemaları dikkate alabileceğimiz bir noktaya kadar da geliştirebiliriz. Mevcut süreçle birlikte, zaman içinde giriş sürecini geliştirmemize olanak tanıyacak belirli bir kullanım ömrü belirlemeyi planlıyoruz. Gönderim süreci tamamlandıktan sonra bu fikri tekrar ele alabiliriz. |
| Depo moderasyonu | Kötüye kullanımı önlemek için FPS Gönderimi deposunda topluluk moderasyonunu etkinleştirin. Kötü niyetli kullanıcılar, grup önermek için tek kullanımlık kaynak kullanarak süreci kolayca tıkayabilir ve çok sayıda istek, gerçek grup teklifleriyle ilgili işlemleri etkileyebilir. | Teknik doğrulama kontrollerini kullanarak kontrolleri mümkün olduğunca objektif hale getirmeye çalışıyoruz. Bu, gönderim sürecine yönelik en ölçeklenebilir yaklaşımdır. Bu hedef doğrultusunda, sürecin spam / tek kullanımlık hesaplar tarafından gönderilen gönderimlere karşı dayanıklı olmasını da sağlamayı amaçlıyoruz. |
| İlişkilendirilmiş alt kümeler | FPS, ilişkili 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 First-Party Sets kapsamında değerlendirilen bir kullanım alanı değildir. Siteler arası çerezlerin bu kullanım alanları için nasıl kullanıldığına dair ek geri bildirim almaktan memnuniyet duyarız. |
| FPS + CHIPS entegrasyonu | A/B testi gibi kullanım alanlarını desteklemek için FPS + CHIPS entegrasyonu isteği | Bu kullanım alanını tartışıyoruz ve WICG görüşmesinde daha ayrıntılı bir şekilde ele almayı da düşünüyoruz. Burada ek görüşlerinizi paylaşabilirsiniz. |
| GDPR | GDPR kavramlarına göre modellenecek yeni bir FPS alt kümesi önerisi | Bu öneriyi şirket içinde tartıştık ve diğer geri bildirimlerle birlikte gizlilik hedeflerimize göre değerlendirdik. Bu öneriyi şu anda neden hayata geçirmeyeceğimizi açıklayan bir yanıt sağladık. |
| Bellek | FPS listesi dahil edildiğinde tarayıcı bellek boyutunda beklenen değişiklik | Tarayıcılarda bu tür listelerin (ör. İzleme Koruması Bağlantısı Kesme Listesi) minimum bellek etkisiyle saklanmasına dair örnekler vardır. First-party Sets listesi her Chrome istemcisine yerel olarak kopyalanırken dosya boyutunu izlemeye devam edeceğiz ve bellek kullanımını optimize edebileceğimizden eminiz. |
Fenced Frames API
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Sınırlı çerçevelerle ilgili sınırlamalar | Çitli çerçevelerin getirdiği sınırlamalarla ilgili netlik | Mart ayında, çitli çerçeveler hakkındaki açıklamamızı güncelledik. Bu açıklamamızda, çitli çerçevelerin özellikleri hakkında bilgi verilmektedir. Ek geri bildirimlerinizi bekliyoruz. |
| Erişim bilgilerini genişletin | Komşu karelerle ilgili bilgilere erişimi genişletme isteği | Bu şartın ekosistem için neden gerekli olduğunu daha iyi anlamak istiyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| Sınırlı çerçeveler ve iFrame'ler | Çitli çerçeveler ile iFrame'ler arasındaki özellik denklik durumuyla ilgili sorular | Mevcut tüm Özel Korumalı Alan API'leri ve raporları, iFrame'ler ve FencedFrames için aynı şekilde kullanılabilir. |
| Sınırlandırılmış kareleri yeniden boyutlandırma | Kare 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 istiyoruz ve ek geri bildirimlerinizi bekliyoruz. |
Shared Storage API
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Üçüncü taraf iş parçacıkları | Üçüncü taraflar, kaynağa göre bölümlendirilmiş ortak depolama alanına yazabilir mi? Yoksa üçüncü taraf ölçüm için başka worklet'ler mi çağırıyorsunuz? | Tarayıcının, kodun yürütüldüğü kaynağı, verilerin kime ait ortak depolama alanına yazılacağını belirler. Bir sayfaya üçüncü taraf kodu eklendiğinde, üçüncü taraf kodu kendi tarama bağlamıyla bir iframe olarak yerleştirilebilir. Bu, üçüncü taraf kodunun kendi kaynağına yazmaya olanak tanır. Üçüncü taraf kodu, tarayıcı bağlamını değiştirmeyen bir iframe yerine komut dosyası olarak da yerleştirilebilir. Bu durumda üçüncü taraf, yerleştirenin paylaşılan depolama alanına yazabilir. Paylaşılan depolama alanından yalnızca bu alanın sahibinin veri okuyabileceğini unutmayın. |
| Tekilleştirme | Chrome ekosisteminin dışındaki etkileşimler için tekilleştirme yapılamaz. | Paylaşılan Depolama Alanı, Chrome'da Chrome Tarayıcı tabanlı benzersiz erişim çıkışları sağlamak için tasarlanmıştır. Bu çıkışların daha geniş erişim modellerinin bir parçası olarak nasıl kullanılabileceğini anlamak için reklam teknolojileriyle çalışmak istiyoruz. Çıktıların yalnızca etkileşimlerin bir kısmını hesaba katabileceğinin farkındayız ve üzerine eklenebilecek ek modelleme metodolojilerini keşfetmek için reklam teknolojileriyle çalışmak istiyoruz. |
| Dönüşüm yeniden inceleme aralığı | Zaman içinde dönüşümdeki değişiklikleri görmek için dönüşüm oranı için yeniden inceleme aralığı isteğinde bulunma | Bu, paylaşılan depolama alanı kullanılarak istemci tarafında çeşitli dönüşüm yollarının işlenmesi yoluyla uygulanabilir. Bu yöntem, güvenli ve bölümlenmemiş tarayıcı depolama alanındaki gelişmiş analizler için ek esneklik sağlar. |
| Öğenin son kullanma aralığı | Geçerlilik bitiş süresinin 90 güne uzatılması için istek | Veri saklama politikası Kasım 2022'de güncellendi ve her anahtarın son yazma işleminden otuz gün sonra temizlendiğini belirtir. Yeni politikanın ekosistem için uygun olup olmadığını anlamak üzere ek geri bildirimler bekliyoruz. |
| Reklam öğesi rotasyonu | Reklam öğesi rotasyonu kullanım alanları, açık artırma sonrası gerçek işlemleri yansıtmaz. | Reklam öğesi rotasyonu dokümanının doğru olup olmadığı konusunda daha fazla alıcı tarafı reklam teknolojisi şirketinden bilgi almak istiyoruz. |
CHIPs
Bu çeyrekte geri bildirim alınmadı.
FedCM
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Kimlik beyanı uç noktası | Kimlik beyanı uç noktasına rastgele isteklere açıkça izin verin. | Web sitelerinin, kullanıcıları rahatsız etmeden kaynaktan bağımsız kimlik bilgisi istekleri gönderme özelliğini sınırlamak için bu pull isteğinde Mozilla ile birlikte çalışıyoruz. Diğer geri bildirimleri de incelemeye ve ele almaya devam edeceğiz. |
| Kimliği önceden doldurma | FedCM, oturum açma formlarını FedCM listesindeki bir kimlik sağlayıcıyla önceden doldurmak için kullanılabilir mi? | Bu kullanım alanındaki endişe, kullanıcıyla etkileşime geçmemiş bir sitenin, kullanıcı tarafından kullanılan son kimlik sağlayıcıyı sorgulayabilmesi durumunda bilgi sızıntısına yol açabilmesidir. Bu konuyu görüşüyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Bağlama dayalı hesap seçimi | Hesap seçimi kullanıcı arayüzüne bağlama sinyalleri ekleme önerisi | Bu teklifi değerlendiriyoruz ve ek görüşmeler yapmaktan memnuniyet duyarız. |
Spam ve sahtekarlıkla mücadele etme
Private State Token API (ve diğer API'ler)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Özellikleri toplama anketi | 1. çeyreğin başlarında, çeşitli sahtekarlık önleme kullanım alanları için hangi özelliklerin gerekli olduğuna dair anket sonuçlarımızı topladık ve bunları herkese açık olarak paylaştık (dakikalar, sonuçlar) | Sahtekarlık önleme özellikleri için özel olarak tasarlanmış, gizliliği korumaya yönelik API'ler için yeni teklifler ve prototipler geliştirirken bu geri bildirimi dahil etmeyi planlıyoruz. Yeterli ihtiyaç duyulan ve kullanıcı gizliliğini korurken web'e özelliği sunmak için yararlanabileceğimiz mevcut teknolojinin bulunduğu geliştirmelere öncelik vermeyi planlıyoruz. Örneğin, cihaz ve önyükleme bütünlüğü yüksek puan aldı. Birçok platformda, cihaz bütünlüğünün değerlendirmesini güvenli bir şekilde paylaşan mevcut API'ler bulunuyor. Bu nedenle, topluluk gruplarında keşif yapmak için iyi bir adaydır. |
| Gönderim Niyeti için PST geri bildirimi | Gönderim işlemi kapsamında, Privacy Pass'in eski bir sürümünü kullandığımız için devam etme konusunda endişe duyduk. Ayrıca, spesifikasyonun belirli bölümlerinde net olmadığı ve tarayıcı uyumluluğunu kolaylaştırmak için iyileştirilmesi gerektiğine dair geri bildirim aldık. | GA'ya dağıtımdan önce önerilen özellik değişikliklerinin çoğunu ve birkaç API değişikliğini uygulamayı planlıyoruz. Geri bildirim 1. çeyreğin sonuna doğru geldi. Bu nedenle, github sorunlarını belirli ayrıntılarla takip ediyor ve lansman planımızda güncelleme yapıyoruz (bu geri bildirim raporu yayınlandığı sırada devam ediyor). API'deki daha büyük değişiklikleri değerlendirmeye açığız ancak en iyi yöntemin, genel kullanıma sunma işlemine devam edip daha fazla geliştiriciden uygulamalı geri bildirim almak olduğunu düşünüyoruz. Bu tartışmayı sürdürmeyi ve tarayıcı standartlaştırmasını sürdürmeyi umuyoruz. Yeni bir standart ortaya çıkarsa ve bu standart ne zaman kullanıma sunulursa bu standardı benimsemeyi ve ona dikkatli bir şekilde geçiş yapmayı planlarız. |