1 puan yazan GN⁺ 2025-02-26 | 1 yorum | WhatsApp'ta paylaş
  • Illinois FOIA’nın geniş açıklık ilkesi, kamu kurumu veritabanı şeması karşısında sınandı; Chicago CANVAS park cezası bileti veritabanı talebi dava ve yasama tartışmalarına yol açtı
  • FOIA, mevcut bilgilerin açıklanmasını güçlü biçimde güvence altına alıyor, ancak yeni kayıt oluşturmayı zorunlu kılamıyor; bu yüzden veriler uygulamaların içinde oldukça, hangi sorguların isteneceğini gösteren şema daha önemli hale geliyor
  • Chicago, CANVAS şemasının güvenliği tehdit ettiğini savundu; davanın özü, şema açıklanmasının SQL Injection saldırılarını gerçekten mümkün kılıp kılmadığı veya kolaylaştırıp kolaylaştırmadığıydı
  • İlk derece ve temyizde açıklama tarafı kazansa da Illinois Supreme Court, file layout kavramını başlı başına istisna kapsamında görerek SQL şemasının da buna girdiğine hükmetti
  • Şu anda Illinois kamu kurumları veritabanı şemalarının açıklanmasını reddedebiliyor; SB0226 ise başvuru sahiplerinin belirli veritabanı sorguları isteyebilmesi için veritabanı yapısının açıklanmasını zorunlu kılmayı amaçlıyor

Illinois FOIA’nın veritabanları karşısında yaşadığı sorun

  • Illinois FOIA, kamu kurumlarının topladığı bilgileri kural olarak kamu malı sayıyor ve istisnaları sınırlı tutuyor
    • Başvuru sahiplerinden genellikle ücret alınmıyor
    • Kamu kurumları talep sayısını kolayca sınırlayamıyor
    • Yanıt süresi varsayılan olarak 5 gün; yazılı uzatma talebi varsa buna 5 gün daha eklenebiliyor
    • Haksız ret kararına karşı dava açılırsa avukatlık ücretlerinin geri alınması mümkün olabiliyor
  • Büyük sınırlama, FOIA ile kamu kurumlarının yeni kayıt oluşturmasının zorunlu tutulamaması
    • İstenen rapor zaten varsa talep edilebiliyor
    • Yoksa ham veriyi isteyip bunu kendiniz derlemeniz gerekiyor
  • Kamu kurumu bilgileri dosya dolapları, paylaşımlı sürücüler ve Word belgeleri yerine giderek daha fazla özelleşmiş uygulamalar ve veritabanları içinde tutuldukça şemanın değeri artıyor
  • Veritabanı şeması, çeşitli tabloların adlarını ve her tablodaki sütun adlarını içeren yapıdır
    • Yazıda bu, birden fazla sekmesi olan bir Excel dosyasına benzetiliyor
    • Her sekmenin adı ve sekmedeki başlık satırı şemaya karşılık geliyor

Matt Chapman’ın CANVAS şeması talebi

  • Matt Chapman, kapsamlı FOIA başvurularını veri gazeteciliği için kullanan bir civic hacker olarak tanıtılıyor
  • Chicago park cezası verileri üzerinde çalışırken CANVAS adlı sistem ortaya çıkıyor
    • CANVAS, Chicago’daki tüm park cezası verilerinin bulunduğu merkezi depo
    • Matt Chapman, CANVAS veritabanında nelerin bulunduğunu anlamak için şemayı FOIA kapsamında talep etti
  • Chicago, Illinois FOIA’daki otomatik veri işleme istisnasına dayanarak talebi reddetti
    • İlgili hüküm; yazılım, işletim protokolleri, program özetleri, file layouts, kaynak listeleri, modüller, kullanıcı kılavuzları, mantıksal ve fiziksel tasarım belgeleri, personel el kitapları gibi unsurları kapsıyor
    • Açıklanması halinde sistem veya veri güvenliğini tehdit edebilecek bilgiler de istisna olarak sayılıyor
  • Chicago, Matt Chapman’a “hacker” diyerek CANVAS şemasının yanlış ellere geçmesi durumunda şehir için risk oluşturabileceğini savundu

