ข้อควรระวังในการให้รหัสผ่าน iCloud/Apple ID ตอนนำเครื่องส่งซ่อม

พอดีว่ามีเคสของพี่ที่รู้จักท่านหนึ่ง นำเครื่อง Macbook pro (2016) ส่งซ่อม แล้ว ศ. บริการในไทยขอรหัสผ่านเข้า account ของ iCloud ไปเพื่อใช้ในการซ่อมเครื่อง ซึ่งต้องบอกว่าอันนี้เป็นเคสที่ค่อนข้างซีเรียสนะ เพราะ account ตัว iCloud นั้นก็คือ Apple ID ด้วยนั้นเอง

คนที่ได้ Apple ID ไปนั้นสามารถเข้าถึงความสามารถ และข้อมูลใน iCloud ได้ทั้งหมด ไฟล์งานต่างๆ ใน iCloud Drive ระบบ tracking location device, สั่ง wipe และปลดการผูกตัวเครื่องกับ account ได้

(มีเคสมากมายที่เวลา iPhone โดนขโมย โจรมักใช้อุบายเพื่อบอกให้เราปลดพวกนี้แหละ)

ในส่วนของบริการทั่วไป ก็สามารถนำไป sign in ตัว iTunes เพื่อซื้อเพลง หนัง และบริการอื่น ๆ ได้ รวมไปถึง Apple online store เพื่อซื้อสินค้าได้ด้วย เพราะอย่าลืมว่า Apple ID ผูกบัตรเครดิตไว้อยู่ด้วยมันซื้อของจาก online store ได้

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

ซึ่งจากเคสตัวอย่างนี้ไม่ใช่แค่ Macbook แต่ยังรวมไปถึง iPhone, iPad และอุปกรณ์อื่นๆ ที่เชื่อมโยงเข้ากับ iCloud ทั้งหมด

สุดท้าย ไม่แน่ใช่แค่สินค้า Apple ที่ใช้ iCloud หรือ Apple ID เท่านั้น สินค้าหลาย ๆ ยี่ห้อ-รุ่นอย่างของ Android ที่ผูกกับ Google Account หรือ Windows ทีใช้ Microsoft Account ก็ไม่แตกต่างกัน ฉะนั้น หาก ศ. จำเป็นต้องใช้ข้อมูลเหล่านี้ เราควรนัดและปลดล็อคให้ภายใน ศ. บริการเองเท่านั้น ลำบากหน่อย แต่ข้อมูลของเราจะไม่ถูกนำไปใช้โดยไม่ผ่านการควบคุมดูแลที่ดี

แก้ปัญหา Chromecast 2 (2015) ต่อ WiFi 5Ghz ไม่ได้

เพิ่งซื้อ Chromecast มาจาก AIS เอามากลับมาบ้านต่อเน็ตในบ้านแล้วต่อด้วย WiFi คลื่น 5Ghz ไม่ได้ แต่พอเปลี่ยนไป 2.4Ghz แล้วทำงานปรกติ ก็เลยงง ๆ เลยลองหาว่ามีใครเป็นแบบเราบ้าง สรุปเป็น bug ของตัว Chromecast เอง มีคนเจอปัญหานี้อยู่เยอะเหมือนกัน เลยเขียนโน๊ตไว้สักหน่อยว่าแก้ไขปัญหายังไง

วิธีการแก้ไขปัญหาต้องปรับแต่งที่ router หลักที่ใช้งาน ตามด้านล่างนี้

  1. ทำการปิดการใช้ WiFi คลื่น 5Ghz ใน router เสียก่อน
  2. เปลี่ยนชื่อ SSID ของ WiFi คลื่น 2.4Ghz ใน router เป็นชื่อเดียวกับ WiFi คลื่น 5Ghz ตัวอย่างเช่น “D-LINK 860L” to “D-LINK 860L 5G” ถ้าใช้ WPA2 ตัว key ที่ใช้เข้า WiFi ต้องเหมือนกันด้วย
  3. ทำการติดตั้ง Chromecast ผ่านมือถือใหม่ แล้วให้เลือกไปที่ “D-LINK 860L 5G”
  4. เมื่อติดตั้งเรียบร้อยแล้ว ตรวจสอบให้แน่ใจว่า cast ข้อมูลขึ้นไปได้ อาจลองเปิด Youtube เคสส่งเข้าไปดู ถ้าได้ให้ทำการถอดสายไฟออกจากตัว Chromecast ให้ปิดตัวลง
  5. ปรับ SSID ของ WiFi คลื่น 2.4Ghz และ 5Ghz กลับมาเป็นชื่อเดิม แล้วเปิดการใช้คลื่น 5Ghz อีกครั้ง
  6. ทำการเสียบสายไฟเพื่อเปิด Chromecast ลองแล้วใช้งานดูอีกครั้ง ตัว Chromecast จะต่อเข้า SSID ตัว 5Ghz ได้แล้ว

