Üçüncü taraflar

Üçüncü taraf nedir?

Bir web sitesinin tamamen bağımsız olması çok nadirdir. HTTP Web Almanağı, çoğu web sitesinin (yaklaşık %95) bazı üçüncü taraf içerikleri barındırdığını gösteriyor.

Yıllık Bunlar, resimler ya da video, yazı tipi veya komut dosyası gibi başka medya olabilir. Resimler ve komut dosyaları, eklenen diğer her şeyden daha fazlasını ifade eder. Üçüncü taraf içerik bir site geliştirmek için gerekli değildir, ancak olabilir. Web yazı tipleri, videoların yerleşik iframe'leri, reklamlar veya JavaScript kitaplıkları gibi herkese açık bir sunucudan yüklenen bir öğeyi kullanıyor olmanız neredeyse kesindir. Örneğin, Google Fonts'tan sunulan web yazı tiplerini veya Google Analytics ile analizleri ölçüyor olabilirsiniz. Sosyal ağlardan Beğen düğmeleri veya Şununla Oturum Aç düğmeleri eklemiş olabilirsiniz; harita veya video yerleştiriyor ya da üçüncü taraf hizmetler aracılığıyla alışverişle ilgili satın alma işlemlerini gerçekleştiriyor olabilirsiniz. Ayrıca, üçüncü taraf izleme araçlarıyla kendi geliştirme ekipleriniz için günlük kaydı yapıyor ve hataları izliyor olabilirsiniz.

Gizlilik nedeniyle, biraz farklı ve daha genel bir tanımı göz önünde bulundurmak yararlıdır: Üçüncü taraf bir kaynak, özellikle de üçüncü taraf bir komut dosyası, paylaşılan ve herkese açık bir kaynaktan sunulur ve gösterildiği gibi yaygın olarak kullanılır ancak aynı zamanda site sahibinden başka biri tarafından da yazılır. Kullanıcılarınızın gizliliğini diğerlerinden nasıl koruyacağınızı değerlendirirken üçüncü taraf yazarlık yaklaşımı çok önemlidir. Böylece var olan riskleri değerlendirebilir ve ardından bu riskleri göz önünde bulundurarak üçüncü taraf bir kaynağı nasıl kullanacağınıza veya kullanıp kullanmayacağınıza karar verebilirsiniz. Daha önce konuştuğumuz gibi, bunlar bağlamı anlamanıza, dolayısıyla hangi ödünleri vermeniz gerektiğini ve bunların ne anlama geldiğini anlamanıza yardımcı olacaktır.

Genel olarak "üçüncü taraf kaynakları" ele alındığında bunun anlamı tam değildir: Birinci taraf ve üçüncü taraf arasındaki ayrım aslında bir öğenin kullanıldığı bağlamdır. Başka bir web sitesinden yüklenen bir komut dosyası üçüncü taraf bir kaynaktır ve komut dosyasını yükleyen HTTP isteği çerez içerebilir, ancak bu çerezler gerçekten "üçüncü taraf çerezleri" değildir; bunlar yalnızca çerezdir ve komut dosyasının sitenizdeki bir sayfada mı yoksa komut dosyası sahibinin sitesindeki bir sayfada mı yüklendiğine bağlıdır.

Neden üçüncü taraf kaynaklarını kullanıyoruz?

Üçüncü taraflar, sitenize işlevsellik eklemek için mükemmel bir yoldur. Bunlar, kullanıcılara sunulan özellikler veya hata izleme gibi görünmez geliştirici işlevleri olabilir. Ancak bunlar, geliştirme yükünüzü azaltır ve komut dosyalarının kendisi başka bir kişi, yani eklediğiniz hizmetin geliştirme ekibi tarafından korunur. Bunların hepsi, web'in bir araya getirilebilirliği sayesinde işe yarar: Parçaları bir araya getirip toplamlarından daha büyük bir bütün oluşturabilmek.

HTTP Arşivi Web Almanağı güzel bir açıklama verir:

Üçüncü taraflar; resimler, videolar, yazı tipleri, araçlar, kitaplıklar, widget'lar, izleyiciler, reklamlar ve web sayfalarımıza yerleştirmeyi düşündüğünüz her şeyden oluşan kesintisiz bir koleksiyon sağlar. Bu sayede, teknik bilgisi olmayan en kişiler bile web'de içerik oluşturup yayınlayabilir. Üçüncü taraflar olmasaydı, bugün birçoğumuzun hayatının ayrılmaz parçası olan zengin, sürükleyici ve karmaşık bir platform yerine web muhtemelen son derece sıkıcı, metin tabanlı ve akademik bir ortam olacaktır.

Üçüncü taraf kaynaklar neler yapabilir?

Bazı bilgilere erişme

Web sitenizde bir üçüncü taraf kaynağı kullandığınızda, olduğundan bağımsız olarak bu üçüncü tarafa bazı bilgiler aktarılır. Örneğin, başka bir siteden bir resim eklerseniz kullanıcının tarayıcısının yaptığı HTTP isteği, sayfanızın URL'sinin yanı sıra kullanıcının IP adresiyle birlikte bir Yönlendiren üst bilgisi iletir.

Siteler arası izleme

Aynı örnekten devam edelim. Resim üçüncü taraf sitesinden yüklendiğinde bir çerez içerebilir ve kullanıcı bu resmi daha sonra istediğinde bu çerez üçüncü tarafa geri gönderilir. Bu, üçüncü tarafın, hizmetinin sitenizde kullanılmakta olduğunu bilebileceği ve potansiyel olarak söz konusu kullanıcı için benzersiz kimliğe sahip bir çerez gönderebileceği anlamına gelir. Diğer bir deyişle, kullanıcı sitenizi veya bu üçüncü taraftan gelen bir kaynağı içeren başka bir siteyi bir sonraki ziyaretinde benzersiz kimlik çerezi tekrar gönderilir. Böylece üçüncü taraf, o kullanıcının ziyaret ettiği yerlerin bir günlüğünü oluşturabilir: siteniz, aynı üçüncü taraf kaynağı kullanan diğer siteler ve web genelinde.

Bu, siteler arası izlemedir: Bir üçüncü tarafın, birçok web sitesindeki kullanıcı etkinliklerinin günlüğünü, söz konusu web sitelerinin tümü aynı üçüncü taraftan gelen bir kaynağı kullandığı sürece toplamasına olanak tanır. Bu bir yazı tipi, resim veya stil sayfası olabilir. Tamamı statik kaynaklardır. Bu aynı zamanda dinamik bir kaynak da olabilir: Metin parçası, sosyal medya düğmesi, reklam. Dahil edilen komut dosyası dinamik olduğundan daha fazla bilgi toplayabilir: Kullanıcının tarayıcısını ve ortamını denetleyip verileri oluşturan kişiye geri iletebilir. Tüm komut dosyaları ve komut dosyası olarak sunulmayan dinamik kaynaklar (ör. sosyal medya yerleştirme, reklam veya paylaş düğmesi) bir dereceye kadar bunu yapabilir. Popüler web sitelerindeki bir çerez banner'ının ayrıntılarına bakarsanız, bir kullanıcının profilini oluşturmak üzere etkinliklerinin bir resmini oluşturmak için kullanıcılarınıza bir izleme çerezi ekleyebilecek kuruluşların bir listesini görebilirsiniz. Yüzlerce olabilir. Üçüncü taraf bir hizmeti ücretsiz olarak sunuyorsa bu verileri toplamaları ve ardından bu verilerden para kazanmaları, söz konusu tarafın ekonomik olarak uygun bir yolunun olmasıdır.

Bir tarayıcının kullanıcılarını koruması gereken gizlilik sorunu türleriyle ilgili yararlı bir kılavuz da Target Privacy Threat Model'tir (Hedef Gizlilik Tehdit Modeli). Bu, yazıldığı tarihte hâlâ tartışılmakta olan bir belge olmakla birlikte, mevcut gizlilik tehditlerinin bazı üst düzey sınıflandırmalarını içermektedir. Üçüncü taraf kaynaklarından kaynaklanan riskler arasında ağırlıklı olarak, bir web sitesinin aynı kullanıcıyı birden fazla sitede tanımlayabileceği "istenmeyen siteler arası tanıma" ve bir sitenin kullanıcının hassas olduğunu düşündüğü bilgileri toplayabileceği "hassas bilgilerin ifşa edilmesi" yer alır.

