อย่าเชื่อข้อมูลตำแหน่งผู้ใช้ (User Location)

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

วิธีรับตำแหน่งของผู้ใช้

• ถามตำแหน่งจากผู้ใช้โดยตรง
  • ข้อดี: ทำได้ง่าย ถ้าผู้ใช้ให้ข้อมูลที่ถูกต้องก็เชื่อถือได้ และรองรับตำแหน่งได้หลากหลาย
  • ข้อเสีย: ผู้ใช้อาจพิมพ์ผิด หรือละข้อมูลบางส่วน ผู้ใช้อาจให้ข้อมูลเท็จได้
• ใช้ heuristic ของอุปกรณ์
  • อุปกรณ์สมัยใหม่เข้าถึงข้อมูลตำแหน่งได้ผ่าน GPS, ข้อมูล Wi-Fi, เสาสัญญาณมือถือ และ IP address
  • นักพัฒนาเว็บสามารถเข้าถึงตำแหน่งผู้ใช้ผ่าน Geolocation API ของเบราว์เซอร์ได้
  • ข้อเสีย: ต้องขออนุญาตผู้ใช้ให้แชร์ตำแหน่ง และผู้ใช้อาจปฏิเสธได้
• ใช้ IP address
  • IP address ใช้ระบุอุปกรณ์บนเครือข่ายแบบเฉพาะเจาะจง และใช้ระบุตำแหน่งได้
  • ตัวเลขแต่ละช่วงใน IP address แทน subnet จากช่วงกว้างไปสู่ช่วงที่แคบลง
  • แต่ IP address เพียงอย่างเดียวไม่พอจะรู้ตำแหน่งผู้ใช้ จึงต้องนำไปเทียบกับฐานข้อมูลตำแหน่งของ subnet ที่รู้จัก
• ใช้ edge computing
  • เป็นวิธีที่ให้คำขอของผู้ใช้ไปรันบนเซิร์ฟเวอร์ที่ใกล้ที่สุด
  • สามารถให้ข้อมูลตำแหน่งได้โดยไม่ต้องขออนุญาตผู้ใช้หรือ lookup IP address
  • ข้อเสีย: มันคือตำแหน่งของ edge node ไม่ใช่ตำแหน่งจริงของผู้ใช้

เหตุผลที่เราเชื่อถือตำแหน่งผู้ใช้ไม่ได้

• เชื่อถือผู้ใช้ไม่ได้
  • ไม่มีอะไรรับประกันว่าผู้ใช้จะกรอกตำแหน่งจริงของตนอย่างซื่อสัตย์เสมอไป
  • ผู้ใช้อาจกรอกข้อมูลผิดโดยไม่ตั้งใจได้ด้วย
• เชื่อถืออุปกรณ์ไม่ได้
  • ผู้ใช้อาจปฏิเสธการใช้ Geolocation API ได้
  • ผู้ใช้สามารถเปลี่ยนข้อมูลของ Geolocation API ได้จากการตั้งค่าเบราว์เซอร์
• เชื่อถือ IP address ไม่ได้
  • ผู้ใช้อาจส่งคำขอผ่าน VPN ได้
  • คุณจะเห็นเพียง IP address ของ VPN และไม่รู้ IP จริงของผู้ใช้
• เชื่อถือ edge computing ไม่ได้
  • เพราะเป็นข้อมูลตำแหน่งของ edge node จึงอาจต่างจากตำแหน่งจริงของผู้ใช้
  • เมื่อใช้ VPN ก็จะเข้าถึง IP address เดิมไม่ได้

แล้วเราควรทำอย่างไร?

• แม้จะมีหลายวิธีในการได้ข้อมูลตำแหน่ง แต่ไม่มีวิธีไหนที่เชื่อถือได้อย่างสมบูรณ์
• แล้วควรยอมแพ้ไหม? No! เรายังหาข้อมูลที่ดีกว่าเดิมและเตรียมรับมือได้

ตัวอย่าง: การแปลเนื้อหา

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

