กรณีข้อมูลผู้ป่วยโรงพยาบาลเพชรบูรณ์หลุดรั่ว

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

ชื่อวอร์ดนี่ตั้งตามชื่อกลุ่มโรค ก็อาจเป็นข้อมูลอ่อนไหวได้

ประเภทสิทธิการรักษา บางประเภทบอกสถานะความพิการได้

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

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

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

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

แม้จนถึงตอนนี้ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 จะถูก “เลื่อน” หรือยกเว้นไม่ให้ใช้บังคับอยู่เกือบทุกมาตราที่เกี่ยวกับการคุ้มครอง (เลื่อนมา 2 รอบละ) แต่มาตรา 4 วรรค 3 ยังไงก็ยังใช้บังคับอยู่นะ

“ผู้ควบคุมข้อมูลส่วนบุคคลตามวรรคหนึ่ง (2) (3) (4) (5) และ (6) และผู้ควบคุมข้อมูลส่วนบุคคลของหน่วยงานที่ได้รับยกเว้นตามที่กำหนดในพระราชกฤษฎีกาตามวรรคสอง ต้องจัดให้มีการรักษาความมั่นคงปลอดภัยของข้อมูลส่วนบุคคลให้เป็นไปตามมาตรฐานด้วย”

และน่าจะมีอย่างน้อยอีก 4 พ.ร.บ.ที่พอจะใช้ได้ ในมุมของผู้ได้รับผลกระทบ

1) โดยตัวข้อมูล เนื่องจากเป็นข้อมูลสุขภาพ ก็มี พ.ร.บ.สุขภาพแห่งชาติ พ.ศ. 2550 แต่ในรายละเอียดน่าจะมีข้อจำกัดอยู่มาก เนื่องจากไม่ได้ระบุเรื่องข้อมูลรั่วไหลตรงๆ แต่อาจจะไปพึ่ง “ธรรมนูญว่าด้วยระบบสุขภาพแห่งชาติ” อีกต่อหนึ่ง ซึ่งไกลอยู่

ข้อ 69 ในธรรมนูญว่าด้วยระบบสุขภาพแห่งชาติ พ.ศ. 2552 “ผู้บริโภคที่ได้รับความเสียหายจากการบริโภคสินค้าหรือการบริการต้องได้รับการชดเชยและเยียวยาอย่างมีประสิทธิภาพ เหมาะสม และรวดเร็ว”

ข้อ 1 (6) ในหมวดการคุ้มครองผู้บริโภคด้านสุขภาพ ของธรรมนูญว่าด้วยระบบสุขภาพแห่งชาติ ฉบับที่ 2 พ.ศ. 2559 “สิทธิในการร้องเรียนและสิทธิในการได้รับการชดเชยเยียวยาความเสียหายจากการบริโภค”

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

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

3) ซึ่งพอเป็นหน่วยงานรัฐ ก็จะเข้าอีกกฎหมายคือ พ.ร.บ.การบริหารงานและการให้บริการภาครัฐผ่านระบบดิจิทัล พ.ศ. 2562 ในมาตรา 12

“เพื่อให้การบริหารงานและการให้บริการภาครัฐผ่านระบบดิจิทัลเป็นไป
ตามวัตถุประสงค์ตามมาตรา 4 […] ให้หน่วยงานของรัฐ […] ดำเนินการดังต่อไปนี้ให้เป็นไปตามธรรมาภิบาลข้อมูลภาครัฐตามมาตรา 8 จัดให้มีมาตรการหรือระบบรักษาความมั่นคงปลอดภัยในการเข้าสู่บริการดิจิทัลของหน่วยงานของรัฐ เพื่อให้มีความพร้อมใช้ น่าเชื่อถือ และสามารถตรวจสอบได้ โดยอย่างน้อยต้องจัดให้มี ระบบป้องกันหรือรับมือกับภัยคุกคามหรือความเสี่ยงทางไซเบอร์ตามกฎหมายว่าด้วยการรักษาความมั่นคงปลอดภัยไซเบอร์ […]”

(ดูประกาศคณะกรรมการพัฒนารัฐบาลดิจิทัล เรื่อง ธรรมาภิบาลข้อมูลภาครัฐ เพิ่ม)

  1. พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 ซึ่งถูกอ้างอิงจากกฎหมายอื่นๆ ข้างบน

ตอนนี้ขั้นต่ำสุดคือ โรงพยาบาลและกระทรวงต้องรีบแจ้งเจ้าของข้อมูล ว่าเกิดอะไรขึ้น ตัวเขาจะได้ระวัง เพื่อลดผลกระทบ

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

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