Bu önemli bir ayrımdır: İstenmeyen siteler arası tanıma, kullanıcının kimliği üzerindeki kontrolünü ortadan kaldırdığı için üçüncü taraf kendisinden ek hassas bilgi toplamasa bile kötüdür. Bir kullanıcının yönlendirenine, IP adresine ve çerezlere erişmek istenmeyen bir açıklamadır. Üçüncü taraf kaynaklarını kullanmak, bu kaynakları gizliliği korumaya yönelik bir şekilde nasıl kullanacağınıza ilişkin bir planlama bileşeniyle birlikte gelir. Bu işin bir kısmı site geliştiricisi olarak sizin görevinizde, bir kısmı da tarayıcı tarafından kullanıcı aracısı rolünde, yani kullanıcı adına çalışan temsilci, mümkün olduğunda hassas bilgilerin ifşa edilmesini ve istenmeyen siteler arası tanımayı önlemek için çalışır. Aşağıda, tarayıcı düzeyinde ve site geliştirme düzeyinde çözümleri ve yaklaşımları daha ayrıntılı bir şekilde ele alacağız.

Sunucu tarafı üçüncü taraf kodu

Önceki üçüncü taraf tanımımız, HTTP Almanağı'nın istemci taraflı yaklaşımını (raporlarına uygun şekilde) kasıtlı olarak değiştirerek üçüncü taraf yazarlık özelliğini de eklemiştir. Çünkü gizlilik açısından bakıldığında, üçüncü taraf, kullanıcılarınız hakkında siz olmayan herhangi bir şey bilen herkestir.