1. ผู้ใช้ร้องขอเว็บไซต์
2. ตรวจพบผ่าน edge computing ว่าคำขอนี้มาจากเบลเยียม
3. ค้นหาค่าภาษาที่ต้องการจาก HTTP cookie
4. ถ้ามี cookie ก็ใช้ภาษาตามค่าที่ตั้งไว้
5. ถ้าไม่มี cookie ก็ใช้เวอร์ชันภาษาอังกฤษหรือดัตช์
6. เว็บไซต์แสดงรายการภาษาที่รองรับให้ผู้ใช้เลือก
7. เมื่อผู้ใช้เลือกภาษาที่ต้องการแล้ว ให้บันทึกไว้ใน cookie

• ในสถานการณ์นี้ เราใช้ทั้ง edge computing และการรายงานจากผู้ใช้ร่วมกันเพื่อให้ได้ข้อมูลตำแหน่งสำหรับปรับปรุงประสบการณ์ผู้ใช้
  • ดูเหมือนไม่จำเป็นต้องใช้ Geolocation API
  • มีความเสี่ยงที่จะแสดงภาษาผิด แต่ต้นทุนต่ำ
  • ต่อให้ข้อมูลตำแหน่งผิดหรือหายไป เว็บไซต์ก็ยังทำงานได้
• อัปเดต: ยังสามารถใช้ header Accept-Language ที่บอกภาษาและ locale ที่ไคลเอนต์ต้องการได้ด้วย

ตัวอย่าง: แอปพยากรณ์อากาศ

• มีแอปพลิเคชันที่แสดงข้อมูลอากาศตามตำแหน่ง
  • ในกรณีนี้ แอปจำเป็นต้องมีข้อมูลตำแหน่งถึงจะทำงานได้ ถ้าไม่มีข้อมูลแล้วจะจะแสดงสภาพอากาศได้อย่างไร?
• ในสถานการณ์นี้ การคาดเดาตำแหน่งของผู้ใช้ในตอนโหลดครั้งแรกถือว่าปลอดภัย
  • คุณสามารถดึงข้อมูลนั้นจาก edge computing หรือ IP address แล้วแสดงสภาพอากาศของพื้นที่ผู้ใช้ (เท่าที่เราคิดว่าใช่)
  • และเพราะจุดสำคัญของเว็บไซต์คือเรื่องตำแหน่ง จึงสามารถใช้ Geolocation API เพื่อขอข้อมูลที่แม่นยำกว่าได้
  • ควรมีตัวเลือกการรายงานจากผู้ใช้ที่ยืดหยุ่นไว้ด้วย เผื่อผู้ใช้อยากดูข้อมูลของตำแหน่งอื่น
  • วิธีหนึ่งคือให้ช่องค้นหาที่มี autocomplete สำหรับข้อมูลตำแหน่งที่ละเอียดที่สุดเท่าที่ทำได้
  • ส่วนการจัดการการเข้าชมครั้งต่อไปทำได้หลายแบบ จะตั้งค่าเริ่มต้นเป็นสภาพอากาศ “ท้องถิ่น” เสมอ หรือจำตำแหน่งจากการเข้าชมก่อนหน้าก็ได้

1. ผู้ใช้ร้องขอเว็บไซต์
2. ในคำขอแรก ให้เริ่มแอปโดยประมาณตำแหน่งจาก edge computing หรือ IP address
3. เมื่อไคลเอนต์โหลดครั้งแรก ให้เรียก Geolocation API เพื่ออัปเดตข้อมูล
4. สามารถบันทึกข้อมูลตำแหน่งลง cookie สำหรับการโหลดครั้งถัดไปได้
5. มีช่องป้อนข้อมูลแบบยืดหยุ่นพร้อม autocomplete สำหรับค้นหาตำแหน่งอื่น

