บันทึกการขึ้นศาลของ SQL Injection

 (sockpuppet.org)
1 คะแนน โดย GN⁺ 2025-02-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลักการเปิดเผยข้อมูลอย่างกว้างของ Illinois FOIA ถูกทดสอบต่อหน้า สคีมาฐานข้อมูลของหน่วยงานรัฐ และคำขอข้อมูลฐานข้อมูลใบสั่งจอดรถ Chicago CANVAS ได้นำไปสู่คดีความและการถกเถียงเชิงนิติบัญญัติ
  • FOIA รับประกันการเปิดเผยข้อมูลที่มีอยู่เดิมอย่างเข้มแข็ง แต่ไม่สามารถบังคับให้ สร้างระเบียนใหม่ ได้ ทำให้ยิ่งข้อมูลอยู่ในแอปพลิเคชันมากเท่าไร สคีมาที่บอกได้ว่าควรขอคิวรีแบบใดก็ยิ่งสำคัญมากขึ้น
  • Chicago โต้แย้งว่าสคีมา CANVAS เป็นภัยต่อความปลอดภัย และประเด็นหลักของคดีคือการเปิดเผยสคีมาจะทำให้การโจมตีแบบ SQL Injection เป็นไปได้จริงหรือทำได้ง่ายขึ้นหรือไม่
  • ในศาลชั้นต้นและศาลอุทธรณ์ ฝ่ายที่ต้องการเปิดเผยเป็นฝ่ายชนะ แต่ Illinois Supreme Court เห็นว่า file layout เป็นข้อมูลที่ได้รับการยกเว้นในตัวเอง และตัดสินว่า SQL schema ก็เข้าข่ายนี้เช่นกัน
  • ปัจจุบันหน่วยงานสาธารณะใน Illinois สามารถปฏิเสธการเปิดเผยสคีมาฐานข้อมูลได้ และ SB0226 มีเป้าหมายจะบังคับให้ให้ คำอธิบายโครงสร้างฐานข้อมูล เพื่อให้ผู้ขอสามารถร้องขอคิวรีฐานข้อมูลที่เจาะจงได้

ปัญหาที่ Illinois FOIA ต้องเผชิญเมื่อเจอกับฐานข้อมูล

  • Illinois FOIA ถือว่าข้อมูลที่หน่วยงานสาธารณะเก็บรวบรวมเป็นทรัพย์สินสาธารณะโดยหลักการ และข้อยกเว้นมีอย่างจำกัด
    • โดยทั่วไปผู้ขอจะไม่ถูกเรียกเก็บค่าใช้จ่าย
    • หน่วยงานสาธารณะไม่สามารถจำกัดจำนวนคำขอได้โดยง่าย
    • กำหนดเวลาตอบกลับปกติคือ 5 วัน และหากมีคำขอขยายเวลาเป็นลายลักษณ์อักษร สามารถเพิ่มได้อีก 5 วัน
    • หากฟ้องร้องกรณีปฏิเสธโดยมิชอบ ก็สามารถเรียกคืนค่าทนายความได้
  • ข้อจำกัดใหญ่คือ FOIA ไม่สามารถบังคับให้หน่วยงานสาธารณะ สร้างระเบียนใหม่ ได้
    • หากรายงานที่ต้องการมีอยู่แล้ว ก็สามารถขอได้
    • หากยังไม่มี ก็ต้องขอข้อมูลดิบมาแล้วประกอบขึ้นเอง
  • เมื่อข้อมูลของหน่วยงานสาธารณะถูกเก็บอยู่ใน แอปพลิเคชันเฉพาะทางและฐานข้อมูล มากขึ้น แทนที่จะอยู่ในตู้เอกสาร shared drive หรือเอกสาร Word คุณค่าของสคีมาก็ยิ่งเพิ่มขึ้น
  • สคีมาฐานข้อมูลคือโครงสร้างที่มีชื่อของหลายตารางและชื่อคอลัมน์ของแต่ละตาราง
    • ในบทความเปรียบเทียบกับไฟล์ Excel ที่มีหลายแท็บ
    • ชื่อของแต่ละแท็บและแถวหัวตารางของแต่ละแท็บก็คือสคีมา

คำขอสคีมา CANVAS ของ Matt Chapman

  • Matt Chapman ถูกแนะนำว่าเป็น civic hacker ที่ทำ data journalism โดยใช้คำขอ FOIA จำนวนมาก
  • ระหว่างทำงานกับข้อมูลใบสั่งจอดรถของ Chicago ได้พบระบบที่ชื่อ CANVAS
    • CANVAS คือคลังกลางที่เก็บข้อมูลใบสั่งจอดรถทั้งหมดของ Chicago
    • Matt Chapman ขอรับสคีมาผ่าน FOIA เพื่อดูว่าภายในฐานข้อมูล CANVAS มีอะไรอยู่บ้าง
  • Chicago ปฏิเสธคำขอโดยอ้างข้อยกเว้นใน Illinois FOIA ที่เกี่ยวกับการประมวลผลข้อมูลอัตโนมัติ
    • ข้อยกเว้นดังกล่าวครอบคลุมซอฟต์แวร์ โปรโตคอลการปฏิบัติงาน ภาพรวมของโปรแกรม file layouts รายการซอร์ส โมดูล คู่มือผู้ใช้ เอกสารออกแบบเชิงตรรกะและกายภาพ รวมถึงคู่มือพนักงาน
    • ยังระบุด้วยว่าข้อมูลที่หากเปิดเผยแล้วอาจเป็นภัยต่อความปลอดภัยของระบบหรือข้อมูลก็เป็นข้อยกเว้นเช่นกัน
  • Chicago เรียก Matt Chapman ว่า “hacker” และอ้างว่าสคีมา CANVAS หากตกไปอยู่ในมือคนไม่หวังดีอาจเป็นความเสี่ยงต่อเมือง