หมอนวนรรน ธีระอัมพรพันธุ์ โพสต์ความเห็นส่วนตัวต่อเรื่องนี้ไว้ในเฟซ

อนุญาตให้เรียนไม่สดเพื่อเพิ่มโอกาสเข้าถึง + การสร้างพื้นที่ปลอดภัยระหว่างบันทึกการสอน

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

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

เวลาที่สะดวกสำหรับการเรียนที่ขึ้นกับทรัพยากรของผู้เรียน

“เวลาที่สะดวก” ในแง่การเรียนออนไลน์นี้ จำเป็นต้องคำนึงถึงปัจจัยดังต่อไปนี้เป็นอย่างน้อย

1) การเข้าถึงอุปกรณ์ที่เหมาะสม (โทรศัพท์หรือคอมพิวเตอร์ที่มีความสามารถเพียงพอจะเปิดสื่อการสอนได้อย่างครบถ้วน)

2) ความเร็วและความเสถียรของอินเทอร์เน็ตที่เหมาะสม

3) พื้นที่ที่เหมาะสม เช่น ที่นั่ง ความสงบ (อาจเป็นในที่พักอาศัยหรือที่อื่น เช่น บ้านญาติ ร้านเน็ต)

“เวลาที่สะดวก” คือช่วงเวลาที่ผู้เรียนสามารถจัดหา (1), (2), และ (3) ได้พร้อมกัน

กรณีบ้านเดียวกันมีอุปกรณ์ตาม (1) เพียงเครื่องเดียว แต่มีสมาชิกในบ้านหลายคนที่ต้องทำงานหรือเรียน การเรียนแบบสด (real time) จะสร้างปัญหาการแย่งกันใช้ทรัพยากรที่มีจำกัด

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

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

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

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

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

ทั้งนี้ “เวลาที่สะดวก” ที่ผู้เรียนสามารถจัดหา (1), (2), และ (3) มาได้พร้อมกันนี้ ไม่จำเป็นจะต้องเป็นเวลาที่ต่อเนื่องกัน เช่น สำหรับคาบเรียน 2 ชั่วโมง ในสัปดาห์หนึ่ง ผู้เรียนรายหนึ่งอาจมีเวลาที่สะดวกตอน 11:30-12:30 หนึ่งชั่วโมงในวันจันทร์ และ 20:00-21:00 อีกหนึ่งชั่วโมงในวันอังคาร และเวลานี้อาจเปลี่ยนไปในอีกสัปดาห์

การบันทึกกับพื้นที่ปลอดภัยในการเรียนการสอน

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

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

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

หากการบันทึกไม่ได้ทำโดยผู้สอนเอง แต่มีเจ้าหน้าที่หรือบุคคลที่สามอื่นทำการบันทึกให้ ในการบันทึก ผู้สอนจะต้องรู้อยู่เสมอด้วยว่ามีการบันทึกอยู่

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

การเผยแพร่สื่อบันทึกการเรียนการสอนสู่สาธารณะ

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

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

การคำนึงถึงสมาธิในพื้นที่ทางกายภาพที่ไม่ใช่ห้องเรียนโดยเฉพาะ

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

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

ฝากทางสถานศึกษาต่างๆ พิจารณาสำหรับภาคการศึกษานี้หรือที่จะถึงนี้ครับ

แถลงการณ์ว่าด้วยการสืบย้อนผู้ใกล้ชิด (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.

เขียนและออกแบบหน้าตานโยบายความเป็นส่วนตัว-นโยบายการใช้ข้อมูล

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

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

หน้าแรกของนโยบายความเป็นส่วนตัวของเว็บไซต์ Juro
หน้าแรกของนโยบายความเป็นส่วนตัวของเว็บไซต์ Juro

 

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)

หลักการ/กลไกการคุ้มครองข้อมูลใหม่ใน GDPR ของสหภาพยุโรป #infosec17

วันนี้เป็นวันที่ 2 ที่มางาน Infosecurity Europe ที่ลอนดอน ได้ฟังหลักๆ 2 เวที เป็น Keynote ทั้งคู่ อันแรกตอนเช้า ฟัง Bruce Schneier พูดหัวข้อ Artificial Intelligence & Machine Learning: Cybersecurity Risk vs Opportunity? ส่วนตอนบ่ายฟัง EU GDPR Special Focus – Extended Session โพสต์นี้เล่าของตอนบ่ายก่อน ส่วนของตอนเช้ากับของงานวันแรกยังไม่ได้เขียนถึง เดี๋ยวทยอยลงนะ