• จุดสำคัญคือ แอปไม่ได้สนใจจริง ๆ ว่า ผู้ใช้ อยู่ที่ไหน
  • มันแค่ต้องการ ตำแหน่ง เท่านั้น
  • ตำแหน่งที่ผู้ใช้รายงานเอง (การค้นหา) มีความสำคัญเหนือกว่าตำแหน่งที่พบจาก cookie, edge computing หรือ IP address
• เพราะสภาพอากาศเปลี่ยนทุกวัน จึงควรคิดเรื่องกลยุทธ์การ cache และจะให้แอปเรนเดอร์ฝั่งเซิร์ฟเวอร์เป็นหลัก หรือเรนเดอร์ฝั่งไคลเอนต์เป็นหลักด้วย

ตัวอย่าง: ตัวค้นหาสาขา

• สมมติว่าคุณมีร้านค้าจริงหลายสาขา
  • คุณอาจแสดงแค็ตตาล็อกสินค้าและสต็อกออนไลน์ได้ แต่การแสดงข้อมูลสต็อกในแต่ละสาขาแบบล่าสุดจะเป็นแนวทางที่ดีกว่า
  • เพื่อทำเช่นนั้น คุณต้องรู้ว่าควรแสดงสต็อกของสาขาใด และเพื่อประสบการณ์ใช้งานที่ดีที่สุด ก็ควรเป็นสาขาที่อยู่ใกล้ผู้ใช้ที่สุด
• อีกครั้งหนึ่ง การคาดเดาตำแหน่งผู้ใช้ด้วย edge computing หรือ IP address ก็สมเหตุสมผล
  • จากนั้นให้มีช่องป้อนข้อมูลแบบยืดหยุ่นที่ผู้ใช้ระบุตำแหน่งเองได้ แต่ควรจำกัด autocomplete ให้เป็นรายชื่อสาขาที่เรียงตามความใกล้เคียง
  • การเรียก Geolocation API ก็นับว่าเป็นความคิดที่ดี
• ความต่างระหว่างตัวอย่างนี้กับตัวอย่างก่อนหน้าคือ จุดประสงค์หลักของเว็บไซต์ ไม่ได้ขึ้นอยู่กับ ตำแหน่ง
  • เพราะฉะนั้นควรรอจนกว่าผู้ใช้จะเริ่มโต้ตอบกับฟีเจอร์ที่ขึ้นอยู่กับตำแหน่ง
  • กล่าวคือ ควรขอตำแหน่งก็ต่อเมื่อผู้ใช้โฟกัสที่ช่องตัวค้นหาสาขาเท่านั้น

ตัวอย่าง: การตั้งราคาตามภูมิภาค

• นี่เป็นหัวข้อที่ค่อนข้างยาก เพราะถ้าคุณต้องการคิดราคาต่างกันตามตำแหน่งผู้ใช้ ควรทำอย่างไร?
• ตัวอย่างเช่น เป็นที่รู้กันว่าสายการบินและโรงแรมบางแห่งแสดงราคาสูงกว่าให้ผู้ใช้ที่จองจากบางภูมิภาค เมื่อเทียบกับภูมิภาคอื่น
• พักประเด็นจริยธรรมไว้ก่อน นี่เป็นเรื่องของความสามารถในการทำกำไร จึงมีผลกระทบสูงมาก
• เพราะอย่างนั้น คุณคงไม่อยากให้ผู้ใช้เปลี่ยนราคาได้ง่าย ๆ ผ่านข้อมูลตำแหน่งที่รายงานเอง
• ในกรณีนี้ คุณน่าจะใช้เพียง edge computing หรือ IP address เท่านั้น
  • ผู้ใช้อาจใช้ VPN เพื่อหลบเลี่ยงได้ แต่ก็คงเป็นวิธีที่ดีที่สุดเท่าที่ทำได้
  • ถ้ากังวลเรื่องการหลอกลวงจริง ๆ คุณอาจพยายามบล็อกคำขอจากผู้ใช้ VPN ด้วยฟีเจอร์ enhanced proxy detection ของ Akamai
  • แต่ถ้าทำแบบนั้น ก็อาจทำให้ไม่ได้ขายเลยแทนที่จะขายในราคาส่วนลด ทางเลือกขึ้นอยู่กับคุณ

