Kendin Yapma …

 (susam.net)
7 puan yazan GN⁺ 9 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Don't Roll Your Own ... ilkesi yalnızca kriptografi için değil, web UI için de geçerlidir; tarayıcının zaten güvenilir biçimde sunduğu işlevler gereksiz yere değiştirilmemelidir
  • Özel kaydırma, bağlantı işleme, metin seçimi, kopyala-yapıştır gibi temel davranışların yerine geçmek, kullanıcıların alıştığı girdi tepkilerini bozarak etkileşim biçimine yeniden dikkat etmelerine neden olur
  • GitHub’daki dosya ve issue bağlantılarında olduğu gibi JavaScript bağlantı gezinmesini araya girip ele alırsa, mevcut sekmede işlenmesini beklemek yerine yeni sekmede açmak bazen daha hızlı olabilir
  • Varsayılan şifre alanı ve <input type="date">, otomatik tamamlama, şifre yöneticileri, erişilebilirlik araçları ve mobil klavyelerle birlikte çalışır; bunları sahte bir UI ile değiştirmek işlevleri bozabilir
  • Birkaç ayda bir değişen düzenler ve form kontrolleri, kullanıcıların işlerinden çok yeniden öğrenmeye zaman harcamasına yol açar; tarayıcının kararlı varsayılan davranışlarını korumak daha uygundur

“Kendin yapma” ilkesinin web UI’a uygulanması

  • Kriptografiyi kendin uygulama uyarısı, hassas verileri koruyan üretim yazılımlarında doğrulanmamış özel uygulamalara bel bağlamamak gerektiği anlamına gelir
  • Bu, hiç kimsenin kriptografi kodu yazmaması gerektiği demek değil; mümkün olduğunca incelenmiş ve doğrulanmış paketler ile araçların kullanılması gerektiği anlamına daha yakındır
  • Yaklaşık 20 yıl önce, uygunsuz başlangıç vektörleri, tahmin edilebilir keystream’ler ve düz metnin bir kısmını açığa çıkaran sorunlar içeren özel RC4 uygulamaları gerçekten vardı
  • Günümüzde büyük e-ticaret siteleri veya bankalar genelde web hizmetlerinde kendi kriptografilerini kullanmaz; ödeme, sağlık ve kişisel veri işleme gibi düzenlemeye tabi alanlarda güçlü şifreleme gerekliliklerini ihlal etmek büyük para cezalarına yol açabilir
  • Web sitesi tasarımı kriptografiyle aynı şey değildir, ancak tarayıcının zaten iyi yönettiği ve kullanıcıların her gün güvendiği işlevleri yeniden uygulamak kullanıcı deneyimini kötüleştirebilir

Tarayıcının varsayılan işlevleri değiştirildiğinde ortaya çıkan sorunlar

  • Sayfa kaydırmayı kendiniz uygularsanız, fare, touchpad ve klavye girdilerine verilen alışıldık tepkiler bozulabilir
  • Varsayılan kaydırma davranışını geçersiz kılmak, sayfanın çok yavaş veya çok hızlı hareket etmesine neden olabilir ve klavyeyle kaydırma da çalışmayabilir
  • Kullanıcının farkında olmadan kullandığı davranışlar yabancı davranışlara dönüşürse, kişi sayfayı nasıl kullanacağını yeniden düşünmek zorunda kalır
  • Kendiniz uygulamamanız gereken başlıca işlevler arasında bağlantı gezinmesi, metin seçimi, bağlam menüsü, kopyala-yapıştır, şifre alanları ve tarih seçiciler yer alır
  • Ciddi iş amaçlı web sitelerine kullanıcı arayüzü işlevleri eklerken, gösterişli özellikler mi ekleneceği yoksa bunun tarayıcının varsayılan davranışına mı bırakılacağı konusunda temkinli karar vermek gerekir