เรื่อง General Data Protection Regulation (GDPR) ซึ่งเป็นกฎหมายคุ้มครองข้อมูลตัวใหม่ของสหภาพยุโรปที่ประกาศเมื่อปีที่แล้วและจะมีผลบังคับใช้ในวันที่ 25 พฤษภาคม 2018 นี่มาแรงมากๆ เดินไปไหนในงานก็เห็นคำนี้ มีในเกือบทุกทอล์ก เพราะเหลือเวลาอีกไม่ถึง 1 ปีแล้ว ที่ทุกบริษัท ทุกหน่วยงาน จะต้องปฏิบัติตามกฎหมายดังกล่าว ซึ่งมีผลบังคับใช้เหมือนกันหมดทั่วสหภาพยุโรป (หัวข้อตอนบ่ายที่ไปฟังมาอันนี้ฮิตมาก คนต่อแถวยาวเหยียด และเวลาก็ได้ยืดมากกว่าหัวข้ออื่น เป็น extended session)

Ready for GDPR (?)

Peter Brown ซึ่งเป็นเจ้าหน้าที่เทคโนโลยีอาวุโสของ Information Commissioner’s Office (ICO – สำนักงานคณะกรรมการข้อมูลข่าวสารของสหราชอาณาจักร) เป็นคนพูดเปิด เล่าถึงหลักการทั่วไปของ GDPR กับความพร้อมของ ICO ในฐานะองค์กรกำกับและคุ้มครองข้อมูลส่วนบุคคลของสหราชอาณาจักร ว่าได้เตรียมข้อแนะนำและหลักปฏิบัติอะไรต่างๆ ให้กับภาคธุรกิจปรับตัวและเปลี่ยนผ่านอย่างไรบ้าง

Peter บอกว่าหลักการคุ้มครองข้อมูลของ GDPR นั้น ไม่ต่างจากที่กฎหมายคุ้มครองข้อมูล หรือ Data Protection Act (DPA) ที่สหราชอาณาจักรมีอยู่ในปัจจุบัน เพียงแต่เพิ่มหลักการขึ้นมา 2 เรื่อง คือ Security และ Accountability & Governance

อธิบายต่อ (ผมพูดเอง) ก็คือ เดิม DPA นั้นพูดถึงเฉพาะตัวข้อมูลและการประมวลผลข้อมูล แต่ GDPR ยังพูดถึงระบบที่ใช้ประมวลผลข้อมูล (เน้นเชิงเทคนิค – technical measures) และความรับผิดและการบริหารจัดการของผู้ที่เกี่ยวข้อง (เน้นเชิงกระบวนการ – organizational measures)

จริงๆ ข้อคำนึงเหล่านี้ มีอยู่แล้วเงียบๆ ใน DPA แต่ GDPR ระบุให้มันแยกออกมาอย่างชัดเจน

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

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

สิ่ง “ใหม่” ที่ถูกพูดถึงในหลักการ Accountability & Governance ของ GPDR ก็คือหลัก data protection by design, data protection by default, และ data protection impact assessment (DPIA) — “ใหม่” ในที่นี้ หมายถึงมันไม่เคยถูกบังคับในกฎหมายมาก่อน

(เรื่อง data protection by design นี่ มีหลายบริษัทที่มาออกงานพูดถึง ตั้งแต่การออกแบบ user experience ที่สนับสนุน security, การทำระบบให้ลด cognitive load เพื่อให้คนทำงานอยู่ในภาวะมีสติ, การออกแบบให้ AI มาช่วยคนตัดสินใจได้ดีขึ้น)

ทั้งหลักการ Security และ Accountability ที่มีใน GDPR เรียกว่าเป็นความพยายามให้เกิดสภาพแวดล้อมที่ลดความเสี่ยงในการรั่วไหลของข้อมูล ไม่ได้มาเน้นเฉพาะการลงโทษหลังข้อมูลรั่วแล้ว นอกจากนี้ ในส่วนของ Security ก็ยังมีการกำหนดมาตรฐานการแจ้งเตือนในกรณีที่พบข้อมูลรั่วไหล (ทาง Article 29 Working Party จะออกแนวปฏิบัติมาภายในปีนี้)

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

หน้าที่ของผู้ประมวลผล-ผู้ควบคุมข้อมูลคือ จะต้องสามารถแสดงหลักฐาน (evidence) ให้ได้ว่า ตัวเองได้ทำสิ่งที่ควรทำทั้งหมดแล้ว