ประเด็นเทคนิคหลักในศาล: SQL Injection

  • คำถามหลักของคดีคือการเปิดเผยสคีมา CANVAS จะทำให้การโจมตีแบบ SQL Injection เป็นไปได้หรือไม่
  • SQL คือภาษาที่หลายโปรแกรมใช้สื่อสารกับฐานข้อมูล และ SQL Injection คือช่องโหว่ความปลอดภัยที่อาจเกิดขึ้นในโปรแกรมที่ใช้ SQL
  • SQL Injection เกิดขึ้นเมื่ออินพุตของผู้ใช้ถูกแทรกเข้าไปในเทมเพลตคิวรี SQL ภายในโค้ดแอปพลิเคชันอย่างไม่ถูกต้อง
    • ตัวอย่างเช่น ในคิวรีที่ครอบชื่อด้วยเครื่องหมายอัญประกาศ อินพุตอย่าง Bob O’Connor ที่มีเครื่องหมายอัญประกาศอยู่ด้วยอาจทำให้การตีความของฐานข้อมูลสับสน
    • ผู้โจมตีสามารถใช้จุดรับอินพุตลักษณะนี้เพื่อทำให้ส่วนที่เหลือของอินพุตถูกรันเหมือนเป็นโค้ดได้
  • Bruce Coffing, CISO ของ Chicago อ้างว่าการเปิดเผยสคีมาช่วยผู้โจมตีได้ 3 ทาง
    • ช่วยให้หาช่องโหว่เจอ
    • ช่วยให้สำรวจช่องโหว่ได้แนบเนียนขึ้น
    • ช่วยให้เลือกแอปพลิเคชันที่คุ้มค่าต่อการโจมตี
  • ฝ่ายที่เห็นต่างเน้นว่าสคีมาไม่ใช่ที่สำหรับค้นหาช่องโหว่ SQL Injection
    • ช่องโหว่ SQL Injection พบได้จากเทมเพลตคิวรี SQL ใน ซอร์สโค้ดของแอปพลิเคชัน ไม่ใช่จากสคีมาฐานข้อมูล
    • สิ่งที่ถูกขอไม่ใช่ซอร์สโค้ด แต่เป็นสคีมาที่ใกล้เคียงกับแถวหัวตาราง
    • ผู้โจมตีสามารถดึงสคีมาออกมาได้ผ่าน SQL Injection ดังนั้นสคีมาไม่ใช่เงื่อนไขก่อนเริ่มโจมตี แต่ใกล้เคียงกับผลลัพธ์ของการโจมตีมากกว่า

คำตัดสินของศาลชั้นต้นและศาลอุทธรณ์

  • ในศาลชั้นต้น ฝั่ง Matt Chapman เป็นฝ่ายชนะ
    • Chicago ยื่นอุทธรณ์ทันที และ Matt Chapman ก็ยังไม่ได้รับสคีมา CANVAS
  • ศาลอุทธรณ์พิจารณาประเด็นกฎหมายบนสมมติฐานว่าศาลชั้นต้นเป็นผู้พิจารณาข้อเท็จจริงหลัก
  • ความเสี่ยงจากการเปิดเผยขึ้นอยู่กับมาตรฐานของคำว่า “would jeopardize”
    • “could” หมายถึงระดับที่พอจินตนาการได้ว่าสิ่งใดสิ่งหนึ่งอาจเกิดขึ้น
    • มาตรฐานทางกฎหมายของ “would” ถูกอธิบายว่าเป็นหลักฐานอันชัดเจนของอันตรายที่ไม่ทิ้งข้อสงสัยอย่างสมเหตุสมผลไว้แก่ผู้พิพากษา
    • ศาลอุทธรณ์จึงมองไปในทางที่ว่าความเป็นไปได้ของอันตรายต้องสูงมาก
  • ศาลอุทธรณ์ยังพิจารณาด้วยว่าถ้อยคำจำกัดในข้อยกเว้นนั้นผูกอยู่เฉพาะกับ “any other information” หรือผูกกับวลี “Administrative or technical information” ของข้อยกเว้นทั้งชุด
    • หากผูกเฉพาะ “any other information” ข้อมูลอย่าง file layouts ก็จะได้รับการยกเว้นในตัวเอง
    • หากผูกกับข้อยกเว้นทั้งชุด เพียงพิสูจน์ตามข้อเท็จจริงได้ว่าการเปิดเผยไม่เป็นภัยต่อความปลอดภัย ฝั่ง Matt Chapman ก็จะชนะ
  • ศาลอุทธรณ์เห็นว่าถ้อยคำจำกัดนั้นครอบคลุมข้อยกเว้นทั้งชุด และจึงตัดสินเข้าข้าง Matt Chapman

ข้อสรุปที่กลับตาลปัตรใน Illinois Supreme Court

  • Chicago ยื่นอุทธรณ์อีกครั้ง และคดีไปถึง Illinois Supreme Court
  • Illinois Supreme Court ตีความข้อยกเว้นของ FOIA ต่างจากศาลอุทธรณ์
    • ถ้อยคำจำกัดใช้กับ “any other information” เท่านั้น
    • รายการอื่นที่เหลือได้รับการยกเว้นในตัวเอง
  • จากคำวินิจฉัยนี้ ประเด็นว่า SQL schema เป็น file layout หรือไม่ จึงกลายเป็นหัวข้อชี้ขาด
  • มีข้อโต้แย้งว่าสคีมากับ file layout ต่างกันในเชิงเทคนิค
    • SQL schema เดียวกันสามารถใช้กับเอนจินฐานข้อมูลหลายตัวได้
    • เอนจินฐานข้อมูลแต่ละตัวจัดการผลลัพธ์ข้อมูลด้วย underlying file layout ที่ต่างกัน
    • McGraw-Hill Dictionary of Scientific & Technical Terms, 6E ให้นิยาม file layout ว่าเป็น “คำอธิบายการจัดเรียงข้อมูลภายในไฟล์”
    • SQL schema ใกล้เคียงกับนามธรรมที่ถูกออกแบบมาเพื่อไม่ต้องคำนึงถึงการจัดเรียงข้อมูลจริง
  • Illinois Supreme Court ยังใช้นิยามคำว่า schema จาก Merriam-Webster Online Dictionary ว่า “structured framework or plan: outline”
    • ศาลเห็นว่าความแตกต่างมีเพียงชื่อเรียก
    • ผลลัพธ์คือสคีมาถูกมองว่าเป็น file layout และฝ่าย Matt Chapman แพ้คดี

