Kullanıcılar için risk azaltmanın iyi bir yolu, gizliliklerini etkilemeyecek şekilde ihtiyaç duymadığınız hassas verileri saklamamaktır. İşletme hedeflerinizi karşılamaya devam ederken bunu yapmanın şaşırtıcı birkaç yolu vardır ve her birini dikkate almaya değer. Şunları yapabilirsiniz:
- Verilere ne için ihtiyaç duyduğunuzu açıklayın.
- Daha düşük ayrıntı düzeyinde veri toplayın.
- Kullanılan verileri kaldırın.
- İlk olarak bunları toplamaz.
Bu yaklaşımların her biri, kullanıcılarınızın neyi neden yaptığınız konusunda kendilerini daha rahat hissetmelerine yardımcı olabilir ve bu da onlarla olan ilişkinize büyük katkıda bulunur. Şeffaflık, güven oluşturur. Daha da önemlisi, güven kazanmak sizin için benzersiz bir satış noktası olabilir. Birçok kişi, kullanıcıların ve müşterilerin varsayılan olarak bunlara güvendiğini varsayar ancak tüketiciler ürün ve hizmetleri sürekli olarak değerlendirir ve bu doğru olmayabilir. Kullanıcılarınızla, verilerini ve etkileşimlerinizi saygı çerçevesinde ele alma konusunda size güvendikleri bir ilişki kurarsanız bu, proje ya da işletme olarak size rekabet avantajı sağlayabilir. Rakiplerinizin eşleşmeyebileceği bir şey ve gerçek bir fark yaratır.
Yukarıdaki yaklaşımları, en etkili (ancak işletmeniz üzerinde en çok etkisi olan) olandan en az etkili, ancak en az rahatsız edici olana doğru sıralayarak inceleyelim.
İlk olarak bunları toplamayın
Kullanıcılarınızın verilerinden ödün vermemenin en bariz yolu, verileri toplamamaktır. Hizmet sunmak için bir miktar veri toplama işlemi gereklidir. Ancak verilerin toplanmasını önlemek için düşünebileceğinizden daha fazla yer vardır. Örneğin, giriş yapmadan öde seçeneğini değerlendirin. Kullanıcılar web uygulamanızı kullanarak bir şey satın almak için geldiklerinde, bir hesaba kaydolmalarını isteyebilirsiniz. Çünkü daha sonra sipariş karşılama için kişisel bilgilerinizi almış olursunuz: Kullanıcılar posta listesine eklenebilir, zaten ilgili bir müşteri olarak önceden uygun niteliklere sahiptir vb. Ancak müşteriler bunu fark etmekte ve beğenmemektedir: 2021'de yapılan bir çalışma, terk edilen dört satıştan birinin sitenin kullanıcıdan hesap oluşturmasını talep etmesi nedeniyle olduğunu ortaya koymuştur. Bir hesaba ihtiyaç duymazsanız bu müşterileri elde tutma olasılığınız daha yüksektir. Satın alma işlemini kaydolmadan tamamlamayı mümkün kılmak kullanıcılara daha iyi seçenekler sunar ve ayrıca, korunacak ve güven altına alınacak çok fazla verisine sahip olmadığınız anlamına gelir.
Verilerinizi "Fuzz"
Elbette, veri toplamaktan kaçınma seçeneği olmayabilir. Hizmet sunmak ve makul iş kararları almak için veri toplamak önemlidir. Pazarlama iletişimlerini güvene dayalı bir ilişki bağlamında kurmak da yararlı olabilir. Bununla birlikte, toplu (yani aynı anda birçok kullanıcıyı etkileyen) kararların toplu veriler (yani verilerin toplu özellikleri hakkında) hakkında alındığını da unutmamak da önemlidir.
Örneğin, kitlenizin hangi yaş gruplarına denk geldiği, bulundukları yer gibi demografik özellikleri hakkında fikir edinmek bazen faydalıdır. Bu durum, mesajınızı veya yaklaşımınızı değiştirebilir. Ancak bu, hizmetinizin her kullanıcısı için tam yaş bilgisini almanız gerektiği anlamına gelmez. Genellikle, trendler ve genel mülklere bakarsınız. Ulaşmak istediğiniz karar, kitlenizin çoğunluğunun "18-34 temel demografi" arasında olup olmamasından etkileniyorsa, aslında sormanız gereken tek soru, kullanıcılarınızın bu demografik grupta olup olmadığıdır. Böylece, öğeler iki "grupta" toplanır: o grupta değil. Bundan daha ayrıntılı verilere ihtiyaç duyduğunuz durumlar olabilir, ancak karar vermek için kullandığınız demografinin listesini almak ve kullanıcılarınızdan kendilerini bu listeyle sınıflandırmalarını istemek tamamen makul bir davranıştır.
Örnek
Bu nedenle, kullanıcı tabanınızın "18-34", "35-49", "49-64" ve "65+" yaş kategorileri arasında nasıl bir dağılım gösterdiğini bilmek faydalıysa, kullanıcılarınızdan bu kategorilerden hangilerini seçmelerini isteyebilirsiniz. Son derece ayrıntılı, kişisel ve kişiselleştirilmiş veriler istemek ve ardından kullanıcılarınızı kendiniz sınıflandırmak cazip gelebilir. Böylece, aynı soruyu daha sonra daha ayrıntılı olarak sorma ihtiyacını ortadan kaldırabilirsiniz. Örneğin, bu soruyu kullanarak tam bir yaş ve doğum tarihi bilgisi isteyebilir ve bu bilgiyi "35-49" kategorisinde kaç kullanıcının bulunduğuna ilişkin kendi listelerinizi oluşturmak için kullanabilirsiniz. Ancak bunun nasıl göründüğünü fark etmek önemlidir: Kursta daha önce değindiğimiz ve tekrar işleyeceğimiz için ayrıntılı veri düzeylerini istemek kullanıcıları rahatsız edebilir ve risk yaratırken kullanıcıların kuruluşunuza olan güvenini azaltabilir.
Veri ihtiyaçlarınızı göz önünde bulundurmak da önemlidir. Bazen daha ayrıntılı verilere duyulan "ihtiyaç", "her ihtimale karşı" bir gereklilik olarak spekülatiftir. Belki de şu anda kullanıcıları yalnızca bu dört yaş grubuna göre sınıflandırmamız gerekiyor, ama gelecekte bunu daraltmamız gerekebilir. Bu nedenle, bu seçeneği daha sonra kullanmak üzere açık tutmak için hemen şimdi çok ayrıntılı veriler toplamamız gerekir. Kararlara yön vermek için geçmişte daha ayrıntılı verilerin gerçekte ne sıklıkta kullanıldığını değerlendirmek faydalı olabilir. Sunulan hizmete göre rahatsız edici olarak algılanan verilerin istenmesi, kullanıcılarınızın kuruluşunuza olan güveninin azalmasına neden olur. Bu veriler "her ihtimale karşı" nedenlerle toplanıyorsa yalnızca daha iyi iş kararları almak için kullanıcıların güvenini zedelemekle kalmaz, yalnızca gelecekte var olmayabilecek teorik kararlar olasılığını göz önünde bulundurarak ve bu bilgiler için güvenlik gereksinimlerini üstlenirsiniz.
Toplanan verilerin ayrıntı düzeyini azaltmanın daha ayrıntılı algoritmik yolları da vardır. Rastgele yanıt yöntemleri, verilerin hassas bir şekilde ayarlanabilen bir doğrulukla toplandığı anlamına gelir. Bu yöntemler, yıllardır sosyal bilimlerde, müdahalecinin gizliliğini korurken potansiyel olarak istilacı veya hassas verilerin toplanmasında kullanılmaktadır. Yukarıdaki veri toplama yöntemi kullanıcının yanıtlarının genişletilmesini içerir (dolayısıyla "kaç yaşındasınız" ifadesi "aşağıdaki yaş gruplarından hangisine girersiniz?" olur). Burada rastgele yanıtlar, kullanıcıların belirli bir bölümünün yanıtları hakkında yalan söylemesini içerir. Yanlış yanıt veren kullanıcıların oranı biliniyorsa toplanan verilerden anlamlı sonuçlar çıkarılabilir ancak toplanan veriler yanlış olabileceği için kullanıcının gizliliği tehlikeye atılmaz. Bu durumda, kitlenizin% 80'i hâlâ 18-34 demografik grubuna dahil olduğunu belirtiyorsa, %10'u kasıtlı olarak yanlış cevaplar veriyor olsa bile, hâlâ bu en büyük pay olduğundan emin olabilirsiniz. Yanlışlık derecesi programlı bir şekilde de değiştirilebilir. Burada her zaman doğru yanıtlar istenir, ancak yazılım iletimden önce yanıtların belirli bir yüzdesini değiştirir. Veriler toplandığında bu süreç ve bunun sonuçları da kullanıcılara açıklanabilir: Bu, bireysel veriler güvenilir olmadığından kullanıcıların, toplanan verilerini kötüye kullanmayacağınıza güvenmelerine gerek olmadığı anlamına gelir.
Benzer ancak teknik açıdan daha karmaşık bir süreç diferansiyel gizlilik sürecidir. Bu yöntemde, verilerin birleştirilmiş özelliklerinin hâlâ mevcut olması için veri depolamayı değiştirmek üzere matematiksel teknikler kullanılmaktadır, ancak belirli bir kişinin veri sağlayıp sağlamadığını mı yoksa hangi veriyi sağladığını bile söylemek mümkün değildir. Rastgele hale getirilmiş yanıtlarda olduğu gibi, bu yöntem de kullanıcıların verilerini sizden bile korur ve sizin açınızdan net bir niyet gösterir: Bu verilere sahip değilseniz kullanıcılarınızın verilerini kullanamazsınız.
Bu ve benzer yaklaşımlar veri ihlallerine ve sızıntılarına karşı daha fazla güvenlik sağlar. Çünkü toplanan veriler, kullanıcı gizliliğine (sizin dahil) yönelik tehlikeleri azaltır ve verilerin sızdırılması halinde güvenlik ihlali düzeyini düşürür. Ancak, sunucuda diferansiyel gizlilik teknikleri uyguluyorsanız (böylece kullanıcılarınız size birleştirilmemiş veriler gönderiyor ve daha sonra bunları toplamak için teknikleri kullanıyorsanız) yine de ham kullanıcı verilerini güvenceye almanız, ardından işlendikten sonra silmeniz ve toplama işleminden önce bunları kullanmadığınızı (veya ne için kullandığınız konusunda net olan) onaylamak için açık politikalara sahip olmanız ve bunları uygulamanız gerekir.
Elde tutma: Verileri toplayın ve kullandıktan sonra kaldırın
Toplanan verilerin bir yaşam döngüsü olduğunu unutmayın. Veriler toplanır, iş kararları almanıza yardımcı olmak için kullanılır ve daha sonra bir noktada kaldırılması gerekir. Bunlar, yine artılar: Kullanıcılarınıza sorular sorduğunuzda veya ziyaret ettikleri diğer web siteleri hakkında bilgi depoladığınızda ya da tercihleri hakkında tahminlerde bulunmak için hangi yerlere ne kadar süre baktıklarını izlediğinizde bu veriler size belirli bir amaç için verilir. Bu veriler, geliştiricinin uygun gördüğü şekilde kullanabileceği açık uçlu bir bağış olarak değildir. Söz konusu verinin bu amaç için artık ihtiyaç duyulmadığı durumlarda (bazen bir dakika, bazen de yıllar sonra) silinmesi gerekir.
Kullanıcılarınız hakkında bilgi topladıktan sonra bu verileri ne için kullanacağınızı (aşağıya bakın) ve bu verileri saklamayı ne zaman ve neden durduracağınızı bilmeniz gerekir. Bu, kullanıcı etkinliği silmeyi seçtiğinde veya oturumu kapattığında, belirli bir süre sonra ya da belirli bir etkinlik gerçekleştikten sonra olabilir. İlişkinizde güven oluşturmanın mükemmel bir yolu, kullanıcılarınıza kendileriyle ilgili verileri nasıl kontrol edebileceklerini (mümkünse tek taraflı kapsam dışında kalma seçeneği de dahil) netleştirmektir. Verileri nasıl silinir? Hesap nasıl silinir? Bu ilişkiyi kurmaya yardımcı olmanın yanı sıra, verileri işlemeniz gereken süre boyunca (daha uzun değil) depolamak ve kullanıcılarınızın onlardan veya onlar adına topladığınız verileri görmesi ve kaldırması için bir yol olması en iyi uygulamadır. Hatta faaliyet gösterdiğiniz bölgelerde bu noktada mevzuat bile olabilir.
Bu alanda teknik hedefleri belirleyebilirsiniz. Bu hedefler, self servis hizmeti olan kullanıcılara yardımcı olur. Kullanıcılarınız izin istemek zorunda kalmadan veri ambarınızı devre dışı bırakabilirse bu seçeneği etkinleştirmek için çok daha rahat hissedebilirler ve bunun için herhangi bir destek kaynağına ihtiyaç duymazlar.
Kolay ve varsayılan devre dışı bırakma işlemlerinin önemini anlamak önemlidir: "Şirketler güven ve tanınırlık oluşturmak için ilk olarak, kitlelerine her temas noktasında saygı göstermeyi, ihtiyaçlarını dinlemeyi ve uygun şekilde karşılık vermeyi taahhüt ettikleri bir sosyal sözleşme kabul edebilir" IAPP. Nielsen Norman Group, kullanıcıların "istenmeyen işlemden ayrılmak zorunda kalmadan istenmeyen işlemden çıkabilmeleri için açıkça işaretlenmiş bir 'acil çıkışa' ihtiyaçları olduğunu" söylüyor. Abone olmanın, abonelikten çıkmaktan daha kolay olduğunu herkes bilir. Ancak Nielsen Norman'ın dediği gibi, kullanıcılara zıplamak zorunda kalmadan uzaklaşma olanağı sunmak "özgürlük ve özgürlük hissini artırır". Akademik çalışmalar bu durumu destekleyerek durumu "geri alınabilirlik ilkesi" olarak adlandırmaktadır ve şöyle denmektedir: "Arayüz, mümkün olan her durumda, kullanıcının verdiği yetkileri kolayca iptal etmesine olanak tanımalıdır. Kullanıcılar bu izni iptal edebilmeli ve bu nedenle mümkünse kaynaklarına erişim yetkisini azaltabilmelidir." (Örnekler için Yee ve Iacono'ya bakın.)
Verilerin ne kadar süre saklanacağı ve hangi verilerin saklanacağı, kurumlar ve projeler arasında büyük farklılık gösteren bir konudur ancak dikkate alınması gereken bazı yaygın yönergeler vardır.
Yapmanız gerekenler:
Burada kullanıcıların hesapları (ve mümkün olduğunda ilişkili verileri) silmelerine izin vermek ve oturum kapatıldığında geçici ve yerel olarak depolanan verileri düzenli olarak (örneğin, oturum kapatıldığında) Clear-Site-Data başlığıyla silmelerine izin vermek yararlıdır.
Makul olduğu durumlarda, istemci tarafında depolanan kullanıcı verilerinin (çerezler, localStorage, IndexedDB veya tarayıcı önbelleğinde) bir kısmını veya tamamını kaldırmak için bir Clear-Site-Data üst bilgisi sağlayın. Site Verilerini Temizle özelliğinin en yaygın kullanım alanı, kullanıcının çıkış yapmasıdır. Ancak bu özellik, güvenlik olaylarından sonra da kullanılabilir. Bu özellik, güvenliği ihlal edilmiş olabilecek bir hesabın, istemcide depolanan güvenliği ihlal edilmiş verilere ait uzun süreli izler olmadığından emin olmak için de kullanılabilir.
Clear-Site-Data desteği eklemek için, kullanıcı oturumu kapattığında (veya istemci taraflı depolama alanını temizlemek istediğiniz diğer zamanlarda), çıkış durumunun (https://your-site/logout veya benzeri) onaylandığı sayfada bir Clear-Site-Data HTTP üst bilgisi gönderilir. Bu başlıkta aşağıdaki değerlerin bazıları veya tamamı ya da tümü için "*" olabilir:
Clear-Site-Data: "cache", "cookies", "storage"
Bu değerler sırasıyla önbelleğe alınmış sayfaları (ve HTTP önbelleğine alınmış diğer kaynakları), depolanan çerezleri, localStorage ve IndexedDB'yi ve benzerlerini temizler.
Başka bir seçeneğe (executionContexts) referans görebilirsiniz, ancak bu birçok tarayıcı tarafından desteklenmez.
Clear-Site-Data üst bilgisini kullanmak, oluşturulan tüm kaynakları tek tek silmekten daha kolay olabilir. Çünkü bu yöntem, istemcide JavaScript kodu çalıştırılmasını gerektirmez (ve tarayıcı önbelleğini temizlemenin tek resmi yoludur), ancak tüm tarayıcılar tarafından desteklenmez.
Kullanım notu: Önbelleği temizliyorsanız (Clear-Site-Data: cache göndererek) Clear-Site-Data üstbilgisi gerçek oturum kapatma sayfanızda değil, başka bir kaynakta sayfa yüklenirken gönderilir. Bunun nedeni, büyük bir önbelleği olan daha yavaş bir bilgisayarda,
önbelleği temizlerken sayfanın engelleneceğinden dolayı gezinmenin engellenmesidir. Bu işlem birkaç dakika sürebilir ve
bu, kullanıcıyı rahatsız eder. Gerçekleşme olasılığı düşük olsa da bunu test etmek zordur. Bu nedenle, bunu göz önünde bulundurmak en iyi yöntemdir.
Hangi veriler için verilere ihtiyaç duyduğunuzu açıklayın
Kullanıcılarınızın hizmetinizle olan ilişkisine duyulan güvenin önemi, kullanıcı süresini artırdığı için birçok kez ifade edilmiştir. Aynı zamanda rekabet avantajı da sağlar. Bu güven düzeyini artırmanın bir yolu da süreçlerinizi şeffaf bir şekilde açıklamaktır. Şeffaf olmanın iyi bir yolu da ne için veri istediğinizi açıklamaktır. Toplanan her verinin ne zaman silineceğini bilmeniz gerektiğini daha önce öğrenmiştiniz. Bunu bilmek için bu verileri neden istediğinizi, yanıt bulmak için hangi belirli sorulara ihtiyaç duyduğunuzu ve bu verilerin toplanarak hangi kararların yönlendirileceğini bilmeniz gerekir. Kullanıcınızdan vazgeçmesini istediğiniz bu verilere neden ihtiyacınız olduğunu öğrendikten sonra, bu verileri söz konusu kullanıcılara açıklayarak güven oluşturabilirsiniz. Gizlilik politikanızda veya hesap oluşturmayla ilgili sorular sorarken söz konusu sorunun cevabına neden ihtiyaç duyduğunuzu, bu verilerle ne yapacağınızı, bu verilerin ne zaman ve nasıl kaldırılabileceğini açıklayın.
Bu açıklamalar satır içinde sunulduğunda çok daha görünür. Açıklamaları web sitesinin başka bir yerindeki yoğun bir politika belgesine gömmek, bunları saklama girişimi gibi görünebilir. Kaydolma, ödeme veya istek formları, veri toplama nedenleri ile birlikte veri toplama nedenlerini de gösterebilir. Genellikle form alanında, bir alanın gerekli olduğunu belirten yıldız işareti (*) bulunabilir. Karmaşık formlarda genellikle alanın ne anlama geldiğini açıklayan bilgi bağlantısı (i) bulunur. Bu açıklamalara verilerin neden toplandığına dair bir açıklama ekleyebilirsiniz. Bu ifade için sık kullanılan bir ifade, form alanının yanındaki "Buna neden ihtiyacımız var?" şeklindedir ve tıklandığında bir pop-up açıklama gösterilir.
Bir örnek HTML'nin görünümü aşağıdaki gibi olabilir. Bu durumda CSS ve JavaScript, <aside> öğesini gizler ve bağlantı tıklandığında pop-up olarak gösterir. (Siteniz için oluşturduğunuz formun erişilebilirliğini onayladığınızdan emin olun.)
Bunun tam olarak nasıl yerleştirileceği, tarzlarınıza ve yaklaşımlarınıza bağlıdır, ancak buradaki asıl mesele, veri toplama işlemini bu verilerin neden toplandığına dair bir açıklamayla doğrudan ilişkilendirmektir. Bu işlem her alan için gerekli değildir. Kimsenin kayıt sırasında şifre seçmesini neden istediğiniz konusunda açıklamaya ihtiyaç duymaz. Ancak kişisel ve iletişim bilgilerinizle ilgili her isteği, bu bilgileri nasıl kullanmayı planladığınızla ve bu şekilde saklamak, kullanıcı verilerini korumaya önem verdiğinizi kullanıcılarınıza daha iyi anlamanızı sağlayabilir.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
Bu süreçten bir kullanıcıyla ilgili topladığınız her şeyi göz önünde bulundurmanız, dahili süreçlere ve tartışmalara yardımcı olabilir. Önceki videolarda, "her ihtimale karşı" veri toplamanın cazip olabileceğini görmüştünüz. Toplama gerekçeleriniz konusunda şeffaf olursanız bu durumun ortaya çıkacağı gayet açık olabilir. Kullanıcı verileriyle ne yapmak istediğinizi herkese açık bir şekilde yazmakta tereddüt ediyorsanız bu kullanıcılar açıklamayı beğenmeyebilir. Bu, verileri toplamayı yeniden düşünmeye değer olduğuna dair bir işaret olabilir. Bu, hoş olmayan açıklamanın fazla yayılmacı ("Ziyaret ettiğiniz yerleri saatlik olarak izlemek için kullanırız"), çok geniş kapsamlı ("henüz bunu ne için kullanacağımızı bilmiyoruz ancak bunun için bir şeyler düşünürsek istiyoruz") veya çok hileli ("bunu açıklanmayan şirket içi amaçlarla kullanacağız"). Bu sadece bir ahlak meselesi değil. İnsanlar daha önce açıklandığı gibi bunu anlayacak kadar bilgili ve bir şeyle deneme yapmanın uzun vadeli bir taahhüdün başlangıcı olmadığına dair bir kullanıcı beklentisi var. Kullanıcı deneyimi tasarımında kullanımın mümkün olduğunca sorunsuz ve kolay olması sık kullanılan bir uygulamadır. Çünkü ilk aşamalarda kullanıcı (tanıma göre) hizmetinize büyük bir yatırım yapmaz. Bu nedenle, henüz buna pek fazla istek duymadıkları halde de daha kolay bir şekilde yatırım yapmalarına izin vermek önemlidir. Tekrar ayrılmak bu kadar kolaysa, hizmeti denemeye zorlanmaktansa uzun süre hevesli bir şekilde denemeye başlamaları gerekmez. Daha önce olduğu gibi paradoksal bir durum ancak güven oluşturmanın en iyi yolunun, istemedikleri takdirde kullanıcılarınızın size güvenmesini şart koşmamak olduğu doğru.
Kullanıcıların veri paylaşmamak veya çok az veri paylaşmak için geçerli nedenleri vardır. Onlarla olan ilişkinizin başlangıcında, size güvenmeleri ve güvenmek zorunda olmamaları gerekir. Hedefiniz, bunları neden yapmaları gerektiğini göstermektir.
Yapmanız gerekenler:
- Neden toplamak istediğiniz tüm verilere ve bu verileri ne kadar süreyle saklayacağınıza karar verin.
- Bu verileri istediğinizde, neden bu verileri topladığınızı kullanıcılarınıza açıklayın.
- Kodu kullandıktan sonra sunucu veritabanlarınızdan silin.
- Kullanıcıların, oluşturdukları hesapları silmesine ve
Clear-Site-Dataüstbilgisi ile, depolanan verileri depolama alanından temizlemesine izin verin.
Neden?
Kullanıcılarınızla ilişki kurmak güvene bağlıdır. Güven ise açık olmakla ilgilidir. Kullanıcılarınız hakkında mümkün olduğunca fazla veri toplamadığınızı ve bu verileri kullanım amacınızı gizlemeniz, güven tesis etmeye yardımcı olur. Bu da daha az vicdanlı rakiplere karşı rekabet avantajı sağlayabilir.