ถ้าดูจากการแก้ไขปัญหา น่าจะเป็นปัญหาตอนที่ตัว Chromecast บันทึกค่าเพื่อเชื่อมต่อ WiFi 5Ghz นั้นแหละ เราเลยต้องหลอกตัว Chromecast ให้บันทึกค่า SSID และ key จากคลื่น 2.4Ghz ที่ไม่มีปัญหาแทน

จากปัญหาข้างต้น เหมือน Google ยังไม่แก้ไข bug นี้เสียที คนที่ซื้อไปใช้ก็นึกว่าไม่รองรับ WiFi 5Ghz เพราะมันต่อไม่ได้ตามปรกติเนี่ยแหละ

อ้างอิง

ตั้งค่า Google Play Store ให้ถามรหัสผ่านทุกครั้งที่จ่ายเงินซื้อแอพผ่าน Google Play Store และของภายในแอพต่างๆ

เผื่อใครยังไม่รู้ …

1. เปิดแอพ Google Play Store แล้วไปที่ Settings

1

3. ที่ User controls ให้เลือกที่ Require password for purchases

2

4. เลือกว่าจะให้ถามรหัสผ่านแบบใด โดยมี 3 แบบให้เลือก

  1. For all purchases through Google Play on this device (ถามทุกครั้ง)
  2. Every 30 minutes (ถาม 1 ครั้ง และมีระยะเวลาจดจำรหัสผ่านไว้ให้ 30 นาที เหมาะกับคนซื้อแอพบ่อยๆ)
  3. Never (ไม่ต้องถาม)

โดยค่าเริ่มต้นแล้วจะตั้ง Never (ไม่ต้องถาม) ไว้ ถ้าต้องการให้ถามทุกครั้งก็เลือก For all purchases through Google Play on this device (ถามทุกครั้ง) ตามโจทย์ที่ได้ตั้งไว้

3 4

5. เมื่อเลือกแล้ว ก็มีการถามรหัสผ่านยืนยันการเปลี่ยนแปลงค่าต่างๆ ก็เป็นอันจบขั้นตอนการตั้งค่า

4.1

 

เวลาซื้อแอพทั่วๆ ไป หรือจ่ายเงินผ่านภายในแอพด้วย Google play จะมีการถามรหัสผ่านทุกครั้งตามที่เราได้ตั้งโจทย์ไว้

5 6

“YouTube” app เจ้าปัญหาของ Microsoft บน Windows phone 8

ส่วนตัวแล้วนั้น Microsoft ทำ “ผิด” โดยละเมิด “terms of service” ในหลายเรื่อง และส่วนที่สำคัญคือ Trademark “YouTube” และการทำวิศวกรรมย้อนกลับที่นำมาใช้เพื่อเพิ่มประสิทธิภาพในการใช้งาน (คำกล่าวอ้างคือ “เพื่อประสบการณ์ในการที่ดีกว่า”)

ซึ่งถ้าไม่ใช้ Trademark “YouTube” และใส่ลง Music+Videos ไปแทน โดยไปพัฒนาส่วนการดึงตัววิดีโอจากหลายๆ แหล่งแทน โดยใช้ YouTube เป็นค่าเริ่มต้น จะดูดีกว่ามากเลยทีเดียว (ไม่แน่อาจจะไม่เกิดปัญหาอีก เพราะไปดึง YouTube มาไม่ได้เพราะ Google ไม่ให้ในกรณีนี้อีก) ซึ่งคล้ายๆ กับ People Hub ที่สามารถเชื่อมต่อกับ Twitter, Facebook และ LinkedIn ได้แบบนั้น ซึ่งส่วนตัวในตอนนี้ผมยังแปลกใจว่าทำไม Microsoft ต้องมาทำ YouTube แล้วบอกว่าเป็น official ให้อยู่เนืองๆ แถมดันทุรังใช้ชื่อ Trademark “YouTube” ที่ Google เป็นเจ้าของอยู่อีก ซึ่งจริงๆ เกมนี้ให้ 3rd party ลงมาเล่นแทนตัวเองก็น่าจะจบ และดูดีกว่า โดยที่ 3rd party ส่วนใหญ่ก็ทำได้ดีพอสมควร แม้ไม่สุด แต่ก็ไม่ได้แย่

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

