สำรวจข้อมูล WiFi บนเที่ยวบิน Southwest โดยไม่ใช้อินเทอร์เน็ต

 (jamesbvaughan.com)
1 คะแนน โดย GN⁺ 2023-09-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระหว่างเที่ยวบินตรง St. Louis-Oakland ขากลับจาก Strange Loop เมื่อ การชำระเงินอินเทอร์เน็ต $8 ล้มเหลว จึงตรวจสอบว่ามีข้อมูลใดบ้างที่เข้าถึงได้โดยไม่ใช้อินเทอร์เน็ตในขณะที่เชื่อมต่อกับ WiFi บนเครื่องบิน
  • จากคำขอเครือข่ายของพอร์ทัล WiFi ของ Southwest พบ endpoint current.json ที่สำเร็จซ้ำ ๆ และ response นี้ดูเหมือนจะเป็นข้อมูลพื้นฐานของหน้าสถานะเที่ยวบิน
  • endpoint ดังกล่าวสามารถเรียกด้วย curl ได้ แม้ไม่มีคุกกี้หรือ header และส่งคืนข้อมูลอย่างความสูง พิกัด เวลาถึงโดยประมาณ ความเร็วภาคพื้น ระยะทางที่เหลือ เปอร์เซ็นต์ความคืบหน้าของเที่ยวบิน และสถานะการเชื่อมต่อดาวเทียม
  • นำข้อมูลที่เก็บได้มาแสดงผลเป็นภาพสำหรับความสูง ETA และความเร็วภาคพื้น โดยหากไม่นับช่วงลดระดับ ความสูงแกว่งเพียงประมาณ 20~30 ฟุต
  • แม้ไม่ใช่การค้นพบที่นำไปใช้ได้จริงเป็นพิเศษ แต่แค่ JSON สถานะเที่ยวบิน ที่พอร์ทัล WiFi บนเครื่องบินเปิดเผย ก็สามารถนำมาเก็บและวิเคราะห์ข้อมูลระหว่างบินได้

เริ่มจากการชำระเงินล้มเหลว สู่การสำรวจ WiFi บนเครื่องบิน

  • ระหว่างเที่ยวบินตรง St. Louis-Oakland ขากลับจาก Strange Loop พยายามซื้อสิทธิ์ใช้อินเทอร์เน็ต $8 ผ่าน พอร์ทัล WiFi บนเครื่องบิน ของ Southwest แต่ไม่มีวิธีชำระเงินใดถูกยอมรับ
  • หน้าเว็บไม่ได้แสดงข้อความผิดพลาดที่ช่วยแก้ปัญหาได้ จึงตรวจสอบคำขอที่ล้มเหลวด้วย เครื่องมือ developer tools ด้านเครือข่าย ของเบราว์เซอร์
  • จากคำขอที่ล้มเหลวเองหาเบาะแสได้ยาก แต่คำขอ current.json ที่สำเร็จซ้ำ ๆ สะดุดตา

ข้อมูลสถานะเที่ยวบินที่ current.json ส่งคืน

  • response ของ current.json ดูเหมือนเป็นข้อมูลที่ขับเคลื่อน หน้าสถานะเที่ยวบิน ของพอร์ทัล WiFi บนเครื่องบิน
  • response ตัวอย่างมีค่าต่อไปนี้
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: ค่าที่ดูเหมือนเปอร์เซ็นต์ความคืบหน้าของเที่ยวบิน
    • altVal: ความสูงปัจจุบัน
    • lat, lon: พิกัดปัจจุบัน
    • dtzone: เขตเวลาของปลายทาง
    • within_us: ระบุว่าเป็นเที่ยวบินภายในสหรัฐฯ หรือไม่
    • etad: เวลาถึงปลายทางโดยประมาณ
    • gspdVal: ความเร็วภาคพื้นปัจจุบัน
    • ttgc: ค่าที่ดูเหมือนเวลาที่เหลือ
    • dist_remain: ระยะทางที่เหลือ
    • actime24: เวลาปัจจุบันของเขตเวลาใดสักแห่ง

