Planet TLWG

Subscribe to Planet TLWG feed
Planet TLWG - http://debianclub.org/planet-tlwg
Updated: 52 min 42 sec ago

bact: นโยบาย Cloud First ของรัฐบาลสหราชอาณาจักร

19 August, 2017 - 14:16

นโยบาย “Cloud First” ของรัฐบาลสหราชอาณาจักร ดูผ่านๆ มีประเด็นน่าสนใจดังนี้

เน้นความคุ้มเงิน

  • เน้นความคุ้มเงิน
  • cloud ในที่นี้ คือ public cloud
  • ให้ใช้ public cloud เป็นตัวเลือกแรก หน่วยงานจะใช้ตัวเลือกอื่นก็ได้ แต่ต้องแสดงให้เห็นได้ว่ามันคุ้มเงินกว่า (“value for money” ใช้นิยามตามกระทรวงการคลัง HM Treasury)

ให้การจัดซื้อจัดจ้างตามมาตรฐานสะดวกขึ้น

  • การแบ่งชั้นความอ่อนไหวของข้อมูลที่ชัดเจนและรู้ว่าแอปจะต้องเจอกับข้อมูลแบบไหนบ้าง จะทำให้การเลือกใช้บริการภายนอกทำได้ง่าย เพื่อช่วยกระบวนการนี้ รัฐบาลสหราชอาณาจักรได้จัดกลุ่มชั้นความลับของข้อมูลใหม่ให้ง่ายขึ้น โดยลดจำนวนจาก 6 ระดับ เหลือ 3 ระดับ คือ Official, Secret และ Top Secret
  • เพื่อให้การจัดซื้อจัดจ้างทำได้สะดวกขึ้น รัฐบาลได้จัดทำแนวทางข้อกำหนด G-Cloud ขึ้น (มีปรับปรุงเรื่อยๆ ล่าสุดเวอร์ชัน 9) มีเทมเพลตสัญญาให้ด้วย
  • G-Cloud เป็นระบบ self-certify ผู้ให้บริการจะต้องทดสอบระบบของตัวเอง และแสดงหลักฐานให้เห็นว่าสามารถทำตามข้อกำหนดเรื่องอะไรได้ที่ระดับไหนบ้าง เพื่อให้ผู้เลือกซื้อบริการตัดสินใจ
  • เกณฑ์อันหนึ่งที่สำคัญคือเรื่องการรักษาความมั่นคงปลอดภัย G-Cloud ที่ดูแลข้อมูลชั้นความลับ Official จะใช้หลักการ 14 ข้อ (14 Cloud Security Principles) ซึ่งปัจจุบัน National Cyber Security Centre ดูแล

เปิดโอกาสผู้ให้บริการหลากหลายทั้งรายเล็กรายใหญ่

  • มี Digital Marketplace ให้หน่วยงานเลือกหาบริการจากผู้ให้บริการที่ทำตามข้อกำหนดของ G-Cloud (มีบริการ 3 แบบ: cloud hosting, cloud software, cloud support)
  • เพื่อลดเวลาและความยุ่งยากในการเริ่มต้นและจัดการแอปบน cloud ด้วยตัวเอง หน่วยงานของรัฐสามารถใช้บริการ GOV.UK Platform as a Service (PaaS) ซึ่งให้บริการโดย Government Digital Service (GDS) [บริการนี้มีฐานะเหมือนเป็น cloud hosting อันหนึ่งใน Digital Marketplace]
  • บริการ GOV.UK PaaS ใช้ Amazon Web Service โดยใช้ศูนย์ข้อมูลที่ตั้งในไอร์แลนด์ (และใช้กฎหมายคุ้มครองข้อมูลส่วนบุคคลของสหภาพยุโรป)
  • GOV.UK PaaS ได้รับการรับรองให้ประมวลผลข้อมูลส่วนบุคคลและข้อมูลชั้นความลับ Official (สำหรับข้อมูลชั้นความลับ Secret หรือ Top Secret จะใช้บริการนี้ไม่ได้)

อื่นๆ

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

bact: [Links] Algorithmic Transparency: Understanding why we are profiled in a certain manner #APrIGF2017 #WS80

31 July, 2017 - 19:00