ลองคิดถึงกฎหมายเกี่ยวกับความปลอดภัยของอาคาร ที่ต่อให้ไฟยังไม่ไหม้ แต่ถ้าพบว่าไม่มีทางหนีไฟ ไม่มีอุปกรณ์จับควัน-แจ้งเตือน-ดับเพลิง ที่ได้มาตรฐานอย่างเพียงพอ ก็มีความผิดอยู่ดี

ใน GDPR หากมีกรณีข้อมูลรั่วไหล หากผู้ประมวลผล/ผู้ควบคุมข้อมูลสามารถแสดงได้ว่า ได้ทำตามมาตรฐานที่กำหนด ยังมีโอกาสได้รับลดหย่อนโทษลงด้วย

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

ยากและไม่ค่อยปลอดภัย Facebook Wi-Fi #FAIL @ ห้องสมุด TCDC

วันนี้มีสัมภาษณ์ เลยลองนัดที่ TCDC ใหม่ ตรงไปรษณีย์กลาง บางรัก ช่วงนี้จนถึงสิ้นเดือนพฤษภาคมเขาเปิดให้ใช้ห้องสมุดฟรี

พบว่าการใช้ไวไฟที่นี่วุ่นวายไปหน่อย คือคงตั้งใจดี ทางหนึ่งก็จะได้ยอดเช็กอินเพิ่ม อีกทางก็คงอยากให้ผู้ใช้ล็อกอินได้ง่ายๆ เลยใช้ Facebook Wi-Fi ในการลงทะเบียน (พูดอีกแบบคือ ฝากภาระในการบันทึกผู้เข้าใช้ระบบให้เฟซบุ๊กทำ – จะไม่ทำเลยก็คงไม่ได้ เพราะพ.ร.บ.คอมพิวเตอร์กำหนดให้บันทึกข้อมูลการจราจร-ที่ระบุตัวผู้ใช้ได้)

รวมๆ คือเราพบว่าการล็อกอินไวไฟที่ TCDC ไม่ค่อยเป็นมิตรเท่าไร แถมอาจส่งเสริมพฤติกรรมเสี่ยงด้านความปลอดภัยของข้อมูลส่วนบุคคล โพสต์นี้จะบอกว่าทำไม ปัญหาน่าจะอยู่ตรงไหน และน่าจะแก้ไขยังไงได้บ้าง (ใครใช้ Facebook Wi-Fi ก็อาจจะเจอปัญหาแบบเดียวกันนี้ได้ ไม่เฉพาะ TCDC – เคยเจอร้านกาแฟบางร้านก็ใช้)

มั่นใจว่าไม่ได้เจอปัญหานี้อยู่คนเดียว เพราะระหว่างที่นั่งทำงานอยู่ที่นั่นตั้งแต่ประมาณ 12:40 จนถึงราว 17:00 ได้ยินโต๊ะรอบๆ ถามกันเป็นระยะถึงเรื่องต่อไวไฟ กดตรงไหน ทำไมต่อไม่ได้

บางส่วนอาจจะเกี่ยวกับ UI (เช่น พอ CSS ไม่โหลด ตำแหน่งของแบบฟอร์มที่จะต้องกรอกก็สับสน) แต่ยังมีส่วน UX ด้วย ที่ประสบการณ์ตั้งแต่ต้นจนจบกว่าจะต่อเน็ตได้มีอุปสรรคพอสมควร ซึ่งถ้ายังยืนยันจะใช้ Facebook Wi-Fi อยู่ คงต้องหาทางไปตั้งค่าให้ถูกต้องและรองรับผู้ใช้ที่มีความต้องการหรือข้อจำกัดแตกต่างกันไป

นี่คือเครือข่ายไวไฟที่พบที่บริเวณห้องสมุดชั้น 5 ของ TCDC (จับภาพหน้าจอมาเมื่อ 19 พ.ค. 2560 ประมาณ 14:30)

TCDC wifi list

Guest@TCDC เป็นเครือข่ายสำหรับผู้ใช้ทั่วไป ส่วน Member@TCDC นั้นสำหรับสมาชิก (บุคคลทั่วไป 1,200 บาท/ปี นักศึกษา 600 บาท/ปี) เนื่องจากเรายังไม่ได้เป็นสมาชิก ก็ลองเลือก Guest@TCDC

ซึ่งก็เหมือนกับการเข้าใช้เครือข่ายไวไฟสาธารณะทั่วไป ที่เราคาดได้ว่าจะมีหน้าจอล็อกอินขึ้นมา ให้ใส่ชื่อหรือรหัสเพื่อเข้าใช้ ของ Guest@TCDC ก็จะเด้งหน้าจอนั้นขึ้นมา เพียงแต่มันจะแสดงคำเตือนนี้มาคั่นก่อน

