Kötüye Kullanıma Karşı Tasarım: İstismarcı ve Mağdur Arketipleri

Bir özelliğin kötüye kullanılacağını genelde ilk kullanıcılar öğretir, tasarımcılar değil. Konum paylaşımı arkadaşları buluşturmak için çıkar, takip aracına dönüşür. Akıllı termostat konfor için alınır, evdeki birine baskı kurmanın yolu olur. Bu ihtimalleri ürün sahaya çıkmadan görmek için kullanıcıyı hep iyi niyetli sayan tasarım alışkanlığını bozmak gerekiyor.

Hangi özelliklere bakılır

Beş adımlı güvenlik süreçleri kağıt üzerinde düzgün durur, pratikte hiçbir ekip her özellik için araştırma, arketip, senaryo, tasarım ve test turunu çeviremez. Filtreyi baştan daraltın: bir kullanıcının eylemi başka bir kullanıcının verisini, konumunu ya da durumunu değiştiriyorsa o özellik listeye girer. Dışarı veri taşımayan, tek cihazda kalan bir özellikte kötüye kullanım yüzeyi neredeyse yoktur.

Listenin en başına sessiz olanları yazın. Karşı tarafa bildirim gitmeyen her erişim, arka planda yenilenen her konum, verildiği an görünmeyen her yetki, istismarcı için en kullanışlı olanıdır.

İki arketip

Persona çalışmaları genelde ürünü amacına uygun kullanan insanı anlatır. Buraya iki tane daha ekleyin.

İstismarcı, ürüne zarar verme aracı olarak bakar: koşu rotalarından eski eşinin ev adresini çıkarmaya çalışan kişi, ortak hesabın fatura ekranından karşı tarafın yeni telefon numarasını gören kişi.

Mağdur ise tek tip değil. Birincisi olan biteni bilir ama durduramaz, termostatı kimin çevirdiğini bilir, hesabın sahibi o değildir. İkincisi bir şeylerin ters gittiğini hisseder, nasıl olduğunu çözemez. Birinciye kontrol lazım, ikinciye görünürlük. Aynı ekranla ikisini birden çözemezsiniz.

Senaryoları üretirken

En uç senaryodan başlamak eğlencelidir ama çıkan listeyi önceliklendiremezsiniz. Gerçek vakalardan başlayın: benzer ürünlerde bildirilmiş istismar örnekleri, destek kayıtlarınızdaki tuhaf talepler, "hesabımı eşim açtı" diye gelen mesajlar. Sonra listeyi üç soruyla sıralayın. Ürün buna teknik olarak izin veriyor mu, zarar ne kadar ağır, tekrarlanabilir mi.

Tek seferde bir kişiyi etkileyen ama sürekli tekrarlanabilen bir açık, teoride daha yıkıcı görünen ama kurulması zor olan bir senaryodan önce gelir.

Tasarımda karşılığı

Elinizde zarar listesi varsa her madde için dört soru yeterli:

• Bu zararın hiç mümkün olmadığı bir tasarım var mı?
• Mağdur, olan bitenden ürünün kendisi üzerinden nasıl haberdar olur?
• Haberdar olduktan sonra durdurmak için ne yapması gerekiyor, kaç adımda?
• Hangi kullanım örüntüsü zarar sinyali sayılır, ürün o noktada yardım önerebilir mi?

Sonuncusu genelde atlanır, oysa en ucuzu odur; çoğu zaman zaten topladığınız veriden çıkar.

Veri tarafında kural basit: toplamadığınız veri sızmaz, kötüye de kullanılmaz. Konum geçmişini kalıcı saklamam, son birkaç saat senaryoların çoğunda yeterli oluyor, gerisi yalnızca risk olarak duruyor. Saklama süresini altyapı detayı değil ürün kararı sayın.

Testi kendiniz yapın

Prototipi iki bakış açısıyla deneyin. İstismarcı turunda amacınız ürünü takip, baskı ya da ifşa aracına çevirmek; bunu ne kadar hızlı başardığınız doğrudan ölçüdür. Mağdur turunda hesabı devralın ve üç soruya cevap arayın: neyin değiştiğini fark edebiliyor musunuz, kimin değiştirdiğini görebiliyor musunuz, tek başınıza durdurabiliyor musunuz.

Üçüncüsü stres testi. Gerçek kullanıcılar bu ekranlara iyi bir günde gelmez. Panikleyen, acele eden, eli titreyen birinin akışı tamamlayıp tamamlayamadığını görmek, tasarımın şefkat eksiği olan yerlerini kalan her yöntemden daha hızlı gösterir.

Bu turların çıktısı rapor değil, birkaç somut değişiklik olmalı: kapatılan bir varsayılan, eklenen bir bildirim, kısaltılan bir kurtarma akışı. O üçü yapıldıysa tur işe yaramıştır.