คิดเงิน “ตามตัวอักษร” แฟร์ไหม?

เช็คอะไรนิดหน่อย ไปเจออันนี้ วิธีการคิดเงินของ Google Cloud Translation API ก็แฟร์ระดับหนึ่งนะ คือคิดตามจำนวนตัวอักษร (code point) แทนที่จะคิดตามปริมาณข้อมูลจริงๆ (byte)

Charged characters

To calculate usage, Google counts usage on a per character basis, even if a character is multiple bytes. Each character corresponds to a code point.

You are charged for all characters that you include in a Cloud Translation request, even untranslated characters. This includes, for example, whitespace characters. If you translate <p>こんにちは</p> to English, it counts as 12 characters for the purposes of billing.

Google also charges for empty queries. If you make a request without any content, Google charges one character for the request.

—-

คือในทางคอมพิวเตอร์ มาตรฐานตัวอักษรที่แพร่หลายในปัจจุบัน คือมาตราฐาน Unicode และวิธีการจัดเก็บตัวอักษรที่นิยมและเข้ากันได้กับแอปบนอินเทอร์เน็ตต่างๆ ก็คือ UTF-8 ซึ่งในตัวอักษรในแต่ละระบบการเขียนอาจใช้จำนวนไบต์ไม่เท่ากัน ตัวละตินที่ไม่มีเครื่องหมายประสม (อย่างที่ใช้ในภาษาอังกฤษ มาเลย์ อินโด) จะใช้เพียง 1 ไบต์ต่อ 1 ตัวอักษร (code point) ส่วนตัวอักษรไทยจะใช้ 3 ไบต์ต่อ 1 ตัวอักษร

จากการตัดสินใจในขั้นการออกแบบ มันเป็นไปได้ที่จะมีการเลือกปฏิบัติ มีความ “ไม่เท่าเทียม” หรือความ “ไม่ปลอดภัย” หรือความใดๆ ที่ถ้าเป็นไปได้ก็ไม่อยากให้มี ฝังอยู่ในระบบสถาปัตยกรรมของระบบ บางอย่างไม่ได้อยากให้มี แต่ด้วยข้อจำกัดของทรัพยากรที่มีจำกัดกว่าหรือสมมติฐานของบริบทการใช้งานในตอนที่ออกแบบ ก็เลยตัดสินใจว่าใช้แบบนี้ไปละกัน มันโอเคสำหรับตอนนั้น – แต่พอเวลาผ่านไป ย้อนกลับไปพิจารณา ก็อาจตัดสินใจอีกแบบได้ (จะมีโอกาสแก้ไขไหมก็อีกเรื่อง)

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

แต่ต่อมาเมื่อสมมติฐานความปลอดภัยนั้นไม่เป็นจริงแล้ว หรือข้อจำกัดทางเทคโนโลยี/เศรษฐกิจนั้นได้คลายลงแล้ว ก็มีการคิดวิธีเข้ารหัสลับให้กับข้อมูลขึ้นมา โดยยังทำงานอยู่บนโปรโตคอลเดิม มีความเข้ากันได้กับระบบเก่าๆ (backward compatible)

การออกแบบคอมพิวเตอร์ดิจิทัลยุคแรก นอกจากจะมีแต่ตัวละตินแล้ว ยังไม่มีกระทั่งตัวอักษรพิมพ์เล็ก เพราะพื้นที่หน่วยความจำและจัดเก็บมีขนาดจำกัด และยังต้องกันที่สำหรับอักขระพิเศษเพื่อควมคุมเครื่องพิมพ์เข้าไปด้วย (จอภาพอาจไม่ใช่ส่วนแสดงผลหลักของระบบคอมพิวเตอร์หลายๆ ระบบในตอนนั้น และการแสดงผลกราฟิกที่แม่นยำที่สุด ก็คือพล็อตเตอร์ ที่เป็นแขนกลวาดรูปด้วยปากกา)

แม้จะมีข้อจำกัด แต่มันก็พอใช้ได้ โดยเฉพาะเมื่อคำนึงถึงบริบทว่าในสมัยนั้น “ผู้ใช้” ระบบคอมพิวเตอร์ก็มีแนวโน้มจะเป็น “ช่างเทคนิค” ในที่ได้รับการอบรมมาในระดับหนึ่งสำหรับการใช้เครื่องระบบดังกล่าว (พูดอีกแบบคือ คนต้องปรับตัวให้เข้ากับเครื่อง เครื่องยังไม่ต้องปรับตัวให้เข้ากับคน)

เมื่อระบบเหล่านี้ขยายใหญ่ขึ้น มีการนำไปใช้กับหลากหลายภาษาวัฒนธรรรมมากขึ้น มีผู้ใช้จำนวนมากขึ้น จากหลากหลายภูมิหลังขึ้น ใช้กับหลากหลายบริบทความปลอดภัยมากขึ้น สมมติฐานหลายๆ อย่างที่เคยใช้ได้ ก็เปลี่ยนไป

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

เช่น เดิมใช้ 7 บิตเพื่อแทนชุดตัวอักษร 128 ตัว ก็ขยายมาเป็น 8 บิต 16 บิต ฯลฯ โดยพยายามทำให้มันรองรับระบบเดิมอยู่ โดย 128 ตัวแรก ยังใช้ตัวอักษรชุดเดิมอยู่อะไรงี้ ซึ่งวิธีที่เก็บตัวอักษรที่ใช้บนอินเทอร์เน็ตส่วนใหญ่ตอนนี้ใช้วิธีนี้อยู่ ชื่อมาตรฐานคือ UTF-8

UTF-8 นี่เป็นวิธีการแปลงรหัสเพื่อบันทึกตัวอักษรแบบที่เรียกว่า “variable-width encoding” คือ ตัวอักษรแต่ละตัวอาจใช้จำนวนข้อมูล (คิดเป็นไบต์) ในการเก็บไม่เท่ากัน — พวกตัวอักษรละตินและสัญลักษณ์พื้นฐาน 128 ตัวแรก จะใช้ 1 ไบต์ ตัวละตินอื่นๆ เกือบทั้งหมดที่เหลือ (ซึ่งภาษาจำนวนมากในยุโรปใช้ รวมถึงภาษาอย่างเวียดนาม ก็ใช้ตัวเขียนเหล่านี้) รวมถึงตัวอักษรกรีก ฮีบรู อารบิก คอปติก พวกนี้ใช้ 2 ไบต์ ตัวอักษรที่เหลือเกือบทั้งหมดจะใช้ 3 ไบต์ ในกลุ่มนี้มีตัวอักษรจีน ญี่ปุ่น เกาหลี ไทย รวมอยู่ด้วย ส่วนพวก 4 ไบต์นี่จะเป็นตัวอักษรที่ไม่พบบ่อยนัก หรือเป็นส่วนขยาย/กรณีพิเศษของตัวอักษรบางตัว

วิธีคิดของคณะออกแบบ UTF-8 ก็คือ ตัวอักษรไหนมีแนวโน้มจะใช้บ่อย ใช้มาก ก็พยายามให้ใช้จำนวนไบต์น้อยๆ เพื่อที่ว่าในภาพรวมจะได้ประหยัดพื้นที่จัดเก็บ เว้นเสียว่าจะทำไม่ได้จริงๆ อย่างกลุ่มตัวอักษรจีน​ญี่ปุ่นเกาหลี (CJK) ที่จำนวนตัวอักษรมันเยอะ จะยัดลง 2 ไบต์ก็ไม่ไหว ก็ใช้ 3 ไบต์ไป