Links for Asia Pacific Regional Internet Governance Forum 2017 – WS80 Algorithmic Transparency: Understanding why we are profiled in a certain manner, hosted by SFLC.in — to be digested and integrated to APrIGF 2017 Bangkok Synthesis Document at https://comment.rigf.asia

My slides

Kitt: Still on my mind

30 July, 2017 - 23:46
H.M. the King – Still on my mind Arranged & performed by /me

Kitt: How many Nobel laureates do you know ?

30 July, 2017 - 23:38
คุยกันเรื่องผู้ได้รับรางวัลโนเบลท่านหนึ่ง ซึ่งรู้จักชื่อแต่ไม่เคยรู้ว่าได้เคยได้รับรางวัลโนเบล  เลยไปสืบรายชื่อผู้ไดัรับรางวัลโนเบลทั้งหมดตั้งแต่ปี 1901 ปรากฎว่าชื่อผ่านตาและจำได้เยอะเหมือนกัน แยกตามสาขาแล้ว ฟิสิกส์ 23 คน เคมี 3 คน แพทย์ 0 คน วรรณกรรม 7 คน สันติภาพ 25 (ส่วนใหญ่เป็นชื่อองค์กร) ส่วน Turing Awards ตั้งแต่มอบรางวัลในปี 1966 นับได้ 23 คน

Kitt: Deja-Dup / Duplicity / GPG

29 July, 2017 - 11:00
Some Linux users user Deja-Dup / Duplicity to backup their files. The tools work pretty well and very reliable. However, in a very rare occasion, Deja-Dup will keep asking you a password even you put the right one. To debug this, you can do DEJA_DUP_DEBUG=1 deja-dup --backup to see what’s going on, and grabbing those … Continue reading Deja-Dup / Duplicity / GPG →

Kitt: 1,500,000,000 seconds after the Unix Epoch

15 July, 2017 - 18:56
Unix epoch to date $ date --date @<number of seconds> Date to Unix epoch $ date +%s

Kitt: เจ้าภาพบำเพ็ญกุศลถวายพระบรมศพ พระบาทสมเด็จพระปรมินทรมหาภูมิพลอดุลยเดช

29 June, 2017 - 10:25
มหาวิทยาลัยขอนแก่นร่วมเป็นเป็นเจ้าภาพบำเพ็ญกุศลถวายฯ และเข้าสักการะพระบรมศพ  วันที่ ๒๗ มิถุนายน พุทธศักราช ๒๕๖๐ ๑๙.๐๐ น. เป็นการเข้าวังที่เศร้า ไม่มีอารมณ์ถ่ายภาพ มีภาพเดียวที่เก็บไว้เมื่อตอนอยู่ที่พัก ก่อนออกเดินทาง YMMV

bact: อินเทอร์เน็ตสีขาว

22 June, 2017 - 03:04

อินเทอร์เน็ตใสสะอาดคงเหมือนกับห้องปลอดเชื้อคนไม่ต้องมีภูมิคุ้มกันอะไรเลยก็อยู่ได้ปลอดภัย

ถามว่าทำไมต้องเป็น “ห้อง”

ก็เพราะเราทำทั้งโลกให้ปลอดเชื้อไม่ได้ (แต่ปลอดมนุษย์นี่ไม่แน่) 

ได้อย่างมากก็ทั้งห้องหรือทั้งส่วนหนึ่งของอาคาร

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

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

แต่เป็นเรื่องทำให้ตัวเองมีภูมิคุ้มกัน

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

ไม่ต้องไปต้านทานหรือจัดการได้ทุกโรค เอาแค่พอมีชีวิตปกติได้ในพื้นที่ที่ใช้ชีวิตประจำวัน

จะไปไหนไกลๆ ไม่คุ้นเคย ก็ค่อยฉีดวัคซีน

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

bact: จุดอ่อนของ AI ในงานความมั่นคงปลอดภัยทางสารสนเทศ #infosec17

13 June, 2017 - 10:55

ในงาน Infosecurity Europe 2017 นอกจากคำว่า GDPR และ IoT ที่เดินไปไหนก็เจอแล้ว ยังมีอีก 2 คำที่มาคู่กันให้เห็นไปทั่ว คือคำว่า artificial intelligence (ปัญญาประดิษฐ์) และ machine learning (การเรียนรู้ของเครื่อง)