Duruşmadaki temel teknik tartışma: SQL Injection

  • Davanın merkezindeki soru, CANVAS şemasının açıklanmasının SQL Injection saldırılarını mümkün kılıp kılmadığıydı
  • SQL, birçok programın veritabanlarıyla iletişim kurmak için kullandığı dildir; SQL Injection ise SQL kullanan programlarda ortaya çıkabilen bir güvenlik zafiyetidir
  • SQL Injection, uygulama kodundaki SQL sorgu şablonuna kullanıcı girdisi hatalı biçimde yerleştirildiğinde oluşur
    • Örnek olarak, adı tırnak içine alan bir sorguda Bob O’Connor gibi tırnak içeren bir giriş veritabanının yorumunu karıştırabilir
    • Saldırganlar bu tür giriş noktalarını kullanarak girdinin geri kalanını kod gibi çalıştırabilir
  • Chicago’nun CISO’su Bruce Coffing, şemanın açıklanmasının saldırganlara üç açıdan yardımcı olacağını savundu
    • Zafiyetleri bulmalarını sağlar
    • Zafiyet araştırmalarını daha gizli hale getirir
    • Saldırmaya değer uygulamaları seçmelerine yardımcı olur
  • Karşı argüman ise şemanın SQL Injection zafiyetlerinin bulunduğu yer olmadığı noktasına odaklandı
    • SQL Injection zafiyetleri, veritabanı şemasında değil, uygulama kaynak kodundaki SQL sorgu şablonlarında aranır
    • Talep edilen şey kaynak kodu değil, tabloların başlık satırlarına daha yakın olan şemaydı
    • Saldırganlar SQL Injection yoluyla şemayı zaten elde edebilir; bu nedenle şema, saldırının önkoşulundan çok saldırının çıktısına yakındır

İlk derece ve temyiz kararları

  • İlk derecede Matt Chapman tarafı kazandı
    • Chicago hemen temyize gitti ve Matt Chapman CANVAS şemasını alamadı
  • Temyiz mahkemesi, asıl olgusal değerlendirmeyi ilk derece mahkemesinin yaptığı varsayımıyla hukuki meseleleri ele aldı
  • Açıklamanın yaratacağı risk bakımından “would jeopardize” ölçütü tartışma konusu oldu
    • “could”, bir şeyin gerçekleşebileceğinin hayal edilebilir olduğu düzeyi ifade eder
    • “would” için hukuki ölçüt, yargıca makul şüphe bırakmayacak kadar açık zarar kanıtı olarak açıklandı
    • Temyiz mahkemesi, zarar olasılığının çok yüksek olması gerektiği yönünde değerlendirme yaptı
  • Temyiz mahkemesi ayrıca istisna hükmündeki sınırlayıcı ifadenin yalnızca “any other information” ibaresine mi, yoksa istisnanın tamamındaki “Administrative or technical information” ifadesine mi bağlandığını inceledi
    • Yalnızca “any other information”a bağlıysa file layouts gibi kalemler kendi başına istisna kapsamına giriyor
    • Tüm istisnaya bağlıysa, açıklamanın güvenliği tehdit etmediğine dair olgusal tespit nedeniyle Matt Chapman tarafı kazanabiliyor
  • Temyiz mahkemesi, sınırlayıcı ifadenin tüm istisnaya uygulandığını kabul ederek Matt Chapman lehine karar verdi

Illinois Supreme Court’ta tersine dönen sonuç

  • Chicago yeniden temyize gitti ve dosya Illinois Supreme Court’a taşındı
  • Illinois Supreme Court, FOIA istisna hükmünün yorumunda temyiz mahkemesinden farklı bir sonuca vardı
    • Sınırlayıcı ifade yalnızca “any other information” için geçerliydi
    • Diğer kalemler ise kendi başına istisna kapsamındaydı
  • Bu yorumla birlikte SQL schema’nın bir file layout olup olmadığı belirleyici mesele haline geldi
  • Şema ile file layout’un teknik olarak farklı olduğu yönünde itirazlar ortaya kondu
    • Aynı SQL schema, birden fazla veritabanı motorunda kullanılabilir
    • Her veritabanı motoru sonuç verilerini altta yatan farklı bir file layout ile yönetir
    • McGraw-Hill Dictionary of Scientific & Technical Terms, 6E, file layout’u “bir dosya içindeki veri düzeninin açıklaması” olarak tanımlar
    • SQL schema ise verinin gerçek düzenini düşünmeyi gereksiz kılan bir soyutlamaya daha yakındır
  • Illinois Supreme Court ayrıca Merriam-Webster Online Dictionary’deki schema tanımını da kullandı: “structured framework or plan: outline”
    • Mahkeme, aradaki farkın yalnızca isimden ibaret olduğuna hükmetti
    • Sonuç olarak şema bir file layout olarak değerlendirildi ve Matt Chapman tarafı davayı kaybetti