ซึ่งในแง่นี้ การให้ตัวอักษร ASCII ใช้เพียง 1 ไบต์ ก็เข้าใจได้มาก ๆ เพราะตัวอักษรในชุดนี้ถูกใช้เป็นคำสั่งและคำสำคัญต่างๆ ในโปรโตคอลการรับส่งข้อมูลและมาตรฐานข้อมูลอื่น ๆ ในระดับพื้นฐานของคอมพิวเตอร์ ถ้าเกิดตัวอักษรชุดนี้ใช้จำนวนไบต์เยอะ ทุกอย่างในระบบก็จะพองขึ้นทันที ซึ่งผลพลอยได้ก็คือ พวกภาษาที่ใช้ตัวอักษรที่อยู่ในกลุ่มตัวละติน (A-Z, a-z) ก็เลย “โชคดี” ไปด้วย (หรือมองอีกมุม ก็เป็นเพราะคนที่ใช้ภาษาที่ใช้อักษรละติน เป็นคนกำหนดมาตรฐานคอมพิวเตอร์ไง ผลที่ตามมาเลยเป็นแบบนี้)

อย่างไรก็ตาม ก็มีคำถามแหละ ว่าเอ๊ะ แล้วเอาเฉพาะชุดตัวที่ใช้บ่อยๆ ของตัวอักษรที่ตอนนี้ถูกจัดอยู่ในหมวด 3 ไบต์ (อย่าง CJK) ไปอยู่ใน 2 ไบต์ก็ได้รึเปล่า อย่าง ฮันกึลของเกาหลี หรือ คะนะของญี่ปุ่น พวกนี้ก็ไม่ได้เยอะมากแบ่งไปใส่ในชุด 2 ไบต์ได้ไหม แล้วพวกฮันจาหรือคันจิ (ตัวจีน) ค่อยใส่ในชุด 3 ไบต์ ไม่ต้องยกกันไปทั้งยวงก็ได้

หรืออย่างตัวอักษรไทย มันก็ไม่ได้เยอะอะไร รวมพยัญชนะ รูปสระ วรรณยุกต์ เครื่องหมายวรรคตอน ตัวเลขไทย มีประมาณ 80-90 ตัวได้ ไม่ได้เยอะมาก และคนใช้ตัวอักษรไทยก็ไม่ได้น้อย น่าจะมากกว่าคนใช้ภาษาคอปติกในชีวิตประจำวันแน่ ทำไมอักษรไทยถึงได้เป็น 3 ไบต์ และคอปติกได้ 2 ไบต์

คำว่า “บ่อย ๆ” นี่เอาอะไรวัด จากมุมของใคร หรืองานแบบไหน

แต่เอาล่ะ มาตรฐานมันก็กำหนดมาแบบนี้แล้ว ไปแก้อะไรไม่ได้ (จริงๆ ก็แก้ได้ แต่ต้องไปตามแก้ข้อมูลที่ถูกจัดเก็บไปแล้วทั้งหมด ก็ลำบากมากๆ อยู่) ก็เลยกลายเป็นว่ามีบางภาษา พอออกมาเป็นรูปตัวเขียน ต้องใช้พื้นที่ในการจัดเก็บมากกว่าภาษาอื่น เพราะต่อ 1 ตัวอักษร ใช้จำนวนไบต์มากกว่า

กลับไปประเด็นตั้งต้น ถ้าบริการไหนคิดค่าบริการตามจำนวนไบต์ (ขนาดพื้นที่จัดเก็บ/รับส่งข้อมูลจริงๆ) มันก็เป็นประเด็นได้ว่า ทำให้ผู้ใช้ภาษาบางภาษาหลีกเลี่ยงไม่ได้ที่จะต้องจ่ายแพงกว่าภาษาอื่น

วิธีการคิดค่าบริการตามจำนวนตัวอักษร แทนที่จะเป็นจำนวนไบต์ข้อมูลที่จะต้องใช้เก็บตัวอักษรนั้น ก็เลยถูกมองได้ว่าแฟร์ขึ้นมาอีกนิดนึง

แต่ก็อาจมองต่อไปได้ว่า พอถัวเฉลี่ยกัน ก็เลยกลายเป็นว่าคนที่ใช้ภาษาที่ใช้จำนวนไบต์น้อย แทนที่จะได้จ่ายถูก ก็ต้องมารับภาระจ่ายแพงขึ้นหลังจากการถัวรึเปล่า แบบนี้ก็ไม่แฟร์สิ

หรือถ้าไปให้สุดๆ เฮ้ย บางภาษา 1 ตัวอักษร มันเก็บความหมาย อุ้มความหมายเอาไว้ได้เยอะกว่า 1 ตัวอักษรในอีกภาษา ภาษาญี่ปุ่นเขียน 1 ตัว 空 ภาษาไทยต้องเขียน 7 ตัว เพื่อจะได้ความหมายว่า ท้องฟ้า เท่ากัน แบบนี้คนไทยก็ต้องจ่ายแพงกว่าคนญี่ปุ่นรึเปล่า (แบบ 280 ตัวอักษรบนทวิตเตอร์ คนจีนแทบจะเขียนเรื่องสั้นได้แล้ว คนไทยแค่รายงานข่าวอาจจะไม่พอ) แบบนี้การคิดค่าบริการตามตัวอักษรก็ไม่แฟร์อยู่ดีปะ

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

ตราบใดที่การสร้างมันเกิดการกระบวนการตัดสินใจเลือก การเลือกปฏิบัติมันมีอยู่แน่ๆ ในผลงานทางวิศวกรรม

มันไม่จำเป็นต้องเป็นการเลือกปฏิบัติในทางลบ (ภาษากฎหมายระหว่างประเทศใช้คำว่า “การเลือกประติบัติ”) มันอาจเป็นทางบวกก็ได้ (จริงๆ การคำนึงถึงความถี่ในการใช้และพยายามให้ตัวอักษรที่พบบ่อย ใช้จำนวนไบต์น้อยๆ ก็เป็นการเลือกปฏิบัติที่พยายามจะให้เกิดผลบวกในภาพรวม ทำให้ในภาพรวมใช้พื้นที่จัดเก็บน้อยลง ส่งข้อมูลได้ไวขึ้น ประหยัดขึ้น)

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

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

เผยแพร่ครั้งแรก 7 เมษายน 2564 บนเฟซบุ๊ก

พอโพสต์เรื่องข้างต้นจบ ก็นึกถึงอีกประเด็นในสัปดาห์ก่อนหน้า ที่คนพูดถึงบทความ When Binary Code Won’t Accommodate Nonbinary People ซึ่งก็คิดๆ ไปก็น่าจะเป็นเรื่องของ encoding นี่อยู่เหมือนกัน เป็นการเอาการจัดประเภทฝังลงไปในระบบ

ถ้าได้อ่านในบทความนั้น คิดว่าหลักใหญ่ใจความประเด็นมันคือเรื่องการออกแบบตัวระบบ — ทั้งระดับโครงสร้างพื้นฐานและระดับส่วนติดต่อผู้ใช้ — ไม่ว่าจะเป็น database schema ช่องหรือปุ่มที่มีให้กดในหน้าจอ UI หรือวิธีการทำ data validation ที่ทำให้ข้อมูลที่อยู่นอกเหนือไปจากที่ผู้ออกแบบระบบอนุญาต มันกรอกไม่ได้ รวมไปถึงคู่มือใช้งาน/การอบรมการใช้งานที่ทำให้เจ้าหน้าที่ที่เป็นผู้กรอกยึดอยู่กับคุณค่าบางอย่าง แม้ตัวระบบจะไม่ได้บังคับ (ในระบบที่ตัวเจ้าของข้อมูลไม่ได้เป็นผู้กรอกเอง)

ส่วนตัวมีประสบการณ์นี้ตอนไปทำบัตรประชาชนนานมาแล้ว ตอนผมกรอกข้อมูลในฟอร์มกระดาษ ช่องศาสนาผมไม่กรอก เว้นว่าง แต่พอเจ้าหน้าที่ไปกรอกในฟอร์มคอมพิวเตอร์ เขาใส่เป็น “พุทธ” ให้ (คงคิดว่าผมลืมกรอก เลยเติมให้)