หัวข้อหนึ่งที่ได้ไปฟังแล้วน่าสนใจคือ Adversarial Machine Learning: The Pitfalls of Artificial Intelligence-based Security โดยมี Giovanni Vigna ซึ่งเป็นอาจารย์ที่ UC Santa Barbara และหนึ่งในผู้ก่อตั้งบริษัท Lastline มาเป็นวิทยากร

Machine learning and security

หลักๆ คือ Giovanni พูดถึงว่า การมีข้อมูลให้เครื่องมันเรียนรู้ถึงรูปแบบมัลแวร์และการโจมตีต่างๆ ก็อาจจะทำให้คอมพิวเตอร์มันเก่งขึ้นได้ในการตรวจจับความผิดปกติ (anomaly detection) โดยอัตโนมัติ ซึ่งอันนี้ก็ใช้เทคนิค classification และ clustering ทำนองเดียวกับแอปพลิเคชันอย่างการรู้จำภาพ โดยเขายกตัวอย่างการหาความผิดปกติในจาวาสคริปต์ ที่ก็อาจจะใช้การวิเคราะห์ข้อมูลจาก abstract syntax tree (AST) เพื่อเปรียบเทียบกับจุดที่เคยมีข้อมูลมาก่อนว่าเป็นอันตราย

Identifying adversaries: Malicious evasive JavaScript

อย่างไรก็ตาม เช่นเดียวกับระบบปัญญาประดิษฐ์ทั่วไป ที่เครื่องมันก็อาจจะตอบผิดบ้าง (ทั้ง false negative – มีอันตรายจริงๆ แต่หลงหูหลงตาไป ไม่ได้แจ้งเตือน และ false positive – แจ้งเตือนว่าเป็นอันตรายทั้งที่จริงไม่ใช่) แต่นอกจากนั้นแล้ว การใช้ปัญญาประดิษฐ์ และโดยเฉพาะเจาะจงคือการเรียนรู้ของเครื่อง กับงานความมั่นคงปลอดภัยยังมีจุดอ่อนอยู่อย่างน้อยอีก 2 อย่าง หากผู้โจมตีสามารถศึกษาและเข้าใจโมเดลที่ระบบใช้ได้ (ซึ่งการได้มาซึ่งโมเดลนี่ก็อาจจะใช้วิธี reverse engineering เอาก็ได้ เช่นขโมยผ่าน machine learning APIดูเปเปอร์)

  • อย่างแรกคือ ศึกษาหาจุดบอดของโมเดล เพื่อสามารถรู้ได้อย่างเจาะจงมากขึ้นว่า ในกรณีไหน (ด้วย feature set แบบไหน ในเงื่อนไขไหน) ที่ระบบจะถูกหลอกได้ (ทั้ง false positive และ false negative) และนำจุดอ่อนนี้ไปหาประโยชน์ และ
  • อย่างที่สองคือ ศึกษาว่าการเรียนรู้ปรับปรุงโมเดลนั้นทำอย่างไร ใช้ข้อมูลทำนองไหน และหาทางป้อนข้อมูลที่สร้างขึ้นมาหลอกๆ เพื่อทำให้โมเดลเปลี่ยนไปในทางที่ต้องการ พูดอีกอย่างคือเป็นการทำให้โมเดลถูกปนเปื้อน (contaminated / polluted)

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

Adversarial machine learning is here

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

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

การใช้ AI ในงานความมั่นคงปลอดภัย จึงจำเป็นต้องระมัดระวังมากขึ้น คือมันมีคนพร้อมจะเล่นงานเมื่อคุณพลาด หรือถ้าคุณยังไม่พลาด เขาก็จะล่อลวงให้คุณพลาดให้ได้

แต่ในด้านกลับ ความรู้ที่เรียกว่า “adversarial machine learning” นี้ก็อาจจะถูกใช้เพื่อสร้างกับดักหรือกระทั่งตามล่าการโจมตีแบบใหม่ๆ ก็ได้ คือเอาไปหลอกคนที่จะมาโจมตีก็ได้