Cannot verify identity of the log in page

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

ถ้ากด “Show Certificate” เพื่อดูรายละเอียดก็จะพบว่า เป็นใบรับรองที่ออกโดย Root Certificate Authority (Root CA – หน่วยงานออกใบรับรองระดับบนสุด) ที่ชื่อว่า cmx.cisco.com และจะหมดอายุวันที่ 12 ตุลาคม 2560 เวลา 01:59:08 (UTC+7) แต่เว็บเบราว์เซอร์ของเรา ไม่เชื่อถือ Root CA รายนี้ มันก็เลยขึ้นคำเตือน

เครือข่ายไวไฟ Member@TCDC ก็พบปัญหาเดียวกัน

ถ้าอยากจะใช้งานเครือข่ายไวไฟ ก็จำเป็นต้องไปให้ถึงหน้าล็อกอินให้ได้ จะไปให้ถึงหน้าล็อกอิน ก็ต้องยอมกด “Continue” ไป ทั้งๆ เราไม่แน่ใจว่ามันปลอดภัยหรือไม่ หรือจะเกิดอะไรขึ้นหลังจากนี้

พอกด Continue ไปแล้ว จะเจอหน้าจอให้ “เช็กอินบน Facebook เพื่อรับการเข้าถึงอินเทอร์เน็ตฟรี”

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

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

(ลิงก์ “ข้ามการเช็กอิน” นั้นไม่สามารถคลิกได้ – ส่วนช่องที่เขียนว่า “ป้อนรหัส Wi-Fi” นั้นก็ใช้ไม่ได้ สอบถามเจ้าหน้าที่ TCDC แล้ว ไม่มีการออกรหัสให้ใช้กับช่องนี้)

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

ถ้ามาถึงหน้าจอนี้ หมายถึงใกล้สำเร็จแล้ว แต่เราจะเจอปัญหากับใบรับรองเหมือนกับที่เราเจอไปแล้วทีหนึ่ง ตรงนี้เว็บเบราว์เซอร์จะแจ้งว่ามันไม่สามารถยืนยันได้ว่าหน้าจอนี้ที่อ้างว่ามาจากหมายเลขไอพี 1.1.1.1 นั้นเป็นอย่างที่อ้างจริงๆ ถ้าเราเชื่อใจ อยากไปต่อ ก็ให้กด “Continue” อีกทีหนึ่ง

บนมือถือ (iOS) จะเป็นแบบนี้

Canno Verify Server Identity "1.1.1.1"

ถ้ากด “Continue” ก็จะมีหน้าจอให้เช็กอิน ประกาศให้โลกรู้ว่าเรามาอยู่ที่ TCDC แล้วนะ พอเราเช็กอินเสร็จ ก็จะใช้อินเทอร์เน็ตได้แล้ว

สรุป