ผมแย้ง ให้เว้นว่าง เขาบอกว่าเว้นว่างไม่ได้ ต้องใส่ค่าอะไรบางอย่าง ไม่งั้นจะคลิกไปต่อไม่ได้ จะเลือก “ไม่มี” ก็ไม่มีให้เลือกใน drop-down list สุดท้ายเลยมาดูจอกัน แล้วค่อยพบว่า เราสามารถกรอก “-” เพื่อให้คลิกต่อได้ ซึ่งเจ้าหน้าที่ก็เพิ่งรู้

พาดหัวมันเล่นกับคำ หลายคนอาจจะ อิหยังวะ เพราะอาจคิดไปถึงเลขฐานสองตรงตัว แต่ถ้าอ่านข้อถกเถียงข้างใน ประเด็นมันก็ตามที่ว่าไว้ข้างบนน่ะ

ซอฟต์แวร์เป็นสถาปัตยกรรมที่กำหนด (อนุญาต/ไม่อนุญาต) ทางที่เราจะใช้ชีวิต{ใน/กับ/ด้วย}สภาพแวดล้อมนี้ได้ ไอเดียเดียวกับที่เลซสิกเสนอว่า code is law น่ะแหละ

เผยแพร่ครั้งแรก 31 มีนาคม 2564 บนเฟซบุ๊ก

แถลงการณ์ว่าด้วยการสืบย้อนผู้ใกล้ชิด (contact tracing) 19 เม.ย. 2563

19 เม.ย. 2563 นักวิทยาศาสตร์และนักวิจัยมากกว่า 300 คนจากทั่วโลก ลงชื่อในแถลงการณ์ร่วม “Joint Statement on Contact Tracing” ว่าด้วยการสืบย้อนกลับว่าบุคคลเคยสัมผัสใกล้ชิดผู้มีเชื้อหรือไม่ เพื่อประโยชน์ในการควบคุมโรคจากไวรัสโคโรนาสายพันธุ์ใหม่ โควิด-19

ใครสนใจก็กดอ่านและร่วมลงชื่อได้ที่ Joint Statement on Contact Tracing: Date 19th April 2020

ประเด็นสำคัญเรื่องหนึ่งในแถลงการณ์ก็คือ เรื่อง “social graph” หรือผังความสัมพันธ์ระหว่างบุคคลในสังคม ซึ่งสามารถสร้างขึ้นจากการประกอบเชื่อมโยงชิ้นส่วนข้อมูลเล็กๆ เข้าด้วยกัน

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

ระบบที่เราจะพึ่งพาได้นั้น จึงต้องเป็นระบบที่อยู่ภายใต้อำนาจของสาธารณะที่จะตรวจสอบได้ และออกแบบมาให้รักษาความเป็นส่วนตัวตั้งแต่ขั้นการออกแบบ (by design) แทนที่จะไปคาดหวังว่าจะมีคนที่น่าเชื่อถือมาดูแลบริหารจัดการ เพื่อจะรับประกันได้ว่าสิทธิในการได้รับการปกป้องข้อมูลของพลเมืองนั้นจะได้รับการเคารพ

“We urge all countries to rely only on systems that are subject to public scrutiny and that are privacy preserving by design (instead of there being an expectation that they will be managed by a trustworthy party), as a means to ensure that the citizen’s data protection rights are upheld.”

ในแถลงการณ์ระบุว่า หลักการดังต่อไปนี้เป็นหลักการขั้นต่ำที่ควรยึดถือเพื่อเดินไปข้างหน้า:

  • แอป contact tracing จะต้องใช้สำหรับสนับสนุนมาตรการทางสาธารณสุขสำหรับการจำกัดการแพร่กระจายของ #COVID19 เท่านั้น ระบบจะต้องไม่สามารถเก็บ ประมวลผล หรือส่งข้อมูล ไปมากกว่าที่จำเป็นสำหรับการบรรลุวัตถุประสงค์ดังกล่าว
  • วิธีการใดๆ ที่นำมาพิจารณาจะต้องโปร่งใสเต็มที่ โพรโทคอลและการสร้างระบบจากโพรโทคอลดังกล่าว ซึ่งรวมถึงชิ้นส่วนย่อยที่จัดหามาให้โดยบริษัทต่างๆ จะต้องถูกพิเคราะห์พิจารณ์ได้โดยสาธารณะ ข้อมูลที่ถูกประมวล รวมถึงเงื่อนไขการจัดเก็บ วิธีการจัดเก็บ สถานที่ที่จัดเก็บ และระยะเวลาการจัดเก็บข้อมูล จะต้องถูกบันทึกเป็นเอกสารเอาไว้อย่างชัดเจน ข้อมูลที่ถูกเก็บจะต้องมีน้อยที่สุดเท่าที่จะเป็นไปได้สำหรับการวัตถุประสงค์หนึ่งๆ
  • เมื่อมีทางเลือกที่เป็นได้หลายทาง สำหรับการสร้างชิ้นส่วนหรือความสามารถของแอป ทางเลือกที่จะรักษาความเป็นส่วนตัวได้มากที่สุดจะต้องถูกเลือก การเบี่ยงเบนไปจากหลักการนี้จะเกิดขึ้นได้ก็ต่อเมื่อมีความจำเป็นที่จะต้องบรรลุวัตถุประสงค์ของแอปให้ได้มีประสิทธิผลมากขึ้น และการเลือกทางเลือกดังกล่าวจะต้องถูกอธิบายแสดงเหตุผลอันสมควรได้อย่างชัดเจน โดยมีข้อกฎหมายที่จะกำหนดวันสิ้นสุดหรือวันหมดอายุของทางเลือกดังกล่าว (sunset provisions)
  • การใช้แอป contact tracing และระบบที่สนับสนุนมัน จะต้องเป็นไปโดยสมัครใจ ใช้โดยได้รับความยินยอมอย่างชัดเจนจากผู้ใช้ และระบบต่างๆ จะต้องถูกออกแบบมาให้สามารถสั่งปิดการทำงานได้ และข้อมูลทั้งหมดจะต้องถูกลบทิ้ง เมื่อวิกฤตในปัจจุบันนี้ได้ผ่านไปแล้ว

สหภาพยุโรปก็มีแนวทางเรื่องนี้ออกมาเช่นกัน โดยออกเป็น Commission Recommendation (EU) 2020/518 ลงวันที่ 8 เมษายน 2563 และในรายละเอียดจะมีเอกสารที่เรียกว่า “toolbox” ตามมาอีกเรื่อยๆ

ตอนนี้ชิ้นแรกที่ออกมาคือ Mobile applications to support contact tracing in the EU’s fight against COVID-19 – Common EU Toolbox for Member States

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

The toolbox sets out the essential requirements for these apps:

  • They should be fully compliant with the EU data protection and privacy rules, as put forward by the guidance presented today following consultation with the European Data Protection Board.
  • They should be implemented in close coordination with, and approved by, public health authorities.
  • They should be installed voluntarily, and dismantled as soon as no longer needed.
  • They should aim to exploit the latest privacy-enhancing technological solutions. Likely to be based on Bluetooth proximity technology, they do not enable tracking of people’s locations.
  • They should be based on anonymised data: They can alert people who have been in proximity for a certain duration to an infected person to get tested or self-isolate, without revealing the identity of the people infected.
  • They should be interoperable across the EU so that citizens are protected even when they cross borders.
  • They should be anchored in accepted epidemiological guidance, and reflect best practice on cybersecurity, and accessibility.
  • They should be secure and effective. 

การสืบย้อนคนที่เคยใกล้กัน ที่ยังรักษาความเป็นส่วนตัว ในบริบท #COVID19

เขียนไว้ในเฟซบุ๊กและทวิตเตอร์ ชวนคุยเรื่องแอปติดตามผู้เคยอยู่ใกล้ผู้เป็นโรคที่อาจติดต่อได้ (contact tracing) กับความอธิบายได้ทางนโยบาย การเลือกปฏิบัติ และผลกระทบที่อาจอยู่กับเราไปนานกว่าอายุของวิกฤต?