From trapping to hunting

ตอบจบก่อนช่วงสรุป วิทยากรบอกให้เราตั้งคำถามให้ดี เวลามีใครมาเสนอขายระบบที่ใช้ AI หรือ Deep Learning (ซึ่งตอนนี้เป็นคำฮิตอีกคำ) เพื่อปกป้องความมั่นคงปลอดภัยทางสารสนเทศ (โน๊ต: วิทยากรก็มานำเสนอในฐานะตัวแทนบริษัทขายระบบพวกนี้เหมือนกัน)  คำถามเหล่านั้นก็คือ

  • ระบบดังกล่าวใช้เทคนิคอะไรมาประกอบกันบ้าง
  • ระบบใช้ข้อมูลชุดใดบ้างในการสอนโมเดล
  • ความสามารถในการป้องกันการถูกโจมตี (ตามที่โฆษณา) นั้นถูกประเมินอย่างไร
  • ประเมินภายใต้โมเดลภัยคุกคาม (threat model) แบบไหน?
  • วิธีที่ระบบใช้มี ความเที่ยง (precision) และ  การเรียกกลับ (recall) เท่าใด (ความเที่ยง หมายถึง จากจำนวนที่ระบบบอกว่าเป็นความผิดปกติ มีที่ผิดปกติจริงๆ เท่าใด, การเรียกกลับ หมายถึง จากจำนวนความผิดปกติที่มีอยู่จริงๆ ระบบสามารถพบได้เท่าใด)

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

What to ask about AI/ML/Deep Learning-based technology

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

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

Giovanni ตอบสั้นๆ ว่า มีคนคิดเรื่องนี้อยู่ แต่ ณ ขณะนี้ เทคโนโลยียังไปไม่ถึงตรงนั้น

ผมถ่ายมาไม่ครบทุกสไลด์ (เกรงใจ) คิดว่าอีกสักพักเขาน่าจะอัปโหลดไปที่ไหนสักที่ครับ ทางงานประชุมมีสรุปไว้ด้วย: #INFOSEC17 Machine Learning is Positive, but not a Security Solution

งาน Infosecurity Europe นี้ไม่ได้ตั้งใจจะไป เพิ่งจะรู้จากทวิตเตอร์ตอนที่ไปอยู่ลอนดอนได้สัปดาห์นึงแล้วนี่แหละ คือพวกผมไปกันอีกงานหนึ่งชื่องาน Mobile Media and Communication Practices in Southeast Asia เป็นงานสัมมนาวิชาการที่คณะสังคมวิทยาและมานุษยวิทยา ที่ธรรมศาสตร์ จัดร่วมกับ Goldsmiths Media Ethnography Group มหาวิทยาลัยลอนดอน ไม่ค่อยเกี่ยวกับด้านความมั่นคงปลอดภัยทางสารสนเทศเท่าไหร่ (แต่ก็มีหัวข้อนึงที่อาจารย์จาก Goldsmiths วิเคราะห์นโยบาย Thailand 4.0 และ Smart Thailand อาจจะเฉียดๆ)

อย่างไรก็ตาม ก็รู้สึกคุ้มค่าที่ได้ไป (ถ้ารู้เร็วกว่านี้ก็จะดี จะได้ลงทะเบียนเข้าฟรี พอรู้ช้าต้องไปลงทะเบียนหน้างาน ต้องจ่าย 35 ปอนด์) ไปแล้วก็รู้สึกว่าอยากเขียนมาเล่า ยังไงอ่านอีกสองโพสต์ก่อนหน้าได้ครับ หลักการ/กลไกการคุ้มครองข้อมูลใหม่ใน GDPR ของสหภาพยุโรป และ ความมั่นคงปลอดภัยของ Internet of Things – ข้อคิดจาก Bruce Schneier

ร่างพ.ร.บ.ว่าด้วยการรักษาความมั่นคงปลอดภัยไซเบอร์ ใกล้จะคลอดเต็มทน ใครมีความคิดเห็นอะไรก็ส่งไปได้นะครับ แฟกซ์ 0-2281-2904 อีเมล legal@alro.go.th

Machine learning: The last line of defense Learn what your network does Conclusions