พบว่าการเข้าใช้เครือข่ายไวไฟ Guest@TCDC นั้นเป็นประสบการณ์ที่ยากลำบากมาก โดยปัญหาที่พบคือ

  • พบปัญหาใบรับรองออกโดย CA ที่เว็บเบราว์เซอร์ไม่ให้การยอมรับถึง 2 ครั้ง ทั้งช่วงก่อนหน้าจอล็อกอินและช่วงใกล้จะล็อกอินสำเร็จ
    • ผู้ใช้ทั่วไปอาจจะทำตัวไม่ถูกว่าให้ทำอย่างไรต่อ เพราะข้อความเตือนของเว็บเบราว์เซอร์อาจเข้าใจยาก
    • กรณีผู้ใช้ TCDC ถูกสอนว่า “ไม่ต้องสนใจ คลิก Continue” ไปเลย ก็จะเป็นการส่งเสริมพฤติกรรมเสี่ยงให้กับผู้ใช้ โดยอาจเข้าใจไปว่า ต่อไปหากเจออาการแบบนี้อีกไม่ว่ากับเครือข่ายไหน หากอยากไปต่อ ก็ให้กด “Continue” เสีย ก็จะแก้ปัญหาได้ พฤติกรรมเช่นนี้ทำให้ผู้ใช้อาจตกเป็นเหยื่อของอาชญากรรมคอมพิวเตอร์หรือข้อมูลส่วนบุคคลถูกขโมยได้
    • ปัญหาใบรับรองนี้ พบว่าไม่ได้เป็นเฉพาะกับหน้าจอล็อกอินไวไฟของ TCDC หน้าเว็บไซต์หลักของ TCDC ก็มีปัญหานี้ด้วย 🙁TCDC Bad Certificate
  • หน้าจอ Facebook Wi-Fi ในบางกรณี อาจแสดงผลไม่ชัดเจนเพียงพอ ว่าผู้ใช้จะต้องกรอกแบบฟอร์มล็อกอินอันไหน ผู้ใช้ไม่สามารถรู้ได้เองอย่างชัดเจน ว่าจะต้องเลื่อนหน้าจอลงมาเพื่อคลิกลิงก์ “เข้าสู่ระบบ” เพื่อจะไปยังหน้าจอล็อกอินอีกอัน ซึ่งจะสามารถนำไปสู่การเช็กอินและใช้อินเทอร์เน็ตได้
  • ใครไม่มีบัญชีเฟซบุ๊กจะใช้อินเทอร์เน็ตผ่านเครือข่าย Guest@TCDC ไม่ได้ เนื่องจากผู้ใช้จะต้องล็อกอินเฟซบุ๊กก่อน
    • หรือถ้าวันไหนเฟซบุ๊กล่มหรือถูกปิดไป ก็อาจจะล็อกอินไม่ได้เหมือนกัน
    • เจ้าหน้าที่ Info Guru ที่ TCDC ยืนยันว่าไม่มีรหัสให้ป้อนเพื่อข้ามการล็อกอินเฟซบุ๊ก
  • ผู้ใช้ถูกบังคับให้ต้องเช็กอิน เนื่องจากลิงก์ “ข้ามการเช็กอิน” ใช้งานไม่ได้  ซึ่งก็คงไม่ใช่ผู้ใช้ทุกคนที่รู้สึกสะดวกเช็กอินหรือรู้วิธีการตั้งค่าโพสต์เช็กอินให้เป็นส่วนตัว (สำหรับ Facebook Wi-Fi เจ้าของหน้าเฟซบุ๊กอย่าง TCDC สามารถตั้งค่า “โหมดบายพาส” ให้ผู้ใช้ไม่ต้องเช็กอินก็ได้ แค่ล็อกอินเฟซบุ๊กก็พอ)
    • สอบถามเจ้าหน้าที่เพิ่มเติม ได้ข้อมูลว่า ถ้าเป็นบนมือถือ จะข้ามได้ แต่เท่าที่ลองบนเดสก์ท็อปข้ามไม่ได้
  • กรณีผู้ใช้ใช้การยืนยันตัวตนแบบสองชั้นและล็อกอินผ่านมือถือเครื่องเดียวกัน จะมีเวลาไม่เกิน 30 วินาทีในการล็อกอิน เนื่องจากถ้าสลับหน้าจอมาเพื่อดูโค้ด หน้าล็อกอินจะหายทันที
  • แถม: พบว่าโปรแกรมอีเมล (อย่าง Mail บน macOS กับ iOS หรือ Thunderbird) ใช้ไม่ได้ พอร์ต 993 (SSL/TLS encrypted IMAP) และ 465 (SSL/TLS encrypted SMTP) ถูกปิด และแอปแชต Signal ก็ใช้ไม่ได้

ข้อเสนอแนะ

  • ที่แก้ไขได้โดยไม่ต้องรอฝ่ายนโยบายนัก เพราะน่าจะเป็นเรื่องการตั้งค่าเครือข่าย คือเรื่องใบรับรองและเรื่องหน้าจอล็อกอิน กรณีใช้ Cisco น่าจะลองดูเอกสารตรง Clients Redirected to External Web Authentication Server Receive a Certificate Warning กับ Cisco Wireless 1.1.1.1/login.html redirect issues (ผมไม่มีความรู้เรื่องการติดตั้งระบบเครือข่ายใดๆ นี่เป็นการลองค้นข้อมูลเบื้องต้นเท่านั้น)
  • ปัญหาการโหลด CSS ไม่ขึ้น ส่งผลให้การใช้งานหน้าจอล็อกอินสับสน ควรหาทางแก้ไข (ผมไม่แน่ใจว่าเกิดเพราะอะไร)
  • ควรอย่างยิ่งที่จะมีทางเลือกให้ผู้ที่ไม่ได้ใช้เฟซบุ๊ก หรือไม่สะดวกจะล็อกอินด้วยเฟซบุ๊ก (เช่นติดปัญหาการยืนยันตัวตนแบบสองชั้น) ให้สามารถกรอกรหัสไวไฟเพื่อเข้าใช้งานได้ (เลือกใน Facebook Wi-Fi ได้)
  • ควรมีทางเลือกให้ผู้ใช้เฟซบุ๊กหลังจากล็อกอินแล้วไม่จำเป็นต้องเช็กอินก็ใช้งานได้ (เลือกใน Facebook Wi-Fi ได้)
  • พิจารณาเปิดพอร์ตพื้นฐานอย่างอีเมล (IMAP, POP, SMTP)

