Bilgisayarın doğru çalıştığı varsayımı
(emptycity.substack.com)- Birleşik Krallık’taki Post Office Horizon kovuşturma skandalı, modern Britanya’nın büyük ölçekli adli hata örneklerinden biri olup, yalnızca bireysel ve kurumsal başarısızlıkları değil, hukuk ve mahkeme süreçlerinin nasıl bir rol oynadığını da gösteriyor
- Mahkemeler, aksi yönde kanıt yoksa mekanik bir cihazın normal çalıştığını varsayar; bu başlangıç noktası bilgisayar kayıtlarına da uygulanır
- Bu tür bir delil karinesi altında, yalnızca bilgisayar kayıtlarıyla muhasebe açığı gibi olgular kanıtlanabilir ve sanığın hatayı kanıtlamak zorunda kaldığı bir yapı oluşur
- 1984 tarihli Police and Criminal Evidence Act’in Section 69 maddesi, savcılığın bilgisayarın normal çalıştığını göstermesini gerektiren ters yönde bir kural getirmişti; ancak 1999’da kaldırıldı
- Section 69 yürürlükte kalmış olsaydı, Post Office kovuşturmalarının yürütülme biçimi farklı olabilirdi; kaldırılmasından sonra yük yeniden sanığın tarafına geçti
Post Office Horizon skandalı ve hukuk süreçlerinin sorumluluğu
- Post Office prosecutions scandal, modern Britanya’nın en büyük ölçekli adli hata vakalarından biri olarak görülüyor
- Olayda kişisel ve kurumsal başarısızlıklar iç içe geçmiş durumda; hukuki belgeler ve deliller de çok kapsamlı olduğu için bütünü kavramak zor
- Mr Justice Fraser’ın 2019 tarihli temel kararı, ekler hariç 1.000’den fazla paragraftan oluşuyor
- Nick Wallis’in konuyla ilgili kitabı ve resmî soruşturma, olayların gelişimini ve tekrarını önleme yollarını izliyor
- Pek çok analiz Post Office yönetiminin, avukatların ve yazılım sağlayıcısı Fujitsu’nun başarısızlıklarına odaklanıyor
- Ancak uygulanan hukuk ve usuller de olayın bir parçasıydı; karar vericilerin bunların sanıklar için sert sonuçlar doğurabileceğini bildiği ya da bilmesi gerektiği düşünüldüğünde, sorumlulukları hafiflemez
“Bilgisayar normal çalışır” delil karinesi
- Hukukçuların söz ettiği karine (presumption), aksi yönde kanıt yoksa mahkemenin belirli bir durumu varsayılan değer olarak kabul etmesini sağlayan bir araçtır
- Klasik ifade şudur: “Aksi yönde kanıt yoksa mahkeme, mekanik bir cihazın ilgili zamanda normal durumda olduğunu varsayar”
- Buradaki mekanik cihaz kapsamına bilgisayarlar da girer
- Bu karine, mahkemenin her koşulda bilgisayara mutlaka güvendiği anlamına gelmez; delille çürütülebilecek bir başlangıç noktasıdır
- Aksi durum kanıtlanmadığı sürece mahkeme bu durumu olgu olarak kabul edebilir
Karineye neden ihtiyaç duyulur ve riski nedir
- Mahkemelerin karine kullanması başlı başına sorun değildir; karineler olmasa pek çok davayı pratikte yürütmek zorlaşır
- Karine, davadaki uyuşmazlık konularını yönetilebilir bir çerçeveye daraltır
- Bir sözleşme, sahte olduğu kanıtlanmadıkça hileli bir belge olarak görülmeyebilir
- Sanık, akıl hastası olduğu kanıtlanmadıkça akıl hastası değilmiş gibi ele alınabilir
- Asıl mesele, hangi durumun varsayılan değer olduğu ve bu varsayılan değeri hangi tarafın çürütmek zorunda kaldığıdır
- Karinenin içeriği gerçekçi değilse ya da çürütme koşulları aşırı zorsa, karine adalete yardımcı olan bir araç değil, adli hataya yol açan bir araç hâline gelir
Bilgisayar kayıtlarının mahkûmiyetin önkoşulu hâline geldiği yapı
- Bilgisayarın normal çalıştığını kabul eden kural, bir delil karinesidir
- Mahkeme, bilgisayarın düzgün çalışmadığına dair kanıt yoksa, yalnızca bilgisayar kayıtlarıyla ilgili olgunun kanıtlandığını kabul edebilir
- Örneğin bilgisayar kaydı bir postane müdürünün ya da postane çalışanı kadının mali açığını gösteriyorsa, mahkeme bunu gerçek açığın kanıtı olarak kabul edebilir
- Bu öncülü sarsmak için sanığın bilgisayarın normal çalışmadığını göstermesi gerekir
- Kovuşturmanın temel delili bilgisayar kayıtları olduğunda yapı, sonuçta “computer says guilty” hâline gelir
Section 69’un getirilmesi ve kaldırılması
- Bu delil karinesi her zaman aynı yönde işlememiştir
- 1984’te kabul edilen Police and Criminal Evidence Act 1984 Section 69, karinenin yönünü tersine çevirdi
- Section 69 kapsamında bilgisayar hatasını sanığın göstermesi değil, savcılığın bilgisayarın normal çalıştığını göstermesi gerekiyordu
- Bu madde, “aksi yönde kanıt yoksa mekanik bir cihazın normal durumda olduğu varsayılır” şeklindeki mevcut common law yaklaşımının yerini aldı
- Post Office, postane müdürlerini ve kadın postane çalışanlarını kovuştururken Section 69 yürürlükte olsaydı, davaların seyri farklı olabilirdi
- Section 69 1999’da kaldırıldı ve önceki common law karinesi geri geldi
- Bundan sonra savcının önce bilgisayarın normal çalıştığını göstermesi değil, sanığın bilgisayarın normal çalışmadığını göstermesi gereken bir yapı oluştu
- Section 69’un nasıl kaldırıldığı ve gerekçesinin geçerli olup olmadığı, devam yazısının konusu olarak kalıyor
1 yorum
Hacker News yorumları
Post Office skandalına en son baktığımda edindiğim izlenim, “IT sistemine fazla güvendik” sözünün daha çok kullanışlı bir mazeret olduğuydu.
Üst yönetim sorunu gayet iyi biliyor, masum insanları kovuşturduklarını da biliyor, buna rağmen kendi başarısızlıklarını örtbas etmek için işi sürdürüyormuş gibi görünüyordu. Öyleyse ciddi hapis cezaları gerekir. Adaleti engellemek hafif bir suç değil; ayrıca Paula Vennells’ın parlamentoda bilerek yalan söylediğine dair iddialar da var.
Bu yüzden Post Office yönetim kurulunun, ırkçılık nedeniyle ipuçlarını birleştirmesini engelleyen psikolojik bir bariyeri vardı; yüzlerce haksız mahkûmiyet gibi ezici kanıtlarla karşılaştıktan sonra bile ahlaki bir duruş göstermeyip aksine daha da direndiler. Bu aynı zamanda üzücü bir teknoloji başarısızlığı hikâyesi, ama İngiltere’deki yönetim kurulu kültürüne yönelik bir suçlama da. Bu felaketi Private Eye dergisi 10 yılı aşkın süredir takip ediyor.
Bu yetkiyi yapısal olarak ortadan kaldırmayı savunmak daha doğru olmaz mı?
Hayatım boyunca bug düzeltmiş biri olarak, bilgisayar sistemlerinin überhaupt çalışıyor olması bile çoğu zaman şaşırtıcı geliyor.
Post Office’in başarısız sistemiyle benzer bir şeyi kişisel olarak da yaşadım; kanıt sunsam bile herkes bilgisayar sisteminin hatalı olabileceği ihtimalini reddetti. Çünkü bunu anlamaya çalışıp derinine inmek çok zahmetliydi.
Yazılımın nasıl üretildiğini gördüğüm için, her şeyin nasıl olup da çalışabildiğini anlamıyorum. Bu paradoksa benim yanıtım şu: Aslında her şey çalışmıyor. Çalışmayan şeyleri başka bir şey olarak kabul etmeye kendimizi eğitmişiz. İnsanlar bilgisayar sistemlerini ya her şeyi bilen, yanılmaz varlıklar olarak görüyor ya da tam tersine günah keçisi muamelesi yapıyor.
Örneğin TAP, Vueling, KLM gibi havayolu web sitelerini son 2 yılda kullandığımda, bilet ayırtmayı ya da hesaba giriş yapmayı engelleyen bug’larla sık sık karşılaştım; çalışmadıkları zamanların daha fazla olduğunu düşünüyorum. Instagram ve Google hesapları belirgin bir neden olmadan otomatik olarak devre dışı bırakıp durdu; Instagram’da iki ay içinde 3 kez yaşadıktan sonra vazgeçip kullanmayı bıraktım. Skype kullananlar için açıklamaya gerek yok; Teams ise ne kadar “güncelleme” alırsa alsın, sessize alma düğmesinin gerçekten sessize almaması, sohbette yazarken cümledeki harf sırasının tersine dönmesi, görüşme sırasında birden kapanıp yanıt vermemesi gibi şaşırtıcı şekillerde başarısız oluyor. Bu tür verimlilik kaybı dünya genelinde ciddi boyutta olmalı; şirketlerin boşa harcadığı iş gücü maliyetinin Microsoft’a ödedikleri lisans ücretlerinden büyük olması muhtemel. Telegram harici monitörleri düzgün yönetemediği için ölçekleme bozuluyor ve yeniden başlatmak gerekiyor; iCloud ise tüm cihazlar iyi bağlantıdayken bile dosya senkronizasyonu için birkaç saniyeden yaklaşık bir saate kadar zaman harcıyor.
Sürekli aksi kanıtları görseler de böyle; ama bir mühendis olarak bunun doğal ve verimli olduğunu düşünüyorum. Öncelikleri belirlemek gerekiyor ve bazı bug’lar diğerlerinden daha az önemli. Tüm yazılımlardaki tüm bug’ları düzeltmektense eğitime, sağlığa ve temel araştırmalara daha fazla çaba harcamanın daha iyi olduğunu düşünüyorum.
Bu yüzden vakaların %1’inde başarısız olmaya başladıklarında bile insanlar, önceki %99’da çalışmış olmasına dayanarak bunu görmezden geliyor. Sonuçlara güvenmeye eğitildikleri için şüphe duymak akıllarına bile gelmiyor. Systemantics adlı kitabı hatırlatıyor: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
O kitabın temel önermelerinden biri, “sistemler yaptığını söylediği şeyi fiilen yapmaz” şeklindeki operasyonel yanılgıdır. Bunu sadece insanlar değil, mühendisler de sık sık unutur. Bir sistem X yaptığını söylüyor diye gerçekten X yaptığı anlamına gelmez. Karmaşık IT sistemlerine karşı sağlıklı bir şüphecilik geliştirmek gerekir. Çoğu zaman başarısız olmayabilirler, ama sonunda bir gün mutlaka başarısız olurlar.
En azından bana öyle geliyor.
Bu kovuşturmaların büyük sorunlarından biri, kovuşturma yetkisine sahip tarafın Post Office’in kendisi olmasıydı.
Bu olaydan önce Post Office’in böyle bir yetkisi olduğunu bilmiyordum. Fiilen Post Office hem şikâyetçi hem de kovuşturma makamı rolünü üstlenmiş oldu. “Post Office Investigation Branch (IB), dünyanın en eski tanınmış suç soruşturma kuruluşudur. 335 yılı aşkın süredir postayla ilgili suçları tespit edip faillerini kovuşturuyor.”
https://www.postalmuseum.org/blog/the-post-office-investigat...
Teoride bu, güçlü kişileri hesap vermeye zorlamanın bir aracıdır; ancak çok pahalı olduğu için, neredeyse tüm özel kovuşturmalar pratikte şirketler tarafından açılır.
Bu skandalı ilk kez duydum
Tutarsızlığa yol açan yazılımın ana sorununun ne olduğunu merak ediyorum. Bağlantı kopması gibi bir şey miydi? Wikipedia’da ayrıntı yoktu. Burada buldum: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...
Daha fazlasını okumanızı öneririm ama midenizin sağlam olması gerekir. Bu olayı kurcalayan birçok kişi yakınlarda bir kova arıyor. Gerçekten okuması çok zor şeyler
Büyük sistemlerde geliştirme sırasında neredeyse her zaman hatalar çıkar ama genelde bulunur ve düzeltilir. Burada hatalar bulunmuştu ama düzeltilmedi
Benim varsayılan öncülüm, bilgisayarların düzgün çalışmadığı yönünde
Çünkü gerçekten düzgün çalışmadıkları çok fazla durum gördüm. Araba kullanırken de Google Maps’e olduğu gibi güvenmem; rotanın mantıklı olup olmadığını kontrol eder, dönmem söylenen yerdeki yol adını ve çıkış numarasını tekrar gözden geçiririm. Çok kez başıma geldi
Bir programcı olarak deneyimime göre bilgisayarın kendisi genelde doğru çalışır
Donanım hatası olması nadirdir. Ama yazılım her zaman yanılır ve bilgisayar donanımı yalnızca yazılımın ona yaptırdığı şeyi körü körüne yürütür
“Yazılımda düzeltiriz” donanım sektörünün resmî sloganı olsa yeridir
Burada “bilgisayar”, donanım ve yazılımdan oluşan sistemi ifade ediyor; “bilgisayar” sözcüğü de neredeyse her zaman böyle kullanılır. Sorun, mahkemelerin aksi yönde kanıt yoksa bilgisayarın normal çalıştığını varsayması. Yani mahkeme, yalnızca bilgisayar kayıtlarıyla ilgili olgunun kanıtlandığına kanaat getirebilir ve sanık bilgisayarın düzgün çalışmadığını gösteremezse, posta şube müdürünün mali açığı olduğunu kabul eder. Kısacası, bir ceza davasının özü bilgisayar kayıtlarıysa, bu bilgisayarın suçlu dediği anlamına gelir
Çok düşük seviyede donanıma doğrudan dokunan yazılımın bu pürüzleri telafi etmesi çoğu zaman beklenir
Eski bir örnek olarak Intel Pentium CPU’larında piyasaya çıktıktan sonra keşfedilen iki ünlü hata vardı. 1994’te geri çağırmaya yol açan kayan nokta bölme FDIV hatası ve 1997’de keşfedilen, yeniden başlatılana kadar işlemciyi kilitleyen F00F hatası.
https://en.m.wikipedia.org/wiki/Hardware_bug
Genelde çalıştığı için neredeyse her zaman kullanıcı hatası saymak gibi. Ne aramanız gerektiğini bilmiyorsanız, yalnızca bildiğiniz hata örneklerini dışlar ve yukarıdaki yazıdaki gibi korkunç bir yanlış hükme varırsınız
Bu varsayım esas olarak bilgisayarın işletmecisi, zulme uğrayan tarafla aynı tarafta olduğunda sorunlu hale geliyor
Mesele mahkemenin ne varsayması gerektiği olsa da, yazılım geliştiricilerin neyi varsayıp neyi varsaymadığını sormak da değerli
Yazılım geliştiriciler, yaygın kullanılan bir yazılımın düzgün çalıştığını varsayar. GitHub issue’larında pandas hatası 3.500 tane olsa bile JavaSDK’nin ya da pandas kütüphanesinin düzgün çalıştığını düşünürler. Ama daha az bilinen bir kütüphaneyi entegre ediyorsanız veya daha az bilinen bir yazılım kullanıyorsanız, onun çalıştığından daha az emin olursunuz
Yani bu, binlerce kişinin yıllarca şikâyet etmesi anlamında. Daha az alaycı söylersek, yaygın kullanılan yazılımların yaygın kullanılan özelliklerinin gerçek koşullarda test edilmiş olmasını bekleyebiliriz; dolayısıyla hata varsa bile en azından biliniyor olma ihtimali yüksektir. Ama orta karmaşıklıktaki bir yazılımın durum uzayını bile tamamen kapsamak muazzam test gerektirir. SQLite’ın test takımının ne kadar büyük olduğuna bakmak yeterli. Az hatalı yazılım üretmek için iyi işleyen tek yaklaşım, küçük, kendi kendine yeten, yalıtılmış ve iyi anlaşılmış parçaları birleştirerek bütünü akıl yürütmesi daha kolay hale getirmek gibi görünüyor. Bu, aslında Unix’in felsefesi, fonksiyonel programlamanın felsefesi ve asenkron etkileşimleri akıl yürütmesi daha zor olsa da aktör sistemleri felsefesinin bir parçasıdır. Pratikte bu yaklaşımı giderek daha fazla görmeyi umuyorum
Başlık belki de clickbait’in tersine yakın
Yazı Post Office skandalını ele alıyor ve gerçekten büyük bir konuyu yakalamış
Saklama amaçlı bağlantı: https://archive.ph/wip/AJl8i