bact: ความมั่นคงปลอดภัยของ Internet of Things – ข้อคิดจาก Bruce Schneier ในงาน #infosec17

8 June, 2017 - 19:57

โพสต์ที่แล้วเล่าเรื่องงาน Infosecurity Europe วันที่สองไป เรื่อง General Data Protection Regulation (GDPR) จากมุมมอง ICO ยังเหลืออีกเรื่องที่ไปฟังมา คือเรื่อง ความปลอดภัยของ Internet of Things (IoT)

หัวข้อคือ Artificial Intelligence and Machine Learning: Cybersecurity Risk vs Opportunity? มี Bruce Schneier เป็นคนพูด คนแน่นมาก ตรงที่เป็นถ่ายทอดให้ดูทางจอก็ยังแน่น (ในภาพนี้เฉพาะที่นั่ง มียืนรอบๆ อีก)


Schneier พูดหลายประเด็น แต่อันหลังสุดมาเน้นเรื่องความมั่นคงปลอดภัยของ Internet of Things หรือ “อินเทอร์เน็ตของสรรพสิ่ง”

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

เราเปลี่ยนมือถือทุก 2-3 ปี กล้องวงจรปิดทุก 5-10 ปี ตู้เย็นบางบ้าน 20 ปี รถยนต์ที่มีตลาดมือสองอาจมีอายุการใช้งาน 40-50 ปี

คนทำซอฟต์แวร์ควบคุมรถยนต์ทำแล้วใช้ไปได้ 40-50 ปี แต่คนทำซอฟต์แวร์มือถือหรือ IoT ไม่เคยทำอะไรแบบนี้มาก่อน

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

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

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

สำหรับอุตสาหกรรมนี้ มันไม่ใช่ทางเลือกระหว่าง “กำกับ vs ไม่กำกับ” แต่เป็นระหว่าง “กำกับอย่างฉลาด vs กำกับอย่างโง่” (smart regulation vs stupid regulation)

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

ใครสนใจงานนี้ ติดตามแฮชแท็ก #infosec17 ได้ในทวิตเตอร์ครับ ส่วนเรื่อง AI กับ security เดี๋ยวมีอีกโพสต์

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

8 June, 2017 - 01:03

วันนี้เป็นวันที่ 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)

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

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

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

จริงๆ ข้อคำนึงเหล่านี้ มีอยู่แล้วเงียบๆ ใน 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 จะออกแนวปฏิบัติมาภายในปีนี้)

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

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

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

ICO’s Peter Brown looks at impact of GDPR on cyber security during his #cyberresilience speech. More here: https://t.co/egGINAdZvX pic.twitter.com/zuXRHre9Tj

— ICO (@ICOnews) February 7, 2017

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

19 May, 2017 - 16:47

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

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

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

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

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

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

ซึ่งหมายความว่า เว็บเบราว์เซอร์ของเรา ไม่สามารถตรวจสอบได้ว่า หน้าเว็บสำหรับการล็อกอินซึ่งอ้างว่าอยู่ที่หมายเลขไอพี 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) จะเป็นแบบนี้

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