Buna, sunucuda kullandığınız hizmetleri sağlayan üçüncü taraflar ve istemci de dahildir. Gizlilik açısından bakıldığında, üçüncü taraf bir kitaplığın da (NPM, Composer veya NuGet'ten dahil edilen bir öğe gibi) anlaşılması önemlidir. Bağımlılıklarınız verileri sınırlarınızın dışına aktarıyor mu? Bir günlük kaydı hizmetine veya uzaktan barındırılan bir veritabanına veri iletiyorsanız yazarlarına "telefon home"u da eklediğiniz kitaplıklar varsa bu kitaplıklar kullanıcılarınızın gizliliğini ihlal edebilir ve dolayısıyla denetlenmelidir. Sunucu tabanlı bir üçüncü tarafa genellikle kullanıcı verilerinin sizin tarafınızdan verilmesi gerekir. Bu da, maruz kaldığı verilerin daha çok sizin kontrolünüz altında olduğu anlamına gelir. Buna karşın, istemci tabanlı bir üçüncü taraf (web sitenize eklenen ve kullanıcının tarayıcısı tarafından getirilen bir komut dosyası veya HTTP kaynağı) toplama işlemini sizin aracılığınızla yapmaksızın bazı verileri doğrudan kullanıcıdan toplayabilir. Uyumlulaştırmanın daha az mümkün olması nedeniyle, bu modülün büyük bir kısmında, dahil etmeyi seçtiğiniz istemci taraflı üçüncü tarafları nasıl tanımlayacağınız ve kullanıcılarınızı nasıl göstereceğinizle ilgilenecektir. Ancak, sunucu tarafı kodunuzu güven altına alarak bu koddan giden iletişimleri anlamanıza ve beklenmedik durumları günlüğe kaydedebilir ya da engelleyebilirsiniz. Bunun tam olarak nasıl yapılacağına ilişkin ayrıntılar buradaki kapsamımızın dışındadır (ve sunucu ayarlarınıza büyük ölçüde bağlıdır). Ancak bu, güvenlik ve gizlilik konusundaki yaklaşımınızın başka bir parçasıdır.

Üçüncü taraflar konusunda neden dikkatli olmanız gerekir?

Üçüncü taraf komut dosyaları ve özellikleri gerçekten önemlidir. Web geliştiricileri olarak hedefimiz bu tür şeyleri entegre etmektir, bunlardan uzaklaşmak değil! Ancak bazı potansiyel sorunlar var. Güven sınırınızın içine harici bir hizmet aldığınız için üçüncü taraf içeriği performans sorunları ve güvenlik sorunları da oluşturabilir. Ancak üçüncü taraf içerikler de gizlilik sorunları oluşturabilir.

Web'deki üçüncü taraf kaynaklarından bahsederken güvenlik sorunlarını (diğer unsurların yanı sıra) bir üçüncü tarafın şirketinizden veri çalabileceği durumlarla karşılaştırmak ve dahil ettiğiniz bir üçüncü tarafın (başka şeylerin de) iznini almadan kullanıcılarınızın verilerini çaldığı veya eriştiği gizlilik sorunları ile kıyaslayabilirsiniz.

Güvenlik sorununa örnek olarak "web kopyalayıcıların" kredi kartı bilgilerini çalması verilebilir. Bir kullanıcının kredi kartı bilgilerini girdiği sayfaya eklenen üçüncü taraf bir kaynak, bu kredi kartı bilgilerini çalabilir ve kötü amaçlı üçüncü tarafa gönderebilir. Bu kayma metinlerini oluşturanlar, bunları gizleyecekleri yerler bulma konusunda çok yaratıcıdır. Bir özet, gezinme komut dosyalarının site logoları, site simgeleri ve sosyal medya ağları için kullanılan resimler, jQuery, Modernizr ve Google Etiket Yöneticisi gibi popüler kitaplıklar, canlı sohbet pencereleri gibi site widget'ları ve CSS dosyaları gibi üçüncü taraf içeriklerde nasıl gizlendiğini açıklamaktadır.

Gizlilik sorunları biraz farklıdır. Bu üçüncü taraflar, teklifinizin bir parçasıdır; kullanıcılarınızın size olan güvenini korumak için kullanıcılarınızın onlara güvenebileceklerinden emin olmanız gerekir. Kullandığınız bir üçüncü taraf, kullanıcılarınız hakkında veri toplar ve ardından bu verileri kötüye kullanırsa veya silinmesini ya da keşfedilmesini zorlaştırırsa veya bir veri ihlaline maruz kalırsa ya da kullanıcılarınızın beklentilerini ihlal ederse kullanıcılarınız muhtemelen bu durumu yalnızca üçüncü tarafın değil, sizin hizmetinize olan güvenlerinin bir dökümü olarak algılar. Bu, itibarınız ve ilişkinizdir. Bu nedenle kendinize şu soruyu sormanız önemlidir: Sitenizde kullandığınız üçüncü taraflara güveniyor musunuz?

Üçüncü taraflara örnekler nelerdir?

Genel olarak "üçüncü tarafları" ele alıyoruz ancak aslında farklı türler vardır ve farklı miktarlarda kullanıcı verilerine erişimleri vardır. Örneğin, farklı bir sunucudan yüklenen <img> öğesini HTML'nize eklemek, söz konusu sunucuya kullanıcılarınız hakkında, <iframe> veya <script> öğesi eklemekten farklı bilgiler verir. Bunlar kapsamlı bir liste değil, örnektir. Ancak sitenizin kullanabileceği farklı üçüncü taraf öğesi türleri arasındaki farkları anlamak yararlıdır.

Siteler arası kaynak isteme

Siteler arası kaynak, sitenizdeki farklı bir siteden yüklenen ve <iframe> veya <script> olmayan her şeydir. Örnekler arasında <img>, <audio>, <video>, CSS tarafından yüklenen web yazı tipleri ve WebGL dokuları yer alır. Bunların tümü bir HTTP isteği aracılığıyla yüklenir ve daha önce açıklandığı gibi, bu HTTP istekleri daha önce diğer site tarafından ayarlanan çerezleri, istekte bulunan kullanıcının IP adresini ve yönlendiren olarak geçerli sayfanın URL'sini içerir. Tüm üçüncü taraf istekleri, geçmişte varsayılan olarak bu verileri içeriyordu. Bununla birlikte, ileride "Üçüncü Taraf Tarayıcı Korumalarını Anlama" bölümünde açıklandığı gibi, çeşitli tarayıcılar tarafından üçüncü taraflara aktarılan verileri azaltmaya veya izole etmeye yönelik çalışmalar yapılmaktadır.

Siteler arası iframe yerleştirme

<iframe> aracılığıyla sayfalarınıza yerleştirilmiş eksiksiz bir doküman, çerezler, IP adresi ve yönlendiren üçlüsünün yanı sıra tarayıcı API'lerine ek erişim izni isteyebilir. <iframe>d sayfaların tam olarak hangi API'leri kullanabileceğini ve erişim isteğinde bulunma şekilleri, tarayıcıya özgüdür ve şu anda değiştirilmektedir: Yerleştirilmiş dokümanlardaki API erişimini kısıtlama veya izlemeyle ilgili mevcut çalışmalar için aşağıdaki "İzin Politikası" bölümüne bakın.

Siteler arası JavaScript'i yürütme

Bir <script> öğesinin eklenmesi, siteler arası JavaScript'i sayfanızın üst düzey bağlamında yükler ve çalıştırır. Bu, çalışan komut dosyasının kendi birinci taraf komut dosyalarınızın yaptığı her şeye tam erişimi olduğu anlamına gelir. Tarayıcı izinleri bu verileri yönetmeye devam eder. Bu nedenle, kullanıcının konumunu istemek için (örneğin) yine de kullanıcı sözleşmesi gerekir. Ancak, sayfada bulunan veya JavaScript değişkenleri olarak mevcut olan tüm bilgiler bu tür bir komut dosyası tarafından okunabilir ve bu, yalnızca isteğin bir parçası olarak üçüncü tarafa iletilen çerezleri değil, aynı zamanda yalnızca siteniz için tasarlanan çerezleri de içerir. Aynı şekilde, sayfanıza yüklenen bir üçüncü taraf komut dosyası da kendi kodunuzun yaptığı tüm HTTP isteklerini yapabilir. Diğer bir deyişle, veri almak için arka uç API'lerinize fetch() isteği gönderebilir.

Bağımlılıklarınıza üçüncü taraf kitaplıkları dahil etme

Daha önce açıklandığı gibi, sunucu tarafı kodunuz büyük olasılıkla üçüncü taraf bağımlılıklarını da içerir ve bunların gücü, kendi kodunuzdan ayırt edilemez. Bir GitHub deposundan veya programlama dilinizin kitaplığından (npm, PyPI, besteci vb.) eklediğiniz kod, diğer kodunuzla aynı verilerin tamamını okuyabilir.

Üçüncü taraflarınızı tanıma

Bu da üçüncü taraf tedarikçiler listenizi ve bu tedarikçilerin gizlilik, veri toplama ve kullanıcı deneyimi duruşlarını ve politikalarını anlamanızı gerektirir. Bu anlayış, sonradan ödün verme serinizin bir parçası haline gelir: Hizmetin ne kadar faydalı ve önemli olduğu; kullanıcılarınızın taleplerinin ne kadar rahatsız edici, kullanışsız veya rahatsız edici olduğu ile dengelenir. Üçüncü taraf içerik, site sahibi olarak ağır işleri üstlenerek değer sağlar ve temel yetkinliklerinize odaklanmanızı sağlar. Bu nedenle, bu içerikten ödün vermek ve daha iyi bir kullanıcı deneyimi için kullanıcı konforu ve gizliliğinden ödün vermek önemlidir. Ancak kullanıcı deneyimini geliştirici deneyimiyle karıştırmamak önemlidir: "Geliştirici ekibimizin hizmeti oluşturması daha kolay", kullanıcılara cazip gelen bir hikaye değildir.

Bu anlayışı bir denetim sürecidir.

Üçüncü taraflarınızı denetleyin

Üçüncü tarafın ne yaptığını anlamak için denetim süreci gerekir. Bunu, teknik veya teknik olmayan olarak ve bağımsız bir üçüncü taraf ve koleksiyonunuzun tamamı için yapabilirsiniz.

Teknik olmayan bir denetim yürütme

İlk adım teknik değildir: Tedarikçilerinizin gizlilik politikalarını okuyun. Varsa üçüncü taraf kaynakları varsa gizlilik politikalarını kontrol edin. Uzun ve yasal metinlerle dolu olan bu belgelerde, önceki modüllerde özellikle uyarılan bazı yaklaşımlar (ör. aşırı genel ifadeler içerir ve toplanan verilerin nasıl veya ne zaman kaldırılacağına dair herhangi bir gösterge olmaksızın) kullanılabilir. Kullanıcı açısından bakıldığında, üçüncü taraflar tarafları da dahil olmak üzere sitenizde toplanan tüm verilerin bu gizlilik politikalarına tabi olacağını unutmamak önemlidir. Her şeyi doğru yapsanız bile hedefleriniz konusunda şeffaf olduğunuzda ve kullanıcılarınızın veri gizliliği ve hassasiyeti beklentilerini aştığınızda, kullanıcılar sizi seçtiğiniz üçüncü tarafların yaptığı her şeyden sorumlu tutabilir. Gizlilik politikalarında, kullanıcıların güvenini azaltacağı için kendi politikalarınızda söylemek istemediğiniz bir şey varsa alternatif bir tedarikçi olup olmadığını düşünün.

Bu konu, daha sonra tartışılacak olan teknik denetimle birlikte kullanılabilir ve iki ekip de birbirlerine bilgi verir. Bir iş ilişkisi olacağından, işle ilgili eklediğiniz üçüncü taraf kaynaklarını (ör. reklam ağları veya yerleştirilmiş içerik) bilmeniz gerekir. Burası, teknik olmayan bir denetim başlatmak için iyi bir yerdir. Teknik denetimin, özellikle ticari nedenlerle değil de teknik nedenlerle dahil edilen üçüncü tarafları (harici bileşenler, analizler, yardımcı program kitaplıkları) tespit etmesi de olasıdır ve bu liste, işletme odaklı üçüncü tarafların listesiyle birleştirilebilir. Buradaki amaç, site sahibi olarak sizin, sitenize eklediğiniz üçüncü tarafların ne yaptığını anladığınızı hissetmesi ve bir işletme olarak, gerekli tüm yükümlülükleri karşıladığınızdan emin olmak için hukuk danışmanınıza üçüncü taraflardan oluşan bu envanteri sunabilmenizdir.

Teknik denetim yapma

Teknik denetim için kaynakları web sitesinin bir parçası olarak yerinde kullanmak önemlidir. Yani bir test bandına bağımlılık yükleyip bu şekilde denetlemeyin. Bağımlılıklarınızın test veya geliştirme modu yerine herkese açık internette dağıtılan gerçek web sitenizin bir parçası olarak nasıl davrandığını gördüğünüzden emin olun. Kendi web sitenizi yeni bir kullanıcı olarak görüntülemek yol gösterici bilgiler verir. Oturum açmadan ve kayıtlı sözleşmeniz olmaması için tarayıcıyı temiz ve yeni bir profilde açın ve sitenizi ziyaret etmeyi deneyin.

Kullanıcı hesapları sağlıyorsanız kendi sitenizde yeni bir hesap için kaydolun. Tasarım ekibiniz bu yeni kullanıcı edinme sürecini kullanıcı deneyimi açısından düzenlemiş olsa da bu sürece gizlilik açısından yaklaşmak açıklayıcı olabilir. Şartlar ve koşullar, çerez uyarısı veya gizlilik politikası üzerinde "Kabul et"i tıklamakla kalmayın. Kendinize, kişisel bilgilerinizi açıklamadan veya izleme çerezi kullanmadan kendi hizmetinizi kullanma görevi atayın ve bunu yapıp yapamayacağınızı ve bunu yapmanın ne kadar zor olduğunu görün. Ayrıca, hangi sitelere erişildiğini ve bu sitelere hangi verilerin aktarıldığını görmek için tarayıcı geliştirici araçlarına göz atmak da yararlı olabilir. Geliştirici araçları, ayrı HTTP isteklerinin bir listesini sağlar (genellikle "Ağ" adlı bir bölümde). Buradan, istekleri türe (HTML, CSS, resimler, yazı tipleri, JavaScript, JavaScript tarafından başlatılan istekler) göre gruplanmış olarak görebilirsiniz. Ayrıca, her talebin alanını göstermek için yeni bir sütun eklenebilir. Bu sütun, kaç farklı yerle iletişim kurulduğunu gösterir ve yalnızca üçüncü tarafları gösteren bir "üçüncü taraf talepleri" onay kutusu bulunabilir. (Daha fazla bilgi edinmek için sürekli denetim gerçekleştirmek üzere Content-Security-Policy raporlamasını kullanmak da yararlı olabilir.)

Simon Hearne'nin "Request Map Üretici" aracı da herkese açık bir sayfanın yaptığı tüm alt isteklere dair yararlı bir genel bakış olabilir.

Bu noktada, teknik olmayan denetimin bir parçası olarak tanımlanan işletme odaklı üçüncü tarafları da (yani kaynaklarını kullanmak için finansal ilişkinizin olduğu şirketlerin listesi) dahil edebilirsiniz. Buradaki amaç, kullandığınızı düşündüğünüz üçüncü tarafların listesini (mali ve yasal kayıtlardan) ve gerçekten kullanmakta olduğunuz listeyi (web sitenizin yaptığı üçüncü taraf HTTP isteklerine bakarak) eşleştirmektir. Her bir üçüncü taraf için hangi teknik giden isteklerin gönderildiğini İş ilişkisine göre tanımlanan bir üçüncü tarafın teknik denetimde isteklerini belirleyemiyorsanız bunun nedenini anlamak ve testlerinizde bu yönlendirmenin size yol göstermesi önemlidir: Belki de üçüncü taraf kaynağı yalnızca belirli bir ülkede, belirli bir cihaz türünde veya giriş yapmış kullanıcılar için yüklenmiştir. Bu işlem, denetlenmesi için site alanları listenizi genişletir ve tüm giden erişimleri gördüğünüzden emin olun. (Ya da belki, ödemesini yaptığınız ve kullanmadığınız bir üçüncü taraf kaynağını tespit edebilir ve bu da finans departmanını her zaman memnun eder.)

Denetime dahil olmasını istediğiniz üçüncü taraflara yönelik taleplerin listesini daralttıktan sonra, her bir talebi tıkladığınızda söz konusu talebin tüm ayrıntıları ve özellikle de söz konusu talebe hangi verilerin aktarıldığı gösterilir. Kodunuzun başlattığı bir üçüncü taraf isteğinin ardından başka birçok üçüncü taraf isteğini başlatması da çok yaygın bir durumdur. Bu ilave üçüncü taraflar da kendi gizlilik politikanıza "aktarılır". Bu görev zahmetli ama değerlidir ve genellikle mevcut analizlere eklenebilir. Ön uç geliştirme ekibiniz zaten performansla ilgili nedenlerle (WebPageTest veya Lighthouse gibi mevcut araçların yardımıyla) istekleri denetliyor olmalı ve bu sürece veri ve gizlilik denetimi dahil etmek işi kolaylaştırabilir.

Yapılması gerekenler

Oturum açmamanız ve kayıtlı sözleşmeniz olmaması için temiz ve yeni bir kullanıcı profiline sahip tarayıcı açın; ardından giden tüm istekleri görmek için tarayıcı geliştirme araçları Ağ panelini açın. Her isteğin alan adını göstermek için yeni bir sütun ekleyin ve varsa yalnızca üçüncü tarafları göstermek için "üçüncü taraf istekleri" onay kutusunu işaretleyin. Ardından:

• Sitenizi ziyaret edin.
• Kullanıcı hesapları sağlıyorsanız yeni bir hesaba kaydolun.
• Oluşturduğunuz hesabı silmeyi deneyin.
• Sitede normal bir veya iki işlem yapın (tam olarak bunun ne olacağı sitenizin ne yaptığına bağlıdır, ancak çoğu kullanıcının gerçekleştirdiği ortak işlemleri seçin).
• Özellikle üçüncü taraf bağımlılıkları içerdiğini bildiğiniz bir veya iki işlem gerçekleştirin. Bu işlemler arasında sosyal medyada içerik paylaşma, ödeme akışı başlatma veya başka bir siteden içerik yerleştirme yer alabilir.

Bu görevlerin her birini yaparken, açıklandığı gibi Ağ paneline bakarak size ait olmayan alanlardan istenen kaynakların kaydını tutun. Bunlar, üçüncü taraflarınızdan bazılarıdır. Bunu yapmanın iyi bir yolu, ağ isteği günlüklerini bir HAR dosyasında yakalamak için tarayıcı ağ araçlarını kullanmaktır.

HAR dosyaları ve yakalama

HAR dosyası, bir sayfa tarafından yapılan tüm ağ isteklerinin standartlaştırılmış bir JSON biçimidir. Belirli bir sayfayla ilgili HAR dosyasını almak için:

Chrome

Tarayıcı Geliştirici Araçları'nı açın (Menü > Diğer Araçlar > Geliştirici Araçları), Ağ paneline gidin, sayfayı yükleyin (veya yenileyin) ve sağ üstteki Kısıtlama yok açılır menüsünün yanında aşağı ok kaydetme simgesini seçin.

Firefox

Tarayıcı geliştirici araçlarını (Menü > Diğer Araçlar > Web Geliştirici Araçları) açın, Ağ paneline gidin, sayfayı yükleyin (veya yenileyin) ve sağ üstteki kısıtlama açılır menüsünün yanında bulunan dişli simgesini seçin. Menüden Tümünü HAR Olarak Kaydet'i** seçin.

Safari

Tarayıcı geliştirici araçlarını açın (Menü > Geliştirme > Web Denetleyicisini Göster). Geliştirme menüsü yoksa menü çubuğunda Menü > Safari > Tercihler > Gelişmiş > Geliştirme menüsünü göster'den bu özelliği etkinleştirin, Ağ paneline gidin, sayfayı yükleyin (veya yenileyin) ve sağ üst kısımdan (Günlüğü Koru'nun sağında) Dışa Aktar'ı seçin (pencereyi büyütmeniz gerekebilir).