สถานะปัจจุบันและ SB0226

  • ปัจจุบันหน่วยงานสาธารณะใน Illinois สามารถปฏิเสธการเปิดเผย สคีมาฐานข้อมูล ได้
  • ยิ่งข้อมูลย้ายเข้าสู่แอปพลิเคชันเฉพาะทางมากขึ้น ก็ยิ่งมีกรณีที่การเข้าถึงข้อมูลพื้นฐานต้องอาศัยการขอให้หน่วยงานรันคิวรีฐานข้อมูลผ่าน FOIA
  • จึงยังมีปัญหาว่าฐานข้อมูลไม่ควรกลายเป็นพื้นที่ปลอดภัยที่ทำให้รัฐบาลท้องถิ่นหลีกเลี่ยงการเปิดเผยข้อมูลสาธารณะได้
  • SB0226 มีเป้าหมายจะเพิ่มข้อความในกฎหมาย FOIA เพื่อบังคับให้หน่วยงานสาธารณะให้คำอธิบายที่เพียงพอเกี่ยวกับโครงสร้างของฐานข้อมูลทุกชุดที่ตนดูแล
    • จุดประสงค์คือเพื่อให้ผู้ขอสามารถร้องขอให้หน่วยงานสาธารณะดำเนินการ คิวรีฐานข้อมูลแบบเจาะจง ได้
  • ร่างกฎหมายนี้สอดคล้องอยู่ไม่น้อยกับความพยายามต่อเนื่องของ Matt Chapman ที่ผลักประเด็นนี้มาโดยตลอด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-02-26