สรุป

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

  • พบปัญหาใบรับรองออกโดย CA ที่เว็บเบราว์เซอร์ไม่ให้การยอมรับถึง 2 ครั้ง ทั้งช่วงก่อนหน้าจอล็อกอินและช่วงใกล้จะล็อกอินสำเร็จ
    • ผู้ใช้ทั่วไปอาจจะทำตัวไม่ถูกว่าให้ทำอย่างไรต่อ เพราะข้อความเตือนของเว็บเบราว์เซอร์อาจเข้าใจยาก
    • กรณีผู้ใช้ TCDC ถูกสอนว่า “ไม่ต้องสนใจ คลิก Continue” ไปเลย ก็จะเป็นการส่งเสริมพฤติกรรมเสี่ยงให้กับผู้ใช้ โดยอาจเข้าใจไปว่า ต่อไปหากเจออาการแบบนี้อีกไม่ว่ากับเครือข่ายไหน หากอยากไปต่อ ก็ให้กด “Continue” เสีย ก็จะแก้ปัญหาได้ พฤติกรรมเช่นนี้ทำให้ผู้ใช้อาจตกเป็นเหยื่อของอาชญากรรมคอมพิวเตอร์หรือข้อมูลส่วนบุคคลถูกขโมยได้
    • ปัญหาใบรับรองนี้ พบว่าไม่ได้เป็นเฉพาะกับหน้าจอล็อกอินไวไฟของ TCDC หน้าเว็บไซต์หลักของ TCDC ก็มีปัญหานี้ด้วย
  • หน้าจอ Facebook Wi-Fi ในบางกรณี อาจแสดงผลไม่ชัดเจนเพียงพอ ว่าผู้ใช้จะต้องกรอกแบบฟอร์มล็อกอินอันไหน ผู้ใช้ไม่สามารถรู้ได้เองอย่างชัดเจน ว่าจะต้องเลื่อนหน้าจอลงมาเพื่อคลิกลิงก์ “เข้าสู่ระบบ” เพื่อจะไปยังหน้าจอล็อกอินอีกอัน ซึ่งจะสามารถนำไปสู่การเช็กอินและใช้อินเทอร์เน็ตได้
  • ใครไม่มีบัญชีเฟซบุ๊กจะใช้อินเทอร์เน็ตผ่านเครือข่าย Guest@TCDC ไม่ได้ เนื่องจากผู้ใช้จะต้องล็อกอินเฟซบุ๊กก่อน
    • เจ้าหน้าที่ Info Guru ที่ TCDC ยืนยันว่าไม่มีรหัสให้ป้อนเพื่อข้ามการล็อกอินเฟซบุ๊ก
  • ผู้ใช้ถูกบังคับให้ต้องเช็กอิน เนื่องจากลิงก์ “ข้ามการเช็กอิน” ใช้งานไม่ได้  ซึ่งก็คงไม่ใช่ผู้ใช้ทุกคนที่รู้สึกสะดวกเช็กอินหรือรู้วิธีการตั้งค่าโพสต์เช็กอินให้เป็นส่วนตัว (สำหรับ Facebook Wi-Fi เจ้าของหน้าเฟซบุ๊กอย่าง TCDC สามารถตั้งค่า “โหมดบายพาส” ให้ผู้ใช้ไม่ต้องเช็กอินก็ได้ แค่ล็อกอินเฟซบุ๊กก็พอ)
    • สอบถามเจ้าหน้าที่เพิ่มเติม ได้ข้อมูลว่า ถ้าเป็นบนมือถือ จะข้ามได้ แต่เท่าที่ลองบนเดสก์ท็อปข้ามไม่ได้
  • กรณีผู้ใช้ใช้การยืนยันตัวตนแบบสองชั้นและล็อกอินผ่านมือถือเครื่องเดียวกัน จะมีเวลาไม่เกิน 30 วินาทีในการล็อกอิน เนื่องจากถ้าสลับหน้าจอมาเพื่อดูโค้ด หน้าล็อกอินจะหายทันที
ข้อเสนอแนะ
  • ที่แก้ไขได้โดยไม่ต้องรอฝ่ายนโยบายนัก เพราะน่าจะเป็นเรื่องการตั้งค่าเครือข่าย คือเรื่องใบรับรองและเรื่องหน้าจอล็อกอิน กรณีใช้ 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 ได้)

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

bact: OTT (Over-the-Top) คืออะไร?

12 May, 2017 - 18:48