Daha fazla ayrıntı için, üçüncü taraflara nelerin aktarıldığını da kaydedebilirsiniz (İstek bölümünde), ancak bu veriler genellikle karartılmıştır ve kullanışlı bir şekilde yorumlanamaz.

Üçüncü tarafları entegre etmeye yönelik en iyi uygulamalar

Sitenizin hangi üçüncü tarafları kullandığı konusunda kendi politikalarınızı belirleyebilirsiniz: kendi uygulamalarına göre hangi reklam sağlayıcısını kullanacağınızı, çerez izin pop-up'ının ne kadar rahatsız edici veya rahatsız edici olduğunu ya da tweet'lerinizdeki Google Analytics'te izlemek için sitenizdeki sosyal medya düğmelerini veya e-postalarınızdaki izleme bağlantılarını ya da utm_campaign bağlantılarını kullanmak isteyip istemediğinizi belirleyebilirsiniz. Site geliştirirken dikkat edilmesi gereken bir nokta da analiz hizmetinizin gizliliği ve güvenliğidir. Bazı analiz hizmetleri, gizliliği korumayı açıkça kullanır. Çoğunlukla, kendi başına gizlilik koruması sağlayan üçüncü taraf komut dosyalarını kullanmanın da yolları vardır: Kullanıcıların gizliliğini iyileştirmek ve kullanıcıları üçüncü taraf veri toplamalarına karşı korumak isteyen ilk ekip siz değilsiniz ve halihazırda bu sorunun çözümleri vardır. Son olarak, birçok üçüncü taraf sağlayıcı veri toplama sorunlarına karşı geçmişe kıyasla daha hassastır ve çoğu zaman, kullanıcıları daha iyi koruyan bir modu etkinleştiren özellik veya parametreler ekleyebilirsiniz. Aşağıda birkaç örnek verilmiştir.

Sosyal medya paylaşım düğmesi eklerken

HTML düğmelerini doğrudan yerleştirmeyi düşünün: https://sharingbuttons.io/ sitesinde bazı iyi tasarlanmış örnekler vardır. Veya düz HTML bağlantıları ekleyebilirsiniz. Bunun karşılığında, "paylaşım sayısı" istatistiğini ve Facebook analizlerinde müşterilerinizi sınıflandırma yeteneğinizi kaybedersiniz. Bu, üçüncü taraf bir sağlayıcı kullanmak ile daha az analiz verisi elde etmek arasında bir denge örneğidir.

Daha genel olarak, üçüncü taraftan herhangi bir tür etkileşimli widget yerleştirirken, genellikle bunun yerine söz konusu üçüncü tarafa bağlantı vermeniz mümkündür. Bu durum, sitenizde satır içi deneyimin bulunmadığı anlamına gelir. Ancak üçüncü tarafla veri paylaşma kararı, sitenizin tercih ettiği şekilde etkileşime girip girmemeyi seçebilecek, üçüncü tarafla paylaşma kararını veren kullanıcıya geçer.

