เนื่องจากผมไม่ได้อยู่ในเหตุการณ์ช่วงที่ Facebook ล่ม ถึงอยู่ในช่วงเวลานั้นก็ไม่กระทบอะไรเพราะตนเองไม่มี account facebook และไม่คิดจะมี account facebook แต่เมื่อหลายคนพูด Talk of the town เลยมานั่งวิเคราะห์ดูว่าสาเหตุที่แท้จริงคืออะไร เผื่อว่าจะเป็นการแชร์ความรู้ให้กับทุกท่านที่ได้ติดตามอ่านบทความของผมอย่างต่อเนื่อง
เมื่อทำการวิเคราะห์สามารถพิจารณาจาก 2 ส่วน ดังนี้
ส่วน ที่ 1 พิจารณาการเชื่อมต่อข้อมูลบนระบบเครือข่าย (Route Traffic) ซึ่งในเส้นทางการเชื่อมต่อในส่วนนี้อาจเปลี่ยนแปลงไปเรื่อยๆ ไม่คงทีขึ้นอยู่กับการ config ของฝั่งผู้ให้บริการ ดังนั้นการยกตัวอย่างในบทความนี้อาจไม่เป็นเช่นนั้นเสมอไป
ส่วนที่ 2 พิจารณาการเรียกค่า DNS (Domain Name System)
ส่วนที่ 1 การเชื่อมต่อข้อมูลบนระบบเครือข่าย (Route Traffic)
ซึ่งในส่วนแรกเราจะต้องตั้งต้นที่ Gateway ในขาต่างประเทศ เพื่อวิเคราะห์ว่ามีก Link ใดบ้างทีเชื่อมต่อกับ Facebook จะพบว่า
ASN ในประเทศไทยที่มีขาเชื่อมต่อต่างประเทศ มีดังนี้
1. AS4651 : CAT Telecom
2. AS17565 : ADC (Advance Datanetwork Communications Co.,Ltd. BuddyB service. Bangkok)
3. AS45796 : BB Connect (UIH or DTAC)
4. AS7568 : CSLoxinfo
5. AS45629 : JasTel (3BB)
6. AS45430 : SBN (AIS)
7. AS132876 : Symphony
8. AS58430 : TCCT
9. AS38082 : True Internet
10. AS38040 : TOT
ASN ของ Facebook คือ AS32934 มีค่าไอพี (IPv4) ทั้งหมด 54,272
ซึ่งในนี้จะมีการเชื่อมต่ออยู่จำนวน 152 Link
ที่ ASN ของ Facebook มี Link ไปประเทศสิงค์โปร มีจำนวน 2 Link คือ
- AS7473 : Singapore Telecom
- AS4844 : Super Internet Access PTE
(1) AS7473 : Singapore Telecom มีการเชื่อมต่อในประเทศไทย ดังนี้
1.1 AS38082 : True Internet
1.2 AS4651 : CAT Telecom
1.3 AS7568 : CSLoxinfo
1.4 AS45629 : JasTel
1.5 AS38040 : TOT
(2) AS4844 : Super Internet Access PTE มีการเชื่อมต่อในประเทศไทย ดังนี้
2.1 AS4651 : CAT Telecom
2.2 AS38082 : True Internet
2.3 AS7568 : CSLoxinfo
2.4 AS38040 : TOT
2.5 AS45629 : JasTel
2.6 AS45796 : BBconnect
2.7 AS45430 : SBN-IIG
2.8 AS9587 : DTAC
2.9 AS9931 : CAT Telecom
เพื่อให้เห็นภาพขอทำการทดสอบผ่านผู้ให้บริการอินเทอร์เน็ต ที่ผู้เขียนสามารถจะทำได้ดังนี้
(1) ทำการ Trace route เพื่อค้นหาเส้นทาง ในกรณีที่ใช้เครือข่าย DTAC
ทำการทดสอบวันที่ 28 พค 57 เวลา 16:38 ซึ่งเป็นเกิดเหตุการณ์ Facebook ล่มไปแล้วไม่นาน
จะพบว่าใน hop ที่1 ถึง 13 เป็นการ Routing บนเครือข่ายของ DTAC เอง (เป็น Private IP Address)
จากนั้นใน hop ที่ 14 เริ่มการไปเชื่อมกับ TOT IIG ที่ ไอพี 180.180.248.69
จากนั้นใน hop ที่ 15 มีการเรียกค่าไปที่โดเมน facebook-sg.totiig.net โดย เป็นค่าไอพี 180.180.255.222
และ hop ที่ 16 เป็นการเชื่อมต่อไปที่ ae11.bb02.sin1.tfbnw.net ไอพี 31.13.28.148 ซึ่งเป็นไอพีภายใต้ AS32934
hop 21 และ hop 22 ที่ติดระบบรักษาความปลอดภัยของ Facebook
ใช้ระยะทางเรียกค่า www.facebook.com ทั้งหมด 23 hop
(2) ทำการ Trace route เพื่อค้นหาเส้นทาง ในกรณีที่ใช้เครือข่าย 3BB
ทำ การทดสอบ ที่ AS45629 ช่วงไอพีที่ทำการทดสอบ เวลาทดสอบวันที่ 29 พค 57 เวลา 8:32 ซึ่งเกิดเหตุการณ์ facebook ล่มไปแล้วหลายชั่วโมง และระบบกลับมาปกติแล้ว
เริ่มมีการเชื่อมต่อกับเครือข่ายอื่นที่ hopที่ 7 จะเป็นเครือข่ายอื่น ไอพี 80.77.0.77
AS15412 : Reliance Globalcom Limited จากนั้้น hop ที่ 8 ไปที่ ge-71-1-0.0.ejr03.sin001.flagtel.com ค่าไอพี 62.216.128.9
จาก hop ที่ 7 ถึง 8 จะไปผ่านที่ประเทศอังกฤษ Flag Telecom Global
และออกไปที่ฮ่องกงใน hop ที่ 10 facebook-10G.hkix.net ไอพี 202.40.161.110 จากนั้นเข้าไปสู่เครือข่ายที่ Facebook
ใช้ระยะทางเรียกค่า www.facebook.com ทั้งหมด 12 hop
(3) ทำการ Trace route เพื่อค้นหาเส้นทาง ในกรณีที่ใช้เครือข่าย True
ทำการทดสอบในวันที่ 30 พค 57 เวลา 07:43 ทดสอบผ่าน AS132061 Real Move (เป็นช่วงไอพีของ True Internet บนเครือข่ายมือถือ)
ใช้ระยะทางเรียกค่า www.facebook.com ทั้งหมด 15 hop
ซึ่ง True Gateway สามารถมีการเชื่อมต่อไปตรงที่ Facebook ได้
(4) ทำการ Trace route เพื่อค้นหาเส้นทาง ในกรณีที่ใช้เครือข่าย CSLoxinfo
ทดสอบบนเครื่องแม่ข่าย (Server ส่วนตัว) เมื่อวันที่ 30 พค 57 เวลา 9:21 โดยทำการทดสอบบนย่านไอพี AS9891 ผลลัพธ์คือ
รวมระยะเส้นทางจำนวน 12 hop
หมายเหตุ : ทุกเส้นทางที่แสดงผลในนี้อาจมีการปรับเปลี่ยนได้ตลอดเวลาเนื่องจาก Routing Traffic จะเกิดขึ้นจากผู้ดูแลระบบที่ทำการ Config ค่า
ส่วนที่ 2 การเรียกค่า DNS
เมื่อทำการ nslookup facebook จะได้ผลลัพธ์ดังนี้
facebook.com nameserver = a.ns.facebook.com
facebook.com nameserver = b.ns.facebook.com
facebook.com text =
"v=spf1 redirect=_spf.facebook.com"
facebook.com MX preference = 10, mail exchanger = msgin.t.facebook.com
facebook.com
primary name server = a.ns.facebook.com
responsible mail addr = dns.facebook.com
serial = 1401416932
refresh = 7200 (2 hours)
retry = 1800 (30 mins)
expire = 604800 (7 days)
default TTL = 120 (2 mins)
facebook.com internet address = 173.252.110.27
facebook.com AAAA IPv6 address = 2a03:2880:2110:df07:face:b00c:0:1
a.ns.facebook.com internet address = 69.171.239.12
b.ns.facebook.com internet address = 69.171.255.12
ส่วนค่า DNS หลักของผู้ให้บริการอินเทอร์เน็ตในประเทศไทย จะแยกกันไป
ในที่นี้ขอยกตัวเฉพาะ DNS ของ TOT
ได้แก่ dns1.totbb.net มีค่าไอพี 203.113.5.130 , dns2.totbb.net มีค่าไอพี 203.113.7.130 และ dns3.totbb.net มีค่าไอพี 203.113.9.123
เมื่อมี การแจกค่า DNS ไปยังอุปกรณ์ Router ตามบ้าน หรือ ค่าที่ได้รับอัตโนมัติจากผู้ให้บริการจะทำให้เครื่องคอมพิวเตอร์ หรือ มือถือ จะได้รับค่า DNS จากผู้ให้บริการทันที ยกเว้นกรณีที่ผู้ใช้งานตั้งค่า DNS เอง (Manual) โดยหลายคนอาจตั้งค่า DNS ไปที่ 8.8.8.8 ของ google เป็นต้น ซึ่งคนที่ตั้งค่าเองอาจไม่ได้รับผลกระทบกับการเรียก www.facebook.com
ดัง นั้นเหตุการณ์ที่เกิดขึ้นนี้ สามารถเข้าใช้งานในโดเมนอื่นๆได้ ยกเว้นโดเมน facebook.com มีความเป็นไปได้ที่มีการเปลี่ยนเส้นทาง DNS เพื่อให้ไป Query โดเมนที่ DNS ของผู้ให้บริการรายใดรายหนึ่ง และ DNS การสามารถกำหนด host file ในเครื่อง DNS Server เพื่อไม่ให้ผู้ใช้งานเข้าใช้บริการเมื่อมีการเรียกค่า DNS ได้ และสามารถ Redirect ไปยังเพจที่ขึ้นข้อความอื่นๆเพื่อบ่งบอกถึงว่าปิดระงับชั่วคราวได้ การปิดกั้นช่องทางผ่านเทคนิค DNS ในทางที่ก่อให้เกิดประโยชน์โดยมากเขาจะปิดกั้นไม่ให้เข้าถึง โดเมนที่มีภัยคุกคามเช่น โดเมนที่ติดไวรัส (Malware) โดเมนที่เป็น Phishing และ โดเมนที่มีความเสี่ยงทางอาชญากรรมคอมพิวเตอร์ เพื่อไม่ให้ผู้ใช้งานตกเป็นเหยื่อได้
* การตรวจดูว่า DNS เราใช้อยู่คืออะไรสามารถทำได้โดย ใช้ command ipconfig /all หรือใน linux ได้โดย ifconfig ตรวจดูค่า DNS หากใช้ผ่าน Router บ้านหรือองค์กรจะได้ค่าชี้ไปที่ Gateway ขององค์กร นั้นและค่า Router นั้นมักตั้งให้รับค่าอัตโนมัติ จะได้ค่า DNS จากผู้ให้บริการ
ตัวอย่าง Log DNS จากของจริงจาก srandns.com
30-May-2014 11:10:30.446 client 101.108.xx.xx#11240: query: mesu.apple.com IN A + (x.x.x.x) 30-May-2014 11:10:19.702 client 180.183.xx.xx#65484: query: sran.net IN A + (x.x.x.x) 30-May-2014 11:09:56.150 client 124.122.xx.xx#11540: query: m.ak.fbcdn.net IN A + (x.x.x.x) 30-May-2014 11:09:49.712 client 180.183.xx.xx#29337: query: www.facebook.com IN A + (x.x.x.x) 30-May-2014 11:09:36.869 client 180.183.xx.xx#19924: query: dnl-15.geo.kaspersky.com IN A + (x.x.x.x) 30-May-2014 11:09:33.959 client 180.183.xx.xx#19922: query: dnl-15.geo.kaspersky.com IN A + (x.x.x.x) 30-May-2014 11:09:14.741 client 101.108.xx.xx#11237: query: z-m.c10r.facebook.com IN A + (x.x.x.x) 30-May-2014 11:08:56.400 client 180.180.xx.xx#17540: query: imap.gmail.com IN A + (x.x.x.x) 30-May-2014 11:08:56.098 client 180.180.xx.xx#17539: query: www.sran.org IN A + (x.x.x.x)
จาก log จะเห็นว่าเราพบวันเวลา ค่าไอพี ของเครื่อง client ที่ใช้ DNS ค่าความต่อเนื่อง #ตามด้วยตัวเลข การ Query โดเมน
และค่า x.x.x.x จะเป็นค่าไอพีของฝั่ง DNS Server
ยกตัวอย่างเบื้องต้นประมาณนี้ก่อน
สรุปได้ว่า : ปัญหาที่เกิดขึ้นอาจจะเกิดจากการเปลี่ยนค่า DNS ที่ฝั่งผู้ให้บริการจะทำให้ผู้ใช้งานทั่วไปเรียกค่าโดเมนผ่าน DNS ใหม่ที่อาจทำให้เป็นการปิดกั้นช่องทางได้ หรือ ที่ผมเคยเขียนไว้ในบทความ "เตือนภัยเรื่อง DNS ที่มีผลกระทบต่อผู้ใช้งานตามบ้าน http://nontawattalk.blogspot.com/2014/04/dns.html " สิ่งที่เกิดขึ้นอาจเป็นเพราะคนที่เข้าไปแก้ไขค่า config เส้นทางการเรียกข้อมูลในช่วงเวลานั้นอาจจะยังไม่เข้าใจในระดับผู้ให้บริการ (ISP) ดีพอจนปล่อยให้เกิดผลกระทบที่ทำให้ทุกคนรับรู้และเป็น Talk of the town ได้ขนาดนี้
แนวทางที่ควรปฏิบัติในอนาคต
ถึงแม้เหตุการณ์นี้จึงเป็นบทเรียนสำคัญสำหรับคนที่คิดจะทำการปิดกั้น โดยเฉพาะการปิดกั้นทั้งโดเมนสามารถทำได้ แต่อาจมีผลกระทบเยอะ และหากเปิดกั้นจากจุดเดียวด้วยวิธีนี้จำเป็นต้อง Route เส้นทาง การเรียกค่าโดเมนแนม ให้ออกไปยังจุดใดจุดหนึ่ง แต่ผลลัพธ์ก็อย่างที่เห็นคือไม่สามารถใช้งานได้ ซึ่งมีเหตุผลรองรับ เช่น อุปกรณ์ Load Balancing ที่อยู่หน้า DNS Farm Server หรือ DNS Server ใหม่ไม่สามารถรองรับ ปริมาณ traffic ได้ การ Query DNS ไม่สมารถรับค่าปริมาณเยอะๆพร้อมกันได้ อุปกรณ์ฝั่งระบบเครือข่ายไม่สามารถรองรับปริมาณข้อมูลได้ในเวลาจำกัด การปิดกั้นควรปิดกั้นเป็นบางเพจหรือค่า URI page นั้น ในอดีตการเปิดกั้นเว็บเพจ มักใช้เทคนิคเรียกว่า "TCP Hijack session" ปิดการเชื่อมต่อ session ของ ไอพีผู้ใช้งาน (Client) เพื่อไม่ให้เรียกเพจ เช่น http://xx.com/abcd/xx.html อันนี้ทำได้ในอดีต
http://www.abc.com/abc.html แบบนี้ปิดได้
https://www.abc.com/abc.html แบบนี้ปัจจุบันยังปิดไม่ได้
แบบ facebook.com โดเมนทั้งหมด ปิดได้อยู่แล้ว (ไม่ควรทำ) แต่อย่างไรก็ดีก็ยังไม่สามารถปิดกั้นจากจุดเดียวแบบ Single command ได้ ไม่ว่าเป็น โดเมนแนม หรือ URI ต้องบอก ISP แต่ละทีให้ปิด
กรณีเฝ้าระวังการใช้งาน HTTP
การเฝ้าระวัง (monitoring) ขอยกตัวอย่างโดยใช้อุปกรณ์ SRAN Light รุ่นเล็กติดตั้งที่ office
หน้าจอเฝ้าระวังโดยการเขียน signature จับค่า HTTP GET
ส่วน MAC Address เครื่องเป็นค่า MAC ของอุปกรณ์ Switch ในองค์กร ซึ่งไม่ต้องสนใจเพราะค่าจะเป็นค่าเดียวเนื่องจากทำการ Mirror traffic มา
กรณีการเฝ้าระวัง HTTP ผ่าน Proxy
กรณีการเฝ้าระวัง HTTPS
แต่อย่างไรก็ดี HTTPS สามารถมองเห็นได้แต่ต้องทำ MITM (Man In The Middle Attack) ซึ่งในระดับองค์กรทำได้ แต่ระดับประเทศทำยาก และไม่ควรทำ
ปัจจุบันเครือข่ายสังคมออนไลน์ facebook , twitter , youtube หันมาใช้บริการ SSL คือผ่าน https หมด จึงไม่สามารถใช้เทคนิคเดิมเพื่อปิดกั้นได้เนื่องจากมีการเข้ารหัสจนไม่ สามารถล่วงรู้ถึง URI ปลายทางได้รู้แต่ค่าไอพี และทำการ covert กลับเป็นชื่อโดเมนทำให้ปัจจุบันไม่สามารถปิดกั้นได้ แต่หากทำการปิดกั้นก็มีหนทางโดยมากจะทำในระดับองค์กร แต่หากทำในระดับผู้ให้บริการระดับ ISP และในเมืองไทยมีผู้ให้บริการที่ออกโครงข่ายต่างประเทศหลายรายที่นับได้คือ เป็น 10 ที่ การทำวิธีดังกล่าวจึงมีออกแบบทั้งปริมาณข้อมูลที่รับได้ และทางฉุกเฉินเมื่อไม่สามารถเชื่อมต่อได้ ซึ่งโดยรวมนั้นอาจมีผลกระทบต่อผู้ให้บริการ (ISP) และผู้ใช้ งาน (User) โดยเฉพาะอาจได้รับ Certificate ที่ไม่ได้มาจากแหล่งต้นทาง ดังนั้นการปิดกั้นควรคำนึงถึงเรื่องนี้ไม่งั้นอาจเป็นภัยคุกคามต่อผู้ใช้งาน ได้ เช่นกรณีคนที่ ใช้เทคนิค MITM (Man In The Middle attack) ในพื้นที่สาธารณะ บนเครือข่ายไร้สาย หรือ องค์กรขนาดเล็กก็จะได้รับค่า Certificate ที่ไม่ได้มาจากแหล่งต้นทางที่แท้จริงได้เช่นกัน และช่องทางพิเศษในการอำพรางตัวตนนั้นมีมากมาย ค้นหาใน Google หรือ Search engine อื่นก็สามารถใช้งานได้ง่ายและปัจจุบันใครก็ทำได้ ยิ่งทำการปิดกั้นก็ยิ่งมีคนอยากเข้าถึง และหาทางหลีกเลี่ยงการหลบซ๋อนค่าไอพียิ่งทำให้หาตัวผู้กระทำความผิดได้ยากขึ้น ซึ่งสิ่งที่ควรปิดกั้นคือช่องทางที่อำพรางตัวตนแบบออนไลน์มากกว่าการปิดกั้นเว็บเพจ
(อาจดูเหมือนทำยากแต่สามารถทำได้และไม่กระทบต่อผู้ให้บริการและผู้ใช้งาน ซึ่งหากมีโอกาสจะแนะนำวิธีการให้ต่อไป)
ค่าไอพี (IP Address : Who) และ เวลา (Time : When) ส่วน What ทางเทคนิคหาได้จาก Log file ถ้าไม่ใช้เทคนิคการหาทางการข่าวได้ เหล่านี้จะเป็นตัวบ่งบอกถึงความเป็นตัวตนของผู้ใช้งาน หากมีการอำพรางตัวตนก็เท่ากับไม่สามารถหาค่าไอพีที่แท้จริงได้ และโดยมากผู้มีเจตนาไม่ดีมักทำการอำพรางตัวตนที่แท้จริง เพราะคนที่เจตนาดีมักจะไม่มีความจำเป็นต้องอำพรางตัวตนในการใช้งาน
สรุปแนวทางในอนาคต
1. ไม่แนะนำให้มีการปิดกั้นการเข้าถึงข้อมูลไม่ว่าเป็นสื่อสังคมออนไลน์หรือเว็บเพจ เพราะยิ่งปิดกั้นคนก็จะพยายามหาทางเข้าถึง และหลีกเลี่ยงโดยไปใช้โปรแกรมอำพรางตัวเอง เช่นโปรแกรม Tor Network , Proxy Anonymous ต่างๆ และทำให้การหาผู้กระทำความผิดได้ยากขึ้น และการปิดกั้นปิด หนึ่งเว็บก็เปิดใหม่ได้อีกเรื่อยๆ เป็นลักษณะแมววิ่งไล่จับหนู ซึ่งไม่มีทางจบสิ้น และอีกอย่างสังคมปัจจุบันเป็นสังคมเปิด โดยเฉพาะสื่อออนไลน์จะมีข่าวสารฉับไว จนสามารถทำให้ผู้คนที่เข้าถึงอินเทอร์เน็ตรู้ทันกันไปหมด คิดอะไรไม่ออกก็ค้นหา google ก็รู้ได้ ดังนั้นการปิดจึงเป็นวิธีการที่ผมเองไม่เห็นว่าจะเกิดประโยชน์ในระยะยาว
2. เมื่อพบเนื้อหาไม่เหมาะสม ต้องไม่ขยายผลต่อ ไม่ว่าเป็นชื่อเพจ หรือการแชร์ ควรส่งให้หน่วยงานที่รับผิดชอบเพื่อไม่เป็นการขยายผลต่อ
3. หากจะทำการปิดกั้น ควรจะทำการปิดกั้นค่าไอพีที่ได้จากโปรแกรมอำพรางตัวตน หรือทำการปลอมตัวตนที่แท้จริงจนไม่สามารถตรวจสอบได้
และควรปิดกั้นการเข้าถึงโดเมนที่ติดเชื้อ Malware โดเมนที่หลอกลวงประชาชน (Phishing) ในฝั่งผู้ให้บริการอินเทอร์เน็ตไทย ซึ่งเป็นการสร้างความปลอดภัยให้กับคนในชาติ ที่ใช้งานอินเทอร์เน็ตไม่ตกเป็นเหยื่อทางอาชญากรรมคอมพิวเตอร์โดยไม่รู้ตัว
4. ควรรณรงค์ให้มีการเก็บ Log ให้ถูกต้องตามกฏหมาย พรบ. คอมพิวเตอร์ฯ เพราะ Log จะเป็นตัวช่วยสืบหาผู้กระทำผิดได้ Log บ่งบอกถึงพฤติกรรมและเหตุการณ์ที่ขยายผลในการหาผู้กระทำความผิดทั้งตัวบุคคลและเครือข่ายได้ ,Log ที่เก็บไม่ว่าผู้ให้บริการ ISP หรือ ผู้ให้บริการทาง Application ต่างๆที่มีความเสี่ยงต่อการกระทำความผิดควรเก็บ Log และไม่ว่าเป็นองค์กร บริษัท โรงเรียน โรงแรม ผู้ให้บริการไร้สาย (Wi-Fi) Log every where เป็นต้น ควรเก็บ Log ทั้งหมด ซึ่งประโยชน์ของ Log ที่สามารถเชื่อมโยงหลักฐานต่างๆ เพื่อเป็นประโยชน์ในการสืบสวนได้ เปรียบได้กล้องวงจรปิดหากมีหลายจุดก็ย่อมปะติดปะต่อข้อมูลได้ อ่านเพิ่มเติมได้
http://nontawattalk.blogspot.com/2010/08/4.html
http://nontawattalk.blogspot.com/2009/04/blog-post.html
5. ควรพัฒนาวิจัยเทคโนโลยีของคนในชาติเองอย่าไปพึ่งคนอื่น ประเทศชาติอื่นให้มาก อย่าเชื่อฝรั่งมาก ในกรณีที่เห็นได้ชัด เช่น facebook หรือ Line เราไม่สามารถขอหลักฐานได้มากมายเพราะการเก็บข้อมูลอยู่ที่ต่างประเทศทั้งหมด ซึ่งต่างประเทศก็มีกฏหมายคอมพิวเตอร์ที่แตกต่างกับเราใช้กันไม่ได้ และอีกไม่นานเมื่อ 4G มาถึงเราจะพบว่าการโทรศัพท์เราก็จะไม่ใช้เบอร์โทรอีกต่อไป เป็นหมายเลข account ของ Line หรือ google หรือ Apple หรือ facebook และโทรศัพท์ผ่านเครือข่ายอินเทอร์เน็ตหมด พอถึงวันนั้นเราจะยืนอยู่ที่ไหน? เพราะ Server ต่างๆเราฝากชีวิตไว้ที่ Cloud Services กับผู้ให้บริการ Application ต่างชาติหมด ไม่ว่ารูปภาพ คลิป เว็บ ข้อมูลต่างๆ ก็เสมือนว่าชีวิตเราฝากไว้กับเขา
เรื่องที่เห็นชัดเจนอีกเรื่อง คือ CDN (Content Delivery Services) ที่ให้บริการ facebook ก็ยังมีเส้นทางผ่านไปประเทศสิงค์โปร CDN หลักฐาน facebook การเก็บข้อมูลส่วนที่ใกล้ที่สุดก็ยังอยู่ที่สิงค์โปรไม่ได้อยู่ในประเทศไทย ... พอเสียที่กับการเป็นแค่ตัวแทนขาย ถึงเวลาที่เราต้องมาร่วมกันสร้างชาติให้เข้มแข็งขึ้นได้แล้ว เราควรมีของที่เราใช้เองพัฒนาเองบางได้แล้ว อาจถึงเวลาที่เรามานั่งทบทวนเรื่องเหล่านี้ให้มากก่อนที่ตกหลุดพรางเสรีภาพออนไลน์แบบไร้พรมแดนแบบนี้ต่อไป
Nontawattana Saraman
SRAN Dev Team
30/05/57