จำลองคำขอจากเบราว์เซอร์ด้วย curl

  • ใช้ฟีเจอร์ “Copy as cURL” ของเบราว์เซอร์เพื่อดึงคำสั่งเรียก endpoint ได้อย่างรวดเร็ว
  • ฟีเจอร์นี้มีใน Firefox และเบราว์เซอร์ที่ใช้ Chromium และมีประโยชน์เมื่อต้องจำลองคำขอที่เบราว์เซอร์ส่งไปพร้อม header เดิม
  • ผลการทดลองพบว่าคุกกี้หรือ header ที่อยู่ในคำขอไม่จำเป็น และสามารถดึงข้อมูลได้ด้วยการเรียก curl แบบง่าย ๆ ดังนี้
curl 'https://getconnected.southwestwifi.com/current.json'
  • จากนั้นรันลูปเพื่อดึงข้อมูลทุก 30 วินาทีและสะสมลงไฟล์ log
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

ข้อสงสัยที่ยังเหลือจากฟิลด์ใน response

  • ฟิลด์ส่วนใหญ่เข้าใจได้ค่อนข้างตรงไปตรงมา แต่ยังมีบางค่าที่ความหมายไม่ชัดเจน
    • ความแตกต่างระหว่าง sat_commlink_portal.status กับ satcomm_status.commlink
    • pcent_flt_complete อิงตามระยะทางหรือเวลาที่คาดการณ์
    • altVal, etad, gspdVal แกว่งมากน้อยแค่ไหนระหว่างบิน
    • ac ใน actime24 หมายถึงอะไร
  • actime24 ดูเหมือนไม่ใช่เวลาปัจจุบัน ณ ตำแหน่งของเครื่องบิน แต่เป็นเวลาปัจจุบันของปลายทาง จึงตีความ ac ว่า “aircraft” ได้ยาก

แสดงภาพข้อมูลที่เก็บระหว่างบิน

  • ใช้ข้อมูลที่เก็บได้เพื่อแสดงภาพการเปลี่ยนแปลงของ ความสูง, ETA, และ ความเร็วภาคพื้น

  • การเปลี่ยนแปลงของความสูง

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

  • การเปลี่ยนแปลงของ ETA

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

  • การเปลี่ยนแปลงของความเร็วภาคพื้น

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