ใครมีโอกาสก็มาลองใช้งานดูครับ TCDC ใหม่ ทางเข้าห้องสมุดอยู่ชั้น 5 หลังจากนี้ถ้าไม่ใช่สมาชิก ก็ใช้บริการได้ โดยจ่ายค่าบริการรายวัน 100 บาท/วัน มีโต๊ะทำงาน มีปลั๊กไฟ มีไวไฟ (ถ้าเข้าได้) ถูกกว่าไปนั่งร้านกาแฟอีก (ถ้าไม่รวมค่ารถ :p) นอกจากนี้ยังมีส่วนนิทรรศการ Maker Space และส่วนอื่นๆ อีก

อ้อ นอกจากที่กรุงเทพ ที่เชียงใหม่ก็มี TCDC นะ และที่ขอนแก่นก็กำลังจะเปิด (ตอนนี้มี mini TCDC อยู่ในมหาวิทยาลัยขอนแก่นอยู่แล้ว)

คุยกับกระทรวงดิจิทัลเรื่องร่างพ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล

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

เรื่องที่คุยกัน เช่น

  • ควรเพิ่มนิยามของคำว่า “ผู้ประมวลผลข้อมูล” (data processor) หรือไม่ แตกต่างจาก “ผู้ควบคุมข้อมูล” (data controller) อย่างไร
  • อะไรคือ Legitimate Interests ที่จะอนุญาตให้ผู้ควบคุมข้อมูลสามารถประมวลผลข้อมูลได้แม้ไม่ตรงตามวัตถุประสงค์ที่เจ้าของข้อมูลให้ความยินยอมไว้เมื่อคราวที่เก็บรวบรวมข้อมูล
  • มีความต้องการนำข้อมูลไปวิเคราะห์ (เช่นในลักษณะ Big Data) หากได้ทำให้ข้อมูลเชื่อมโยงกลับมาระบุตัวบุคคลไม่ได้แล้ว ยังจะต้องขอความยินยอมอีกหรือไม่ (เรื่องนี้เคยพูดไปบ้างแล้ว โดยยกตัวอย่างข้อมูลสุขภาพ อ้างงานของ Sweeney (2000))
  • จะทำอย่างไรกับข้อมูลที่เก็บรวบรวมมาก่อนกฎหมายคุ้มครองข้อมูลประกาศใช้ – ให้ใช้ต่อไปได้เลยโดยไม่ต้องขอความยินยอมใหม่? หรือต้องขอใหม่? หรือกำหนดระยะผ่อนผันให้ใช้ได้ไประยะเวลาหนึ่ง แต่ถ้าพ้นช่วงนี้แล้วไม่ได้รับความยินยอมใหม่ ก็ต้องหยุดใช้และทำลายข้อมูลทิ้ง?
  • การกำหนดข้อยกเว้นหรือกำหนดให้กิจการใดที่ไม่อยู่ใต้บังคับของกฎหมายนี้
  • หลักการของ EU General Data Protection Regulation และ APEC Privacy Framework รวมถึง APEC Cross Border Privacy Rules (CBPR) system

และมีอีกบางประเด็นที่ไม่ได้คุยระหว่างประชุม แต่กลับมาค้นเพิ่ม เช่นนิยาม “profiling” ของ GDPR และการพรางข้อมูล (data masking/data obfuscation)

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

ข้อมูลประกอบการนำเสนอความเห็นและข้อเสนอแนะ แนวทางแก้ไขหรือปรับปรุง ร่างพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. …. PDF | OpenDocument Text

ใครมีความคิดเห็นอะไรกับตัวร่าง (ขณะนี้ใช้ร่างฉบับที่สำนักงานคณะกรรมการกฤษฎีกาตรวจพิจารณาแล้ว เรื่องเสร็จที่ 1135/2558ในการพิจารณา) ก็ส่งความคิดเห็นไปได้ที่ คณะทำงานร่างแก้ไขกฎหมาย กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม — ทางคณะทำงานแจ้งว่าทางเขามีกำหนดส่งเรื่องออกไปภายในเดือนเมษายนนี้ ก็เหลือเวลาอีกไม่มากแล้วครับ