Örneğin, hizmetinizi sitem.example.com'da paylaşmak için Twitter ve Facebook için aşağıdaki gibi bağlantılar ekleyebilirsiniz:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Facebook'un paylaşılacak bir URL'nin belirtilmesine izin verdiğini, Twitter'ın ise bir URL ve bazı metinler belirtmeye izin verdiğini unutmayın.

Video yerleştirirken

Video barındırma sitelerindeki videoları yerleştirirken yerleştirme kodunda gizliliği korumaya yönelik seçenekler olup olmadığına bakın. Örneğin, YouTube söz konusu olduğunda, yerleştirme sayfasını görüntüleyen kullanıcılara çerez yerleştirilmesini önlemek için yerleştirme URL'sindeki youtube.com değerini www.youtube-nocookie.com ile değiştirin. Ayrıca, YouTube'un kendisinden Paylaş/Yerleştir bağlantısını oluştururken "Gizliliği geliştirilmiş modu etkinleştir"i de işaretleyebilirsiniz. Bu, üçüncü tarafın sağladığı daha kullanıcıyı koruyan bir modun kullanımına iyi bir örnektir. (https://support.google.com/youtube/answer/171780 adresinde bu konu ve özellikle YouTube için diğer yerleştirme seçenekleri daha ayrıntılı olarak açıklanmıştır.)

Diğer video sitelerinin bu konuda daha az seçeneği var: Örneğin TikTok'un bu yazı yazıldığında videoları izlemeden yerleştirme yöntemi bulunmuyor. Videoları kendiniz de barındırabilirsiniz (bu alternatif bir yöntem kullanılmaktadır) ancak özellikle birçok cihazı desteklemek, çok daha fazla iş gerektirebilir.

Daha önce bahsettiğimiz etkileşimli widget'larda olduğu gibi, yerleştirilmiş bir videoyu videonun bağlantısı veren web sitesinin bağlantısıyla değiştirmek çoğu zaman mümkündür. Video satır içinde oynatılmasa da kullanıcıyla izleme seçeneği sunulduğu için daha az etkileşimlidir. Bu, etkileşimli içeriği kullanıcının tetiklemesi gereken bir şeyle dinamik olarak değiştirmek için kullanılan "yüzme kalıbı" örneği olarak kullanılabilir. Yerleştirilmiş TikTok videosu, düz bir şekilde TikTok video sayfasına yönlendiren bir bağlantıyla değiştirilebilir. Ancak biraz daha fazla çabayla videonun küçük resmini alıp görüntülemek ve bağlantı oluşturmak da mümkündür. Seçilen video sağlayıcı, videoları izlemeden yerleştirmenin kolay bir yolunu desteklemese bile oEmbed API'sini destekler. Bu API, bir video veya yerleştirilmiş içeriğin bağlantısı verildiğinde küçük resim ve başlık gibi programatik ayrıntıları döndürür. TikTok oEmbed'i destekler (ayrıntılar için https://developers.tiktok.com/doc/embed-videos adresine bakın). Diğer bir deyişle, (manuel veya programlı olarak) TikTok videosunun bağlantısını https://www.tiktok.com/@scout2015/video/6718335390845095173 https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 ile bu video hakkındaki JSON meta verilerine dönüştürebilir, böylece gösterilecek küçük resim alabilirsiniz. WordPress, örneğin, yerleştirilmiş içerikle ilgili oEmbed' bilgilerini istemek için genellikle bunu kullanır. Etkileşimli görünen bir "cephe" göstermek ve kullanıcı tıklamayı seçtiğinde etkileşimli bir videoya yerleştirmek veya bağlantı vermek için bunu programatik olarak kullanabilirsiniz.

Analiz komut dosyalarını yerleştirirken

Analytics, kullanıcılarınızla ilgili bilgilerin analiz edilebilmesi için toplamak üzere tasarlanmıştır. İşte amacı budur. Analytics sistemleri temel olarak erişimler ve kullanıcılar hakkında veri toplamayı ve göstermeyi sağlayan hizmetlerdir. Bu işlemler, uygulama kolaylığı açısından Google Analytics gibi üçüncü taraf bir sunucuda gerçekleştirilir. Ayrıca https://matomo.org/ gibi kendi bünyesinde barındırılan analiz sistemleri de vardır. Ancak bu, bunun için üçüncü taraf bir çözüm kullanmaktan daha fazla iş yükü anlamına gelir. Ancak böyle bir sistemi kendi altyapınızda çalıştırmak, kendi ekosisteminizi terk etmediği için veri toplamayı azaltmanıza yardımcı olur. Diğer yandan, bu verileri yönetmek, kaldırmak ve politikalar belirlemek sizin sorumluluğunuzdadır. Siteler arası izlemeyle ilgili endişelerin büyük bir kısmı, bu işlemlerin habersiz ve gizlice yapıldığında veya hiç veri toplama içermeyen bir hizmeti kullanmanın yan etkisi olarak ortaya çıkar. Analytics yazılımları, site sahiplerini kullanıcıları hakkında bilgilendirmek amacıyla veri toplayacak şekilde yoğun bir şekilde tasarlanmıştır.

Tarih boyunca, dev bir balık ağı gibi her şey hakkında bulabildiğiniz tüm verileri toplayıp daha sonra ilginç kalıplar için analiz etmeyi içeren bir yaklaşım vardı. Veri toplama konusunda büyük ölçüde, bu kursun 1. bölümünde ele alınan huzursuzluk ve huzursuzluk duygusu bu zihniyetle yaratılmıştır. Artık birçok site önce hangi soruların sorulacağını belirler, ardından bu soruları yanıtlamak için belirli ve sınırlı veriler toplar.

Siteniz ve diğer siteler tarafından bir üçüncü taraf hizmeti kullanılıyorsa ve söz konusu üçüncü taraf hizmeti, sitenize ilgili JavaScript'i dahil ederek çalışıyorsa ve bu hizmetler her bir kullanıcı için çerez ayarlarsa, bu üçüncü taraf hizmetlerin istenmeyen siteler arası tanıma işlemi gerçekleştiriyor, diğer bir deyişle kullanıcılarınızı sitelerde takip ediyor olabileceğini göz önünde bulundurmak önemlidir. Kimisi olmayabilir, kimileri de olmayabilir. Ancak burada gizliliği korumaya yönelik yaklaşımı, böyle bir üçüncü taraf hizmetinin, aksini düşünmek veya bilmek için geçerli bir nedeniniz olmadığı sürece aslında siteler arası izleme yaptığını varsaymaktır. Bu, tek başına bu tür hizmetlerden kaçınmanın bir nedeni değildir ancak bu tür hizmetlerden yararlanmanın avantajlarını değerlendirirken dikkate almanız gereken bir noktadır.

Eskiden analizlerde dengeyi sadece bu verinin kullanılıp kullanılmayacağına karar vermek gerekiyordu: Tüm verileri toplamak ve bilgi ve planlama karşılığında gizlilikten ödün vermek veya bilgiden tamamen vazgeçmekti. Ancak durum artık böyle değil ve artık bu iki uç nokta arasında bulmak için bir orta yol var. Toplanan verileri sınırlamak ve depolama alanı miktarını ve süresini azaltmak için yapılandırma seçenekleri için analiz sağlayıcınıza danışın. Daha önce açıklanan teknik denetim kayıtları elinizde olduğundan, bu yapılandırmaları değiştirmenin toplanan veri miktarını önemli ölçüde azalttığını doğrulamak için ilgili denetimin ilgili bölümlerini tekrar çalıştırabilirsiniz. Bu geçişi mevcut bir sitede yapıyorsanız bu, size kullanıcılarınız için yazılabilecek ölçülebilir bir ölçüm sağlayabilir. Örneğin, Google Analytics'te bir dizi etkinleştirme (ve dolayısıyla varsayılan olarak devre dışı) gizlilik özellikleri vardır. Bunların çoğu, yerel veri koruma yasalarına uymanıza yardımcı olabilir. Google Analytics'i kurarken göz önünde bulundurulması gereken bazı seçenekler arasında, toplanan veriler için saklama süresini (Yönetici > İzleme Bilgileri > Veri Saklama) 26 aylık varsayılan değerden daha düşük olarak ayarlamak ve kısmi IP anonimleştirme gibi daha teknik çözümlerden bazılarını etkinleştirmek yer alır (daha ayrıntılı bilgi için bkz. https://support.google.com/analytics/answer/9019185).

Üçüncü tarafları gizliliği koruyan bir şekilde kullanma

Şimdiye kadar uygulamanızın tasarım aşamasında kullanıcılarınızı üçüncü taraflardan nasıl koruyacağınızı ele alırken, siz de söz konusu uygulamanın ne yapacağını planlarken ele aldık. Belirli bir üçüncü tarafı kullanmamaya karar vermek bu planlamanın bir parçasıdır ve kullanımlarınızın denetlenmesi de bu kategoriye girer: Gizlilik tutumunuzla ilgili kararlar almaktır. Ancak bu kararlar, doğası gereği çok ayrıntılı değildir. Belirli bir üçüncü tarafı kullanmayı ya da kullanmamayı seçmek ayrıntılı bir karar değildir. Belirli bir üçüncü taraf teklifine ihtiyaç duymayı veya kullanmayı planlamayı ancak gizliliği ihlal eden tüm eğilimleri (kasıtlı veya kazara) azaltmayı isteme olasılığınız çok daha yüksektir. Bu, kullanıcıları "derleme zamanında" koruma görevidir. Yani, beklemediğiniz zararları azaltmak için önlemler eklemektir. Bunların tümü, sayfa sunarken sağlayabileceğiniz ve kullanıcı aracısına belirli gizlilik veya güvenlik önlemlerini alması için ipucu veya komut veren yeni HTTP üst bilgileridir.

Yönlendiren Politikası

Yapılması gerekenler

Kendilerine bağlantı verdiğinizde veya bir sayfa tarafından alt kaynak olarak yüklendiklerinde diğer sitelerin Yönlendiren başlığı almasını önlemek için strict-origin-when-cross-origin veya noreferrer politikası ayarlayın:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Veya sunucu tarafında, örneğin Express'te:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Gerekirse belirli öğeler veya istekler için bir laxer politikası belirleyin.

Bu önlemin kullanıcı gizliliğini koruma nedeni

Varsayılan olarak tarayıcının yaptığı her HTTP isteği, isteği başlatan sayfanın URL'sini (bağlantı, yerleştirilmiş resim veya komut dosyası) içeren bir Referer üst bilgisi üzerinden iletilir. URL'ler özel bilgiler içerebileceği ve bu URL'ler, üçüncü taraflara ait olan URL'ler söz konusu gizli bilgileri kendilerine aktarabileceği için bu bir gizlilik sorunu olabilir. Web.dev, gizli veriler içeren URL'lerle ilgili bazı örnekler listeler. Bir kullanıcının sitenize https://social.example.com/user/me@example.com adresinden geldiğini bilerek kullanıcının kim olduğunu bilirseniz bu, kesin bir sızıntıdır. Ancak özel bilgileri göstermeyen bir URL bile söz konusu kullanıcının (giriş yapmışsa tanıyor olabileceğiniz kullanıcı) başka bir siteden buraya geldiğini ve dolayısıyla bu kullanıcının başka bir siteyi ziyaret ettiğini ortaya koymaktadır. Bu, kendi başına kullanıcılarınızın tarama geçmişi hakkında bilmemeniz gereken bilgilerin açığa çıkmasıdır.

Bir Referrer-Policy üstbilgisi (doğru yazımla) sağlamak, yönlendiren URL'nin bir kısmının veya hiçbirinin aktarılmaması için bunu değiştirmenize olanak tanır. MDN tüm ayrıntıları listeler ancak çoğu tarayıcı varsayılan olarak strict-origin-when-cross-origin varsayılan değerini benimsemiştir. Bu da yönlendiren URL'nin artık üçüncü taraflara kaynak olarak yalnızca kaynak olarak aktarıldığı anlamına gelir (https://web.dev/learn/privacy yerine https://web.dev). Bu, herhangi bir şey yapmanız gerekmeden yararlı bir gizlilik korumasıdır. Ancak, yönlendiren bilgilerinin üçüncü taraflara iletilmesini önlemek için Referrer-Policy: same-origin değerini (veya kendi kaynağınız dahil olmak üzere hiç kimseye iletmemek için Referrer-Policy: no-referrer) belirterek bu süreci daha da sıkılaştırabilirsiniz. (Bu, gizlilik ile yardımcı program arasındaki dengenin iyi bir örneğidir. Yeni varsayılan, gizliliği korumaya yönelik eskiye göre çok daha fazladır, ancak analiz sağlayıcınız gibi tercih ettiğiniz üçüncü taraflara yüksek düzey bilgiler sağlar.)

Bu üst bilginin açık bir şekilde belirtilmesi de yararlı olur. Çünkü böylece, tarayıcının varsayılan ayarlarına bağlı kalmak yerine politikanın tam olarak ne olduğunu bilirsiniz. Üstbilgileri ayarlayamıyorsanız <head>: <meta name="referrer" content="same-origin"> içindeki bir meta öğeyi kullanarak HTML sayfasının tamamı için bir yönlendiren politikası belirleyebilirsiniz. Ayrıca, belirli üçüncü taraflar hakkında endişeleriniz varsa <script>, <a> veya <iframe> gibi bağımsız öğeler için bir referrerpolicy özelliği de ayarlayabilirsiniz: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

İçerik-Güvenliği-Politikası

Genellikle "CSP" olarak adlandırılan Content-Security-Policy üst bilgisi, harici kaynakların nereden yüklenebileceğini belirtir. Temel olarak güvenlik amacıyla, siteler arası komut dosyası saldırılarını ve komut dosyası yerleştirmeyi önleyerek kullanılır. Ancak normal denetimlerinizle birlikte kullanıldığında seçtiğiniz üçüncü tarafların verileri iletebileceği yerleri de sınırlayabilir.

Bu, potansiyel olarak mükemmel olmayan bir kullanıcı deneyimidir. Üçüncü taraf komut dosyalarınızdan biri, listenizde olmayan bir kaynaktan gelen bağımlılıkları yüklemeye başlarsa, bu istek engellenir, komut dosyası başarısız olur ve uygulamanız başarısız olabilir (veya en azından JavaScript hatası veren yedek sürümüne düşürülebilir). Bu, güvenlik amacıyla CSP uygulandığında kullanışlıdır. Bu uygulamanın normal amacı, siteler arası komut dosyası çalıştırma sorunlarına karşı koruma sağlamaktır (bunun için katı bir CSP kullanın). Sayfanızın kullandığı tüm satır içi komut dosyalarını öğrendikten sonra bunların bir listesini hazırlayabilir, bunların her biri için bir karma değeri hesaplayabilir veya rastgele bir değer ("tek seferlik sayı" olarak adlandırılır) ve ardından karmaların listesini İçerik Güvenliği Politikanıza ekleyebilirsiniz. Bu, listede olmayan komut dosyalarının yüklenmesini engeller. Bunun, site için üretim sürecine dahil edilmesi gerekir: Sayfalarınızdaki komut dosyalarının tek seferlik rastgele sayı içermesi veya derlemenin bir parçası olarak bir karmaya sahip olması gerekir. Tüm ayrıntılar için strict-csp ile ilgili makaleye bakın.

Neyse ki tarayıcılar, ilgili Content-Security-Policy-Report-Only başlığını destekler. Bu başlık sağlanırsa sağlanan politikayı ihlal eden istekler engellenmez ancak sağlanan URL'ye bir JSON raporu gönderilir. Böyle bir başlık şu şekilde görünebilir: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ ve tarayıcı 3p.example.com dışında bir yerden komut dosyası yüklerse bu istek başarılı olur ancak sağlanan report-uri öğesine bir rapor gönderilir. Normalde bu yöntem, bir politikayı uygulamadan önce deney yapmak için kullanılır ancak burada yararlı bir yaklaşım, bunu "sürekli denetim" yürütme yöntemi olarak kullanmaktır. Daha önce açıklanan düzenli denetlemenizin yanı sıra, beklenmedik alanların görünüp görünmediğini görmek için CSP raporlamasını etkinleştirebilirsiniz. Bu durum, üçüncü taraf kaynaklarınızın kendilerine ait üçüncü taraf kaynaklarını yüklediği ve dikkate almanız ve değerlendirmeniz gereken anlamına gelebilir. (Bu durum, bazı siteler arası komut dosyası açıklarından yararlanmanın güvenlik sınırınızı aştığına işaret edebilir. Elbette bunu bilmeniz de önemlidir.)

Content-Security-Policy, kullanımı kolay ve karmaşık bir API'dir. Bu durum biliniyor. Aynı hedefleri karşılayacak ancak kullanımı çok karmaşık olmayan "yeni nesil" CSP'yi oluşturmak için çalışmalar devam ediyor. Bu henüz hazır değil, ancak bunun nereye doğru ilerlediğini görmek (veya sürece dahil olmak ve tasarımına yardımcı olmak) istiyorsanız ayrıntılar için https://github.com/WICG/csp-next adresine göz atın.

Yapılması gerekenler

Sunulan sayfalara şu HTTP üstbilgisini ekleyin: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. JSON bu URL'de yayınlandığında dosyayı depolayın. Web sitenizin başka kullanıcılar tarafından ziyaret edildiğinde istediği üçüncü taraf alanlarının bir koleksiyonunu edinmek için depolanan verileri inceleyin. Listenin ne zaman değişeceğini görmek için Content-Security-Policy-Report-Only üst bilgisini beklediğiniz alanları listeleyecek şekilde güncelleyin:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Neden

Bu durum, sürekli olarak teknik denetlemenizin bir parçasını oluşturur. Gerçekleştirdiğiniz ilk teknik denetim, sitenizin kullanıcı verilerini paylaştığı veya ilettiği üçüncü tarafların bir listesini verir. Bu başlık, daha sonra sayfa isteklerinin şu anda hangi üçüncü taraflarla iletişim kurulduğunu bildirmesine neden olur ve zaman içindeki değişiklikleri izleyebilirsiniz. Bu, yalnızca mevcut üçüncü taraflarınız tarafından yapılan değişiklikler konusunda sizi uyarmakla kalmaz, aynı zamanda teknik denetime eklenmemiş, yeni eklenmiş üçüncü tarafları da işaretler. Başlığı, beklediğiniz alanlarla ilgili rapor oluşturmayı durduracak şekilde güncellemek önemlidir ancak zaman zaman manuel teknik denetimin tekrarlanması da önemlidir (Content-Security-Policy yaklaşımı hangi verilerin iletildiğini işaretlemediği, yalnızca bir istek yapıldığı için).

Bu değerin her seferinde veya her sayfaya sunulan sayfalara eklenmesi gerekmediğini unutmayın. Çok fazla olmayan, temsili bir rapor örneği almak için başlığın aldığı sayfa yanıtlarının sayısını ayarlayın.

İzin politikası

Permissions-Policy başlığı (Feature-Policy adıyla kullanıma sunulmuştur) Content-Security-Policy ile benzer bir konsepte sahiptir ancak güçlü tarayıcı özelliklerine erişimi kısıtlar. Örneğin, ivme ölçer, kamera veya USB cihazları gibi cihaz donanımının kullanımını kısıtlamak ya da tam ekrana geçme veya eşzamanlı XMLHTTPRequest kullanma izni gibi donanım dışı özellikleri kısıtlamak mümkündür. Bu kısıtlamalar, üst düzey bir sayfaya (yüklenen komut dosyalarının bu özellikleri kullanmayı denemesini önlemek için) veya bir iframe aracılığıyla yüklenen alt çerçevelere uygulanabilir. API kullanımıyla ilgili bu kısıtlama, aslında tarayıcının parmak iziyle ilgili değildir. Üçüncü tarafların, araya giren işlemler (güçlü API'ler kullanma, izin pencereleri açma gibi) yapmalarına izin vermemekle ilgilidir. Bu, Hedef Gizlilik Tehdit Modeli tarafından "intrusion" olarak tanımlanır.

Permissions-Policy üstbilgisi, (özellik, izin verilen kaynaklar) çiftlerinden oluşan bir liste olarak belirtilir. Bu nedenle:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

Bu örnek, bu sayfanın ("kendisi") ve example.com kaynağındaki <iframe> öğelerinin JavaScript'teki navigator.geolocation API'lerini kullanmasına izin verir. Hem bu sayfanın hem de tüm alt çerçevelerin tam ekran API'sini kullanmasına olanak tanır ve bu sayfanın dahil olduğu herhangi bir sayfanın, video bilgilerini okumak için kamera kullanmasını yasaklar. Daha fazla ayrıntıyı ve olası örneklerin listesini burada bulabilirsiniz.

Permissions-Policy başlığı tarafından işlenen özelliklerin listesi büyüktür ve değişim halinde olabilir. Bu liste şu anda https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md adresinde yönetilmektedir.

Yapılması gerekenler

Permissions-Policy destekleyen tarayıcılar, alt çerçevelerde güçlü özelliklere varsayılan olarak izin vermez ve bunları etkinleştirmek için işlem yapmanız gerekir. Bu yaklaşım varsayılan olarak gizlidir. Sitenizdeki alt çerçevelerin bu izinleri gerektirdiğini fark ederseniz bunları seçerek ekleyebilirsiniz. Ancak, varsayılan olarak ana sayfaya herhangi bir izin politikası uygulanmaz. Bu nedenle, ana sayfa tarafından yüklenen komut dosyalarının (üçüncü taraf komut dosyaları dahil) bu özellikleri kullanması kısıtlanmaz. Bu nedenle, varsayılan olarak tüm sayfalara kısıtlayıcı bir Permissions-Policy uygulamak, ardından sayfalarınızın gerektirdiği özellikleri kademeli olarak tekrar eklemek faydalıdır.

Permissions-Policy ürününün etkilediği güçlü özelliklere örnek olarak kullanıcının konumunu isteme, sensörlere erişim (ivme ölçer, jiroskop ve manyetometre dahil), tam ekrana geçme izni verme ve kullanıcının kamerası ile mikrofonuna erişim isteğinde bulunma bulunur. Özelliklerin (değişen) tam listesi yukarıda verilmiştir.

Ne yazık ki, tüm özelliklerin varsayılan olarak engellenmesi ve daha sonra, seçmeli olarak yeniden izin verilmesi, tüm özelliklerin başlıkta listelenmesini gerektirir. Bu, biraz uygunsuz görünebilir. Yine de, böyle bir Permissions-Policy başlığı başlamak için iyi bir yerdir. permissionspolicy.com/ bu tür bir üstbilgi oluşturmak için kolayca tıklanabilir bir oluşturma aracına sahiptir: Bu başlığı tüm özellikleri devre dışı bırakan bir üstbilgi oluşturmak için kullanmak şu sonuçları verir:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Web tarayıcılarındaki yerleşik gizlilik özelliklerini anlama

"Derleme zamanı" ve "tasarım zamanı" korumalarına ek olarak "çalışma zamanında" gerçekleşen gizlilik korumaları da vardır. Diğer bir deyişle, kullanıcıları korumak için tarayıcılarda uygulanan gizlilik özellikleri de mevcuttur. Bunlar, site geliştiricisi olarak doğrudan kontrol edebileceğiniz veya faydalanabileceğiniz özellikler değil, ürün özellikleridir, ancak siteleriniz tarayıcılardaki bu ürün kararlarından etkilenebileceğinden dikkat etmeniz gereken özelliklerdir. Burada, bu tarayıcı korumalarının sitenizi nasıl etkileyebileceğine dair bir örnek vermek gerekirse, sayfa kurulumuna devam etmeden önce üçüncü taraf bağımlılığının yüklenmesini bekleyen istemci taraflı JavaScript'iniz varsa ve üçüncü taraf bağımlılığı hiçbir zaman yüklenmezse sayfa kurulumunuz hiçbir zaman tamamlanmayabilir. Bu nedenle kullanıcıya yarı yüklenmiş bir sayfa sunulur.

Safari'de (ve temel WebKit motorunda) Intelligent Tracking Prevention (Akıllı İzleme Önleme) ve Firefox'ta (ve motoru Gecko'da) Gelişmiş İzleme Koruması'nı içerir. Bunların tümü, üçüncü tarafların kullanıcılarınızla ilgili ayrıntılı profiller oluşturmasını zorlaştırır.

Gizlilik özellikleriyle ilgili tarayıcı yaklaşımları sık sık değiştiğinden gelişmeleri takip etmek önemlidir. Aşağıdaki koruma listesi yazıldığı tarihte doğrudur. Tarayıcılar başka korumalar da uygulayabilir; bu listeler tam kapsamlı değildir. Buradaki değişiklikleri takip etmenin yollarını öğrenmek için en iyi uygulamalar modülüne göz atın ve projelerinizi etkileyebilecek değişiklikler olup olmadığını görmek için gelecekteki tarayıcı sürümleriyle testler yapmayı unutmayın. Gizli/gizli tarama modlarının bazen tarayıcının varsayılan ayarından farklı ayarlar uyguladığını unutmayın (örneğin, bu modlarda üçüncü taraf çerezleri varsayılan olarak engellenebilir). Bu nedenle, gizli modda test etmek, çoğu kullanıcının gizli taramayı kullanmıyorsa normal tarama deneyimini her zaman yansıtmayabilir. Ayrıca, çeşitli durumlarda çerezleri engellemenin yalnızca çerezlerin değil, window.localStorage gibi diğer depolama çözümlerinin de engelleneceğine dikkat edin.

Chrome

• Üçüncü taraf çerezlerinin gelecekte engellenmesi amaçlanmaktadır. Bu yazı hazırlandığı sırada varsayılan olarak engellenmemiştir (ancak bu, kullanıcı tarafından etkinleştirilebilir): https://support.google.com/chrome/answer/95647 ayrıntıları açıklamaktadır.
• Chrome'un gizlilik özellikleri, özellikle de Chrome'un Google ve üçüncü taraf hizmetleriyle iletişim kuran özellikleri privacysandbox.com/ adresinde açıklanmıştır.

Edge

• Üçüncü taraf çerezleri varsayılan olarak engellenmez (ancak kullanıcı tarafından etkinleştirilebilir).
• Edge'in Tracking Prevention (İzleme Önleme) özelliği, ziyaret edilmemiş sitelerden gelen izleyicileri ve bilinen zararlı izleyiciler varsayılan olarak engellenir.

Firefox

• Üçüncü taraf çerezleri varsayılan olarak engellenmez (ancak kullanıcı tarafından etkinleştirilebilir).
• Firefox'un Gelişmiş İzleme Koruması, varsayılan izleme çerezlerini, parmak izi komut dosyalarını, kripto para madenciliği komut dosyalarını ve bilinen izleyicileri engeller. (https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track biraz daha ayrıntılı bilgi sağlar).
• Üçüncü taraf çerezleri sitelerle sınırlıdır, bu nedenle her sitenin temelde ayrı bir çerez kutusu vardır ve bu çerezler siteler arasında ilişkilendirilemez (Mozilla buna "Toplam Çerez Koruması" denmektedir).

Nelerin engellenebileceği hakkında bilgi edinmek ve sorunları gidermeye yardımcı olmak için adres çubuğundaki kalkan simgesini tıklayın veya Firefox'ta (masaüstü sürümü) about:protections adresini ziyaret edin.

Safari

• Üçüncü taraf çerezleri varsayılan olarak engellenir.
• Safari, Intelligent Tracking Prevention (Akıllı İzleme Önleme) özelliğinin bir parçası olarak, diğer sayfalara iletilen yönlendireni belirli bir sayfa yerine üst düzey bir site olacak şekilde azaltır: (https://something.example.com/this/specific/page yerine https://something.example.com).
• Tarayıcı localStorage verileri yedi gün sonra silinir.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/, bu özellikleri özetlemektedir.)

Nelerin engellenebileceğine dair fikir edinmek ve sorunların hata ayıklamasına yardımcı olmak için masaüstünde Safari'nin geliştirici menüsünde"Akıllı İzleme Önleme Hata Ayıklama Modu"nu etkinleştirin. (Daha ayrıntılı bilgi için https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ adresine bakın.)

API teklifleri

Neden yeni API'lere ihtiyacımız var?

Tarayıcı ürünlerindeki gizliliği korumaya yönelik yeni özellikler ve politikalar, kullanıcı gizliliğini korumaya yardımcı olsa da bazı zorlukları da beraberinde getirmektedir. Birçok web teknolojisi, başka amaçlar için tasarlanıp kullanılmasına rağmen siteler arası izleme için kullanılabilir. Örneğin, her gün kullandığımız kimlik federasyon sistemlerinin çoğu üçüncü taraf çerezlerine dayanıyor. Yayıncıların günümüzde gelir elde etmek için kullandığı çok sayıda reklamcılık çözümü, üçüncü taraf çerezlerinin üzerine inşa edilmiştir. Sahtekarlık algılama çözümlerinin çoğu dijital parmak izi tekniğini kullanır. Üçüncü taraf çerezleri ve dijital parmak izi kullanımdan kaldırıldığında bu kullanım alanlarına ne olur?

Tarayıcıların kullanım alanlarını ve gizliliği ihlal eden kullanımları diğerlerinden güvenilir bir şekilde ayırt etmek zor ve hataya açıktır. Bu nedenle çoğu tarayıcı, kullanıcı gizliliğini korumak için üçüncü taraf çerezlerini ve dijital parmak izlerini engellemiş veya böyle yapmayı amaçlamaktadır.

Yeni bir yaklaşım gerekiyor: Üçüncü taraf çerezleri kullanımdan kaldırıldıkça ve dijital parmak izi azaltıldığından geliştiriciler, kullanım alanlarını karşılayan (ve kullanımdan kaldırılmayan) ancak gizliliği koruyacak şekilde tasarlanmış, amaca yönelik API'lere ihtiyaç duyuyor. Amaç, siteler arası izlemede kullanılamayacak API'ler tasarlamak ve oluşturmaktır. Önceki bölümde açıklanan tarayıcı özelliklerinin aksine, bu teknolojiler tarayıcılar arası API'ler haline gelmeyi amaçlar.

API teklifi örnekleri

Aşağıdaki liste kapsamlı değildir; tartışılanlardan bazılarına dair bir özgüdür.

Üçüncü taraf çerezlerini temel alan teknolojilerin yerini alacak API tekliflerine örnekler:

• Kimlik kullanım alanları: FedCM
• Reklam kullanım alanları: Özel Tıklama Ölçümü, Birlikte Çalışabilir Gizli İlişkilendirme, İlişkilendirme Raporları, Konular, FLEDGE, PARAKEET.

Pasif izleme üzerine kurulu teknolojilerin yerini alacak API tekliflerine örnekler:

• Sahtekarlık algılama kullanım alanları: Güven Jetonları.

Üçüncü taraf çerezleri olmadan gelecekte diğer API'lerin geliştirebileceği diğer tekliflere örnekler:

• Storage Access API

Buna ek olarak, tarayıcıya özel gizli izleme çözümlerinin deneme amacıyla başka bir API teklifi türü de ortaya çıkmaktadır. Buna örnek olarak Gizlilik Bütçesi verilebilir. Bu çeşitli kullanım alanlarında, başlangıçta Chrome tarafından teklif edilen API'ler, Özel Korumalı Alan çatı terimi altında yayınlanır.

Global-Privacy-Control, kullanıcının toplanan kişisel verilerin başka sitelerle paylaşılmamasını istediği bir siteyle iletişim kurulmasını amaçlayan bir başlıktır. Bu özelliğin amacı, kullanımdan kaldırılan Do Not Track ile benzer.

API tekliflerinin durumu

Bu API tekliflerinin çoğu henüz dağıtılmamış veya yalnızca işaretlerin arkasında ya da deneme amacıyla sınırlı ortamlarda dağıtılmaktadır.

Bu herkese açık geliştirme aşaması önemlidir: Tarayıcı tedarikçileri ve geliştiricileri, bu API'lerin kullanışlı olup olmadığı ve gerçekten amaçladıkları şeyi yapıp yapmadıkları konusunda tartışmalara ve deneyime ev sahipliği yapar. Geliştiriciler, tarayıcı tedarikçileri ve diğer ekosistem aktörleri, API'nin tasarımını yinelemek için bu aşamayı kullanır.

Teklif edilen yeni API'lerden haberdar olmak için en iyi yer, şu anda Gizlilik Grubu'nun GitHub'daki teklifler listesidir.

Bu API'leri kullanmanız gerekiyor mu?

Ürününüz doğrudan üçüncü taraf çerezlerine veya dijital parmak izi gibi tekniklere dayanıyorsa bu yeni API'lerle ilgilenmeniz, denemeler yapmanız, ayrıca kendi deneyimlerinizi tartışmalara ve API tasarımına katkıda bulunmanız gerekir. Diğer tüm durumlarda, bu yeni API'lerle ilgili tüm ayrıntıları bu yazı yazarken öğrenmeniz gerekmez ancak yenilikler hakkında bilgi sahibi olmak iyi bir fikirdir.