Geçmişte üçüncü taraf çerezleri, kullanıcının durumuyla ilgili bilgileri (ör. oturum açma durumu, kullandığı cihazla ilgili bilgiler veya bilinen ve güvenilir olup olmadığı) depolamak ve iletmek için kullanılıyordu. Örneğin, kullanıcının TOA ile oturum açıp açmadığı, belirli bir uyumlu cihaz türüne sahip olup olmadığı veya bilinen ve güvenilir bir kullanıcı olup olmadığı. Üçüncü taraf çerez desteğinin kullanımdan kaldırılmasıyla bu kullanım alanlarının çoğunun başka yöntemlerle desteklenmesi gerekecek.
Gizli durum jetonları, web'de bilgi paylaşmanın bir yolunu sunar. Ancak paylaşılabilen gerçek veri miktarıyla ilgili denetimler sayesinde gizliliği korur.
Gizlilik durumu jetonları (eski adıyla güven jetonları), kullanıcının kimliğine olan güvenin bir bağlamdan diğerine aktarılmasına olanak tanır. Ayrıca, sitelerin pasif izleme olmadan sahtekarlıkla mücadele etmesine ve botları gerçek kullanıcılardan ayırt etmesine yardımcı olur.
Bu belgede, Gizlilik Jetonları'nın (PST) uygulanmasıyla ilgili teknik ayrıntılar özetlenmiştir. Daha üst düzey bir özet için PST'ye genel bakış başlıklı makaleyi inceleyin.
Gizlilik jetonları nasıl çalışır?
PST'de anlaşılması gereken en önemli ilişki, kart verenler ile kart kullananlar arasındaki ilişkidir. Kartı veren ve kullanan aynı şirkette olabilir.
- Kullanıcı kimliği verenler: Bu varlıklar, bir kullanıcıyla ilgili bir sinyale (ör. kullanıcının bot olup olmadığı) sahiptir ve bu sinyali kullanıcı cihazında depolanan bir jetona yerleştirir (daha fazla bilgi için sonraki bölümlere bakın).
- Kullanıcı kimliğini doğrulayanlar: Bu tüzel kişiler bir kullanıcıyla ilgili sinyal almamış olabilir ancak kullanıcı hakkında bilgi edinmesi (ör. kullanıcının bot olup olmadığını öğrenmesi) ve kullanıcının güvenilirliğini anlamak için sağlayıcıdan jeton kullanması gerekir.
Her PST etkileşimi, sağlayıcıların ve kullanıcıların web'de sinyal paylaşmak için birlikte çalışmasını gerektirir. Bu sinyaller, kullanıcıları tanımlayacak kadar ayrıntılı olmayan kaba değerlerdir.
Gizlilik jetonları benim için uygun mu?
Güven kararları alan ve bu bilgilerin farklı bağlamlarda kullanılmasını isteyen şirketler PST'lerden yararlanabilir. PST'lerin olası kullanım alanları hakkında daha fazla bilgi için PST kullanım alanları ile ilgili dokümanlarımıza göz atın.
Jeton kullanma ve kullanma
PST'nin uygulanması üç aşamada gerçekleşir:
- Jeton verme
- Jeton kullanma
- Kullanım kaydı yönlendirme
İlk aşamada, jetonlar bir tarayıcıya verilir (genellikle bir tür doğrulama işleminden sonra). İkinci aşamada, başka bir öğe, bu öğedeki değeri okumak için verilen jetonu kullanma isteği gönderir. Son aşamada, jetonu kullanan taraf, jetonda bulunan değeri içeren bir kullanım kaydı (RR) alır. Bu kullanıcı, bu kaydı çeşitli amaçlarla kullanıcının onay belgesi olarak kullanabilir.
Jeton stratejinizi tanımlama
Jeton stratejinizi tanımlamak için PST'nin temel kavramlarını (jetonlar ve kullanım kayıtları), değişkenlerini, davranışlarını ve sınırlamalarını anlamanız gerekir. Böylece, kullanım alanınızdaki potansiyel kullanımlarını düşünebilirsiniz.
Jetonlar ve kullanım kayıtları: Aralarındaki ilişki nedir?
Her cihaz, üst düzey web sitesi ve ihraççı başına en fazla 500 jeton saklayabilir. Ayrıca her jetonda, jetonu veren tarafın jetonu vermek için hangi anahtarı kullandığını bildiren meta veriler bulunur. Bu bilgiler, jeton kullanma işlemi sırasında jetonun kullanılıp kullanılmayacağına karar vermek için kullanılabilir. PST verileri, tarayıcı tarafından kullanıcının cihazında dahili olarak depolanır ve yalnızca PST API'si tarafından erişilebilir.
Bir jeton kullanıldığında, Kullanım Kaydı (RR) cihazda depolanır. Bu depolama alanı, gelecekteki kullanımlar için önbelleğe alınmış olarak kalır. Cihaz, sayfa ve ihraç eden başına 48 saatte iki jeton kullanma sınırı vardır. Yeni kullanım çağrıları, mümkün olduğunda yayıncıdan istek yerine önbelleğe alınmış RR'leri kullanır.
- Yeni jetonlar verilir (her sağlayıcı, site ve cihaz için en fazla 500).
- Tüm jetonlar cihaz üzerinde jeton deposunda (çerez deposuna benzer) saklanır.
- Etkin RR bulunamazsa yayından sonra yeni RR'ler oluşturulabilir (48 saatte en fazla 2).
- RR'ler, geçerlilik süreleri dolana kadar etkin olarak kabul edilir ve yerel önbellek olarak kullanılır.
- Yeni teklif kullanma çağrıları yerel önbelleğe ulaşır (yeni RR oluşturulmaz).
Kullanım alanınızı tanımladıktan sonra, RR'lerinizin kullanım süresini dikkatlice belirlemeniz gerekir. Bu, kullanım alanınızda bunları kaç kez kullanabileceğinizi belirler.
Stratejinizi belirlemeden önce aşağıdaki kritik davranışları ve değişkenleri anladığınızdan emin olun:
| Değişken / davranış | Açıklama | Olası kullanım |
|---|---|---|
| Jeton anahtarı meta verileri | Her jeton yalnızca bir şifreleme anahtarı kullanılarak oluşturulabilir ve PST'de her sağlayıcı için altı anahtar sınırlaması vardır. | Bu değişkeni kullanmanın bir yolu, jeometrik anahtarlarınıza göre jetonlarınız için bir güven aralığı tanımlamaktır (örneğin, 1. anahtar = yüksek güven, 6. anahtar = güven yok). |
| Jetonun son kullanma tarihi | Jetonun geçerlilik bitiş tarihi, anahtarın geçerlilik bitiş tarihiyle aynıdır. | Anahtarlar en az 60 günde bir döndürülebilir ve geçersiz anahtarlarla verilen tüm jetonlar da geçersiz kabul edilir. |
| Jeton kullanma oranı sınırı | Cihaz ve sağlayıcı başına 48 saatte iki jeton kullanma sınırı vardır. | Kullanım alanınız için her 48 saatte bir gereken tahmini kullanım sayısına bağlıdır. |
| Üst düzey kaynak başına maksimum yayıncı sayısı | Üst düzey kaynak başına maksimum sağlayıcı sayısı şu anda ikidir. | Her sayfanın sağlayıcılarını dikkatlice tanımlayın. |
| Bir cihazdaki sağlayıcı başına jeton | Belirli bir cihazda sağlayıcı başına maksimum jeton sayısı şu anda 500'dür. | Jeton sayısını, sağlayıcı başına 500'den az tuttuğunuzdan emin olun. Jeton yayınlamaya çalışırken web sayfanızdaki hataları giderdiğinizden emin olun. |
| Anahtar taahhütlerini döndürme | Her PST yayıncısının, 60 günde bir değiştirilebilecek anahtar taahhütleri içeren bir uç nokta göstermesi gerekir. Bu süreden daha hızlı bir rotasyon göz ardı edilir. | Anahtarlarınızın süresi 60 günden kısa bir süre içinde dolacaksa kesinti yaşanmaması için anahtar taahhütlerinizi bu tarihten önce güncellemeniz zorunludur (ayrıntılara bakın). |
| Kullanım kaydı kullanım ömrü | Son kullanma tarihi belirlemek için RR'nin ömrü tanımlanabilir. RR'ler, ihraççıya gereksiz yeni kullanım çağrıları gelmesini önlemek için önbelleğe alındığından, yeterli miktarda yeni kullanım sinyali alabilmeniz için bu önemlidir. | 48 saatte iki jetonluk bir kullanım oranı sınırı olduğundan, en az bu süre boyunca kullanım çağrılarını başarıyla yürütebilmek için RR'nizin kullanım süresini tanımlamanız önemlidir (RR kullanım süresi buna göre ayarlanmalıdır). Bu geçerlilik süresini haftalar düzeyinde ayarlamanız önerilir. |
Örnek senaryolar
1. senaryo: RR ömrü 24 saatten kısa (t=t) ve teklifin kullanılması 48 saatlik süre içinde birden fazla kez gerçekleştirilir.
2. senaryo: RR'nin geçerlilik süresi 24 saat ve teklifin kullanılması 48 saatlik süre içinde birden fazla kez gerçekleştirilir.
Senaryo 3: RR kullanım süresi 48 saat'tir ve teklifin kullanılması 48 saatlik süre içinde birden çok kez gerçekleştirilir.
Demoyu çalıştırma
PST'yi kullanmaya başlamadan önce demoyu ayarlamanızı öneririz. PST demosunu denemek için Chrome'u , demo veren anahtar taahhütlerini etkinleştirmek üzere işaretlerle çalıştırmanız gerekir (demo sayfasında bulunan talimatları uygulayın).
Bu demoyu çalıştırarak tarayıcınız, jetonları sağlamak ve kullanmak için demo veren ve kullanan sunucuları kullanır.
Göz önünde bulundurulması gereken teknik hususlar
Demoyu en iyi şekilde çalıştırmak için aşağıdaki adımları uygulayın:
- Chrome'u işaretlerle çalıştırmadan önce tüm Chrome örneklerini durdurduğunuzdan emin olun.
- Windows makine kullanıyorsanız Chrome yürütülebilir ikilisine parametre geçirme hakkındaki bu kılavuzu inceleyin.
- Demo sağlayıcı tarafından verilen/kullanılan jetonları görmek için demo uygulamasını kullanırken Uygulamalar > Depolama > Gizli Durum Jetonları bölümünde Chrome Geliştirici Araçları'nı açın.
Benimseme için ayarlama
Kart veren kuruluş olma
Düzenleyenler, PST'de önemli bir rol oynar. Kullanıcının bot olup olmadığını belirlemek için jetonlara değer atar. PST'yi veren kurum olarak kullanmak istiyorsanız veren kurum kayıt sürecini tamamlayarak kaydolmanız gerekir.
Kart veren olmak için başvuruda bulunmak isteyen kart veren web sitesinin operatörü, "Yeni PST Kart Vereni" şablonunu kullanarak GitHub deposunda yeni bir sorun açmalıdır. Sorunu doldurmak için depoda verilen talimatları uygulayın. Doğrulanan uç noktalar bu depoyla birleştirilir ve Chrome sunucu tarafı altyapısı bu anahtarları getirmeye başlar.
Düzenleyen sunucuları
PST'nin temel aktörleri, verenler ve kullananlar; temel araçları ise sunucular ve jetonlardır. Jetonlar ve GitHub dokümanları hakkında bazı ayrıntıları daha önce paylaşmıştık. Şimdi de PST sunucuları hakkında daha fazla bilgi vermek istiyoruz. PST'nin sağlayıcısı olarak ayarlanabilmek için öncelikle bir sağlayıcı sunucusu oluşturmanız gerekir.
Ortamınızı dağıtma: Issuer sunucuları
Jeton veren sunucuyu uygulamak için HTTP uç noktalarını gösteren kendi sunucu tarafı uygulamanızı oluşturmanız gerekir.
Yayınlayıcı bileşeni iki ana modülden oluşur: (1) yayınlayıcı sunucusu ve (2) jeton yayınlayıcısı.
Web'e açık tüm uygulamalarda olduğu gibi, sağlayıcı sunucunuza ek bir koruma katmanı eklemenizi öneririz.
Yayınlayan sunucusu: Örnek uygulamamızda, yayınlayan sunucumuz, yayınlayan HTTP uç noktalarını barındırmak için Express çerçevesini kullanan bir Node.js sunucusu. GitHub'daki örnek koda göz atabilirsiniz.
Jeton veren: Yayıncı şifreleme bileşeni için belirli bir dil gerekmez ancak bu bileşenin performans gereksinimleri nedeniyle, jetonları yönetmek için BoringSSL kitaplığını kullanan bir C uygulaması örneği sunuyoruz. Düzenleyen kodu örneğini ve kurulum hakkında daha fazla bilgiyi GitHub'da bulabilirsiniz.
Anahtarlar: Jeton yayınlayıcı bileşeni, jetonları şifrelemek için özel EC anahtarları kullanır. Bu anahtarlar korunmalı ve güvenli bir depolama alanında saklanmalıdır.
Sertifika veren sunucular için teknik koşullar
Protokole göre, sağlayıcı sunucunuzda en az iki HTTP uç noktası uygulamanız gerekir:
- Anahtar taahhüt (ör.
/.well-known/private-state-token/key-commitment): Bu uç noktada, şifreleme ortak anahtar ayrıntılarınız tarayıcılar tarafından sunucunuzun meşru olduğunu doğrulamak için kullanılabilir. - Jeton verme (örneğin,
/.well-known/private-state-token/issuance): Tüm jeton isteklerinin işlendiği jeton verme uç noktası. Bu uç nokta, jeton veren bileşeninin entegrasyon noktası olacaktır.
Daha önce de belirtildiği gibi, bu sunucunun olası yüksek trafiği işlemesi nedeniyle arka uç sunucunuzu değişken talebe göre ayarlayabilmek için ölçeklenebilir bir altyapı (ör. bulut ortamında) kullanarak dağıtmanızı öneririz.
Issuer sunucusuna çağrı gönderme
Yeni jetonlar yayınlamak için kart kuruluşu yığınınıza bir web sitesi getirme çağrısı uygulayın.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Redeemer sunucuları
Kendi sunucu tarafı uygulamanızı oluşturarak jeton kullanma hizmetini uygulamanız gerekir. Bu sayede, bir sağlayıcının gönderdiği jetonları okuyabilirsiniz. Aşağıdaki adımlarda, jetonların nasıl kullanılacağı ve bu jetonlarla ilişkili kullanım kayıtlarının nasıl okunacağı açıklanmaktadır.
Düzenleyeni ve kullananı aynı sunucuda (veya sunucu grubunda) çalıştırmayı seçebilirsiniz.
Kodu kullanan sunucular için teknik koşullar
Protokole göre, kod kullanacak kullanıcı sunucunuz için en az iki HTTP uç noktası uygulamanız gerekir:
/.well-known/private-state-token/redemption: Tüm jetonların kullanılacağı uç nokta. Bu uç nokta, jetonu etkinleştiren bileşenin entegre edileceği yerdir.
Kodu kullanan sunucuya çağrı gönderme
Daha önce verilen jetonları kullanmak için jetonu kullanan yığınınıza bir web sitesi getirme çağrısı uygulamanız gerekir.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Kod örneğine bakın.
Bir jetonu kullandıktan sonra başka bir getirme çağrısı yaparak kullanım kaydını (RR) gönderebilirsiniz:
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
Kod örneğine bakın.
Uygulamanızı dağıtma
Uygulamanızı test etmek için önce, yayınlama çağrısının yapıldığı web sayfasına gidin ve jetonların mantığınıza göre oluşturulduğunu onaylayın. Arka uçta, aramaların spesifikasyona uygun şekilde yapıldığını doğrulayın. Ardından, kod kullanma aramasının yapıldığı web sayfasına gidin ve mantığınıza göre RR'lerin oluşturulduğunu onaylayın.
Gerçek hayatta dağıtım
Belirli kullanım alanınızda yer alan web sitelerini hedeflemenizi öneririz:
- Aylık ziyaret sayısı az (< 1 milyon ziyaret/ay): API'yi önce küçük bir kitleye dağıtarak başlamanız gerekir.
- Sahipliğiniz ve kontrolünüz altındadır: Gerekirse karmaşık onaylar olmadan uygulamayı hızlıca devre dışı bırakabilirsiniz
- En fazla bir sağlayıcı: Testi basitleştirmek için jeton miktarını sınırlamak amacıyla.
- En fazla iki kullanıcının kullanabileceği kodlar: Sorun olması durumunda sorun giderme işlemini basitleştirmeniz gerekir.
İzin politikası
PST API'nin düzgün çalışması için üst düzey sayfanın ve API'yi kullanan tüm alt kaynakların erişimine açık olması gerekir.
Jeton isteği işlemi, private-state-token-issuance yönergesiyle kontrol edilir. token-redemption ve send-redemption-record işlemleri private-state-token-redemption direktifi tarafından kontrol edilir. Chrome 132 ve sonraki sürümlerde bu yönergelerin izin verilenler listesi varsayılan olarak * (tüm kaynaklar) olarak ayarlanır. Bu, özelliğin üst düzey sayfa, aynı kaynaklı iframe'ler ve açık yetkilendirme olmadan kaynaklar arası iframe'ler tarafından kullanılabileceği anlamına gelir.
Her sayfanın Permissions-Policy başlığına private-state-token-issuance=() ve private-state-token-redemption=() ekleyerek sitenizdeki belirli sayfalar için PST jetonu yayınlamayı veya kullanmayı devre dışı bırakabilirsiniz.
PST'ye üçüncü taraf erişimini kontrol etmek için Permissions-Policy üstbilgisini de kullanabilirsiniz. Başlık kaynağı listesi parametreleri olarak self ve API'ye erişmesine izin vermek istediğiniz tüm kaynakları kullanın. Örneğin, kendi kaynağınız ve https://example.com hariç tüm tarama bağlamlarında PST kullanımını tamamen devre dışı bırakmak için aşağıdaki HTTP yanıt üst bilgilerini ayarlayın:
Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")
API'yi tüm kaynaktan kaynakta kaynakları için etkinleştirmek üzere kaynak listesini * olarak ayarlayın.
Privacy Sandbox özelliklerini izin politikasıyla nasıl kontrol edeceğinizi öğrenin veya izin politikasını daha ayrıntılı bir şekilde inceleyin.
Sorun giderme
PST'leri Chrome Geliştirici Araçları'nın Ağ ve Uygulama sekmelerinden inceleyebilirsiniz.
Ağ sekmesinde:
Başvuru sekmesinde:
Bu Geliştirici Araçları entegrasyonu hakkında daha fazla bilgi edinin.
İstemcilerle ilgili en iyi uygulamalar
Web sitenizin kritik işlevleri belirli jeton sağlayıcılara bağlıysa bu sağlayıcılara öncelik verin. Diğer komut dosyalarını yüklemeden önce bu tercih edilen sağlayıcılar için hasPrivateToken(issuer)'ü arayın. Bu, olası kullanım hatalarını önlemek için çok önemlidir.
Üst düzey başına verici sayısı iki ile sınırlıdır. Üçüncü taraf komut dosyaları da kendi tercih ettikleri vericilere öncelik vermek için hasPrivateToken(issuer)'yi çağırmayı deneyebilir. Bu nedenle, sitenizin beklendiği gibi çalıştığından emin olmak için temel sağlayıcılarınızın güvenliğini önceden sağlayın.
// Prioritize your critical token issuer.
document.hasPrivateToken('https://critical-issuer.example')
.then(hasToken => {
if (hasToken) {
// Use the token or perform actions based on its availability.
} else {
// Handle the case where the token is not available.
}
});
// Load third-party scripts or secure another token issuer (up to two in total).
Sunucu en iyi uygulamaları ve sorun giderme
Kart veren ve kart kullanan sunucunuzun etkili bir şekilde çalışması için PST ile ilgili erişim, güvenlik, günlük kaydı veya trafik sorunlarına karşılaşmamak üzere aşağıdaki en iyi uygulamaları uygulamanızı öneririz.
- Bitiş noktalarınız, TLS 1.3 veya 1.2'yi kullanarak güçlü kriptografi uygulamalıdır.
- Altyapınız, değişken trafik hacimlerini (ani artışlar dahil) işlemeye hazır olmalıdır.
- Anahtarlarınızın, Erişim Denetimi Politikanız, Anahtar Yönetimi Stratejiniz ve İş Sürekliliği Planlarınızla uyumlu şekilde korunduğundan ve güvenli olduğundan emin olun.
- Üretime geçtikten sonra kullanım, darboğazlar ve performans sorunlarını anlamak için görünürlüğe sahip olmanız amacıyla yığınınıza gözlemlenebilirlik metrikleri ekleyin.
Daha fazla bilgi
- Geliştirici belgelerini inceleyin:
- PST ve özellikleri hakkında bilgi edinmek için genel bakış bölümünü okuyarak başlayın.
- PST tanıtım videosunu izleyin.
- PST demosunu deneyin.
- Ayrıca, API hakkında daha fazla bilgi edinmek için API açıklamasını da okuyun.
- API'nin mevcut spesifikasyonu hakkında daha fazla bilgi edinin.
- GitHub sorunları veya W3C toplantıları aracılığıyla sohbete katkıda bulunun.
- Terminolojiyi daha iyi anlamak için Özel Korumalı Alan terimleri sözlüğünü inceleyin.
- "Kaynak denemesi" veya "Chrome işaretleri" gibi Chrome kavramları hakkında daha fazla bilgi edinmek için goo.gle/cc adresindeki kısa videoları ve makaleleri inceleyin.