TraceTogether ของสิงคโปร์

ทางสิงคโปร์ที่เราพอได้ยินจากข่าวมาบ้าง วันนี้มีโปรโตคอลกับตัวซอร์สโค้ดออกมาแล้ว

  • BlueTrace เป็นโปรโตคอล ที่เขาใช้คำว่า “privacy-preserving cross-border contact tracing”
  • OpenTrace เป็นแอปที่ใช้ BlueTrace (open source reference implementation)
  • TraceTogether เป็น OpenTrace ที่ปรับแต่งเพื่อใช้ในสิงคโปร์

ทาง GovTech หน่วยงานด้านเทคโนโลยีรัฐบาลของสิงคโปร์ เล่าเรื่องของ OpenTrace ไว้ที่ 6 things about OpenTrace

ไอเดียรวมๆ คือใช้บลูทูธเพื่อเก็บข้อมูลว่า เราเคยไปอยู่ใกล้ใครบ้าง (มือถือของเราเคยไปอยู่ใกล้ใครมือถือเครื่องไหนบ้าง) คือมองว่าต้องการติดตามการติดต่อที่อาจเกิดขึ้นได้ระหว่างคนสู่คนโดยตรง ดังนั้นสิ่งที่สนใจ คือการอยู่ใกล้ชิดของคน ไม่สนใจว่าคนนั้นจะไปอยู่ที่ไหน — คือเก็บเฉพาะ who ไม่เก็บ where

เท่าที่ดูในข่าว Channel News Asia เป็นการเปิดให้ใช้ตามความสมัครใจ ไม่บังคับ แต่ก็เชิญชวน

ThaiAlert (รอประกาศชื่อจริง)

ส่วนนี่เป็นแอปโดยกลุ่ม Code for Public ใน GitHub ใช้ชื่อว่า “contact-tracer”

ไอเดียคล้ายกันในส่วนการใช้บลูทูธ แต่เพิ่มเติมการเก็บตำแหน่งที่ตั้งจาก GPS มาด้วย — ก็คือเก็บทั้ง who และ where

NuuNeoi อธิบายแนวคิดไว้ในบล็อกของเขา (ภาษาไทย – เป็นคนไทย)

คุณลิ่วไปทักเรื่องการเปิดเผย user id ระหว่าง broadcast ใครสนใจตามต่อได้ในเฟซบุ๊กของ NuuNeoi

เข้าใจว่าวันศุกร์ที่ 10 เมษายนนี้ จะมีการประกาศใช้แอปจากกลุ่ม Code for Public นี้ในประเทศไทย (มี DEPA และ DGA ของกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม ร่วมสนับสนุน)

ระบบอื่นๆ

ตอนนี้ก็มีระบบอื่นที่เสนอกันมาเยอะ เช่น

  • WeTrace เป็นแบบทำนอง TraceTogether จากสวิตเซอร์แลนด์
  • Decentralized Privacy-Preserving Proximity Tracing (DP-3T) จาก EPFL+ทีม
  • Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) ที่เป็นโครงการระดมสมองออกแบบในทวีปยุโรป
  • หรือวิธีการเก็บตำแหน่งไว้ในเครื่องโดยมีกลไกป้องกันของ MIT Private Kit (ในนั้นมี whitepaper ชื่อ Apps Gone Rogue: Maintaining Personal Privacy in an Epidemic ด้วย ถ้าสนใจลองดูได้)

ระบบเหล่านี้อาจมีแนวคิดในการออกแบบต่างกัน บางระบบรวมศูนย์ (centralized) บางระบบกระจาย (decentralized) บางอันเก็บแค่ ใคร (who) บางอันเก็บ ที่ไหน (where) ด้วย แต่รวมๆ ก็พยายามบันทึกข้อมูลให้น้อยที่สุดเท่าที่จะใช้ติดตามผู้ที่เคยอยู่ใกล้ผู้ติดเชื้อได้ ตามที่ผู้ออกแบบเห็นว่าเหมาะสมกับบริบทของพื้นที่ที่จะเข้าไปดูแล

สิ่งที่น่าห่วงกว่าเรื่องเทคนิค — การเลือกปฏิบัติ?

แม้ในทางเทคนิค กว่าจะแปลงจากจากอัลกอริทึมสู่แอปที่รันจริงในมือถือเรา มันก็มีเรื่องต้องระวังกันในแต่ละขั้นอยู่แล้ว

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

ตัวอย่าง:

หากกำหนดว่าใครไม่ลงแอปก็จะไม่รับรักษา หรือจัดลำดับการรักษาไว้ท้ายๆ หรือใช้ข้อมูลที่ได้มาในการจำกัดสิทธิอื่น

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

เหล่านี้เป็นเรื่องทำได้หรือไม่ เพราะอะไร จะเป็นการขัดต่อสิทธิในการได้รับการรักษาพยาบาลหรือไม่ (คือต่อให้ไม่มีข้อมูลว่าเคยไปอยู่กับใคร แต่ถ้ามีอาการเข้าข่าย ก็ควรได้รับการรักษาหรือไม่?)

ตรงนี้นอกจากเรื่องสิทธิพลเมืองแล้ว ในแง่จริยธรรมทางการแพทย์ก็ต้องตอบให้ได้ชัดเจนด้วย

(อันนี้ยังไม่นับเรื่องความเป็นเจ้าของสมาร์ตโฟน การเข้าถึงโครงข่าย ฯลฯ)

วันศุกร์ที่ 10 เมษานี้ ถ้าจะมีการประกาศใช้แอปจริง รายละเอียดที่น่าติดตามคือ จะใช้อะไรในการ “บังคับ” หรือ “จูงใจ” คนให้ติดตั้งแอป และถ้าไม่มีแอป ไม่มีข้อมูล ไม่ว่าด้วยเหตุผลอะไร จะเก็บอะไรขึ้นกับบุคคลนั้น

หน้าที่ในการอธิบายของผู้ใช้อำนาจ

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

อย่างของ BlueTrace มีอธิบายข้อพิจารณาทางนโยบายของรัฐบาล ซึ่งเป็นที่มาของการออกแบบตัวโปรโตคอลทางเทคนิคที่นี่ https://bluetrace.io/policy/

หากมีหน่วยงานใดก็ตามในไทย ประกาศจะทำ contact tracing ทำนองนี้สำหรับโรคระบาด ไม่ว่าจะเป็น #COVID19 หรือโรคใดก็ตาม เราก็คาดหวังคำอธิบายอะไรทำนองนี้เหมือนกัน ไม่ใช่เพียงเรื่องเทคนิค แต่เป็นเรื่องว่าการตัดสินใจใช้มาตรการต่างๆ นี้จะทำให้เกิดอะไร มีประโยชน์อะไร จะเอาอะไรไปแลกให้ได้ประโยชน์นั้นมา การเอาสิ่งนั้นไปแลก อาจมีผลกระทบอะไร ป้องกันความเสียหายยังไง เยียวยายังไง คือไม่ใช่ว่าค้านไม่ให้ทำไปเสียหมด ถ้าสมเหตุสมผล อธิบายได้หมด เราในฐานะประชาชนก็ควรสนับสนุน และจริงๆ การตั้งคำถามเหล่านี้ ก็คือการสนับสนุนทางหนึ่ง เป็นการสนับสนุนให้ทำอย่างรับผิดชอบ

ผลกระทบที่จะอยู่กับเราเกินอายุของวิกฤต

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

Paul-Olivier Dehaye, director of PersonalData.IO, speaks to Open Rights Group about the use of contact tracing surveillance in the global response to Covid-19.

ทำเว็บไซต์ให้ปลอดภัยขึ้นอีกนิดนึง ไม่ยากเกินไป ถ้าเขียนเว็บได้ก็น่าจะทำได้ #websecurity