Bağlantı gezinmesi ve GitHub örneği

  • Web tarayıcıları bağlantıları takip etme işini zaten iyi yapar; bağlantı gezinmesi tarayıcının temel işlevlerinden biridir
  • Normal bağlantı davranışına müdahale etmeniz gerektiğini düşünüyorsanız, ulaşmak istediğiniz hedefin sıradan bağlantı gezinmesini bozacak kadar önemli olup olmadığını yeniden değerlendirmelisiniz
  • GitHub’da dosya bağlantılarına veya issue bağlantılarına tıklandığında, JavaScript ile yazılmış büyük bir özellik tıklamayı kendisi işler
  • Firefox veya Chrome’da F12 ile geliştirici araçlarını açıp, Debugger ya da Sources sekmesindeki Event Listener Breakpoints altında Mouse içindeki click seçeneğini işaretledikten sonra GitHub’daki bir bağlantıya tıklayarak bu davranışı görebilirsiniz
  • GitHub’da mevcut sekmedeki JavaScript gezinme işlemini beklemektense bağlantıyı yeni sekmede açmak bazen daha hızlıdır

Şifre girişi ve tarih seçici

  • Tarayıcının şifre giriş alanı, şifre kaydetme, otomatik doldurma ve yeni hesaplar için güçlü şifre üretme işlevleri sunabilir
  • Varsayılan şifre alanı, şifre güvensiz bir HTTP bağlantısı üzerinden gönderildiğinde uyarı verir ve şifre yöneticileri, otomatik tamamlama, mobil klavyeler ve erişilebilirlik araçlarıyla da birlikte çalışır
  • Bunun yerine sahte bir şifre alanı kullanılırsa bu işlevler bozulabilir; düz metin alanını elle maskelemek ise tarayıcı, işletim sistemi ve yardımcı araçların şifreyi normal görünür metin gibi ele almasına neden olabilir
  • <input type="date"> doğrudan tarih aralığı seçimini desteklemez, ancak başlangıç ve bitiş tarihi için iki giriş alanı sunarak tarayıcının varsayılan tarih seçicisini koruyabilirsiniz
  • Özel tarih seçiciler, uygulamaya göre farklı çalışır; yıl görünümüne büyütmek gerekebilir, doğum yılını seçmek için önceki yıl düğmesine onlarca kez basmak gerekebilir ya da tarihin doğrudan girilmesi engellenebilir
  • Varsayılan tarih seçiciyi yeterince desteklemeyen tarayıcılarda takvim bileşeni gerekiyorsa, <input type="date"> yerine geçmek yerine aynı alanı yöneten yardımcı bir bileşen olarak eklemek daha iyidir

Sık UI değişikliklerinin maliyeti

  • Form kontrollerini gelişigüzel değiştirmek, mevcut sorunları çözerken neredeyse her zaman yeni sorunlar da ortaya çıkarır
  • Web sitesi düzeni ve arayüzü birkaç ayda bir değişirse bazı kullanıcılar uyum sağlasa bile, daha yaşlı kullanıcılar her seferinde yeni bir araç öğreniyormuş gibi bir yük yaşar
  • Birçok web sitesi arayüzünü sürekli değiştirirse, kullanıcılar işlevsel bir kazanç olmadan alıştıkları şeyleri yeniden öğrenmek için önemli miktarda zaman harcamak zorunda kalır
  • Linux dağıtımlarının birkaç ayda bir tüm temel komutları ve komut satırı seçeneklerini yeniden tasarlaması ya da çamaşır makinesindeki düğme düzeninin her sabah değişmesi gibi, tekrarlanan UI yeniden düzenlemeleri rahatsız edici bir deneyime dönüşür
  • Web UI, kullanıcıların işlerini tamamlamak için kullandığı bir araçtır; bu nedenle tarayıcının zaten sunduğu tanıdık ve kararlı davranışları gereksiz yere değiştirmemek tercih edilmelidir

İlgili okumalar

2 yorum

 
kirinonakar 3 시간 전

Bizim ülkemizdeki gibi kendine özgü şifreleme ve kendine özgü güvenlik programlarının bu kadar çok olduğu başka bir ülke yoktur herhalde.
 