ตัวอย่าง: แบนเนอร์คุกกี้

• ตัวอย่างสุดท้ายนี้เน้นเรื่องการปฏิบัติตามกฎหมายมากกว่า จึงขอเริ่มด้วยข้อสงวนเล็กน้อย: ฉันไม่ใช่ทนายความ!!!
  • นี่เป็นเพียงตัวอย่างสมมุติ และไม่ควรถูกตีความว่าเป็นคำแนะนำทางกฎหมาย
• ในปี 2016 สหภาพยุโรปได้ผ่านกฎหมาย General Data Protection Regulation (GDPR)
  • นี่คือกฎหมายที่คุ้มครองความเป็นส่วนตัวของผู้ใช้อินเทอร์เน็ตในสหภาพยุโรป และมีผลกับบริษัทที่เสนอสินค้าหรือบริการให้บุคคลใน EU แม้ว่าบริษัทนั้นจะอยู่นอก EU ก็ตาม
• ข้อกำหนดสำหรับเจ้าของเว็บไซต์มีอยู่มากมาย แต่สิ่งที่ฉันอยากชี้คือผลเสียของแบนเนอร์คุกกี้ที่ตอนนี้เราเห็นกันทั่วไปบนอินเทอร์เน็ต
  • ฉันจะไม่ถกเรื่องข้อกังวลด้านความเป็นส่วนตัว ว่าแบนเนอร์คุกกี้ถูกหรือผิด มีประสิทธิภาพหรือไม่มีประสิทธิภาพ หรือมีแนวทางที่ดีกว่าหรือไม่
  • แต่จะบอกว่า ควรแสดงแบนเนอร์คุกกี้เฉพาะเมื่อกฎหมายกำหนดจริง ๆ และควรหลีกเลี่ยงเมื่อไม่จำเป็น
• อีกครั้งหนึ่ง การรู้ตำแหน่งของผู้ใช้เป็นเรื่องสำคัญมาก
  • กรณีนี้คล้ายกับตัวอย่างก่อนหน้ามาก และแนวทางการทำก็คล้ายกัน ความต่างหลักคือความรุนแรงหากทำพลาด ดังนั้นระดับความพยายามที่จะทำให้ถูกต้องจึงต่างกัน
• แบนเนอร์คุกกี้อาจเป็นตัวอย่างที่แพร่หลายที่สุดของการที่กฎหมายและตำแหน่งผู้ใช้ส่งผลต่อเว็บไซต์อย่างไร แต่ถ้าจะหาตัวอย่างที่รุนแรงที่สุด ก็น่าจะเป็น Great Firewall ของจีน

บทสรุป

• ไม่มีคำตอบเดียวที่ถูกต้องสำหรับการระบุตำแหน่งผู้ใช้
  • คุณต้องเลือกใช้การรายงานจากผู้ใช้, heuristic ของอุปกรณ์, edge computing และ IP address ร่วมกันตามแต่สถานการณ์
• สิ่งสำคัญที่ต้องถาม
  • คุณต้องการตำแหน่งของผู้ใช้จริง ๆ หรือแค่ต้องการตำแหน่งใดก็ได้?
  • ข้อมูลต้องแม่นยำแค่ไหน?
  • ถ้าตำแหน่งผู้ใช้ถูกปลอมขึ้นมา จะยังยอมรับได้ไหม?
• ควรพิจารณาด้วยว่าการปฏิบัติตามกฎหมาย ข้อบังคับ ฟังก์ชันการใช้งาน และความน่าเชื่อถือระดับ 95% นั้นเพียงพอหรือไม่
• หากคุณใช้ลอจิกตำแหน่งด้วยเหตุผลทางกฎหมาย ก็ควรมีมาตรการป้องกันตัวเองไว้
• การปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล เช่น CCPA, GDPR เป็นต้น