ช่วงนี้เห็นเว็บไซต์ที่เกี่ยวกับคนใกล้ตัวโดนแฮ็กบ้าง หรือบางอันไม่ได้โดนแฮ็ก แต่เหมือนเอาของไปวางไว้หน้าบ้านรอคนมาหยิบเอาไปบ้าง เลยขอโน๊ตๆ ไว้หน่อย ถึงวิธีการป้องกันตัวเองเบื้องต้น (มากๆ) ที่คนทำเว็บน่าจะพอทำเองได้ครับ

เครื่องมือตรวจสอบเบื้องต้น (ส่วนใหญ่ฟรี)

ใครเป็นคนดูแลเว็บ ลองใช้เครื่องมือในลิงก์นี้ตรวจสอบเบื้องต้นก่อนก็ได้ครับ ว่าเว็บไซต์เรายังโอเคไหม: 12 Online Free Tools to Scan Website Security Vulnerabilities & Malware

เข้าไล่มา 12 เครื่องมือ ผมก๊อปมาให้ดูตรงนี้อีกที (บางตัวก็ทำงานคล้ายๆ กัน)

  • Scan My Server – ตรวจหารูรั่วอย่าง SQL injection, PHP injection, HTTP Header injection, cross site scripting (XSS)
  • SUCURI – ตรวจหามัลแวร์ ลิงก์สแปม
  • Qualys SSL Server Test – ตรวจความปลอดภัยของการเข้ารหัสลับข้อมูลที่เว็บไซต์รับส่ง
  • Quttera – ตรวจหามัลแวร์และรูรั่วอื่นๆ
  • Detectify – ตรวจหาจุดอ่อน เช่นจุดอ่อนตามรายการ OWASP Top 10 ที่เว็บแอปโดนเจาะบ่อยๆ
  • SiteGuarding – ตรวจหามัลแวร์ ลิงก์สแปม
  • Web Inspector – ตรวจหา backdoor มัลแวร์ เฟรมหรือการเชื่อมต่อแปลกๆ
  • Acunetix – ตรวจหาความผิดปกติที่ระดับเครือข่าย อย่าง DNS รวมไปถึงการตรวจหารูรั่วอื่นด้วย
  • Asafa Web – ตรวจหาการใช้คุกกี้ที่ไม่ได้เข้ารหัสลับ clickjacking
  • Netsparker Cloud – ตรวจหารูรั่วประเภท injection, permission
  • UpGuard Web Scan – ตรวจหาความไม่ปลอดภัย โดยอาศัยข้อมูลที่บุคคลภายนอกสามารถดูได้ เช่น ตรวจว่ามีใครส่งอีเมลจากชื่อโดเมนเราได้ไหม
  • Tinfoil Security – ตรวจหาความไม่ปลอดภัย อย่างเช่นตามรายการ OWASP Top 10 และรูรั่วอื่นๆ

ที่ตรวจดูได้โดยไม่ต้องพึ่งผู้เชี่ยวชาญมากๆ ก็เช่น ติดมัลแวร์รึเปล่า การส่งข้อมูลได้เข้ารหัสลับ (https) ดีพอไหม พวกคุกกี้ของเว็บไซต์เราที่ไปฝากไว้กับเครื่องผู้ใช้นี่เว็บไซต์อื่นเข้ามาอ่านได้ไหม

ส่วนใหญ่จะฟรี บางอันต้องลงทะเบียนก่อน หรือต้องยืนยันสิทธิ์ก่อนว่าเราเป็นผู้ดูแลของเว็บไซต์นั้นจริงๆ (ด้วยการเอาไฟล์บางอย่างไปวางไว้ในเครื่องเรา – ยังไงก็ตรวจสอบดีๆ ก่อนจะเอาไฟล์อะไรไปวางนะครับ มันควรจะเป็น text/html file ที่เราเปิดเข้าไปอ่านๆ ได้ ถ้าดูแปลกๆ ก็อย่าทำต่อ)

* สำหรับตัวที่มีการทดสอบ SQL injection ให้ระวังด้วยว่ามันจะพยายามยิงอะไรบางอย่างเข้าไปในฐานข้อมูลของคุณ เพื่อจะทดสอบ แปลว่ามันอาจจะทำให้เกิดขยะในฐานข้อมูลได้  ดังนั้นไม่ควรทดสอบกับระบบที่ใช้อยู่จริง (on production) นะครับ ให้ทดสอบกับระบบที่เอาไว้ทดสอบเท่านั้น ถ้าเจอรูก็รีบอุด พอแน่ใจแล้วค่อยไปอัปเดตโค้ดในส่วนของ production ครับ [ขอบคุณคุณ Thitipong Samranvarnich ในกลุ่มสมาคมโปรแกรมเมอร์ไทย ที่เตือนเรื่องนี้ครับ]

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

ทีนี้ถ้าสมมติว่าพบสิ่งปกติ แล้วอยากแก้ไข ถ้าไม่มั่นใจจะทำเอง ก็อาจจะต้องเรียกหาคนที่ทำเป็นมาทำน่ะครับ

(แต่ถ้าไม่พบ ก็ไม่ได้แปลว่าไม่มีนะครับ อาจจะแค่หาไม่เจอ)

ป้องกันคนมาดูภาพหรือไฟล์ที่ยังไม่พร้อมเผยแพร่

สำหรับเว็บไซต์ที่ไม่อยากให้คนมาดูภาพ ดูข้อมูลอะไรที่อยู่เว็บไซต์นั่นแหละ อัปโหลดเตรียมไว้ แต่ยังไม่ได้เผยแพร่ในหน้าเว็บ อันแรกที่ควรทำก็คือ ปิด directory listing ไม่ให้คนมาไล่ดูชื่อไฟล์ได้ง่ายๆ

ถ้าเว็บเซิร์ฟเวอร์ใช้ Apache HTTP Server ก็ทำได้ด้วยการแก้ไขไฟล์ .htaccess โดยเพิ่มบรรทัด

Options -Indexes

ทีนี้ก็จะยังมีปัญหาอยู่บ้าง คือถ้าคนรู้ชื่อไฟล์ (อาจจะเดาไปเรื่อยๆ) เขาก็จะยังดูได้อยู่ดี

อันนึงที่ทำได้ก็คือ อย่าตั้งขึ้นไฟล์ให้มันเดาง่ายนัก (พวกรันเลขเรียงลำดับไปเรื่อยๆ นี่เดาสบายเลย)

อีกวิธีคือ ป้องกันการ hot link ไม่ให้คนเข้าถึงได้โดยตรง (พิมพ์ url ชื่อไฟล์ในเบราว์เซอร์ตรงๆ จะดูไม่ได้ ) แต่ถ้าภาพไหนถูกโหลดจากหน้าเว็บของโดเมนนั้นเอง จะโหลดดูได้ (ซึ่งกรณีหลังนี้ เป็นเรื่องที่เราต้องการให้ทำได้ เพราะเราเป็นคนเผยแพร่เอง)

แต่ปลอดภัยที่สุดคือ อะไรที่ไม่อยากให้คนเห็น ลับมาก อย่าเพิ่งไปอัปขึ้นเว็บเซิร์ฟเวอร์ครับ lol

Please do not leave the key in the lock

ปกปิดข้อมูลเว็บเซิร์ฟเวอร์

อีกอันที่ทำได้ไม่ยาก และช่วยให้การเจาะเว็บเราวุ่นวายขึ้นมาอีก “เล็กน้อย” คือปิดข้อมูลเกี่ยวกับเว็บเซิร์ฟเวอร์เราครับ