ส่วนฝั่งของ Google ก็ดูจะพยายามเหมือนจะกีดกัน คือมาแนวตัวเองก็ไม่ทำ official app ภายใต้การกำกับดูแล จน Microsoft ต้องลงมาทำให้เอง และสุดท้ายกลายเป็นบีบ Microsoft ต้องทำผิด terms of service ไปเสียเอง

ศึกนี้ถ้ามองจริงๆ “Microsoft ผิด และ Google ถูก” อย่างไม่ต้องสงสัย (ผมพยายามหาข้อแก้ตัวให้ แต่สุดท้ายมันก็ไม่ไหวจริงๆ)

ในข้อเสนอผมตอนนี้ Microsoft ควรทำคือ

  • ลบ “YouTube” app ออกไปจาก Windows phone store และเลิกใช้ชื่อนี้ไปเลย ให้เจ้าของ Trademark เป็นคนจัดการณ์เอง พร้อมทำ FAQ เสีย (ทำแบบรวมๆ)
  • ออกแถลงการณ์ขอโทษ Google ต่อกรณีใช้ Trademark “YouTube” และการทำวิศวกรรมย้อนกลับ
  • สนับสนุนบริการ Video Sharing ตัวอื่นๆ แทน เช่น Vimeo ที่มี Official ที่ก็ใช้งานได้เป็นอย่างดีแทน

ผมมองว่า Microsoft ควรใช้กระแสของข่าวนี้แม้ตัวเองจะผิด แต่เพื่อให้กระแสสังคมตีคำถามกลับไปยัง Google เองว่า เมื่อไหร่จะมี Official app บน Windows phone แน่นอนว่าจะเป็นมาตรฐานต่อไปในอนาคตว่า ถ้าจะทำ app หรือบริการที่เชื่อมต่อกับ Google จะมีกรณีอะไรเกิดขึ้นได้บ้างด้วย ซึ่งกรณีแนวๆ นี้ก่อนหน้านี้อย่าง ยกเลิก EAS ใน Google apps และ Gmail, โจมตี EAS และให้นักพัฒนามาใช้มาตรฐานเปิด และสุดท้ายก็ปิดการรองรับมาตรฐานเปิดเพราะ Microsoft ก็ปรับ OS ให้กลับมารองรับมาตรฐานเปิดดังกล่าว ซึ่งเป็นเหมือนเกมไล่จับกันไป-มา และสุดท้ายเราต้องกลับมาตั้งคำถามต่อกรณีแนวๆ นี้ระหว่างผู้ผลิตและผู้ให้บริการที่มีปัญหาพยายามกีดกันไป-มาว่า “ผู้ใช้งานเสียประโยชน์ เพราะผู้ใช้งานดังกล่าวก็อาจเป็นลูกค้าของทุกฝ่ายที่กำลังตีกันอยู่ แล้วพวกเราได้อะไรกับกรณีนี้บ้าง”

Google เสียงอ่อนกรณี CalDAV API ยอมเปิดให้นักพัฒนาทุกคนเข้าถึงได้แล้ว

ถ้าเราจำกันได้ เมื่อเดือนมีนาคมที่ผ่านมา Google ได้ประกาศว่า CalDAV ซึ่งเป็นมาตรฐานเปิดสำหรับการเข้าถึงข้อมูลปฏิทิน (calendar) ผ่านเว็บจะกลายเป็น API สำหรับพันธมิตรและนักพัฒนาเฉพาะกลุ่มของ Google ที่ได้รับการคัดเลือกเท่านั้น หลังจากนั้น Google ก็ได้รับข้อเรียกร้องให้กลับมาพิจาราณาให้ CalDAV สามารถเข้าถึงได้สำหรับนักพัฒนาทุกคน ไม่ใช่เฉพาะกลุ่มตลอดมา

มาในวันนี้ Piotr Stanczyk ซึ่งเป็น Tech Lead ของ Google ได้ทบทวนนโยบายใหม่ตามข้อเรียกร้องของนักพัฒนา ให้สามารถเข้าถึง CalDAV API สำหรับนักพัฒนาทุกคนอีกครั้ง (We are keeping the CalDAV API public. And in the spirit of openness.) โดยสามารถเข้าถึงด้วย endpoint ใหม่ที่ https://apidata.googleusercontent.com/caldav/v2

ในด้านของ CardDAV API ซึ่งมาตรฐานเปิดสำหรับการเข้าถึงข้อมูลติดต่อ (contact) ผ่านเว็บ Piotr Stanczyk ได้ประกาศว่านักพัฒนาทุกคนสามารถเข้าถึง API ดังกล่าวได้แล้ว พร้อมทั้งแนะนำการเข้าถึงผ่าน OAuth 2.0 อีกด้วย

ที่มา: Google Developers Blog