สรุป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-29
ความคิดเห็นจาก Hacker News

  • ตอนลูกชายอายุราว 9–10 ขวบ ผมเห็นเขาใช้อินเทอร์เน็ตบนมือถือบนเครื่องบิน ทั้งที่ผมไม่เคยจ่ายค่าอินเทอร์เน็ต เลยถามว่าใช้งานได้อย่างไร
    เขาบอกว่าเพื่อนที่โรงเรียนสอนมา ว่าให้ลองเปลี่ยนตัวเลขของ ที่อยู่ IP ที่ DHCP จัดสรรให้ ในการตั้งค่า Wi‑Fi ไปเรื่อย ๆ ก็ได้ ตอนนั้น American Airlines ดูเหมือนจะอนุญาตเฉพาะ IP ของผู้ใช้ที่จ่ายเงิน ดังนั้นถ้าเดา IP ในช่วง 192.168 ของคนอื่นแล้วปลอมตัวได้ ก็อาจยึดการเชื่อมต่อนั้นมาใช้ได้โดยไม่ต้องยืนยันตัวตนเพิ่มเติม
    ผมบอกเขาว่าอย่าทำ แต่ก็อดภูมิใจกับความกล้าลองของเขาอยู่เล็กน้อยไม่ได้

    • สมัยก่อนผมทำแบบคล้ายกันบ่อยกับฮอตสปอต Wi‑Fi แบบเสียเงิน
      ก่อนอื่นใช้ nmap -sP ทำ ping sweep ทั้งซับเน็ตเพื่อเติมที่อยู่ IP/MAC ที่น่าจะใช้ได้ลงใน ARP cache จากนั้นค่อย ๆ เปลี่ยน ที่อยู่ IP และ MAC ทีละชุด เพื่อหาคู่ที่ผ่านไฟร์วอลล์ได้
      การเคยทำงานเป็นวิศวกร NOC ที่ Wayport (ปัจจุบันคือ AT&T WiFi) ช่วยให้เข้าใจโครงสร้างได้มาก
    • ผมใช้วิธีเดียวกันบนเครื่องบินและในโรงแรม และในโรงแรมสำเร็จบ่อยกว่า
      เพราะโอกาสที่คนอื่นจะใช้งานอยู่ในตอนนั้นต่ำกว่า และโอกาสหลุดก็ต่ำกว่า
      ตอนเด็ก ๆ ผมยังเคยทำแฮ็กเล็ก ๆ อีกอย่างหนึ่งด้วย สมัยที่สายการบินขายหรือให้เช่าหูฟังพิเศษสำหรับดูหนังบนเครื่อง พอร์ตจะเป็นรูสองรูเรียงกัน และปลั๊กเป็นท่อสองท่อ
      ก่อนขึ้นเครื่อง ถ้าแวะร้านฟาสต์ฟู้ดในเทอร์มินัลก็หยิบหลอดมาสักสองสามอัน ถ้าเป็นหลอดงอได้ยิ่งดี แล้วต่อเข้าด้วยกันให้เป็นหลอดยาว เสียบด้านหนึ่งเข้าพอร์ต อีกด้านแนบหู ก็ฟัง เสียงภาพยนตร์ฟรี ได้
    • เมื่อไม่กี่ปีก่อน บนเที่ยวบินของ Southwest ผมลืมปิด OpenVPN แต่กลับเชื่อมต่ออินเทอร์เน็ตผ่านท่อ VPN ได้โดยไม่ต้องจ่ายเงิน
      ตอนนั้นดูเหมือนว่าผู้ใช้ที่ยังไม่ได้จ่ายเงินจะถูกบล็อกเฉพาะพอร์ตที่พบบ่อย (80, 443, 53 เป็นต้น) และหลังจากนั้นช่องโหว่นี้ก็ถูกปิดไปแล้ว
    • เป็นเรื่องเล่าที่น่าทึ่งจริง ๆ
      สภาพของ ความปลอดภัย Wi‑Fi แบบเปิด ในทางปฏิบัตินั้นค่อนข้างน่าเสียดาย และผมก็ไม่แน่ใจว่าสายการบินจะทำให้ดีกว่านี้ได้ง่าย ๆ อย่างไร
      ถ้าอุปกรณ์รองรับ ก็อาจใช้ Opportunistic Wireless Encryption [1] และผูกการยืนยันตัวตนไว้กับ OWE session เฉพาะ แทนที่จะผูกกับ MAC address เฉพาะได้ แต่ผมไม่รู้ว่า OWE session จะเสถียรแค่ไหน
      ถ้าต้องล็อกอินใหม่ทุกครั้งที่เปลี่ยนจุดเชื่อมต่อ ก็คงไม่สะดวกมาก
      น่าเสียดายที่ความปลอดภัยของ Wi‑Fi แบบเสียเงินหรือ Wi‑Fi ฟรียังไม่ใช่ปัญหาที่แก้ได้เรียบร้อย และยังจำเป็นต้องมี วิธีแก้เฉพาะหน้าแบบปรับแต่งเอง อย่าง captive portal ที่เปราะบาง ซึ่งต้องปล่อยทราฟฟิกบางอย่างผ่าน เช่น การชำระเงิน, 3DS, อีเมลรีเซ็ตรหัสผ่าน
      ถ้ามี endpoint และ API มาตรฐานให้ไคลเอนต์รู้ได้ว่าตอนนี้เชื่อมต่อแล้ว, ถูกจำกัด, หรือต้องชำระเงิน/ยืนยันตัวตน ก็คงดี และถ้ารับ authentication token แล้ว reconnect ในเซสชันเดียวกันได้อย่างเป็นธรรมชาติก็คงดีเช่นกัน
      มี Hotspot 2.0 และ WPA‑EAP (WPA Enterprise) อยู่ก็จริง แต่แต่ละอย่างเหมาะกับเครือข่ายฮอตสปอตที่ผู้ให้บริการโทรคมนาคมดำเนินการ และสภาพแวดล้อมองค์กร มากกว่าการใช้งานแบบ “จ่ายเงินผ่านเว็บพอร์ทัล”
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • เมื่อก่อนมีแอปที่สแกน IP และ MAC address ในเครือข่ายที่เชื่อมต่ออินเทอร์เน็ตอยู่แล้วให้
      ถ้าเปลี่ยนการตั้งค่าให้เป็น MAC address หนึ่งในนั้น พอผู้ใช้เดิมเลิกใช้งานแล้ว ก็สามารถใช้การเชื่อมต่อนั้นคนเดียวได้
      ตอนเดินทางไปทำงาน ผมปฏิเสธที่จะจ่ายค่า Wi‑Fi และสมัยที่สนามบินกับร้านกาแฟยังเก็บเงินค่าเชื่อมต่อ วิธีนี้ค่อนข้างมีประโยชน์
      ตอนนี้แทบไม่จำเป็นแล้ว แต่ในที่ที่ยังมีค่าใช้จ่ายในการเชื่อมต่อ ก็อาจยังช่วยได้

  • “จากข้อมูลนี้ ระดับความสูงของเครื่องบินแกว่งแค่ประมาณ 20–30 ฟุตเท่านั้น ถือว่าเสถียรกว่าที่คิด!”
    ระบบขับอัตโนมัติยอดเยี่ยมมาก และควบคุมเซอร์โวโดยอิงจาก ระดับความสูงแบบความกดอากาศ
    ตัวเข้ารหัสระดับความสูงแบบความกดอากาศจำนวนมากในเครื่องบินสมัยใหม่ เช่น อุปกรณ์ที่ขับค่าระดับความสูงซึ่งทรานสปอนเดอร์รายงานผ่านเรดาร์ SSR หรือ ADS-B มีความละเอียดในการเข้ารหัส 25 ฟุต
    สิ่งที่เห็นตรงนี้ก็น่าจะเป็นความละเอียด 25 ฟุตนั้น และถึงจะมีตัวเข้ารหัสความละเอียด 10 ฟุตด้วย แต่ 25 ฟุตพบได้ทั่วไปมาก

    • ไม่รู้ว่า API ที่กล่าวถึงในบทความรับข้อมูลจากเซ็นเซอร์อะไร แต่เครื่องบินโดยสารส่วนใหญ่จะกระจายสัญญาณค่าความแม่นยำของตำแหน่งที่ตรวจจับได้ รวมถึงความแม่นยำของตำแหน่งแนวดิ่ง/ระดับความสูงด้วย
      ถ้าคลิกเครื่องบินบนแผนที่ https://globe.adsbexchange.com/ แล้วเลื่อนแถบด้านซ้ายลงไปจนสุด จะเห็นส่วน “Accuracy”
      ADS-B Exchange ไม่แสดง Rc/v ซึ่งเป็นความแม่นยำของตำแหน่งแนวดิ่ง แต่แสดงค่าอื่น ๆ
      ดูรายละเอียดได้ที่ https://mode-s.org/decode/content/ads-b/7-uncertainty.html
    • ถ้าเป็นเครื่องบินเล็ก ช่วง 20–30 ฟุตก็ไม่ผิดปกติเมื่อบังคับด้วยมืออย่างตั้งใจ
      แน่นอนว่าเครื่องบินโดยสารขณะบิน巡航น่าจะใช้ระบบขับอัตโนมัติ
      ครั้งหนึ่งตอนที่ผมได้รับการติดตามการบินอยู่ พอลดลงไปราว 100 ฟุต เจ้าหน้าที่ควบคุมจราจรทางอากาศก็ถามว่าโอเคไหม ทำให้ผมแปลกใจที่เขาดูละเอียดขนาดนั้น
      ตอนนั้นก่อนถึงช่วงบินเหนือผิวน้ำ ผมลืมใส่เสื้อชูชีพ และระหว่างกำลังใส่ก็ส่งการควบคุมให้ภรรยา ซึ่งตอนนั้นยังไม่เคยเรียนบิน
      ภายหลังภรรยาก็ได้ใบอนุญาตแล้ว และเป็นเรื่องน่าสนใจที่การติดตามของหอบังคับการแม่นยำพอจะเข้ามาแทรกได้
    • ถ้าได้บันทึก GPS track ที่รวมระดับความสูงด้วยโทรศัพท์แล้วเอามาเทียบกันก็น่าจะเจ๋ง
      ความกดอากาศกับ GPS ไม่เหมือนกัน และก็อยากรู้ว่าถ้ารีเซ็ต altimeter แบบความกดอากาศตามค่า AWOS คนละแห่ง ความต่างจะกระโดดให้เห็นชัดหรือไม่
      ไม่รู้ว่าเครื่องบินใหญ่ทำอย่างไร แต่ในเครื่องบินเล็กต้องตั้ง altimeter ให้ตรงกับสภาพอากาศในพื้นที่
      สถานีตรวจอากาศจะวัดความกดอากาศที่ระดับความสูงของตัวเอง แล้วแจ้งค่าที่ “ปรับแก้เป็นระดับน้ำทะเล” ทางวิทยุ จากนั้นใส่ค่านี้ลงใน altimeter เพื่อชดเชยค่าระดับความสูงแบบความกดอากาศตามการเปลี่ยนแปลงของสภาพอากาศท้องถิ่น
      แม้บินไปหนึ่งชั่วโมงแล้วกลับมายังที่เดิม ค่า altimeter setting ก็อาจต่างกันได้ไม่กี่มิลลิบาร์
    • ด้วยการนำ RVSM มาใช้ ก็น่าจะแม่นยำขึ้นมาก
      มาตรฐานการแยกแนวดิ่งระหว่างเครื่องบินเคยเป็น 2000 ฟุต แต่ช่วงต้นทศวรรษ 2000 ลดลงเหลือ 1000 ฟุต
    • เคยอ่านมาว่าในบางสถานการณ์ ความแม่นยำมากเกินไปอาจกลับเป็นอันตรายได้
      เช่น ถ้านักบินไปที่ 3000 ฟุต ก็จะอยู่ที่ 3000 ฟุตพอดี และถ้านักบินอีกคนในเส้นทางชนกันก็ต้องการ 3000 ฟุตเหมือนกัน การชนก็อาจแน่นอน
      ถ้าระดับความสูงแม่นยำน้อยกว่า ก็มีโอกาสมากขึ้นที่จะเป็นแค่เหตุการณ์เฉียดใกล้
      ทางแก้น่าจะเป็นการหลีกเลี่ยงเลขกลม ๆ แล้วใช้เช่น 2950 ฟุต หรือ 3050 ฟุต
      รายละเอียดอาจผิดได้ แต่ค่อนข้างมั่นใจว่าปัญหานี้เคยถูกพิจารณาอย่างจริงจัง

  • เมื่อไม่กี่เดือนก่อนผมเจอแบบเดียวกัน เลยทำ CLI flight tracker ที่ใช้ API นี้ขึ้นมา
    ลองทดสอบกับหลายสายการบินแล้ว และเพราะทุกเจ้าต่างใช้ผู้ให้บริการอินเทอร์เน็ตบนเครื่องบินรายเดียวกัน จึงทำงานได้แทบสมบูรณ์แบบ
    [1]: https://github.com/NalinPlad/OuterFlightTracker

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

  • วิธีดูข้อมูลเดียวกันบนเที่ยวบินของ Delta เป็นแบบนี้

    $ curl https://wifi.delta.com/api/flight-data | jq  

    {  
"timestamp": "2023-07-11T14:54:41Z",  
"eta": "17:48",  
"flightDuration": 278,  
"flightNumber": "DAL786",  
"latitude": 39.723472595214844,  
"longitude": -97.1514205932617,  
"noseId": "3879",  
"paState": false,  
"vehicleId": "N879DN",  
"destination": "KPDX",  
"origin": "KATL",  
"flightId": "N879DN_SF_20230711121358",  
"airspeed": null,  
"airTemperature": 24,  
"altitude": 33922,  
"distanceToGo": 179,  
"doorState": "Closed",  
"groundspeed": 442,  
"heading": -73,  
"timeToGo": 174,  
"wheelWeightState": "Off"  
}

    ยังมีท่อนที่น่าสนใจด้วย

    $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=";, .latitude, ",", .longitude' | tr -d '\n'; echo  