ไอเดียมันคือว่า ซอฟต์แวร์ที่เอามาใช้เป็นเว็บเซิร์ฟเวอร์นี่มันก็มีบั๊ก มีรูรั่วอะไรอยู่แหละ คนเจออยู่เรื่อยๆ ทีนี้พอเจอปุ๊บก็จะมีการแก้ไขในซอฟต์แวร์รุ่นใหม่ แต่ถ้าใครไม่อัปเดต ก็จะมีความเสี่ยง คนที่อยากจะลองเจาะ เขาก็จะไปไล่หาเว็บไซต์ที่ยังใช้ซอฟต์แวร์ตกรุ่นพวกนี้แหละครับ เพราะเป็นเป้าหมายที่รู้อยู่แล้วว่าจะเจาะตรงไหนได้

ถ้าเราปกปิดข้อมูลเกี่ยวกับเว็บไซต์เราเสียหน่อย ก็จะลดโอกาสเป็นเป้าไปไ้ด้บ้างจากนักเจาะที่ฉวยโอกาส

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

ยังไงก็ควรหมั่นอัปเดตรุ่นของซอฟต์แวร์ที่เขาแก้ไขเรื่องความปลอดภัยครับ

WordPress และ CMS อื่นๆ

ใครใช้เวิร์ดเพรส ลองดูหน้านี้ครับ มีอะไรที่พอทำตามได้บ้าง เช่นการตั้ง permission ของ directory ต่างๆ การปิดไม่ใช้แก้ไขไฟล์ของเวิร์ดเพรสผ่านหน้า dashboard ได้
https://codex.wordpress.org/Hardening_WordPress

คนใช้ Joomla, Drupal หรือ CMS อื่นๆ ลองเสิร์ชดูครับ ผมว่ามีแน่ๆ
https://docs.joomla.org/Security
https://www.keycdn.com/blog/drupal-security/

พอทำได้เบื้องต้นไปก่อน-แต่ในระยะยาวก็ต้องลงทุนน่ะ

ทั้งหมดที่เขียนมานี้ เป็นของที่ ถ้าเขียนเว็บได้ ตั้งค่าเว็บไซต์เบื้องต้นได้ อัปโหลดไฟล์ขึ้นไปเซิร์ฟเวอร์ได้เอง ก็น่าจะพอทำตามตัวอย่างในลิงก์ได้ครับ

แน่นอนว่าถ้าจะให้ดี ก็ควรปรึกษากับคนที่ชำนาญเรื่องความปลอดภัยของเว็บไซต์ (ซึ่งก็อาจจะมีค่าใช้จ่ายน่ะแหละ แต่อันนี้ก็ต้องไปอธิบายกันในองค์กรว่า มันสำคัญยังไง ทำไมถึงควรจ่าย – คิดมันอยู่ในหมวดเดียวกับรปภ.ไรงี้ได้ไหม อันนั้นยังจ่ายได้เลย :p)

คำเตือน

ผมไม่ใช่ผู้เชี่ยวชาญด้านนี้ ไม่ต้องมาถามผมเรื่องนี้ lol
ทั้งหมดนี้อาศัยจำจากเพื่อนๆ ที่เขาทำงานพวกนี้ และอ่านๆ เอาในเน็ตทั้งนั้น

แต่นั่นหมายความว่า นักออกแบบเว็บและคนทำเว็บไซต์ทั่วไปทุกคน ก็เข้าใจเรื่องพวกนี้ในเบื้องต้นได้ครับ ไม่ต้องเป็นผู้เชี่ยวชาญด้านความปลอดภัยมากๆ ก็พอจะตามประเด็นและป้องกันตัวเองได้ในระดับหนึ่งครับ 🙂

ชุมชนความปลอดภัยเว็บ

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

https://www.facebook.com/groups/2600Thailand/
https://www.facebook.com/groups/owaspthailand/

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

อีกกรุ๊ปในเฟซบุ๊กที่ก็เข้าไปถามได้เหมือนกัน คือกลุ่มสมาคมโปรแกรมเมอร์ไทยครับ กลุ่มนี้ใหญ่และหลากหลายครับ https://www.facebook.com/groups/ThaiPGAssociateSociety/

เพิ่มเติม

  • คำแนะนำในการเก็บรหัสผ่านในระบบสำหรับนักพัฒนาซอฟต์แวร์ และผู้ดูแลระบบไอที@FordAntiTrust แนะนำวิธีการเก็บ “ข้อมูลตัวแทนรหัสผ่าน” ที่ทำให้เราไม่จำเป็นต้องเก็บรหัสผ่านต้นฉบับ ทำให้แม้ระบบถูกเจาะหรือข้อมูลรั่ว ข้อมูลที่หลุดไปก็ไม่ใช้รหัสผ่านที่เอาไปใช้ได้ทันที ต้องใช้เวลาในการย้อนรอยหารหัสผ่านจริงๆ ทำให้ผู้ใช้พอมีเวลาบ้างในการเปลี่ยนไปใช้รหัสผ่านใหม่
  • การออกแบบระบบให้รับ Request เยอะๆ — อันนี้ไม่ใช่ระดับพื้นฐานละ แต่เห็นว่าน่าสนใจดี เผื่อใช้เป็น reference เอาไปคุยตอนจ้างคนมาทำระบบ — คุณ ijemmy อธิบายแนวคิดเอาไว้ในโพสต์นี้ครับ (เรื่องจริงๆ ก็มีมุม security เหมือนกัน คือมุม availability หรือความพร้อมใช้ของระบบ ออกแบบยังไงให้ระบบไม่ล่มตอนมีคนใช้เยอะๆ พร้อมๆ กัน)

(เผยแพร่ครั้งแรกในเฟซบุ๊ก 1 พ.ค. 2018)

ภาพประกอบ “Key locker” โดย Jonathan O’Donnell สัญญาอนุญาตครีเอทีฟคอมมอนส์แบบแสดงที่มา-อนุญาตแบบเดียวกัน

อุตสาหกรรมไอทีล้มเหลวที่จะปกป้องผู้ใช้ เพราะเรา move fast and break things?

“Move fast and break things. Unless you are breaking stuff, you are not moving fast enough”

— Mark Zuckerberg

ไม่ใช่แค่เฟซบุ๊กนะครับ ผมว่าเกือบทั้งอุตสาหกรรมไอทีนั่นแหละที่มีปัญหา อุตสาหกรรมเราโตมาโดยคิดเรื่องความปลอดภัยสาธารณะเป็นอันดับท้ายๆ ไม่เหมือนพวกวิศวกรรมโยธา ที่สร้างตึกสร้างถนนที่คนใช้ร่วมกันเยอะๆ ทุกๆ วัน

การสร้างของที่ “ดีพอ” (good enough) เอาล่ะพอใช้ได้แล้ว แล้วเอาไปใช้ก่อน เสียก็ซ่อม ผิดก็แก้ไข เมื่อก่อนมันไม่ค่อยมีปัญหา เพราะเทคโนโลยีมันมาเกี่ยวกับชีวิตคนเราน้อย – ข้อผิดพลาดในการคำนวณเลขทศนิยมในซีพียูเพนเทียมไม่ได้ทำให้ใครตาย (อย่างน้อยก็ไม่มีบันทึกเอาไว้) เล่นเกมแล้วติดบั๊ก ไอเท็มไม่ออก ก็ไม่ได้ทำให้ใครเสียหาย (แม้จะอารมณ์เสีย)

แต่เดี๋ยวนี้ เกมมีการแข่งขันเป็นอาชีพ มีเรื่องเงินทองจำนวนมากมาเกี่ยวข้อง ก็ต้องหาวิธีจัดการที่ซีเรียสขึ้น, อุปกรณ์ที่ควบคุมด้วยคอมพิวเตอร์มาเกี่ยวกับร่างกายและสวัสดิภาพของเรามากขึ้น ก็ต้องมีการทดสอบต่างๆ ให้มั่นใจก่อนใช้จริง, ระบบประมวลผลข้อมูลอัตโนมัติเกี่ยวข้องกับการตัดสินใจเรื่องชีวิตเราในฐานะพลเมืองและในฐานะผู้บริโภคมากขึ้น (ได้หรือไม่ได้ทุนการศึกษา ได้หรือไม่ได้เงินกู้ ได้หรือไม่ได้งาน ได้หรือไม่ได้ประกัน…) มันก็ต้องมีการตรวจมาตรฐานตามเกณฑ์ตามข้อกำหนดของกฎหมาย audit กันมากขึ้นเป็นปกติ