“Over-the-Top” หรือ OTT เป็นคำศัพท์ในวงการโทรคมนาคมและกระจายภาพและเสียง มีความหมายโดยทั่วไปถึงเนื้อหาหรือบริการที่ถูกส่งผ่านโครงข่ายที่ไม่ได้ถูกออกแบบมาให้ทำสิ่งดังกล่าวตั้งแต่ต้น ด้วยเหตุนี้ OTT จึงถูกเรียกในภาษาทั่วไปว่า “value added” ซึ่งหมายถึงเนื้อหาหรือบริการที่สร้าง “มูลค่าเพิ่ม” จากเนื้อหรือบริการพื้นฐานที่โครงข่ายถูกออกแบบมาแต่แรก

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

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

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

  • ตามชนิดของใบอนุญาต — โทรคมนาคม v กระจายภาพและเสียง v ไม่ต้องมีใบอนุญาต)
  • ตามประเภทของผู้ให้บริการ — ผู้ให้บริการเนื้อหาเป็นรายเดียวกับผู้ให้บริการโครงข่าย vs เป็นคนละราย
  • ตามประเภทของชนิดบริการ — รายการวิทยุหรือโทรทัศน์ที่เผยแพร่เวลาตรงกับที่กำลังเผยแพร่ในโครงข่ายกระจายภาพและเสียง รายการวิทยุหรือโทรทัศน์ที่เคยหรือจะเผยแพร่ในโครงข่ายกระจายภาพและเสียงและผู้ชมเลือกเวลาดูได้เอง เนื้อหาแบบรายการวิทยุหรือโทรทัศน์ที่ไม่ได้ผลิตเพื่อเผยแพร่ในโครงข่ายกระจายภาพและเสียง ภาพยนตร์ ฯลฯ
  • ตามประเภทการบอกรับสมาชิก — เสียค่าบอกรับหรือไม่, subscription-based v advertising-based
  • ตามประเภทผู้ผลิตเนื้อหาหลักในบริการนั้น — ผลิตเอง v จ้างผลิต v ผู้ใช้เป็นผู้ผลิต
  • ตามมิติอื่นๆ

นอกจากนี้ ยังสามารถแบ่ง OTT ตามประเด็นในการกำกับกิจการได้ด้วย ตัวอย่างเช่น Body of European Regulators for Electronic Communications (BEREC) ซึ่งเป็นองค์การกลางของหน่วยงานกำกับกิจการสื่อสารอิเล็กทรอนิกส์ของสหภาพยุโรป แบ่งบริการ OTT เป็น 3 ประเภทคือ

  1. บริการ OTT ที่ถือเป็น “บริการสื่อสารอิเล็กทรอนิกส์” (electronic communications service – ECS)
  2. บริการ OTT ที่ไม่ถือเป็น ECS แต่มีศักยภาพจะแข่งขันกับ ECS และ
  3. บริการ OTT อื่นๆ

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

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

 

bact: จะเป็นกสทช.ของไทยต้องวัยวุฒิเพียบพร้อม ว่าที่ประธานาธิบดีฝรั่งเศสยังเป็นไม่ได้เลย

8 May, 2017 - 13:39

“อายุ 39 มีปุ่มนิวเคลียร์ในมือ แต่เป็น กสทช. ไม่ได้นะครับ”
— มิตรสหายท่านหนึ่ง


ตามพ.ร.บ.กสทช.ฉบับใหม่ ว่าที่ประธานาธิบดีฝรั่งเศสที่เพิ่งได้รับเลือกไปเมื่อวันอาทิตย์ที่ผ่านมา เป็นกรรมการกสทช.ไม่ได้นะครับ

อายุไม่ถึงน่ะ (แน่นอนว่าไม่มีสัญชาติไทยด้วย)

พ.ร.บ.กสทช.ฉบับใหม่ ที่สนช.ผ่านไปเงียบๆ เมื่อ 31 มี.ค. 2560 ขยับอายุขั้นต่ำของกรรมการจาก 35 ปี เป็น 40 ปี (ร่างที่เสนอแก้ไขตอนแรก เสนอไปถึง 45 ปีด้วยซ้ำ)

เอ็มมานูเอล มาครง นี่ 39 ปี (เกิด 2520) วัยวุฒิไม่ถึงครับ

เหมือนกับ ออเดรย์ ถัง รัฐมนตรีดิจิทัลของไต้หวัน ที่ตอนเข้ารับตำแหน่งนี่ 35 ปี (เกิด 2524) แต่ก็วัยวุฒิไม่พอสำหรับประเทศไทยอยู่ดี แล้วอย่าไปพูดถึงตามาร์ก เฟซบุ๊ก ขานั้น 32 ปี (เกิด 2527) ประสบการณ์ไม่ถึงแน่ๆ

#สังคมสูงวัย #ประสบการณ์สูงวิสัยทัศน์ไกล #วางยุทธศาสตร์ประเทศกันถึงสัมปรายภพเลย

ดู ตารางเปรียบเทียบอายุของกรรมการชุดต่างๆ ของไทย

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้