กฎหมายคุ้มครองข้อมูลไทย จะเดินตามโมเดลไหนดี: สหภาพยุโรป หรือ เอเปค?

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

ผมก็เคยอธิบายแบบเร็วๆ อย่างนั้นเหมือนกันนะ คือในแง่ที่มามันก็น่าจะทำนองนั้น

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

เราไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่ง สิทธิมนุษยชนกับเศรษฐกิจทั้งสองอย่างนี้ไปด้วยกันได้ โดยเฉพาะเศรษฐกิจดิจิทัลที่มันต้องตั้งอยู่บนฐาน “ความไว้เนื้อเชื่อใจกัน”

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

การมีมาตรฐานด้านสิทธิที่ดี ก็เพื่อให้คู่ค้าของเราไว้ใจเรา เชื่อใจเรา ว่าเราให้ความสำคัญกับคุณค่าที่เขาให้ความสำคัญ มันแยกกันไม่ขาด

….

อีกประเด็นคือ ของ EU ที่เราคุยกันเนี่ย อันนึงคือ General Data Protection Regulation (Regulation (EU) 2016/679) กับอีกอันคือ Directive (EU) 2016/680 ซึ่งทั้งคู่เพิ่งออกมาเมื่อปีที่แล้ว (2016 และจะมีผลบังคับใช้ในปี 2018)

ในขณะที่ APEC Privacy Framework ออกเมื่อปี 2005 (เริ่มร่างปี 2003 adopted ปี 2004 แต่ finalized ปี 2005)

ตอนปี 2005 นี่โลกเทคโนโลยีสารสนเทศเป็นอย่างไรบ้าง?

  • hi5 กำลังเริ่มเป็นที่นิยม (ตั้งปี 2004)
  • MySpace เป็นสื่อสังคมออนไลน์อันดับหนึ่ง (ตั้งปี 2003)
  • Facebook เพิ่งตั้งได้ปีเดียว (2004) แต่ยังจำกัดสมาชิกอยู่เฉพาะนักศึกษาในสหรัฐ (เปิดให้ลงทะเบียนทั่วไปปี 2006)
  • Gmail ก็เพิ่งเปิดให้บริการแบบจำกัดได้หนึ่งปีเหมือนกัน (2004) ต้องมี invite ถึงจะสมัครได้ และกว่าจะเปิดให้บริการทั่วไปก็ปี 2009
  • โทรศัพท์ “สมาร์ตโฟน” ในตอนนั้นคือ Nokia รุ่น 9300i (ประกาศพ.ย. 2005 วางขายจริง ม.ค. 2006) ระบบปฏิบัติการ Symbian 7.0S หน่วยความจำ 80 MB เบราว์เซอร์รองรับ HTML 4.01 กับ WML 1.3 ราคาเกือบสามหมื่น
  • ยังไม่มี iPhone (ออกปี 2007)
  • ยังไม่มี Google Android (กูเกิลซื้อบริษัทแอนดรอย์มาปี 2005 แล้วเอามาพัฒนาต่อ แล้วออกรุ่นแรกในปี 2008)
  • ยังไม่มี Line (ออกปี 2011)
  • ยังไม่มี Amazon Web Services (เริ่มปี 2006)

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

ซึ่งพอเป็นแบบนี้ มันก็ลำบากอยู่เหมือนกัน ที่จะคาดหวังให้กรอบกฎหมายจากปี 2005 อย่าง APEC Privacy Framework มันจะมาเห็นประเด็นอะไรในปัจจุบันแบบละเอียดๆ คือสมัยนั้นมันยังไม่มี (เอาจริงๆ มันก็พอมี เช่น APEC Cross-border Privacy Enforcement Arrangement จากปี 2010 แต่เราไม่ยอมอ้างกัน ไปอ้างแต่ของเก่า)

ในขณะที่ตอนร่าง General Data Protection Regulation ของ EU มันก็มีกรณีศึกษาอะไรให้สรุปเป็นบทเรียนเยอะแล้ว โดยเฉพาะจากอุตสาหกรรมอินเทอร์เน็ตและการประมวลผลข้อมูลที่มันเปลี่ยนไปอย่างมากในทศวรรษที่ผ่านมา เขาเลยปรับปรุงออกมาแบบนี้

ถ้าไทยจะมีกฎหมายใหม่ ก็ควรคิดถึงอนาคตไหม ไม่ใช่เอาวิธีคิดจากเมื่อ 12 ปีที่แล้วมาใช้ ประกาศปุ๊บ ล้าสมัยทันที เสียเวลาไหม

 

ภาพประกอบ: Nokia 9300i จาก Nokia Museum