GN⁺ 9 시간 전
Lobste.rs görüşleri

  • Sayfa kaydırmasını kendin uygulamaman gerektiğine katılıyorum. Bunu native kadar iyi yapamazsın; istisna olarak kabul edilebilecek durum, haritalarda olduğu gibi kaydırmanın yakınlaştırma/uzaklaştırmaya eşlendiği yerleşik bir alışkanlığın olduğu durumlar olabilir

    Bağlantı gezinimini kendin uygulamamanın bir kural olmasına ise güçlü biçimde karşı çıkıyorum. Sıradan bir içerik sitesi için istemci tarafı yönlendirmeyi (CSR) önermem ama bazı uygulamalarda tam tersine özellikle tavsiye edilebilir; GitHub gibi servisler ise ortalarda bir yerde duruyor

    Yine de tarayıcının native işlevlerinin çalışması için her zaman gerçek `` öğeleri kullanılmalı. Webmail istemcisi gibi uygulamalarda CSR kullanmak mantıklı; GitHub da eskiden hafif uygulandığında iyileşmişti ama son dönemdeki frontend yaklaşımı epey kötüleşti

    Sorun şu ki CSR çok sık özensiz uygulanıyor ve kötü ağ koşullarına dayanıklı hale getirilmiyor. Tarayıcı bu tür durumlarda güçlüdür; sekme yükleniyor göstergesi ya da bfcache gibi optimizasyonlar da CSR yüzünden engellenebilir

    Metin seçimini kendin uygulamaya ancak mobilde parmağı fosforlu kalem gibi kullanan açıklama/not uygulamaları gibi çok özel durumlarda istisna tanınabilir. Hatta ::selection bile kullanılmamalı diye eklemek isterim. Sadece stylesheet'e ::selection{} eklemekle seçili alanın görünmez hale gelebilmesi kötü bir tasarım

    Bağlam menüsünü kendin uygulama yasağına katılmıyorum. E-posta istemcisi, dosya yöneticisi, kelime işlemci gibi uygulamalarda kendilerine özgü öğeler gerekir ve tarayıcı bunları genişletmenin bir yolunu sunmadığı için tamamen özelleştirilmiş menü şu anda pratik bir tercih. Firefox'ta Shift+sağ tık ile native menüyü zorla açabilmek neyse ki iyi

    Kopyala/yapıştırmayı kendin uygulama yasağına ise yoruma göre katılabilir ya da karşı çıkabilirim; daha açık ifade edilmeli

    Teknik demo dışında parola alanını kendin uygulayan bir örnek neredeyse hiç gördüğümü hatırlamıyorum. Göster/gizle düğmesiyle `` tipini password yerine text yapmak bence buna girmez

    Tarih seçiciyi kendin yapmama kuralına da katılmıyorum. Native kontrolü tavsiye etmek isterim ama sınırları ve tutarsızlıkları büyük; son 10 yılda bunları düzeltmeye yönelik ilgi de neredeyse yoktu. Seçiciye ek bilgi koyamıyorsun ve doğum tarihi gibi eski tarihler seçmek bazı platformlarda korkunç. Örnek: Safari's date-picker is the cause of 1/3 of our customer support issues

    Özel tarih seçicilerde çok sayıda erişilebilirlik sorunu var ama çoğu kullanıcı için daha iyi oldukları da sık görülüyor; ayrıca native kontrolde olmayan işlevler gerektiği için kullanılamadıkları durumlar çok. Basit tarih seçiminde, kullandığım tarayıcıda elle giriş yapılabildiği için native'i tercih ediyorum ama birçok kullanıcı için native yeterince iyi değil. Tarih aralığını `` iki adet kullanarak yapmak da çoğu kişi için çok daha kötü olabilir

    • Erişilebilirlik ihtiyacı olan ya da bundan yararlanan insanları “normal insanlar”la karşı karşıya koyan ifadeler bazı okurları dışlayabilir. Erişilebilirlik desteği kullanan insanların deneyim ve ihtiyaçlarını gerçekten önemser görünüyorsun; bu yüzden özellikle belirtmek istedim

    • Safari'nin tarih seçicisini bizzat deneyince ne kadar kısıtlı olduğunu anladım. Ama web sitelerinin neden native tarih seçiciyi bir takvim widget'ı ile değiştirdiğini hep merak etmişimdir

      Takvim widget'ı native widget'ın yanında birlikte sunulamaz mı? İki ayrı giriş yöntemi varmış gibi görünüp UI'ı kafa karıştırabilir ama uygun etiketlemeyle birini gelişmiş tarih seçici diye belirtmek çözüm olabilir gibi geliyor. Böylece native tarih seçiciyi rahat kullananlar kaybedilmez, tarayıcının tarih seçicisi yetersiz kalanlara da yardım edilmiş olur

      Doküman aracı ya da diyagram editörü gibi web uygulamalarında bağlam menüsüne ihtiyaç olduğunu anlıyorum ama sağ tıklayınca tarayıcının normal menüsünün kaybolması yine de rahatsız edici. Bu yüzden Firefox ayarlarında genelde dom.event.contextmenu.enabled = false kullanıyorum. Böyle olunca Firefox menüsü önde, web uygulamasının menüsü arkada açılıyor ama native menü çalıştığı için fena olmayan bir geçici çözüm oluyor. Mümkünse web uygulamasının menü çubuğunu kullanmak ve tarayıcının native bağlam menüsüne dokunmamak daha iyi. Shift+sağ tık ipucu da iyi bir çözüm

    • Erişilebilir kontrollere ihtiyaç duyan insanlar da normal insanlardır

    • Parola alanını kendin uygulama örneğini Peru'daki neredeyse tüm bankalarda görebilirsiniz

      Tarih seçicisinde native kullanmak isterim ama uygulayan tarafta bunu iyileştirmeye ilgi pek yok gibi. Firefox'ta saat/zaman seçimi UI'ı ile ilgili bir sorun var ve ilerlemesi yavaş: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

  • Web formları için iyi bir nokta. Tarayıcıya güvenmek en basit, en hızlı ve neredeyse her zaman en tutarlı yöntem

    Ama kriptografi kodu tarafı farklı. Doğru kripto kodu yazmak kolay değil ama imkânsız da değil. Bazı durumlarda seçenekler o kadar azdır ki kendin yapmak en iyi tercih olabilir

    Burada sorun olan şey, güvenlik ortodoksluğu tarafının yeni kripto kodu yazmak için kendi iç grubuna ait olman gerektiğini varsayma eğilimi. Kriptografi doktoran ya da DJB, Dan Boneh yanında staj geçmişin yoksa kripto kodu yazmaman gerektiği söyleniyor. “Öğrenme amaçlı” tamam ama öğrendiğini gerçek hayatta uygulamaya kalkarsan olmaz deniyor. Hatta bazen dış gruplardaki insanların gerçek yetkinliğini fark etmekte de zorlanıyorlar. İlginç biçimde, bu güvenlik ortodoksluğu ile makale yayımlayan gerçek kriptografların kesişimi çok küçük görünüyor

    Şimdi bu, bellek güvenli olmayan dillerle hiçbir şey yazmamaya kadar genişletiliyor. Kritik açıkların %70'i öyle olsa bile asıl neden neydi? Bence sorunların çoğu, stack'te olmayan her küçük nesne için malloc() ya da açık new kullanmaktan veya null sonlandırılmış string'lerle uğraşmaktan çıkıyordu. Arena ve slice kullansalardı bu tür sorunlar çok daha az olurdu. Elbette bazı yüksek riskli senaryolarda belirli hata sınıflarını tamamen ortadan kaldırmak gerekir; o zaman da bellek güvenliği en önemli önceliktir

    Sıradaki adım ne, güvenilmeyen girdiyi işleyen hiçbir şey yazmamak mı? Elindeki tüm tekerlekler kare olsa da yeniden tekerlek yapma mı diyeceğiz? Yine de JavaScript şişkinliğinden kaçınıp tarayıcının sunduğu formları kullanıyorsan, kendi web framework'ünü yapmayı çok da büyük mesele etmezdim

    • C'nin asli günahı, dizi geçirirken üst sınır bilgisini kaybedip bunun pointer'a indirgenmesi bence

    • “Kendi kriptonu yazma” sözünü mutlak bir yasa değil, güçlü bir uyarı olarak gördüm hep. Doktora olmadan da güvenli biçimde uygulanabileceği doğru ama yine de muazzam bir öğrenme gerektiriyor

      Eğer iş sadece spesifikasyonu dikkatle uygulamaksa bu gereksinim çok daha az olabilir. Ama çoğu yazılım hızlı kripto uygulaması istiyor ve o zaman karmaşıklık ciddi biçimde artıyor. Bağlantı verilen Monocypher açığı da iyi bir örnek. Bir anda twisted equivalence ile Edwards noktalarının ve Montgomery ladder'ın nasıl bağlandığını bilmek zorunda kalıyorsun

      Doktora gibi nitelikler, başkalarının senin ne yaptığını bildiğine güvenmesini sağlar. Denetim de başka bir yol. Monocypher, Cure53'ten iki doktora sahibi kişi tarafından denetlenmiş görünüyor. Sorun şu ki programcıların çoğu bir kripto kütüphanesinin güvenli olup olmadığını değerlendirmeye hazır değil; bu yüzden nitelik ya da denetçinin niteliği gibi teknik olmayan sinyallere dayanıyorlar. Daha doğrudan bir yol olsa iyi olurdu ama nitelikler oldukça iyi iş görüyor

    • Kendi kriptonu yazmanın mümkün olduğu tabii ki açık. İmkânsız olsaydı kripto kütüphaneleri de olmazdı. Esas soru yapılıp yapılamayacağı değil; kullanıcı parolalarını hash'leyen ve kişisel verileri koruyan bir üretim ortamında senin ya da benim elimizle yazdığımız kriptoya güvenilip güvenilemeyeceği. Ben güvenmem

    • Eski iş yerimde eski kod lisans kontrolü için MD5 kullanıyordu ve eski C++ kodunu çalıştıramadığımız bir ortamda doğrulama yapmamız gerektiği için MD5'i yeniden uygulamak zorunda kalmıştım. Mevcut kütüphaneler bulduk ama IV değişimini destekleyen yoktu

    • Kendi kriptomu yazacak cesaretim yok ama güvenlik dünyasının artık kendi kimlik doğrulamanı bile yapma demeye gelmesi biraz aşırı görünüyor

  • Keşke tarayıcı, kendin yapmaya gerek bırakmadan kullanılabilir bir çoklu seçim alanı sunsa

    • Var ama berbat

  • `` iki tane kullanarak başlangıç ve bitiş tarihi almak tarih aralığı için hantal ve sezgisel de değil. Kavramsal olarak tek bir şeyi, görsel olarak ilişkili görünmeyen iki ayrı görünüme bölüyor

    Tarih aralığının olmaması, `` ile ilgili pek çok sorundan sadece biri. Örneğin belirli tarihleri hariç tutamazsın; bu yüzden rezervasyon hizmeti sunan neredeyse her durumda daha başlangıçtan kullanılamaz

    Her yerde tarihleri aynı biçimde kullanmak uğruna iki giriş alanının küçük maliyetine katlanalım görüşünün çoğunlukta olduğundan şüpheliyim. Ortalama kullanıcı alanlardan hoşlanmaz; bir alandan daha kötü tek şey iki alandır. Alışkanlık argümanı da pek ikna edici değil. Benim deneyimimde web'de native tarih girişi nadir

    • Başlangıç ve bitiş tarihi için ayrı ayrı düzgün çalışmayan iki özel takvim widget'ı koyan çok sayıda site gördüm. Kötünün kötüsü

    • Tarih aralığı kısmına ben de katılmamıştım. Tarih aralığını, kavramsal olarak tek bir kontrol olmasına rağmen pratikte ne kadar karmaşık olabildiğini gösteren bir örnek olarak sık kullanırım. “Her zaman native kontrol kullan” sloganı, probleme daha uygun daha iyi bir kontrol sunabildiğin durumlarda kullanıcı deneyimini aslında kötüleştirebilir

      Native ile uygulanamayan tarih/tarih aralığı kontrollerinin yararlı bir özelliği fiyat gösterebilmesi. Uçak bileti ya da otel ararken hangi günlerin daha ucuz ya da pahalı olduğunu tarih seçicinin içinde doğrudan görmek çok faydalı. Native kontrolde bu bilgiyi görmek için çok daha fazla tıklaman ya da ayrı bir tabloya bakman gerekir; oysa özel bir kontrolde her tarihe böyle metadata eklenebilir

      Klasik örnek doğum tarihi girişidir. Tarih seçici genelde varsayılan olarak içinde bulunulan ayı gösterir; istenen tarihle neredeyse ilgisiz olduğu için bu en kötü durumdur. Burada özel kontrol kullanılabilir ama metin kutuları kombinasyonu çoğu zaman daha iyi olur. Tamamen özel bir kontrol olmaktan ziyade native kontrollerin birleşimi gibi ama asıl mesele, her durumu iyi çözen tek bir “her şeye uyan” tarih seçici olmadığıdır

  • Üzerinden birkaç yıl geçti, yeniden kontrol etmem gerekir ama html5 tarih seçicisi yerine kendi çözümümüzü yazmak zorunda kalmamızın can sıkıcı bir sebebi vardı. Bazı tarayıcılardaki `` UI'ı gerçekten berbattı

    Bağlam menüsünü kendin uygulamak nadir gerekir ama gerektiğinde çok yararlıdır. Mesela bir web sayfasının içinde diyagram editörü yapıyorsan, diyagram düğümlerine tıklayıp kullanışlı işlemler yapmak için bir özel bağlam menüsü görmek isterim. Tüm etkileşimleri yalnızca sol tık tabanlı bir UI'a, örneğin eylem paletiyle düğüm arasında gidip gelmeye sıkıştırmak iyi değil

    Listedeki diğer maddelerin geri kalanına ise güçlü biçimde katılıyorum

  • Kriptografi örneğiyle kaydırma davranışı sorununu nasıl birlikte yorumlamam gerektiğinden emin değilim. Bunlar çok farklı alanlar gibi geliyor

    Web sitelerinin gereğinden fazla şey yaptığı genel fikrine katılıyorum. Yalnız o davranış, kullanıcının ve web sitesinin hedeflerine göre değişiyor

    prefers-reduced-motion gibi prefers-user-scroll benzeri bir ayar ara çözüm olabilir mi?

    • Dikey kaydırma alanı uygulamak için scrolljacking kullanmanın haklı bir kullanım senaryosu yok. Böyle kodlar en baştan yazılmamalıydı

      Ama bu yalnızca dikey kaydırma alanı için geçerli. Kaydırmayı kaydırma dışı bir davranışa yeniden eşlediğin durumlarda bazı kullanım senaryoları var; hâlâ çok sorunlu olsalar da dikey yazı sistemlerinde dikeyi yataya eşlemek gibi şeyler tartışılabilir. Bunun dışında da bir iki meşru kullanım alanı olabilir ama gerçek uygulama biçimleri genelde yine yanlış

  • Sayfa kaydırmasını kendin uygulamama fikrine güçlü biçimde katılıyorum. KotlinConf'ta Compose Multiplatform for Web'in kaydırma uygulamasındaki zorlukları anlatan ilginç bir sunum dinlemiştim

    Sorunlardan biri, web tarayıcılarının native uygulamalara göre daha seyrek kaydırma olayı göndermesi ve bu yüzden kaydırma yönü hesaplama algoritmasının başarısız olmasıydı. Tüm noktalardan geçen bir parabol çizip son noktadaki eğimi kullanan bir yöntemdi; nokta sayısı az olunca kaydırma yönü ters çıkabiliyordu

    Başka platformlardan taşırken ya da bu tür etkileşimleri yeniden uygularken, yanlış varsayımlarla başlamak ya da tarayıcının varsayılan sunduğu “garip” davranışları unutmak kolay oluyor

    • Asıl uygulamada bu kaydırma olaylarının ne için kullanıldığını, bunu web bağlamında da neden kopyalamak gerektiğini merak ediyorum. Kaydırmayı bir şeyin sürücü girdisi gibi kullanma fikrine biraz şüpheyle bakıyorum

  • “Platforma yaslan” tavsiyesi doğru ama platformu sürekli takip etmek zor. enterkeyhint ya da inputmode gibi, kabaca varlığını bildiğin ama etkisini unuttuğun şeyler oluyor

    Bu hafta ekibimiz buna yardımcı olmak için [0]'ı yayımladı. Uygulama en iyi pratiklerini skill biçiminde sunuyor. Dokümantasyonu da insanlar için oldukça okunabilir. Örnek: [1]

    [0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…

  • Yazının tonu biraz kaçmış. İnsanların ne zaman ve neden tekerleği yeniden icat etmeleri gerekmediğini yeterince iyi anlamasını sağlayacak şekilde açıklamak çok daha üretken olurdu

    Yazı nedenleri iyi anlatıyor ama “kendin yapma” gibi buyurgan ifade yüzünden zayıflıyor

    “Kendi kriptonu yazma” sloganı da sonuçta dogma gibi hissettiriyor. Bunu söyleme hakkına sahip uzmanlar kim ve onları kim atadı? Bunu söylemeden önce kodun kendisine gerçekten baktılar mı? Heartbleed gibi açıklar bunun gerçekte acemice hatalar olduğunu göstermiyor mu?

    • Onlar hayatlarını kriptografiye adamış insanlar. Kimse onları atamadı; faydalı araştırmalar yayımlayıp alanı bilen kişilerin incelemesinden geçerek bu yetkinliği kazandılar

      Algoritmalar açıktır, incelenir, kamuya açık biçimde saldırıya uğrar, geliştirilir ve standartlaştırılır. Kapalı kapılar ardında olan bir şey değil. Makaleler de açık, kod da açık. İsteyen bakabilir. Sen bakmadın diye kimsenin bakmadığı anlamına gelmez. İnsanlar bakıyor ve kırmaya çalışıyor. Biz bunları saldırılara dayandıkları için kullanıyoruz

      Heartbleed'den çıkaracağın çözüm OpenSSL'i kendin yeniden yazmaksa, senin yazdığın OpenSSL'de gerçek OpenSSL'deki her bir Heartbleed'e karşı elli tane Heartbleed olacağına garanti veririm. Fark şu: gerçek OpenSSL bilen insanlar tarafından inceleniyor, test ediliyor, denetleniyor, saldırıya uğruyor ve düzeltiliyor. Seninki ise özel kalıp yanlış şekilde varlığını sürdürür

    • Mesele, AES çağırmaya korkusuzca cesaret edecek kusursuz bir uzmanın var olması değil. Güvenli çalışan popüler bir wrapper kullanırsan hata olsa bile tek bir yerde bulunup düzeltilebilir olmasıdır

      Yeni bir side-channel attack bulunsa bile buna tek bir yerde yanıt verilebilir. Kendi yaptığın çözüm, yeni saldırıları sürekli takip etmek için tam zamanlı vakit harcamıyorsan bu iyileştirmeleri alamaz

  • Bu biraz da web araçlarını kötü kullanan insanlara yönelik bir yakınma gibi. Kendi uygulamanın meşru olduğu kullanım senaryolarını da ele alsaydı daha ilginç olurdu. O zaman okur “asla kendin yapma” gibi çocuksu bir model yerine gerçekten yararlı bir şey öğrenebilirdi

    Ustalık, kendin yapacak bilgi ve beceriye sahip olmakla, bunu ne zaman yapmaman gerektiğini bilme bilgelikini birlikte taşımaktır

    Yine de şikâyete sempati duyuyorum. Benim de benzer şikâyetlerim oldu. Sorunlardan biri, web etkileşimlerini web geliştiricilerinin kolayca başvurabileceği kadar kapsamlı ve ayrıntılı biçimde belgelemeye yönelik çabanın az olması. Programlamaya komşu bilgilerin yeterince belgelenip sonraki kuşaklara aktarılamaması gibi ciddi bir sorunumuz var; bu yüzden aynı sorunları sürekli yeniden keşfediyoruz. Genelde sektör içinde standart davranışlar ve etkileşim kümeleri kazanan olarak ortaya çıkıyor ama kimse bunları yazıp bırakmıyor