Mevcut durum ve SB0226

  • Şu anda Illinois kamu kurumları veritabanı şemalarını açıklamayı reddedebilir
  • Veriler özelleşmiş uygulamalara taşındıkça, temel verilere erişmek için FOIA kapsamında veritabanı sorguları talep etme ihtiyacı daha sık ortaya çıkıyor
  • Veritabanlarının, yerel yönetimlerin kamusal bilgi açıklamasından kaçınabileceği bir güvenli bölgeye dönüşmemesi gerektiği sorunu ortada duruyor
  • SB0226, FOIA metnine kamu kurumlarının yönettiği tüm veritabanı yapıları hakkında yeterli açıklama sağlanmasını zorunlu kılan bir ifade eklemeyi amaçlıyor
    • Amaç, başvuru sahiplerinin kamu kurumlarından belirli veritabanı sorgularını çalıştırmalarını isteyebilmesini sağlamak
  • Bu yasa tasarısı, Matt Chapman’ın bu meseleyi gündemde tutma çabasıyla önemli ölçüde örtüşüyor

1 yorum

 
GN⁺ 2025-02-26
Hacker News yorumları
  • Bu davanın davacısı benim. tptacek’in yazısına eşlik edecek bir yazı üzerinde hâlâ çalışıyorum ve yakında hazır olacak; o zamana kadar soruları burada sorabilirsiniz.
    Beklerken eski yazıya da göz atmanız iyi olabilir: https://mchap.io/that-time-the-city-of-seattle-accidentally-...

    • Matt gerçekten yapılması gereken bir işi yapıyor.
      Ancak Matt’in, ülkenin en üst düzey medeni haklar avukatlarından Loevy and Loevy’nin desteğini almasına rağmen teknik olarak kaybettiğini unutmamak gerekir. Bu, belediye binasına karşı mücadele etmenin ne kadar akıl almaz derecede zor olduğunu gösteriyor; avukatsız yapmaya çalışırsanız durum daha da kötü.
      Bizim lehimize olan şey, yazıda önerildiği gibi yasayı değiştirmek. Eyalet yüksek mahkemesi bir karar verirse, değişiklik yapılmadan iş biter; Illinois’in FOIA yasasını sık sık değiştirmiş bir geçmişi var. Ancak bunların bir kısmı şeffaflığı artırmak yerine bilgileri daha fazla gizli tutma yönündeydi.
      Gerekli olan bir başka değişiklik de bu tür mücadeleleri kaybeden kurumlara ağır yaptırımlar uygulanması. Illinois’te bu, kuruma karşı 5000 dolarlık medeni para cezası gibi bir şeyle sınırlı. Medeni para cezasının ne olduğu bile belirsiz tanımlanmış; eskiden davacıya verilirdi, ama daha sonra mücadele ettiğim davalarda paranın doğrudan ilçeye gitmesine karar verdiler. Bir eyalet savcısının dediği gibi, “kaybetsem de umurumda değil, sadece kendime bir çek yazarım” durumuna dönüşüyor.
      Son olarak, davada ne istediğinize dikkat etmek gerekir. Böyle bir temyiz kararı çıkıp, tam da mücadele ettiğim şeyi hukuka sabitleyebilir. Kimsenin suçu değil ama gerçekten oluyor. Ben de mahkûm haklarını güçlendirmek bir yana, ortadan kaldıran saçma bir karar elde etmişliğim var.
    • Sütun adlarını bilmenin saldırgana yardımcı olmadığı argümanını anlamakta zorlanıyorum. Joker karakterlere izin vermeyen bir veritabanıysa, sütun adlarını tahmin etmek zorunda kalmaktansa '); SELECT col FROM logins yapabileceğini bilmek çok daha kolaylaştırmaz mı?
      Mahkemenin şema ve dosya yerleşimi konusundaki değerlendirmesine de pek itiraz etmek zor. Şema, dosya yerleşiminin kendisi değildir ama benzerdir: “dosyaların” (kayıtların) “dosya sistemi”nde (veritabanı tablosunda) nasıl yerleştirildiğini gösterir. Örneğin denormalizasyon, veriyi dosya kaydının içine inline koymaya çok benzer. Dosya sistemlerinin fiilen veritabanı olduğu görüşü de iyi bilinir. İkisinin benzer olmadığını nasıl savunabileceğinizi merak ediyorum.
    • “CANVAS veritabanındaki tüm tablolardan birer satır” gibi bir talebin mümkün olup olmadığını merak ediyorum.
    • Bu mücadeleye dayanmış olmanız harika. Şeffaflık ancak insanlar rehavete kapılmadığında elde edilebilir.
      Sıradaki adımın ne olduğunu düşünüyorsunuz merak ediyorum.
    • CANVAS yöneticileri neyi saklıyor olabilir?
  • Belediyenin şemayı paylaşması gerektiğini ve esasen belirsizlik yoluyla güvenlik savunması yaptığını düşünüyorum; ancak yazının temel öncülü olan “SQL şemasını bilmek saldırgana yardımcı olmaz” görüşüne katılmıyorum.
    Yazının argümanını şöyle anladım: “Saldırganlar SQL enjeksiyon saldırılarıyla SQL şemasını yeniden çıkarır. Şema saldırının önkoşulu değil, saldırının ürünüdür.” Bu, bir açık bulunursa şemanın da zaten çıkarılabileceği anlamına geliyor gibi görünüyor; ama bu her zaman doğru değil. Bazı SQL enjeksiyonları yalnızca o anda sorgulanan tablodaki verilerin bir kısmını getirebilir, information_schema gibi başka tablolara erişemeyebilir. Açıktan elde edilen sinyal yalnızca “sorgu başarısız” veya “sorgu başarılı, veri döndü” ise, şemayı bilmek istismarı çok daha kolay hâle getirir.
    Başarısız veritabanı sorgularını ayrıca kaydediyorsanız, 24 saat çalışan bir saldırının bulabileceği enjeksiyonları muhtemelen zaten yamamışsınızdır. Bu durumda gerçek enjeksiyon noktası, örneğin yalnızca oturum açmış kullanıcılar için var olan ve botların bulamadığı bir açık keşfedilene kadar loglar gürültülü olmayabilir; o noktada da saldırgan gerçekten nasıl kullanacağını bulmadan önce görüp düzeltmek için zamanınız olur.
    Şemayı bilmek yalnızca açığın istismar hızını artırmakla kalmaz, baştan itibaren sorgu hatası oluşturmadan enjeksiyon arama olasılığını da yükseltir.

    • “SQL şemasını bilmek saldırgana yardımcı olmaz” ölçüt alınacaksa, hizmet adını bilmek de saldırgana yardımcı olur, belediye memurlarının adlarını bilmek de yardımcı olur, park cezasının hukuken ne olduğunu bilmek de yardımcı olur. Dava edildikten sonra devleti hacklemek isteyen biri için kendi davasının ayrıntılarını bilmek de saldırıya yardımcı olur.
      Ölçüt “yardımcı olan tüm bilgileri sansürleyin” değil, “parolaları veya arka kapıları açığa çıkaran kodu yayımlamayın” olmalı. Şema bu kategoriye giremez.
    • Saldırgan değilim, sıradan bir yazılım geliştiriciyim; ama SQL enjeksiyonu varsa şema konusunda işin fiilen bittiğini düşünürüm.
      Yine de tam bir enjeksiyon olmasa bile şemayı bilmenin veri sızıntısına yardımcı olduğu uygulamalarla gerçekten uğraştım. En bariz örnek, URL parametrelerine göre sorgu oluşturup bu parametreleri izin listesiyle sınırlandırmayan durumlardır.
      Bu yüzden şemanın saldırgana küçük de olsa bir avantaj sağlayabileceğine katılıyorum.
    • Yakın zamanda bulunan “YouTube üzerinden e-posta sızdırma” açığının da özünde şema sayılabilecek bir şeyi okumakla başladığını hatırlıyorum.
      https://brutecat.com/articles/leaking-youtube-emails
    • Başarısız veritabanı sorgularını ayrıca kaydediyorsanız ve o “başarısızlık” “SQL enjeksiyonu belirtisi” anlamına geliyorsa, şemayla yapılabilecek hiçbir şey o sinyali azaltmaz. Tek bir SQL sözdizimi hatası bile izlemeye değerdir.
      Bu yüzden bu argümanın geçerli olmadığını düşünüyorum.
    • Blind SQL enjeksiyonu, hata oluşmayan ama ince sinyallerle başarı ve başarısızlığın ayırt edildiği bir türdür. Bildiğim en ilginç örnekte, başarılı enjeksiyonun normal görünen yanıtı başarısız enjeksiyondan 1 bayt daha uzundu; bununla yalnızca şema öğrenilmekle kalmadı, tüm veritabanı tamamen dışarı aktarıldı.
      Sunucu loglarında hataya işaret eden hiçbir şey yoktu.
      Öğrettiğim nispeten giriş düzeyi SQL enjeksiyonu alıştırmalarının çoğu da şema bilinmeden yapılıyordu. SQL enjeksiyonunu bu kadar sinsi ve tehlikeli yapan da bu.
  • Kurt bunu beni oltaya getirmek için paylaşmış. Asıl hedef kitlenin çoğunlukla benim bölgem olan Chicagoland’deki yerel yönetim siyasetiyle ilgilenen teknik olmayan kişiler olduğunu bilmekte fayda var.
    Yerel siyaset için bir kamu spotu yapacak olursam: ulusal siyasete dahil olmak, bir gökdelenin camına çarpan bir sinek gibi kasvetli ve moral bozucu. Buna karşılık yerel siyaset son derece duyarlı. Boş zamanımda ve neredeyse hiç masraf yapmadan gerçek sonuçlar aldım; hatta bir yasanın geçirilmesini bile sağladım. Ulusal siyasetten dramatik biçimde farklı.
    Birçok yerde şaşırtıcı olan şey, yerel siyasetin forumlar etrafında dönmesi. O forumlar bulunmak isteyeceğiniz yerler olmayabilir; özellikle de çok sayıda Facebook Group var, ama buna katlanmak gerekiyor. HN gibi topluluklara katılmaktan hoşlanıyorsanız siyasete de katılabilirsiniz; yalnızca forumlarda aktif olarak bile işlerin olmasını sağlayabilirsiniz.

    • Yerel yönetimlerin yasa yapma yetkisine sahip olduğu bir ülkede yaşamanız da büyük bir etken. Başka birçok ülkede bu böyle değil ya da daha doğrusu yasama yetkileri son derece sınırlı.
      Aslında ABD içinde de bu durum sık görülüyor. Yalnızca home rule yetkisine sahip yerel yönetimler, eyalet ve federal yasalarla çelişmediği sürece herhangi bir konuda yönetmelik çıkarabilir; buna sahip olmayan yerel yönetimler ise yalnızca eyalet meclisinin izin verdiği belirli konularda düzenleme yapabilir. Bazı eyaletler tüm county’lere ve belediyelere home rule verir, bazıları hiç vermez, bazıları ise yalnızca bir kısmına verir. Örneğin Texas’ta bir belediye nüfusu 5000’e ulaştıktan sonra seçmen onayı alırsa home rule yetkisine sahip olabilir.
    • Geçmesine yardımcı olduğun yasanın ne olduğunu biraz daha açıklayabilir misin, merak ediyorum.
      Ayrıca Chicago siyasetine daha fazla dahil olmak isteyen birinin başvurabileceği iyi kaynaklara, Facebook’ta ya da başka bir yerde, bağlantı verebilir misin merak ediyorum. Daha önce aramıştım ama sonuçlar çok sınırlıydı.
    • “Düşünceli ve kendini adamış küçük bir yurttaş grubunun dünyayı değiştirebileceğinden asla kuşku duymayın. Gerçekten de dünyayı değiştiren hep yalnızca bu olmuştur.” - Margaret Mead
    • Böyle forumları nasıl bulmak gerekir, merak ediyorum.
    • Bir zamanlar senin ve Maciej’in seçim kampanyası çalışanlarına FIDO anahtarları dağıtmaya çalıştığınızı hatırlıyorum; gerçekten iç karartıcıydı.
  • Yüksek Mahkeme ile temyiz mahkemesinin cümle yapısı meselesinde ayrışmış olması saçma değil mi? Bunun yaygın bir şey olmasını bir kenara bırakırsak, “tüm dosya yerleşimleri ve diğer öğeler de kapsama girer, ama o diğer öğeler yalnızca kötü olanlarsa” diye yorumlamak bana şahsen akıl almaz geliyor. Hukuk metinlerinin tamamen muğlak kalmasına razı olunması tuhaf.
    Bu tür belirsizliklerin takdir yetkisi kazanan mahkemelerin işine yaradığını da biliyorum; cesur girişimler olsa bile yasa dilini “biçimsel olarak eksiksiz” bir dile dönüştürmenin mümkün olmadığını da biliyorum. Hukukun dağınık olduğunu, hukuku da hata yapan saf insanların yazdığını da biliyorum.
    Yine de yasada yazan temel cümle yapısı mahkemeler için bile açık değilse, bütün sistem ilk kapıda başarısız olmuş sayılmaz mı?

    • Avukat değilim ama yargı sisteminin zaten böyle işlediğini anlıyorum. Dil belirsizliklerle dolu olduğundan, makul insanlar bile karmaşık bir cümlenin tam olarak ne anlama geldiği konusunda farklı düşünebilir. ABD Anayasası’nın tam olarak ne söylediği konusunda da yazıldığı günden beri tartışma var ve hâlâ çok sayıda görüş ayrılığı bulunuyor.
      Genelde yanıt, yasaların muğlak olmayacak şekilde yazılması gerektiğidir; ama bunu söylemek yapmaktan kolay. Üstelik yasa koyucuların kendileri de bazen tam olarak uzlaşamadığından, mahkemelerin yorumlaması için bazı ifadeleri kasıtlı olarak belirsiz bırakabiliyorlar.
    • Bu tür ihtilaflar, birden fazla temyiz mahkemesi kademesinin var olmasının nedeni gibi geliyor. “Dosya biçimi” kısmı gerçekten aptalcaydı ve yanlış değerlendirildi; ama “if disclosed” ifadesine ilişkin hukuki yorumun nihai ve tutarlı bir karara bağlanması gerekiyormuş gibi görünüyor.
  • Kaynak kodu istisnasının doğrudan metne girmiş olması konusunda biraz şaşıran ve endişelenen yalnızca ben miyim?
    Belediyenin belirli bir yazılımı kurum içinde geliştirdiği ve istenmeyebilecek “önyargıları” ya da başka unsurları kaynak koda gizlediği bir senaryoyu kolayca hayal edebiliyorum.
    Hatta her şeyi sıfırdan yapmaları da gerekmez. İzin verici lisanslı üçüncü taraf bileşenleri yamalayıp kullanmaları yeterli olabilir.
    Bence önerilen değişiklik yeterince ileri gitmiyor.

    • Bence şaşırtıcı değil.
      Kapalı projeleri açık kaynağa dönüştürmeye çalışanların yaşadığı sorunla aynı. Geliştiricilerin ve müşterilerin yalnızca kullanma hakkına sahip olduğu, kaynak kodunu paylaşma hakkına sahip olmadığı tescilli kod her yere kilitlenmiş durumda.
      Devlet yüklenicileri gibi doğrudan ticari çıkarı olmayan ve baştan güçlü bir açık yaklaşım ile oluşturulmuş projeler bile bu sorunla karşılaşabilir. Linux çekirdeğinin ZFS’i ya da çekirdek/kullanıcı alanındaki binary blob sürücüleri desteklerken yaşadığı sorunlar iyi biliniyor[1].
      İşin ironik yanı, bir yandan bilgi özgürleşmek istiyor; ekonomik açıdan ise açık kaynak yazılım zamanla kapalı rakiplerini geride bırakacak. Ama bir projeyi açık kaynağa dönüştürmek başlı başına pahalı ve bazen kaldırılamayacak kadar zor olduğundan, yöneticiler ve şirketler istese bile eski araçların yayımlanmasını engelliyor. Hukuk ekibini işin içine katmak ve her bileşenin hak sahiplerini bulmak bile çoğu yöneticinin pes etmesine yetiyor.
      Devlet, sözleşmelerde tedarikçilerin tüm bağımlılık ağacında yalnızca açık kaynak bileşenler kullanmasını şart koşarsa maliyet çok yükselebilir. Çünkü birçok bağımlılık için eşdeğer bir açık kaynak alternatif yoktur ya da kapalı alternatifin işlevleri eksik olduğundan bu işlevleri tamamlamak için bütçe gerekir. Kısa vadede hiçbir meclis böyle bir ek maliyeti kabul etmez; ama uzun vadede kamu bundan fayda görür.
      [1] Çekirdek meselesinin büyük ölçüde GPL’in bir fonksiyonu olduğu doğru. Apache 2 ya da MIT gibi daha izin verici lisanslarda böyle bir sorun olmazdı; BSD türevleri de ZFS desteğinde zorluk yaşamadı. Ancak kamu uygulamalarının hükümet tarafından ilke olarak açık kaynak yapılması gerektiği görüşü, lisans açısından MIT’den çok GPL’e yakındır. Aksi halde tedarikçi gerçekten önemli kısımları “vendor edilmiş” binary blob kod olarak getirip, yayımlanan bileşenlerde yalnızca anlamsız bir iskelet bırakarak gerekliliği karşılayabilir.
    • Teorik olarak, koda böyle bir önyargı koyma kararının kendisi kamuya açık bilgi olmalı. Yazılımın hangi kriterlere göre yapıldığını talep edebilirsiniz; talep edemeyeceğiniz şey yalnızca yazılımın kendisidir.
      Ancak böyle bir karar caydırıcı etki yaratabilir.
    • Bu yüzden AB’deki bazı ülkelerin ilerletmeye çalıştığı kamu parası - açık kaynak türü inisiyatifleri zorlamak önemli.
      Hatırladığım kadarıyla, Almanya’nın artık başarısız olmuş önceki koalisyon hükümeti bunu vaatlerine koymuştu ama uygulayamadı. Yeni hükümet belki yapar.
  • Çok ilginç bir yazı
    Şemanın açıklanmasını korunması gereken bir şey olarak görmek saçma görünüyor. Anlatıldığı gibiyse, “veritabanının içinde olduğu için hiçbir şey bilinemez; onu nasıl bulacağını söyleyemiyorsan işin bitti” gibi sihirli bir sonuç mümkün oluyor
    Çok müşterisi olan küçük bir şirkette çalışan biri olarak veritabanı şemasını olduğu gibi vermek istemem ama yine de müşterinin istediği veriyi bulup sağlamaya çalışırız, reddetmeyiz

    • Özel bir şirketin veritabanı şemasını açıklamak istememesi, rakiplerin şirketin işleri nasıl yaptığını görmesinin onlara avantaj sağlayacak olmasındandır. Devlet veritabanları için bu mantık geçerli değildir
  • cleartap.com projesi için ABD su kalitesi veritabanı belgelerinin 1 milyondan fazla sayfasını FOIA kapsamında talep ettim
    Çoğu eyalet belgeleri toplamak için yalnızca küçük bir ücret istedi
    Michigan, FOIA talebi için 50 bin dolar istedi. Bunun Flint kurşun kirliliği olayı yüzünden olduğunu düşünüyorum. Sanırım beni vazgeçirmeye çalıştılar

    • Flint verileri oradaymış; gerçekten o parayı ödeyip ödemediğini merak ediyorum. Ya da haksız derecede yüksek bir fiyat biçildiğinde itiraz süreci gibi bir şey olup olmadığını merak ediyorum
      Proje harika
  • “Bob O’ya kesilen tüm park cezası verilerini getir; ayrıca veritabanındaki geri kalan tüm bilgileri ve herkesin parolasını da getir.”
    Bu, düz İngilizceyle yazılmış bir SQL enjeksiyonu örneği; burada “everyone's” ifadesinin de ortada kalan tek tırnak oluşturması açısından sorunlu olduğunu belirtmek gerekir. “Bob O'Conner” kötüyse “everyone's” de kötüdür

  • “Çalıştırdıkları programların kaynak kodu da genelde FOIA kapsamında talep edilemez.”
    Ne yazık ki bence bu kısmın FOIA kapsamında hukuka aykırı olması gerekir
    Kaynak kod açık kaynak olmalı ve doğrulanabilir olmalıdır. FOIA istisnası olması, devletin yazılım kullanımına yönelik kamu güvenini baypas eder
    Mahkemelerin bu tür meseleleri daha önce nerede ve nasıl değerlendirdiğini merak ediyorum

    • Güçlü bir kamu yararı argümanı olsa bile, devlet kurumlarının kaynak kodun açıklanmasını toptan engelleme eğiliminin şirketlerle aynı temel nedenden kaynaklandığını düşünüyorum. Yani parola, token, IP adresi gibi hassas bilgilerin, 12 faktörlü uygulama yaklaşımından uzak kodlarda hard-coded olarak bulunma ihtimali çok yüksek; bu hassas bilgiler sızarsa güvenlik ve sorumluluk sorunları çok büyür
      Devlet kurumlarının gizli tutmak isteyebileceği ve hukuken de buna izin verilen iş mantığı da gerçekten olabilir. Özgün yazıdaki park cezası veritabanı söz konusuysa, o veritabanıyla iletişim kuran yazılımın kaynak kodunda park görevlilerinin ne zaman ve nerede “rastgele” yoğun denetim yapacağını seçen mantık bulunuyor olabilir
  • Bu tür şeyler yüzünden hukuk fakültesine gitme isteğim kırıldı. Davaların önemli bir kısmı kabuki tiyatrosu gibi; adil ya da mantıklı sonuçlara ulaşmaya yönelik bir retorik değil, yetkili kişinin duruşmadan önce zaten vermek istediği karara bahane sağlayan bir retorik gibi görünüyor

    • Bu olay da öyle geliyor. Özellikle gözüme çarpan, “yalnızca biraz değeri var” ifadesini “benmerkezci forum tarzı bir çekince” diye nitelemesiydi. Aslında bu ifade basitçe doğru da; ama yazar, “biraz” kelimesi ve uzun açıklama retorik açıdan “yok” demek kadar kullanışlı olmadığı için bunun söylenmemesi gerektiği sonucuna varmış gibi
      Birileri, HTTP isteklerinde gelen information_schema gibi anahtar sözcükleri ve bunların kodlanmış varyantlarını tarayan web güvenlik duvarı benzeri bir sistemi meşru biçimde kurabilir. Bunlar her zaman hackleme girişimi sayılıp engellenebilir. Şemayı zaten biliyorsanız, sorgu oluşturmak için önce bu kısıtı aşmanız gerekmez. Bunun ciddi bir engel olma olasılığı yüksek mi? Hayır. Bunun benmerkezcilikle ilgisi var mı? Öyle görünmüyor
      Yalnızca “marjinal”, yani esas mesele olmayan ve tartışılacak kadar önemli sayılmayan bir anlamda çok az değeri olduğunu söylemek doğru görünüyor. Ama yalnızca gerçeği söyleyince karşı taraf bunu büyütüp “bakın, karşı tarafın uzmanı da değeri olduğunu söylüyor” diye mahkemeyi ikna etmeye çalışıyor. Bu yüzden uzman, sadece “değeri yok” demeliydi sonucuna varılıyor. Bence bu söz yanlış olurdu; ama o kadar önemsiz derecede yanlış ki karşı tarafın tamamen haklı olmadığını kanıtlamak zorlaşıyor. Sonuçta bu mahkemede daha az doğru ifade daha avantajlı hale geliyor ve retorik, uzmanlık rolü kadar önemli oluyor