Move Fast and Break Things.

“Move fast and break things.” (ให้แปลก็คงทำนองว่า พุ่งให้เร็ว ใส่ไม่ยั้ง พังไม่เป็นไร) เป็นคำขวัญที่โด่งดังของเฟซบุ๊ก เป็นหลักคิดที่ดีเพื่อการสร้างนวัตกรรม ทดลองทำ ดูว่าใช้ได้หรือไม่ เก็บข้อมูล ตรงไหนไม่ดีก็ทำใหม่ ทำซ้ำวนรอบไปเรื่อยๆ

ฟังดูโอเค แต่ถ้าเมื่อใดมันเป็นเรื่องที่จะกระทบกับสาธารณะ คุณทำแบบนี้คนจะเจ็บเยอะ มันไม่ควร โน่นครับ ไปทำใน sandbox ก่อนดีไหม เพื่อจำกัดความเสียหาย

ถ้า things ที่จะถูก break เป็น status quo หรือเป็นวิธีการทำธุรกิจแบบเก่าๆ น่ะ break ไปเถอะครับ break คนที่โดยเปรียบเทียบแล้วมีอำนาจมากกว่า

แต่ถ้า things ที่จะถูก break เป็นข้อมูลคนทั่วไป เป็นผู้ใช้บริการ ที่โดยเปรียบเทียบแล้วมีอำนาจน้อยกว่า พังแล้วมีโอกาสที่ชีวิตเขาจะพังไปอีกนาน โอ้โห คือคุณไม่มีความรับผิดชอบน่ะครับ (ซึ่งอันนี้เฟซบุ๊กก็ควรถูกด่าจริงๆ เพราะมีคนเตือนมาตลอด แต่เฟซบุ๊กก็ไม่ได้สนใจ)

ถ้าตอนนี้จะ “เห็นใจ” มาร์ก ก็มีแค่เรื่องนี้ล่ะครับ คือทุกคนรุมเฟซบุ๊กราวกับว่าคนอื่นในอุตสาหกรรมไม่ได้ทำงานในโหมดนี้กันเลย (หรือเอาจริงๆ คนที่เห็นใจมาร์กจำนวนหนึ่งก็คือคนที่ทำงานในโหมดนี้แหละ รู้สึกว่าการ break things มันก็โอเคนี่นา มีปัญหายังไงเหรอ ไม่เข้าใจ) คือผมว่ามันห่วยทั้งอุตสาหกรรม

ถ้าอุตสาหกรรมไอทีกำลังจะทำสิ่งที่เป็นโครงสร้างพื้นฐานให้คนทั้งสังคมใช้ คุณจะ break things ง่ายๆ ไม่ได้ ชีวิตคนมันพังได้ยาวอยู่ ต่อให้แก้บั๊กแล้ว ก็ไม่ได้แปลว่าชีวิตมันจะหายพังทันที

อ้อ เฟซบุ๊กเปลี่ยนคำขวัญแล้วตั้งแต่ปี 2014 มาใช้ของใหม่ว่า “Move fast with stable infrastructure.”

(โพสต์ครั้งแรกในเฟซบุ๊ก 12 เม.ย. 2018)

ประชารัฐ? มีบริการสาธารณะอะไรบ้างไหม ที่ไม่ควรให้เอกชนทำ?

“TurboTax’s powerful lobbying against tax simplification is a great example of what happens when tech is deployed to ‘solve’ a political problem.”

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

บทความ Why I’m boycotting TurboTax this year พูดถึงความพยายามของรัฐบาลสหรัฐที่จะออกกฎหมายสร้างระบบให้ประชาชนไม่ต้องกรอกแบบฟอร์มภาษีหรือกรอกให้น้อยที่สุด และความพยายามล็อบบี้โดยบริษัทซอฟต์แวร์ช่วยกรอกแบบฟอร์มภาษีที่จะไม่ให้กฎหมายดังกล่าวผ่าน

เจอลิงก์บทความข้างบนนั้นในทวิตเตอร์ จาก @FrankPasquale เขาให้มุมมองน่าสนใจด้วยว่า นี่เป็นตัวอย่างหนึ่งที่ว่าทำไมปัญหาบางอย่างถึงไม่ควรเอาบริษัทเอกชนมาแก้ (เพราะบริษัทนี่ก็เหมือนสิ่งมีชีวิต มันต้องการมีชีวิตรอดให้นานที่สุด+ขยายพันธ์ อะไรที่จะทำให้แหล่งอาหารหายไปมันจะไม่ทำ มันจะช่วยคน “แก้” ความไม่สะดวกจากปัญหานั้นเป็นคราวๆ ไป แต่มันจะไม่ “ขจัด” ต้นตอของปัญหา)

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

ถ้าเมืองไทยนี่นึกถึงการลงทะเบียนแรงงานต่างด้าว ถ้าทำให้ง่าย บริษัทนายหน้าและธุรกิจที่เกี่ยวข้องคงได้รับผลกระทบ

บทความวิชาการนี้น่าสนใจ

Pasquale, Frank A., A Rule of Persons, Not Machines: The Limits of Legal Automation (March 6, 2018). George Washington Law Review, Forthcoming; U of Maryland Legal Studies Research Paper No. 20018-08. Available at SSRN: https://ssrn.com/abstract=3135549

(โพสต์ครั้งแรกในเฟซบุ๊ก 15 เม.ย. 2018)

ภาพประกอบ “Tabletop Assistant” โดย Matthew Hurst สัญญาอนุญาตครีเอทีฟคอมมอนส์แบบแสดงที่มา-อนุญาตแบบเดียวกัน

National Digital ID

Aadhaar เป็นระบบยืนยันตัวตนแห่งชาติของอินเดีย ดูแลโดยหน่วยงานชื่อ UIDAI (Unique Identification Authority of India) ถ้าจะเทียบกับของไทยตอนนี้ก็คือโครงการ National Digital ID

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

แต่ก็นั่นแหละ ตั้งแต่เปิดใช้มา มีข่าวเจ๊ง หลุด รั่ว ล่ม แทบทุกสัปดาห์ (ลองดูข่าวที่ Software Freedom Law Centre, India และ Centre for Internet and Society รวบรวมมา) และปัญหาที่เกิด ไม่ได้มีเพียงปัญหาทางเทคโนโลยี แต่มีปัญหาที่เกิดระหว่างชิ้นส่วนที่เอามาประกอบกันด้วย และรูรั่วอีกมาจากคนหรือระบบการทำงานขององค์กร

Sunil Abraham จากศูนย์ Centre for Internet and Society ที่อินเดีย เขียนไว้น่าสนใจว่ามันอาจจะเกิดความผิดฝาผิดตัวในสมมติฐานการออกแบบระบบ

“This is because the digital identity solution for the nation as conceived by Aadhaar architects is based on the problem statement of digital identity within a firm. Within a firm all internal entities can be trusted. But in a nation state you cannot make this assumption.”

คนออกแบบระบบอาจใช้โมเดลความปลอดภัยจากการออกแบบระบบสารสนเทศในองค์กร มาออกแบบระบบที่ใช้กับคนทั่วไป ซึ่งความแตกต่างคือ ในขณะที่เราพอจะเชื่อใจส่วนงานแต่ละส่วนในองค์กรได้ แต่เราทึกทึกเอาอย่างนั้นกับทุกหน่วยงานกับทุกคนในประเทศไม่ได้