ความคิดเห็นจาก Hacker News

  • ผมเป็น โจทก์ในคดีนี้เอง บทความประกอบที่จะเขียนคู่กับบทความของ tptacek ก็ยังอยู่ระหว่างเขียน และน่าจะพร้อมเร็ว ๆ นี้ ระหว่างนี้ถามคำถามที่นี่ได้
    ระหว่างรอ ลองอ่านบทความเก่าดูได้: https://mchap.io/that-time-the-city-of-seattle-accidentally-...

    • Matt กำลังทำสิ่งที่จำเป็นจริง ๆ
      แต่ต้องจำไว้ว่า แม้ Matt จะได้รับการสนับสนุนจาก Loevy and Loevy ซึ่งเป็นทนายความด้านสิทธิพลเมืองระดับแนวหน้าของประเทศ เขาก็ยังแพ้ในเชิงเทคนิคอยู่ดี นี่แสดงให้เห็นว่าการสู้กับศาลากลางนั้นยากอย่างไร้เหตุผลแค่ไหน และถ้าจะทำโดยไม่มีทนายก็ยิ่งหนักกว่าเดิม
      สิ่งที่เป็นประโยชน์ต่อเราคือ การแก้กฎหมาย อย่างที่บทความเสนอไว้ ถ้าศาลสูงของรัฐตัดสินไปแล้ว หากไม่มีการแก้ไขก็จบ และ Illinois ก็มีประวัติแก้กฎหมาย FOIA อยู่บ่อยครั้ง เพียงแต่ว่าบางส่วนในนั้นไม่ใช่การขยายการเปิดเผย แต่กลับเป็นการทำให้ปิดข้อมูลได้เข้มงวดยิ่งขึ้น
      อีกการเปลี่ยนแปลงหนึ่งที่จำเป็นคือการกำหนดบทลงโทษที่รุนแรงต่อหน่วยงานที่แพ้ในการต่อสู้แบบนี้ ใน Illinois จำกัดไว้ประมาณ ค่าปรับทางแพ่ง 5,000 ดอลลาร์ ต่อหน่วยงาน ค่าปรับทางแพ่งเองก็ถูกนิยามไว้อย่างคลุมเครือ และเมื่อก่อนเคยจ่ายให้โจทก์ แต่ในคดีหลัง ๆ ที่ผมสู้ กลับให้เงินนั้นไปเข้าคาน์ตีแทน มันเลยกลายเป็นแบบที่อัยการรัฐคนหนึ่งพูดไว้ว่า “แพ้ก็ไม่เป็นไร แค่เขียนเช็คให้ตัวเองก็พอ”
      สุดท้าย เวลาฟ้องร้องต้องระวังสิ่งที่ต้องการ เพราะคำพิพากษาศาลอุทธรณ์แบบนี้อาจออกมาแล้วทำให้เรื่องที่ผมกำลังต่อสู้อยู่ถูกตรึงเป็นกฎหมายไปเลย ไม่ใช่ความผิดของใคร แต่เกิดขึ้นจริง ผมเองก็เคยได้คำพิพากษาเหลวไหลฉบับหนึ่งที่ไม่เพียงไม่ช่วยเสริมสิทธิของผู้ต้องขัง แต่กลับตัดสิทธินั้นทิ้งไปเลย
    • ผมเข้าใจยากกับตรรกะที่ว่า การรู้ ชื่อคอลัมน์ ไม่ช่วยผู้โจมตี ถ้าเป็นฐานข้อมูลที่ไม่อนุญาต wildcard การรู้ว่าสามารถทำ '); SELECT col FROM logins ได้ ไม่ง่ายกว่าการต้องเดาชื่อคอลัมน์หรอกหรือ?
      ผมก็ไม่ค่อยคัดค้านการวินิจฉัยของศาลเรื่อง schema กับการจัดวางไฟล์ด้วย schema ไม่ใช่การจัดวางไฟล์โดยตรง แต่คล้ายกันมาก: มันบอกว่า “ไฟล์” (record) ถูกจัดวางอย่างไรใน “file system” (database table) เช่น denormalization ก็คล้ายมากกับการใส่ข้อมูลแบบ inline ไว้ใน record ของไฟล์ มุมมองที่ว่า file system โดยแท้จริงแล้วเป็น database ก็เป็นที่รู้กันดี ผมสงสัยว่าจะโต้แย้งได้อย่างไรว่าสองอย่างนี้ไม่คล้ายกัน
    • สงสัยว่าคำขอแบบ “หนึ่งแถวจากทุกตาราง ในฐานข้อมูล CANVAS” ทำได้หรือเปล่า
    • น่าทึ่งที่คุณอดทนสู้เรื่องนี้มาได้ ความโปร่งใสจะเกิดขึ้นได้ก็ต่อเมื่อผู้คนไม่ยอมอยู่เฉย
      อยากรู้ว่าคุณมองว่าขั้นต่อไปคืออะไร
    • ผู้ดูแล CANVAS กำลังซ่อนอะไรอยู่กันแน่?

  • ผมคิดว่าเมืองควรต้องแชร์ schema และโดยพื้นฐานแล้วกำลังอ้าง security through obscurity อยู่ แต่ผมไม่เห็นด้วยกับสมมติฐานหลักของบทความที่ว่า “การรู้ SQL schema ไม่ได้ช่วยผู้โจมตี”
    ผมเข้าใจประเด็นของบทความประมาณนี้: “ผู้โจมตีกู้คืน SQL schema ผ่านการโจมตี SQL injection ดังนั้น schema ไม่ใช่เงื่อนไขตั้งต้นของการโจมตี แต่เป็นผลผลิตของการโจมตี” ดูเหมือนจะหมายความว่า ถ้าพบช่องโหว่ ยังไงก็สามารถกู้คืน schema ได้อยู่ดี แต่ไม่ใช่ทุกกรณี SQL injection บางแบบอาจดึงได้แค่ข้อมูลบางส่วนจากตารางที่ query อยู่ตอนนั้น และไม่สามารถดึงจากตารางอื่นอย่าง information_schema ได้ ถ้าสัญญาณที่ได้จากช่องโหว่มีแค่ “query ล้มเหลว” หรือ “query สำเร็จและส่งข้อมูลกลับมา” การรู้ schema จะทำให้ exploit ได้ง่ายขึ้นมาก
    หากมีการบันทึก query ฐานข้อมูลที่ล้มเหลวแยกไว้ injection ที่การโจมตีซึ่งรันตลอด 24 ชั่วโมงหาเจอ ก็น่าจะถูกแพตช์ไปแล้ว ถ้าเป็นเช่นนั้น log อาจยังไม่ส่งเสียงดัง จนกว่าจะพบจุด injection จริง ๆ เช่น ช่องโหว่ที่มีอยู่เฉพาะกับผู้ใช้ที่ล็อกอิน ซึ่ง bot หาไม่เจอ และเมื่อถึงตอนนั้นก็ยังมีเวลาเห็นและแก้ก่อนที่ผู้โจมตีจะหาวิธีใช้ประโยชน์จริงได้
    การรู้ schema ไม่เพียงทำให้ exploit ช่องโหว่ได้เร็วขึ้น แต่ยังเพิ่มโอกาสที่จะสำรวจ injection ได้โดย ไม่ทำให้ query ล้มเหลว ตั้งแต่แรกด้วย

    • ถ้าใช้เกณฑ์ว่า “การรู้ SQL schema ไม่ได้ช่วยผู้โจมตี” งั้นการรู้ชื่อ service ก็ช่วยผู้โจมตีได้ การรู้ชื่อเจ้าหน้าที่เทศบาลก็ช่วยได้ และการรู้ว่าใบสั่งจอดรถผิดกฎหมายคืออะไรตามกฎหมายก็ช่วยได้ คนที่ตั้งใจจะ hack รัฐบาลหลังถูกฟ้อง หากรู้รายละเอียดคดีของตัวเองก็ช่วยการโจมตีได้เหมือนกัน
      เกณฑ์ไม่ควรเป็น “ข้อมูลใดก็ตามที่มีประโยชน์ต้องถูกเซ็นเซอร์ทั้งหมด” แต่ควรเป็น “อย่าเปิดเผย code ที่เผยรหัสผ่านหรือ backdoor” schema ไม่ควรอยู่ในหมวดนั้น
    • ผมไม่ใช่ผู้โจมตี เป็นแค่นักพัฒนาซอฟต์แวร์ธรรมดา แต่ถ้ามี SQL injection อยู่ ผมมองว่าเรื่อง schema นั้นแทบจะจบแล้ว
      ถึงอย่างนั้น ผมเคยทำงานกับแอปพลิเคชันจริงที่แม้ไม่มี injection แบบสมบูรณ์ การรู้ schema ก็ช่วยให้ข้อมูลรั่วได้ ตัวอย่างที่ชัดที่สุดคือกรณีที่สร้าง query จาก URL parameter แต่ไม่ได้จำกัด parameter นั้นด้วย allowlist
      ดังนั้นผมเห็นด้วยว่า schema อาจให้ประโยชน์เล็กน้อยแก่ผู้โจมตีได้
    • นึกถึงช่องโหว่ “อีเมลรั่วผ่าน YouTube” ที่พบเมื่อไม่นานมานี้ ซึ่งโดยเนื้อแท้ก็เริ่มจากการอ่านสิ่งที่มองได้ว่าเป็น schema
      https://brutecat.com/articles/leaking-youtube-emails
    • ถ้าบันทึก query ฐานข้อมูลที่ล้มเหลวแยกไว้ และ “ความล้มเหลว” นั้นหมายถึง “สัญญาณของ SQL injection” แล้ว ไม่ว่า schema จะทำอะไรได้ ก็ลดสัญญาณนั้นไม่ได้ แค่มี SQL syntax error เพียงครั้งเดียวก็ควรค่าแก่การติดตามแล้ว
      ดังนั้นผมคิดว่าตรรกะนั้นใช้ไม่ได้
    • Blind SQL injection เป็นประเภทที่ไม่เกิด error แต่แยกความสำเร็จกับความล้มเหลวด้วยสัญญาณอันละเอียดอ่อน กรณีที่น่าสนใจที่สุดที่ผมรู้คือ response ที่ดูเหมือนปกติจาก injection ที่สำเร็จ ยาวกว่า injection ที่ล้มเหลว 1 ไบต์ และจากสิ่งนี้ไม่เพียงทำให้รู้ schema ได้ แต่ยังดึงฐานข้อมูลทั้งหมดออกมาได้ครบถ้วนด้วย
      ใน server log ไม่มีอะไรที่บ่งชี้ error เลย
      แบบฝึกหัด SQL injection ระดับค่อนข้างเริ่มต้นที่ผมเคยสอน ส่วนใหญ่ก็ทำโดยไม่รู้ schema มาก่อน นั่นแหละที่ทำให้ SQL injection แยบยลและอันตรายขนาดนั้น

  • Kurt โพสต์สิ่งนี้มาเพื่อล่อผมนั่นแหละ ควรรู้ไว้ว่าเดิมทีผู้อ่านเป้าหมายส่วนใหญ่เป็น คนที่ไม่ใช่สายเทคนิค ซึ่งเกี่ยวข้องกับการเมืองท้องถิ่นของเขต Chicagoland ที่ผมอยู่
    ถ้าจะทำประกาศสาธารณะเรื่องการเมืองท้องถิ่น การเข้าไปเกี่ยวข้องกับการเมืองระดับชาตินั้นหดหู่และหมดแรงเหมือนแมลงบินไปชนกระจกตึกระฟ้า ในทางกลับกัน การเมืองท้องถิ่น ตอบสนองได้ดีมาก ผมใช้เวลาว่างกับค่าใช้จ่ายแทบไม่มี แล้วก็สร้างผลลัพธ์จริงได้ ถึงขั้นช่วยผลักดันกฎหมายฉบับหนึ่งให้ผ่าน ต่างจากการเมืองระดับชาติอย่างมาก
    สิ่งที่น่าประหลาดใจในหลายพื้นที่คือการเมืองท้องถิ่นขับเคลื่อนโดยมีเว็บบอร์ดเป็นศูนย์กลาง เว็บบอร์ดนั้นอาจไม่ใช่ที่ที่คุณอยากอยู่ โดยเฉพาะอย่างยิ่งมี Facebook Group เยอะ แต่ก็ต้องยอมรับมันไป ถ้าคุณสนุกกับการมีส่วนร่วมในคอมมูนิตี้อย่าง HN คุณก็มีส่วนร่วมทางการเมืองได้ และแค่ทำกิจกรรมบนเว็บบอร์ดก็ทำให้งานสำเร็จได้

    • การได้อยู่ในประเทศที่รัฐบาลท้องถิ่นมีอำนาจออกกฎหมายก็เป็นเรื่องใหญ่เหมือนกัน ในหลายประเทศอื่นไม่เป็นแบบนั้น หรือพูดให้แม่นกว่านั้นคือมีอำนาจนิติบัญญัติจำกัดมาก
      ที่จริงแม้แต่ในสหรัฐฯ เองก็มีกรณีแบบนี้มากมาย เฉพาะรัฐบาลท้องถิ่นที่มีอำนาจ home rule เท่านั้นที่สามารถออกเทศบัญญัติในหัวข้อใดก็ได้ ตราบใดที่ไม่ขัดกับกฎหมายรัฐและกฎหมายรัฐบาลกลาง ส่วนรัฐบาลท้องถิ่นที่ไม่มีอำนาจนี้จะออกได้เฉพาะหัวข้อที่สภานิติบัญญัติของรัฐอนุญาตเท่านั้น บางรัฐให้ home rule แก่ทุกเคาน์ตีและเทศบาล บางรัฐไม่ให้เลย และบางรัฐให้เฉพาะบางแห่ง ตัวอย่างเช่นใน Texas เทศบาลจะมีอำนาจ home rule ได้เมื่อมีประชากรถึง 5,000 คนแล้วได้รับการอนุมัติจากผู้มีสิทธิเลือกตั้ง
    • อยากรู้ว่าคุณช่วยอธิบายเพิ่มเติมได้ไหมว่ากฎหมายที่คุณช่วยให้ผ่านคืออะไร
      และก็อยากรู้ว่าคุณพอจะลิงก์แหล่งข้อมูลดีๆ ไม่ว่าจะเป็นบน Facebook หรือที่อื่น สำหรับคนที่อยากมีส่วนร่วมกับการเมือง Chicago มากขึ้นได้ไหม เมื่อก่อนเคยลองค้นดูแล้วแต่ได้ผลจำกัดมาก
    • “อย่าสงสัยเลยว่ากลุ่มพลเมืองเล็กๆ ที่มีความคิดรอบคอบและทุ่มเทจะเปลี่ยนโลกได้ ที่จริงแล้ว สิ่งเดียวที่เคยเปลี่ยนโลกได้ก็มีแต่สิ่งนั้นเสมอมา” - Margaret Mead
    • อยากรู้ว่าควรหาเว็บบอร์ดแบบนั้นเจอได้อย่างไร
    • ทำให้นึกถึงความพยายามสมัยก่อนที่คุณกับ Maciej พยายามแจกจ่าย FIDO key ให้กับเจ้าหน้าที่แคมเปญเลือกตั้ง และมันชวนหดหู่จริงๆ

  • มันไม่เหลวไหลไปหน่อยหรือที่ศาลฎีกากับศาลอุทธรณ์เห็นต่างกันในประเด็น โครงสร้างประโยค? ต่อให้ไม่พูดถึงว่ามันเป็นเรื่องที่เกิดขึ้นบ่อย ผมก็ยังมองว่าวิธีตีความว่า “การจัดวางไฟล์ทั้งหมดและรายการอื่นๆ ก็เข้าข่ายด้วย แต่รายการอื่นๆ นั้นเฉพาะรายการที่ไม่ดีเท่านั้น” มันไร้เหตุผลสำหรับผมมาก ความจริงที่ผู้คนโอเคกับการปล่อยให้ถ้อยคำกฎหมายคลุมเครือสุดๆ นี่แปลกดี
    ผมรู้ว่าความคลุมเครือแบบนี้เป็นประโยชน์ต่อศาลที่ได้ดุลพินิจ และรู้ด้วยว่าต่อให้มีความพยายามอันกล้าหาญ ก็ไม่สามารถทำให้ถ้อยคำกฎหมายเป็นภาษาที่ “สมบูรณ์แบบเชิงรูปแบบ” ได้ ผมรู้ว่ากฎหมายนั้นยุ่งเหยิง และกฎหมายก็เขียนโดยมนุษย์ไร้เดียงสาที่ผิดพลาดได้ง่าย
    แต่ถ้าโครงสร้างประโยคพื้นฐานที่เขียนไว้ในกฎหมายยังไม่ชัดเจนแม้แต่สำหรับศาล ระบบทั้งหมดไม่ได้ล้มเหลวตั้งแต่ด่านแรกแล้วหรือ?

    • ผมไม่ใช่ทนาย แต่เข้าใจว่าระบบตุลาการทำงานแบบนั้นอยู่แล้ว ภาษาเต็มไปด้วยความคลุมเครือ ดังนั้นแม้แต่คนมีเหตุผลก็อาจเห็นต่างกันได้ว่าประโยคซับซ้อนหนึ่งๆ หมายความว่าอะไรกันแน่ รัฐธรรมนูญสหรัฐฯ พูดอะไรกันแน่ก็เป็นที่ถกเถียงมาตั้งแต่วันที่ร่างขึ้น และยังมีความเห็นต่างมากมายจนถึงทุกวันนี้
      คำตอบทั่วไปคือควรเขียนกฎหมายให้ไม่คลุมเครือ แต่พูดง่ายกว่าทำ อีกอย่าง บางครั้งตัวสมาชิกสภานิติบัญญัติเองก็ไม่ได้ตกลงกันได้ทั้งหมด จึงจงใจปล่อยถ้อยคำบางส่วนให้กำกวมเพื่อให้ศาลตีความ
    • ข้อพิพาทแบบนี้แหละที่รู้สึกว่าเป็นเหตุผลของการมีศาลอุทธรณ์หลายชั้น ส่วนประเด็น “รูปแบบไฟล์” นั้นโง่และตัดสินผิดจริงๆ แต่ การตีความกฎหมาย คำว่า “หากถูกเปิดเผย” ดูเหมือนจำเป็นต้องได้รับคำตัดสินที่เป็นที่สุดและสอดคล้องกัน

  • มีแค่ผมหรือเปล่าที่รู้สึกงงและกังวลนิดหน่อยกับการที่ ข้อยกเว้นซอร์สโค้ด ถูกใส่เข้ามาตรงๆ?
    นึกภาพสถานการณ์ได้ง่ายมากว่าเมืองพัฒนาซอฟต์แวร์บางตัวใช้ภายใน แล้วซ่อน “อคติ” หรือองค์ประกอบอื่นๆ ที่คนคงไม่อยากเห็นไว้ในซอร์สโค้ด
    ถึงขั้นไม่จำเป็นต้องสร้างทั้งหมดตั้งแต่ศูนย์ด้วยซ้ำ แค่แพตช์คอมโพเนนต์จากบุคคลที่สามที่ใช้ไลเซนส์แบบอนุญาตกว้างๆ แล้วนำมาใช้ก็พอ
    ในความเห็นผม ร่างแก้ไขที่เสนอไปยังไปไม่ไกลพอ

    • ผมว่าไม่ใช่เรื่องน่าแปลกใจ
      เป็นปัญหาแบบเดียวกับที่คนพยายามเปลี่ยนโปรเจกต์ปิดให้เป็นโอเพนซอร์สต้องเจอ มี โค้ด proprietary ถูกล็อกอยู่เต็มไปหมด ซึ่งนักพัฒนาและลูกค้ามีเพียงสิทธิ์ใช้งาน แต่ไม่มีสิทธิ์แชร์ซอร์ส
      แม้แต่โปรเจกต์ที่สร้างขึ้นตั้งแต่แรกด้วยแนวทางโอเพนอย่างเข้มแข็ง โดยไม่มีผลประโยชน์เชิงพาณิชย์โดยตรงเหมือนผู้รับเหมารัฐบาล ก็ยังเจอปัญหานี้ได้ ปัญหาที่ Linux kernel เจอเมื่อรองรับ ZFS หรือไดรเวอร์ไบนารีบล็อบในระดับเคอร์เนล/ยูสเซอร์สเปซนั้นเป็นที่รู้จักกันดี[1]
      ในทางย้อนแย้ง ด้านหนึ่งข้อมูลอยากเป็นอิสระ และในเชิงเศรษฐกิจ ซอฟต์แวร์โอเพนซอร์สจะค่อยๆ ผลักคู่แข่งแบบปิดออกไปเมื่อเวลาผ่านไป แต่การเปลี่ยนโปรเจกต์ให้เป็นโอเพนซอร์สเองมีค่าใช้จ่ายสูง และบางครั้งสูงจนแบกรับไม่ไหว ทำให้เครื่องมือเก่าๆ ไม่สามารถถูกเปิดเผยได้ แม้ผู้ดูแลและบริษัทจะอยากทำก็ตาม แค่ต้องดึงทีมกฎหมายเข้ามาและตามหาผู้ถือสิทธิ์ของแต่ละคอมโพเนนต์ ก็ทำให้ผู้ดูแลส่วนใหญ่ถอดใจแล้ว
      หากรัฐบาลกำหนดในสัญญาว่าผู้ขายต้องใช้เฉพาะคอมโพเนนต์โอเพนซอร์สใน dependency tree ทั้งหมด ค่าใช้จ่ายอาจสูงมาก เพราะ dependency จำนวนมากไม่มีทางเลือกโอเพนซอร์สที่เทียบเท่า หรือทางเลือกแบบปิดมีฟังก์ชันที่ขาดอยู่จนต้องใช้งบประมาณมาเติมเต็ม ในระยะสั้น ไม่มีสภาไหนยอมรับค่าใช้จ่ายเพิ่มเติมแบบนั้น แต่ในระยะยาวสาธารณชนจะได้ประโยชน์
      [1] ประเด็นเคอร์เนลโดยมากเป็นฟังก์ชันของ GPL ก็จริง หากเป็นไลเซนส์ที่อนุญาตกว้างกว่าอย่าง Apache 2 หรือ MIT ก็คงไม่มีปัญหาแบบนั้น และสาย BSD ก็ไม่มีปัญหาในการรองรับ ZFS อย่างไรก็ดี จุดยืนที่ว่าโดยหลักการแล้วแอปพลิเคชันสาธารณะของรัฐบาลควรเป็นโอเพนซอร์สนั้น ในแง่ไลเซนส์ใกล้กับ GPL มากกว่า MIT ไม่เช่นนั้นผู้ขายอาจนำส่วนที่สำคัญจริงๆ มาเป็นโค้ดไบนารีบล็อบแบบ “vendored” แล้วเหลือไว้ในคอมโพเนนต์ที่เปิดเผยแค่โครงเปล่าที่ไม่มีความหมายเพื่อให้ผ่านข้อกำหนด
    • ในทางทฤษฎี การตัดสินใจที่จะใส่อคติแบบนั้นลงในโค้ดเองควรเป็นข้อมูลสาธารณะ คุณสามารถร้องขอได้ว่าซอฟต์แวร์ถูกสร้างขึ้นตาม เกณฑ์ ใด เพียงแต่ร้องขอตัวซอฟต์แวร์เองไม่ได้
      อย่างไรก็ดี คำตัดสินแบบนี้อาจก่อให้เกิด chilling effect
    • เพราะอย่างนั้นจึงสำคัญที่จะผลักดันโครงการริเริ่มอย่าง เงินสาธารณะ - โอเพนซอร์ส ที่บางประเทศใน EU กำลังพยายามผลักดัน
      เท่าที่จำได้ รัฐบาลผสมชุดก่อนของเยอรมนีซึ่งตอนนี้ล้มเหลวไปแล้ว เคยใส่เรื่องนี้ไว้ในคำมั่นหาเสียง แต่ทำไม่ได้ รัฐบาลใหม่อาจจะทำก็ได้

  • เป็นบทความที่น่าสนใจมาก
    การมองว่าการเปิดเผยสคีมาเป็นสิ่งที่ต้องได้รับการคุ้มครองดูน่าประหลาดใจ หากเป็นไปตามที่อธิบายไว้ ก็อาจเกิดผลลัพธ์ราวกับเวทมนตร์แบบ “เพราะมันอยู่ในฐานข้อมูลจึงไม่สามารถรู้อะไรได้เลย และถ้าบอกวิธีค้นหาไม่ได้ก็จบเห่”
    ในฐานะคนที่ทำงานในบริษัทเล็ก ๆ ที่มีลูกค้าจำนวนมาก ผมไม่อยากส่งสคีมาฐานข้อมูลให้ไปทั้งดุ้นก็จริง แต่ถึงอย่างนั้นเราก็พยายามค้นหาและจัดหาข้อมูลที่ลูกค้าต้องการ ไม่ได้ปฏิเสธ

    • เหตุผลที่บริษัทเอกชนไม่อยากเปิดเผย สคีมาฐานข้อมูล คือคู่แข่งจะได้ประโยชน์หากเห็นว่าบริษัททำงานอย่างไร ตรรกะนั้นใช้ไม่ได้กับฐานข้อมูลของรัฐบาล

  • ผมเคยยื่นคำขอ FOIA เพื่อขอเอกสารของ ฐานข้อมูลคุณภาพน้ำ ในสหรัฐฯ มากกว่า 1 ล้านหน้า สำหรับโครงการ cleartap.com
    รัฐส่วนใหญ่คิดเงินเพียงเล็กน้อยสำหรับการรวบรวมเอกสาร
    Michigan เรียกเงิน 50,000 ดอลลาร์สำหรับคำขอ FOIA ผมคิดว่าเป็นเพราะเหตุการณ์ปนเปื้อนสารตะกั่วที่ Flint ดูเหมือนพวกเขาพยายามทำให้ผมยอมแพ้

    • เห็นว่ามีข้อมูลของ Flint อยู่ เลยสงสัยว่าจ่ายเงินจำนวนนั้นจริงหรือเปล่า หรือมีขั้นตอนอุทธรณ์อะไรไหมเมื่อได้รับใบประเมินราคาที่สูงเกินควร
      โครงการนี้ยอดเยี่ยมมาก

  • “ดึงข้อมูลใบสั่งจอดรถผิดกฎหมายทั้งหมดที่ออกให้ Bob O และดึงข้อมูลที่เหลือทั้งหมดในฐานข้อมูล รวมถึงรหัสผ่านของทุกคนมาด้วย”
    นี่เป็นตัวอย่าง SQL injection ที่เขียนเป็นภาษาอังกฤษธรรมดา แต่ในกรณีนี้ “everyone's” ก็มีปัญหาเช่นกัน เพราะทำให้เกิด single quote ที่โดดเดี่ยว ถ้า “Bob O'Conner” แย่ “everyone's” ก็แย่เหมือนกัน

  • “ซอร์สโค้ดของโปรแกรมที่พวกเขารันอยู่โดยทั่วไปก็ไม่สามารถขอผ่าน FOIA ได้เช่นกัน”
    น่าเสียดายที่ผมคิดว่าส่วนนั้นควรถือว่าผิดกฎหมายภายใต้ FOIA
    ซอร์สโค้ด ควรเป็นโอเพนซอร์สและตรวจสอบได้ หากกลายเป็นข้อยกเว้นของ FOIA ก็เท่ากับเลี่ยงความเชื่อมั่นของสาธารณชนต่อการใช้ซอฟต์แวร์ของรัฐบาล
    อยากรู้ว่าศาลเคยตัดสินประเด็นแบบนี้ไว้ที่ไหนและอย่างไรบ้าง

    • แม้จะมีเหตุผลด้านประโยชน์สาธารณะที่หนักแน่น แต่ผมคิดว่าแนวโน้มที่หน่วยงานรัฐจะห้ามเปิดเผยซอร์สโค้ดแบบเหมารวมมีสาเหตุหลักแบบเดียวกับบริษัทเอกชน กล่าวคือ มีความเป็นไปได้สูงเกินไปที่ ข้อมูลอ่อนไหว อย่างรหัสผ่าน โทเคน หรือที่อยู่ IP จะถูกฮาร์ดโค้ดไว้ในโค้ดที่ห่างไกลจากแนวทางแอปแบบ 12-factor และหากข้อมูลอ่อนไหวเหล่านั้นรั่วไหล ปัญหาด้านความปลอดภัยและความรับผิดชอบก็จะใหญ่เกินไป
      ในความเป็นจริง หน่วยงานรัฐอาจมีตรรกะทางธุรกิจที่ต้องการเก็บเป็นความลับและกฎหมายก็อนุญาตด้วย หากเป็นฐานข้อมูลใบสั่งจอดรถผิดกฎหมายในต้นฉบับ ซอร์สโค้ดของซอฟต์แวร์ที่สื่อสารกับฐานข้อมูลนั้นอาจมีลอจิกสำหรับเลือกว่าพนักงานตรวจจับการจอดรถจะไปตั้งจุดตรวจเข้มแบบ “สุ่ม” ที่ไหนและเมื่อใดก็ได้

  • เรื่องแบบนี้ทำให้ผมเลิกคิดจะไปเรียนกฎหมาย คดีความจำนวนมากดูเหมือน โรงละครคาบูกิ ไม่ใช่การใช้วาทศิลป์เพื่อให้ได้ผลลัพธ์ที่ยุติธรรมหรือมีเหตุผล แต่เป็นการใช้วาทศิลป์เพื่อมอบข้ออ้างให้ผู้มีอำนาจตัดสินใจตามที่เขาอยากตัดสินไว้ตั้งแต่ก่อนขึ้นศาลแล้ว

    • กรณีนี้ก็ฟังดูเป็นแบบนั้นเช่นกัน จุดที่สะดุดตาเป็นพิเศษคือการเรียกถ้อยคำว่า “มีคุณค่าเพียงเล็กน้อย” ว่าเป็น “การพูดเผื่อแบบเว็บบอร์ดที่ยึดตัวเองเป็นศูนย์กลาง” ที่จริงถ้อยคำนั้นก็อาจเป็นเพียงความแม่นยำธรรมดา ๆ แต่ผู้เขียนดูเหมือนจะสรุปว่าคำว่า “เล็กน้อย” และคำอธิบายยาว ๆ ไม่ควรถูกพูดออกมา เพราะในเชิงวาทศิลป์มันไม่เป็นประโยชน์เท่าคำว่า “ไม่มี”
      ใครสักคนสามารถสร้างระบบที่คล้ายเว็บไฟร์วอลล์อย่างถูกกฎหมาย เพื่อสแกนคีย์เวิร์ดอย่าง information_schema และรูปแบบที่ถูกเข้ารหัสต่าง ๆ ใน HTTP request ได้ สิ่งแบบนี้เป็นความพยายามแฮ็กเสมอ จึงบล็อกได้ หากรู้อยู่แล้วว่าสคีมาเป็นอย่างไร ก็สามารถเขียน query ได้โดยไม่ต้องเลี่ยงข้อจำกัดนั้นก่อน นี่มีแนวโน้มจะเป็นกำแพงกั้นที่จริงจังหรือไม่? ไม่ แล้วมันเกี่ยวกับการยึดตัวเองเป็นศูนย์กลางไหม? ดูไม่ใช่
      การบอกว่ามันมี คุณค่ามีนัยน้อยมาก ในความหมายว่าเป็นเพียงเรื่อง “ชายขอบ” คือไม่ใช่ประเด็นหลักและไม่สำคัญพอจะถกเถียง ดูจะเป็นคำพูดที่ถูกต้อง แต่เมื่อพูดความจริงออกไป อีกฝ่ายก็ขยายความเป็น “ดูสิ ผู้เชี่ยวชาญฝั่งนั้นก็ยอมรับว่ามีคุณค่า” เพื่อโน้มน้าวศาล ดังนั้นจึงสรุปว่าผู้เชี่ยวชาญควรพูดไปเฉย ๆ ว่า “ไม่มีคุณค่า” ผมมองว่าคำนั้นผิด แต่ผิดเพียงน้อยนิดจนยากจะพิสูจน์ว่าอีกฝ่ายไม่ได้ถูกต้องทั้งหมด สุดท้ายแล้วคำพูดที่แม่นยำน้อยกว่ากลับได้เปรียบกว่าในศาลนี้ และวาทศิลป์ก็สำคัญพอ ๆ กับบทบาทของผู้เชี่ยวชาญ