https://maps.google.com/?q=40.5615234375,-101.2824478149414
    • ถ้าใช้ฟีเจอร์ string interpolation ของ jq จะทำให้เรียบง่ายกว่านี้ได้ 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • ตอนนี้ผมลองเข้า URL นี้จากบนเครื่องบินแล้ว มันใช้งานได้จริง
      เป็นข้อมูลที่ดูได้จาก UI ของพอร์ทัล Wi‑Fi อยู่แล้ว แต่พอเห็นเป็น ก้อน JSON ก็ให้ความรู้สึกไปอีกแบบ 
      {"timestamp":"2023-09-28T21:57:39Z","eta":"23:45","flightDuration":164,"flightNumber":"DAL992","latitude":47.4557876586914,"longitude":-111.73490905761719,"noseId":"3883","paState":false,"vehicleId":"N883DN","destination":"KMSP","origin":"KSEA","flightId":"N883DN_SF_20230928195737","airspeed":null,"airTemperature":null,"altitude":35273,"distanceToGo":13,"doorState":"Closed","groundspeed":499,"heading":95,"timeToGo":107,"wheelWeightState":"Off"}
      พิมพ์บนมือถือ เลยขออภัยที่ไม่ได้จัดรูปแบบ JSON
    • ถ้าอยากได้อากาศสดชื่น คงดีถ้าส่ง POST request ไปเปิดประตูได้
    • การเลือกใช้ vehicleId ที่เป็นคำทั่วไปกว่า แทน planeId หรือ tailNumber น่าสนใจ
      สงสัยว่าในอุปกรณ์ปฏิบัติการของ Delta มีประเภทอื่นที่มี API ตรงกับแบบนี้ไหม
      และก็สงสัยว่าคนที่รู้ระบบภายในอื่น ๆ จะอนุมานโครงสร้างระบบจาก flightId ได้มากแค่ไหน
      ดูเผิน ๆ เหมือนเป็นแค่ composite key ที่สร้างจากข้อมูลที่เห็นได้เท่านั้น แต่ก็ยังน่าสนใจอยู่ดี
    • "airspeed": null
      ทำให้เผลอมองออกไปนอกหน้าต่างอย่างกังวล

  • อยากเห็นใครสักคนทำ พร็อกซี ที่ส่งข้อมูลตามใจผ่านการเชื่อมต่อที่อนุญาตให้ใช้ iMessage หรือ WhatsApp ฟรี
    ประมาณว่าตั้ง WhatsApp relay ไว้ที่บ้าน แล้วส่งข้อความไปมาจากบนเครื่องบิน
    แบบพื้นฐานที่สุดน่าจะทำได้โดยส่ง URL ไปยัง WhatsApp ที่บ้าน ให้ฝั่งบ้านโหลดเว็บเพจแล้วส่ง HTML กลับมาเป็นข้อความตอบกลับใน WhatsApp เพื่อเอามา render
    อยากรู้ว่าจะทำให้ใช้งานได้มากแค่ไหน
    เหมือนมีคนทำ TCP relay ผ่าน WhatsApp ไว้แล้วด้วย เจ๋งดี

    • https://github.com/aleixrodriala/wa-tunnel
    • ยังไม่ได้อ่านเงื่อนไขการใช้งาน แต่ก็คิดว่า ทำไมไม่วาง IP router จริง ๆ ไปเลยล่ะ
      จ่ายค่าสมัคร แล้วเปิดเครือข่าย Wi‑Fi ขึ้นมาเองด้วย
      ถ้า SSID บนเครื่องบินชื่อ “Foo” ก็ตั้งชื่อว่า “Foo discounted” แล้วใน captive portal ให้เลือก “ส่วนลด” หลายแบบ เช่น ทหารผ่านศึก ผู้สูงอายุ เด็ก
      ไม่ว่าจะเลือกแบบไหน หน้า payment ก็เก็บ 2 ดอลลาร์
      พอคืนต้นทุนค่าบริการได้แล้ว ก็แสดงให้ผู้เข้าชมหลังจากนั้นเห็นว่า “ส่วนลดทั้งหมดถูกใช้หมดแล้ว โปรดใช้ Foo”
      แบบนี้ผมก็ได้ใช้อินเทอร์เน็ตฟรี ส่วนผู้ใช้เราเตอร์/พอร์ทัลก็ได้ใช้อินเทอร์เน็ต 2 ดอลลาร์
      แบนด์วิดท์อัปโหลดคงแย่มากแน่ ๆ ดังนั้นการ multiplex ข้อมูลทั้งหมดผ่านการเชื่อมต่อเดียวของผมน่าจะทำได้ง่าย
      ใส่ไว้ในอุปกรณ์อย่าง RPi แต่ถ้าจะผ่านจุดตรวจความปลอดภัยได้ มันต้องดูเหมือนผลิตภัณฑ์สำเร็จรูป เช่น เครื่องเล่นเพลง และต้องทำงานต่อได้แม้ตอนต้องเก็บโต๊ะหรือไปห้องน้ำ
      ดูแล้วมีโอกาสน้อยมากที่บนเครื่องบินจะมี WIPS หรือ WIDS คอยตัดการเชื่อมต่อ Wi‑Fi ปลอม
      อีกอย่าง LAN party ก็ไม่ได้ถูกห้ามตั้งแต่แรกไม่ใช่เหรอ
    • เมื่อ 1–2 ปีก่อน หลังเบต้าแรกของ Apple Private Relay ออกมาได้วันสองวัน ผมขึ้นเครื่องบินแล้วใช้ Wi‑Fi ฟรีได้ตลอดเที่ยวบิน
      น่าจะเพราะรายการที่อนุญาตไว้สำหรับ iMessage หรือ push notification ดันครอบคลุมสิ่งนั้นไปด้วย
      ไม่กี่วันต่อมาก่อนเที่ยวบินขากลับ มันก็ถูกบล็อกไปแล้ว
    • สิ่งแรกที่นึกไม่ใช่ “ว้าว เจ๋งจัง” แต่เป็น “การส่งข้อความฟรีเป็นสิทธิประโยชน์ที่ดี แต่ถ้าถูกใช้ผิดวิธี เขาก็คงปิดมัน”
      ดูเหมือนยุคแฮ็กเกอร์ของผมจะผ่านไปแล้ว
    • เคยเห็น Wi‑Fi ของสายการบินไม่บล็อก DNS traffic
      มีโอกาสสูงที่จะทำอะไรคล้าย ๆ กันได้ด้วย DNS tunnel อย่าง Iodine(https://github.com/yarrick/iodine)

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

    • ใช่แล้ว ถูกต้องเลย
      สามารถดูหน้าสถานะเจ๋ง ๆ ที่แสดงภาพข้อมูลนี้ได้ฟรี
      แต่เหตุผลที่ยังดึงข้อมูลออกมาก็มีสองข้อ
      ข้อแรก หน้าสถานะแสดงเฉพาะค่าปัจจุบัน จึงอยากดู ข้อมูลเที่ยวบินทั้งหมด
      ข้อสอง เพราะมันสนุก
    • เที่ยวบินในสหรัฐฯ เมื่อไม่นานมานี้ น่าจะเป็น Alaska Airlines มี กล่อง LAN ภายในเครื่อง ที่ให้ดูภาพยนตร์และรายการทีวีผ่าน Wi-Fi ได้แม้ไม่มีการเชื่อมต่ออินเทอร์เน็ต
    • ไขข้อสงสัยได้แล้วว่า “ทำไมพยายามเปิดหน้า portal แล้วกลับได้ข้อมูลเครื่องบินกลับมาเต็มไปหมด?”

  • ชอบจิตวิญญาณของบทความนี้
    ผู้เขียนน่าจะ Git scrape ข้อมูลนี้ได้ด้วย
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • คิดว่าน่าจะถ่ายรูปนอกหน้าต่าง แล้วเชื่อม พิกัด GPS จากเอาต์พุต JSON นั้นเข้ากับรูปภาพได้
    ดูมีประโยชน์ทีเดียว

    • ถ้าเปิดสิทธิ์ตำแหน่งในแอปกล้องไว้ พิกัดจะถูกใส่ลงในข้อมูล EXIF ของภาพ
      อุปกรณ์ GPS พลเรือนของสหรัฐฯ ถูกห้ามไม่ให้ทำงานที่ความสูงเกิน 60,000 ฟุตเหนือระดับน้ำทะเล และความเร็วเกิน 1,000 นอต เนื่องจากข้อจำกัดการส่งออกยุทโธปกรณ์ของ ITAR

  • ถ้าอยากเปรียบเทียบข้อมูลจากตัวเครื่องกับข้อมูล ADS-B เที่ยวบินนี้น่าจะเป็นเที่ยวบินของผู้เขียนต้นฉบับ
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • มีความเป็นไปได้ว่าแหล่งข้อมูล ADS-B กับแหล่งข้อมูลของ API นี้ อย่างน้อยก็คำนวณมาจากเครื่องมือวัดและระบบการบินชุดเดียวกัน
    • เป็นเที่ยวบินที่ถูกต้อง
      เป็นไอเดียที่ดี น่าเสียดายที่นึกไม่ถึง

  • เป็นเรื่องที่น่าสนุก
    แต่ไม่มีใครติดใจกับ รูปแบบ time นั้นบ้างหรือ
    ดูเป็นตัวเลือกที่แปลก และคาดว่าจะเป็นอะไรที่เป็นมาตรฐานกว่านี้อย่าง ISO 8601 พร้อม timezone offset
    "time": "Sun Sep 24 22:02:19 2023"

    • รู้สึกคล้ายกัน
      ดูเหมือนคนออกแบบระบบนี้จะแปลงเวลาบนเซิร์ฟเวอร์ให้เป็นรูปแบบที่ localize ตามตำแหน่งของเที่ยวบิน แล้วตั้งใจจะใส่ลงในเว็บ UI โดยตรงโดยไม่ต้องมี logic ฝั่งไคลเอนต์
    • ดูเหมือนรูปแบบค่าเริ่มต้นที่ ctime ใช้
      อาจเป็นเบาะแสเกี่ยวกับแบ็กเอนด์ที่อยู่ข้างใต้
      https://cplusplus.com/reference/ctime/ctime/