กรณีโดนเอาบัตรประชาชนไปเปิดบัญชี เอาสำเนาบัตรประชาชนไปออกซิมใหม่ ฯลฯ พวกนี้อาจไม่ได้หมายความว่าตัวเทคโนโลยีบัตรประชาชนไม่ดี (คือมันอาจจะดีหรือไม่ดีก็ได้) เพราะสิ่งที่เกิดอาจเกิดตรงรอยต่อของระบบ หรือเกิดตรงคน ที่จัดการความเชื่อใจกันผิดพลาด ทึกทักกันไปเองว่าของที่ถูกส่งมาตรงหน้านั้นเชื่อถือได้ เพราะคนนั้นคนนี้ระบบนั้นระบบนี้ส่งมาให้ ก็เลยปล่อยผ่าน

ก็เรียนรู้จากบทเรียนในอดีตของเรา กับบทเรียนในปัจจุบันของประเทศอื่นกันไปครับ

ใครสนใจโครงการ Digital ID Platform ของไทย เชิญได้ที่เว็บไซต์ www.digitalid.or.th ครับ มีร่าง White Paper ให้โหลดไปอ่านด้วย นอกจากนี้ยังมีกิจกรรม open forum อยู่เป็นระยะ ถ้าสนใจเข้าร่วมก็ติดต่อทีมงานได้ครับ ข่าวสารส่วนหนึ่งเผยแพร่ทางเฟซบุ๊กด้วยที่เพจ National Digital ID

 

ตรวจสอบการจัดหาข้อมูลเข้าสำหรับระบบปัญญาประดิษฐ์

โมเดลหนึ่งในการพิจารณาการเลือกปฏิบัติของอัลกอริทึม แบ่งการพิจารณาออกเป็นส่วนๆ ดังนี้
Input -> Process -> Output(2) นี่มันอาจจะเป็นเหมือนกล่องดำ คือไม่สามารถบอกได้ชัดๆ ว่าเครื่องมันตัดสินใจอย่างไร การจะไปประเมินไปตรวจสอบก็ทำลำบาก

ที่ง่ายกว่าก็คือมาดูที่ (1) กับ (3) ถ้ามีข้อมูลอะไรที่ไม่ควรใช้ก็ไม่ให้มันวิ่งเข้าไปในระบบเลยตั้งแต่แรก กับไปดูว่าผลลัพธ์สุดท้ายมันโอเคหรือไม่ โดยทั้งหมดนี้ ให้พิจารณา (4) ซึ่งเป็นบริบทแวดล้อมด้วย

แต่โมเดลนี้ก็ไม่ชัดเจนว่า ใครเป็นผู้จัดหาข้อมูลเข้าดังกล่าว คือตัวโมเดลมันเหมือนกับว่า การตัดสินใจของเครื่องมันอยู่เฉพาะที่ (2)

เป็นไปได้ไหมว่า ปัญญาประดิษฐ์มันสามารถตัดสินใจเกี่ยวกับข้อมูลเข้าได้ด้วย ว่าจะเลือกข้อมูลชนิดไหนเข้ามา ด้วยปริมาณเท่าไหร่

เช่นโจทย์ตั้งต้นอาจจะบอกว่าให้เพิ่มอัตราการคลิกปุ่ม ‘ซื้อ’ จากสื่อสังคม ตอนแรกๆ ก็อาจจะใช้ข้อมูลประชากรอะไรก็ว่าไปเท่าที่คนจัดหามาให้ แต่ต่อมาผู้พัฒนาอาจจะเพิ่มความสามารถให้ระบบมันไปหาข้อมูลเพิ่มเติมได้เองจากเน็ต เช่นระบบสร้างการทดลองขึ้นมาได้เอง ส่งข้อมูลเดียวกันไปคนต่างกลุ่มประชากร หรือข้อมูลต่างกันไปคนกลุ่มประชากรเดียวกัน เพื่อหาข้อมูลพฤติกรรมที่ตัวระบบอยากได้

พูดง่ายๆ ก็คือว่า คอมพิวเตอร์สามารถตัดสินใจสร้างการทดลองและ incentive ได้เอง เพื่อให้มนุษย์กลุ่มต่างๆ มาป้อนข้อมูลเพิ่มให้มัน (แน่นอนว่า incentive พวกนี้ มาจากทรัพยากรที่เจ้าของระบบจัดหาให้ แต่เจ้าของระบบไม่ได้เป็นผู้ตัดสินใจจัดหาข้อมูลเองโดยตรง)

ถ้าเป็นแบบนี้ การประเมิน “ข้อมูลเข้า” (1) อย่างเดียวก็จะไม่พอไหม ต้องประเมิน “การจัดหาข้อมูลเข้า” (0) ด้วยอีกที?

ก่อนหน้านี้มันเป็น คอมเล่มเกมกับคอมกันเอง เพื่อฝึกฝน
ต่อไปมันจะเป็น คอมสร้างเกมขึ้นมาให้คนเล่นตามเกมนั้น เพื่อฝึกฝน

Collect -> Input -> Process -> Output

ออกแบบ User Interface และ User Experience กรณีศึกษาฉลากโภชนาการแบบใหม่ของสหรัฐ

องค์การอาหารและยาของสหรัฐ (USFDA) ปรับปรุงการออกแบบของฉลากโภชนาการใหม่ ให้ชัดเจนขึ้น บอกข้อมูลที่จำเป็น ปรับปรุงข้อมูลร้อยละที่ต้องการต่อวันให้ทันสมัยมากขึ้น และปรับปรุงการระบุหน่วยบริโภคให้เป็นไปตามพฤติกรรมจริงของผู้บริโภค

จะเห็นว่ามีการปรับ interface การแสดงผล ทำให้ข้อมูลสำคัญอย่างปริมาณแคลอรีปรากฏเด่นขึ้น ดูได้ง่ายขึ้น มองแว๊บเดียวก็เจอเลยฉลากโภชนาการใหม่ของสหรัฐ

นอกจากนี้ในส่วนของ experience คนทำตัวมาตรฐาน ก็เข้าใจว่า สุดท้ายคนกินก็ไม่ได้กินอาหารกันตามน้ำหนักหรือปริมาตรอาหาร แต่กินตามขนาดของบรรจุภัณฑ์ ดังนั้นการระบุหน่วยบริโภค จึงคำนึงถึงขนาดบรรจุภัณฑ์ด้วย เช่นน้ำอัดลมขวด 330 มล. กับขวดครึ่งลิตร ปกติคนก็กินหมดขวดเหมือนกัน ดังนั้นจึงนับเป็น 1 หน่วยบริโภคเหมือนกัน

ตรงนี้คนทำงานต้องไม่ทำงานแค่ส่วนกราฟิกหรือการออกแบบ interface แต่ต้องไปทำความเข้าใจพฤติกรรมผู้บริโภคจริงๆ ด้วยหน่วยบริโภคใหม่ตามอย.สหรัฐ

ลองเปรียบเทียบกับของประเทศไทยในปัจจุบัน
ฉลากโภชนาการของไทย

ข้อมูลและภาพจาก Banana Post – อย.สหรัฐดีไซน์ป้ายข้อมูลสารอาหารใหม่ ปรับสูตรโภชนาการ แจ้งน้ำตาลที่ใส่เพิ่ม (ภาพ 2 ภาพแรกดัดแปลงมาจากภาพของ USFDA)

(วันนี้นั่งเคลียร์ Desktop เจอรูปนี้เลยเอามาอัปบล็อก เผื่อหาย / Banana Post ตอนนี้เหมือนไม่ค่อยได้อัป สงสัยบก.หายตัว ถถถถถ)

Privacy by design, at the protocol level

Doing human rights right at the internet infrastructure level. Wow.

Read about this for quite sometime, the works by IETF and friends, but mostly from ones that related to HTTP/2 development. Today I’m learning more on these efforts (and beyond) during APC Member Meeting 2017. Thanks to Avri Doria.

Find out more RFC (request for comment) documents at Internet Architecture Board – Privacy and Security Program.

More explanations on human rights and internet engineering standards here:

Also these initiatives:

 

(photo by thierry ehrmann. Creative Commons Attribution License)