ข้อเสนอเพื่อจำกัดเว็บไซต์ที่เข้าถึงเครือข่ายภายในของผู้ใช้

• ทีมความปลอดภัยของ Chrome เสนอระบบใหม่ชื่อ "สิทธิ์การเข้าถึงเครือข่ายภายใน" เพื่อแก้ปัญหา เว็บไซต์เข้าถึงเครือข่ายภายใน
• ปัจจุบันเว็บไซต์สาธารณะอาจเข้าถึงหรือโจมตี อุปกรณ์ในเครือข่ายภายในของผู้ใช้ เช่น เครื่องพิมพ์ ได้โดยไม่ได้รับอนุญาต แต่ข้อเสนอนี้มีเป้าหมายเพื่อ บล็อกคำขอไปยังเครือข่ายภายในโดยไม่มีการอนุญาตจากผู้ใช้
• ต่างจาก Private Network Access(PNA) เดิม ข้อเสนอนี้ทำงานบนพื้นฐานของ การยินยอมด้านสิทธิ์จากผู้ใช้แทน preflight ช่วยเสริม อำนาจการควบคุมของผู้ใช้ และรองรับได้ด้วยการอัปเดตเว็บไซต์โดยไม่ต้องเปลี่ยนอุปกรณ์
• โดยเฉพาะเมื่อ เว็บไซต์สาธารณะส่งคำขอ fetch ไปยัง local IP, โดเมน .local เป็นต้น หาก ยังไม่มีสิทธิ์ เบราว์เซอร์จะแสดงคำขอความยินยอมอย่างชัดเจนต่อผู้ใช้
• นโยบายนี้ช่วย เสริมความปลอดภัยและความเป็นส่วนตัว พร้อมทั้งยังรับประกันว่ากรณีใช้งานที่เหมาะสม เช่น การตั้งค่าอุปกรณ์ IoT จะ ทำงานได้ตามปกติเมื่อผู้ใช้อนุญาต

---

ภาพรวมและเป้าหมายของข้อเสนอ

• ทีม Chrome Secure Web and Network เปิดเผยร่างการออกแบบเบื้องต้นของวิธีให้สิทธิ์ 'การเข้าถึงเครือข่ายภายใน' เพื่อแก้ปัญหา เว็บไซต์สาธารณะเข้าถึงเครือข่ายภายในโดยไม่ได้รับอนุญาต
• ที่ผ่านมาเว็บไซต์ที่ผู้ใช้เข้าเยี่ยมชมสามารถพยายามทำ CSRF หรือการโจมตีอื่น ๆ ไปยังอุปกรณ์ในเครือข่ายภายใน เช่น เครื่องพิมพ์หรือเราเตอร์ของผู้ใช้ได้
• ต่อไปนี้มีข้อเสนอให้เบราว์เซอร์บล็อกคำขอที่ข้ามขอบเขตของ address space เช่น public IP → local IP และจะอนุญาตได้ก็ต่อเมื่อได้รับ การยินยอมอย่างชัดเจนจากผู้ใช้ สำหรับแต่ละเว็บไซต์

ที่มาและจุดแตกต่าง

• Private Network Access(PNA) แบบเดิมใช้ preflight (คำขอก่อนหน้า/การตอบกลับล่วงหน้า) เป็นฐาน และต้องให้ฝั่งอุปกรณ์มีการเปลี่ยนแปลงด้วย จึงนำมาใช้งานได้ยาก
• ข้อเสนอนี้สามารถจัดการได้ด้วย การยินยอมด้านสิทธิ์จากผู้ใช้ เพียงอย่างเดียว และต้องแก้ไขแค่ฝั่งเว็บไซต์เล็กน้อย จึงใช้งานจริงและขยายการรองรับได้ง่ายกว่า

เป้าหมายและสิ่งที่ไม่ใช่เป้าหมาย

• เป้าหมาย
  • ป้องกันการโจมตีแบบ drive-by บนเว็บที่ นำอุปกรณ์หรือเซิร์ฟเวอร์ที่มีช่องโหว่มาใช้ประโยชน์
  • อนุญาตให้ เว็บไซต์สาธารณะสื่อสารกับอุปกรณ์ภายใน ได้เฉพาะเมื่อผู้ใช้ต้องการและอนุญาตเท่านั้น
• สิ่งที่ไม่ใช่เป้าหมาย
  • ไม่มุ่งบล็อกกระบวนการใช้งานที่สมเหตุสมผลทั้งหมด เช่น การตั้งค่าหรือควบคุมอุปกรณ์ภายในที่มีอยู่เดิม
  • ปัญหา HTTPS ในเครือข่ายภายใน หรือการออกใบรับรองที่ซับซ้อน ไม่รวมอยู่ในขอบเขตของข้อเสนอนี้

กรณีใช้งาน

• กรณีที่ 1: หากผู้ใช้ทั่วไปไม่ต้องการ เมื่อ example.com ส่งคำขอไปยัง 192.168.0.1 เป็นต้น เบราว์เซอร์จะถามว่าต้องการอนุญาตหรือไม่ และหากปฏิเสธจะบล็อกคำขอ
• กรณีที่ 2: หน้าเว็บตั้งค่าอย่างเป็นทางการของผู้ผลิตอุปกรณ์ เช่น IoT หรือเราเตอร์ จะสามารถสื่อสารได้หลังจากขออนุญาตจากผู้ใช้ในครั้งแรกที่เข้าถึง

การออกแบบโดยละเอียด

• การแยก address space:
  • แบ่ง ชั้นเครือข่าย IP ออกเป็น 3 ระดับคือ loopback (ใช้กับตัวเองเท่านั้น), local (ภายในเครือข่ายภายใน), public (ทุกคนเข้าถึงได้)
  • รวมเกณฑ์ระบุเครือข่ายภายในหลายแบบ เช่น โดเมน .local, private IP ตาม RFC1918/4193, ชื่อ link-local ตาม RFC6762
• คำขอเครือข่ายภายใน: ต้องใช้สิทธิ์เมื่อเข้าถึงจาก public→local, public→loopback, local→loopback เป็นต้น
  • ตั้งแต่คำขอจาก เครือข่ายสาธารณะ ไปยัง เครือข่าย local/loopback ไปจนถึงคำขอจาก local ไปยัง loopback จะถือเป็น คำขอเครือข่ายภายใน
  • ข้อยกเว้น: local→local, loopback→ที่อยู่ใด ๆ เป็นต้น จะไม่อยู่ในขอบเขตการจำกัด
• พรอมป์ต์ขอสิทธิ์:
  • เมื่อเว็บไซต์ส่งคำขอไปยังเครือข่ายภายใน หากยังไม่มีสิทธิ์ เบราว์เซอร์จะแสดงพรอมป์ต์ถามผู้ใช้ว่าจะอนุญาตหรือไม่
  • หากปฏิเสธ คำขอจะถูกบล็อก หากยอมรับ คำขอจะดำเนินต่อไป
• การผนวกรวมกับ fetch API: สามารถระบุ option เช่น targetAddressSpace: "local" ในการเรียก fetch เพื่อแยกเจตนาได้อย่างชัดเจน
  • เนื่องจาก สเปก Fetch นิยามเพียงการเชื่อมต่อ ไม่ได้กำหนดการแก้ DNS จึงใช้การเชื่อมต่อใหม่เป็นจุดตัดสินว่าคำขอนั้นเป็นคำขอเครือข่ายภายในหรือไม่
  • อนุญาตคำขอเครือข่ายภายในได้เฉพาะใน security context เท่านั้น หากยังไม่ได้สิทธิ์จะขึ้นพรอมป์ต์ และหากได้รับสิทธิ์แล้วจึงอนุญาตคำขอ
  • เพิ่มพารามิเตอร์ targetAddressSpace ใน options ของ fetch() เพื่อให้นักพัฒนาระบุ address space ปลายทางได้อย่างชัดเจน
    • เช่น fetch("http://router.com/ping";, { targetAddressSpace: "local" })
  • หากที่อยู่จริงที่เชื่อมต่อไม่ตรงกับ space ที่ระบุใน option จะถือว่าคำขอล้มเหลว เพื่อป้องกัน การเลี่ยง mixed content
• HTML, WebRTC, ServiceWorker ฯลฯ ใช้นโยบายเดียวกัน
  • เพิ่มค่า address space ให้กับ เอกสาร HTML/worker เพื่อติดตาม space ตามต้นทาง
  • เมื่อเพิ่ม candidate ให้ ICE Agent ใน WebRTC หากเป็นที่อยู่ local/loopback จะใช้พรอมป์ต์ขอสิทธิ์
  • สิทธิ์จะเชื่อมโยงกับ Permissions API เพื่อให้เว็บไซต์สามารถตรวจสอบสถานะสิทธิ์ปัจจุบันได้
  • โดยปกติจะอนุญาตการเข้าถึงเครือข่ายภายในจากเอกสารระดับบนสุดเท่านั้น และหากจำเป็นสามารถมอบสิทธิ์ให้เฟรมย่อยผ่านนโยบายมอบหมายของ Permissions Policy ได้
• ปัญหา mixed content (HTTP/HTTPS):
  • ครอบคลุมกรณีเช่น การพยายามเข้าถึงเครือข่ายภายในจาก non-secure context, การโหลด subresource แบบ HTTP, และการใช้การบล็อก mixed content
  • สำหรับ private IP literal, โดเมน .local, หรือคำขอที่ระบุ targetAddressSpace จะข้ามขั้นตอน upgrade และ block ของ mixed content และหากต้นทางยังไม่มีสิทธิ์ในขั้นเชื่อมต่อถัดไปก็จะถูกบล็อก
• ตัวอย่างการทำงาน
  • หากมีความพยายามเข้าถึงเครือข่ายภายในที่ผู้ใช้ไม่คาดคิด ผู้ใช้สามารถ ปฏิเสธสิทธิ์ เพื่อบล็อกคำขอที่ไม่ได้รับอนุญาตได้
  • สำหรับหน้าเว็บควบคุมอุปกรณ์ที่ผู้ผลิตดูแล หากเรียกใช้งานด้วยพร็อพเพอร์ตีที่เหมาะสม (เช่น targetAddressSpace="local") ก็จะยังทำงานแบบเดิมได้เมื่อผู้ใช้ยินยอม

ทางเลือกและประเด็นอภิปราย

• แนวทาง PNA:
  • PNA เดิมกำหนดให้ต้องมี CORS preflight แต่ในทางปฏิบัตินำมาใช้และกระจายใช้งานได้ยากมาก
  • ในบางช่วงมีข้อเสนอให้ใช้ พรอมป์ต์ขอสิทธิ์ และอนุญาตข้อยกเว้น mixed content
  • อย่างไรก็ตามยังมีข้อจำกัดในโลกจริงจากปัญหา DNS และการที่อุปกรณ์แต่ละชนิดไม่รองรับสเปก
• บล็อกคำขอเครือข่ายภายในทั้งหมด: แม้จะเรียบง่าย แต่ไม่เหมาะกับการใช้งานจริงเพราะเสี่ยงทำลาย use case และเพิ่มต้นทุนในการหลบเลี่ยง
• คงสภาพปัจจุบันไว้: เมื่อระบบปฏิบัติการเริ่มจัดการสิทธิ์เครือข่ายภายในแบบรายแอปมากขึ้น จึงยิ่งตอกย้ำความจำเป็นของการจัดการในระดับเบราว์เซอร์
• ทางเลือกด้าน mixed content:
  • มีการอภิปรายทั้งเรื่องการประเมินความปลอดภัยของวิธีเชื่อมต่อ เช่น "อนุญาตเฉพาะ subresource ของเครือข่ายภายในที่ปลอดภัย" และภาระในการนำไปใช้
  • ยังมีการหารือทางเลือกอื่น เช่น การประกาศ address space ผ่าน response header/เมตาแท็ก หรือการเพิ่มแอตทริบิวต์ให้กับองค์ประกอบ HTML

ประเด็นเพิ่มเติม

• มีการหารือความเป็นไปได้ในการเพิ่มคุณสมบัติ address space ให้กับ HTML subresource (เช่น iframe, img) ด้วย
• มีการสะท้อนผลการวิจัยเกี่ยวกับประเด็นสิทธิ์ส่งต่อเกินจำเป็น (transitivity) เมื่อมีการให้สิทธิ์
• เมื่อมีการนำทาง main frame อาจจำกัดการเข้าถึงเครือข่ายภายในหรือแสดง interstitial เตือน
• ยังพิจารณาแนวทางที่ตีความคำขอข้ามต้นทางทั้งหมดไปยังที่อยู่ local/loopback ว่าเป็นคำขอเครือข่ายภายในอย่างกว้างขวาง
• มีการศึกษาวิธี ให้สิทธิ์แบบละเอียดตามแต่ละเครือข่าย รวมถึงความจำเป็นที่จะต้องขอความยินยอมใหม่เมื่อย้ายไปยังเครือข่ายอื่น (เช่น เปลี่ยนสถานที่เชื่อมต่อ)

ข้อพิจารณาด้านความปลอดภัยและความเป็นส่วนตัว

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

[GN⁺]

ความเห็นจาก Hacker News

• ตอนที่เห็นครั้งแรก ฉันชอบฟีเจอร์นี้มาก เพราะแนวคิดที่ว่าเว็บไซต์จะสามารถยิงคำขอ HTTP ไปยัง local IP ได้ตามอำเภอใจ (หรือจริง ๆ จะเป็น IP ไหนก็ตาม) เป็นความเสี่ยงที่อันตรายจนน่าเหลือเชื่อ ต่อให้มันทำให้แอปองค์กรบางตัวหรือความสามารถด้านการเชื่อมต่อบางอย่างพังก็ไม่ได้ใส่ใจ องค์กรสามารถเปิดฟีเจอร์นี้กลับผ่านเครื่องมือจัดการได้ และผู้ใช้ทั่วไปก็ตั้งค่าเองได้เช่นกัน แค่มีป๊อปอัปว่า "เว็บไซต์นี้กำลังพยายามควบคุมอุปกรณ์ในเครื่องข่ายท้องถิ่นของคุณ - อนุญาต/ปฏิเสธ" ก็น่าจะเพียงพอแล้ว

  • มีการชี้ให้เห็นว่ามุมมองนี้คลาดเคลื่อนอยู่บ้าง โดยอธิบายว่าอุปกรณ์บนเครือข่ายท้องถิ่นได้รับการป้องกันจากเว็บไซต์ทั่วไปอยู่แล้วด้วย CORS แม้จะไม่สมบูรณ์แบบแต่ก็ถือว่ามีประสิทธิภาพพอสมควร ประเด็นคือ CORS อาศัยเพียงความยินยอมจากเซิร์ฟเวอร์ปลายทางเท่านั้น เพราะเซิร์ฟเวอร์ต้องอนุญาตให้เว็บไซต์นั้นเข้าถึงได้ผ่านเฮดเดอร์บางตัว ข้อเสนอนี้จึงเป็นการทำให้เข้มงวดยิ่งขึ้น โดยแม้เซิร์ฟเวอร์และเว็บไซต์จะต้องการสื่อสารกันทั้งคู่ ก็ยังต้องได้รับการอนุมัติจากผู้ใช้อย่างชัดเจน เดิมทีเคยมองว่าการตกลงกันระหว่างเซิร์ฟเวอร์กับเว็บไซต์ก็เพียงพอแล้ว แต่กรณีล่าสุดอย่าง Facebook ที่เว็บไซต์แอบเข้าถึงแอปในโทรศัพท์ของผู้ใช้ ทำให้หลักการนี้พังลง กล่าวคือ ตอนนี้เว็บไซต์และเซิร์ฟเวอร์ในเครือข่ายท้องถิ่นสามารถทำงานสวนทางกับผลประโยชน์ของผู้ใช้ได้แล้ว

  • สำหรับความเห็นที่ว่า "ผู้ใช้ทั่วไปก็แค่กดอนุญาต/ปฏิเสธจากป๊อปอัปเองได้" มีการยกตัวอย่างว่า MacOS ปัจจุบันก็ขอสิทธิ์ลักษณะนี้แยกตามแอปอยู่แล้ว แต่ผู้ใช้ส่วนใหญ่ก็กด 'อนุญาต' ไปโดยแทบไม่คิดอะไร จึงคาดว่าแม้เปลี่ยนมาเป็นแยกตามเว็บไซต์ก็อาจไม่ได้เพิ่มความระมัดระวังมากนัก

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

• อยากให้ Apple, Microsoft, Google และเจ้าอื่น ๆ ใช้แนวทางคล้ายกันกับ USB และ Bluetooth ด้วย ทุกวันนี้แอปแทบทุกตัวที่ติดตั้งมักขอสิทธิ์เข้าถึง Bluetooth ซึ่งน่ารำคาญมาก จึงอยากให้แอประบุ ID ของอุปกรณ์บลูทูธที่เข้าถึงได้ไว้ใน manifest และให้ระบบปฏิบัติการจำกัดการเข้าถึงไว้เฉพาะอุปกรณ์นั้น เช่น แอป Bose ก็ควรมองเห็นได้เฉพาะอุปกรณ์ของ Bose เท่านั้น มีคนเล่าว่าเคยเจอแอปขอสิทธิ์อะไรบางอย่างจนต้องกดปฏิเสธ และคิดว่าน่าจะมีทั้งการลงทะเบียน device ID และพรอมป์ตผู้ใช้คล้ายกับสิทธิ์กล้องหรือ GPS ในกรณี Bose ก็อาจลงทะเบียน prefix เป็น bose.xxx แล้วขอสิทธิ์แค่ "bose.*" ใน manifest จากนั้นให้ OS อนุญาตตามกฎนั้นเท่านั้น และเสนอว่าน่าจะมีระบบ ID คล้ายกันสำหรับ USB กับอุปกรณ์บนเครือข่ายท้องถิ่นด้วย โดยอยากให้ OS ขยับไปในทางที่แอปไม่สามารถสแกนเครือข่าย, USB หรือ Bluetooth ได้ตามอำเภอใจ

  • มีความหวังว่าสักวัน Apple อย่างน้อยก็น่าจะเพิ่มตัวเลือกแบบ 'อนุญาตสิทธิ์ปลอม' ให้แอปได้ เช่น ถ้าแอปบอกว่าจำเป็นต้องใช้รายชื่อผู้ติดต่อ ก็อาจแสดงรายชื่อสุ่มที่แยกไม่ออกจากของจริงให้แทน และอยากให้ใช้แนวคิดคล้ายกันกับ GPS ด้วย มีคนเล่าว่าเคยได้ยินมาด้วยว่า WhatsApp ถ้าไม่แชร์รายชื่อผู้ติดต่อ ก็จะตั้งชื่อให้รายชื่อเหล่านั้นไม่ได้

  • ชอบโมเดลสิทธิ์แบบละเอียดคล้ายการเชื่อมต่อแอปภายนอกของ Github ที่ขึ้นว่า "ABC ต้องการดู repo ของคุณ ต้องการแชร์ repo ไหนบ้าง?"

• มีความเห็นว่า Internet Explorer เคยแก้ปัญหาแนวนี้ด้วยระบบโซน (zoning) มาก่อนแล้ว รายละเอียดดูได้จากเอกสารของ MS

  • น่าเหน็บแนมที่ Chrome บน Windows เองก็เคยใช้ระบบความปลอดภัยแบบโซนของ IE บางส่วนเหมือนกัน แต่แทบไม่มีเอกสารทางการเกี่ยวกับเรื่องนี้เลย

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

• รู้สึกเหลือเชื่อที่เว็บเบราว์เซอร์เปิดให้ทำสิ่งนี้ได้เป็นค่าเริ่มต้น ถ้าคิดว่ามีเว็บไซต์สาธารณะเข้าถึงทั้งระบบไฟล์ของเราแบบเงียบ ๆ ได้ก็คงถือเป็นช่องโหว่ความปลอดภัยที่ร้ายแรงมาก แต่พอเป็นบริการบนเครือข่ายท้องถิ่นกลับใช้ XHR ได้ตามปกติและโยนภาระความปลอดภัยไปให้การตั้งค่าเซิร์ฟเวอร์เพียงอย่างเดียว ถ้าเป็นนักพัฒนา เวลารันเว็บแอปภายในบริษัทเพื่อทดสอบบนเครื่องพัฒนาเอง (ที่ตั้งค่าความปลอดภัยหละหลวมหรือไม่มีเลย) มันก็อาจถูกเข้าถึงได้จาก facebook.com, google.com และเว็บอื่น ๆ ทันที ที่บ้านเองก็มีคนจำนวนมากรันบริการแบบไม่ต้องยืนยันตัวตนโดยเชื่อในไฟร์วอลล์ของเราเตอร์ จึงไม่มั่นใจจริง ๆ ว่าทุกคนตั้งค่า CORS ไว้ถูกต้องหรือไม่

  • มีความสงสัยอย่างมากว่าทุกคนจะตั้งค่า CORS ได้ถูกต้องจริงหรือ และมองว่าความเป็นจริงน่าจะใกล้ 0% มากกว่าที่จะมีการตั้งค่าอย่างเหมาะสม

• คาดหวังว่าข้อเสนอนี้จะช่วยหยุดวิธีการของ Meta ที่ใช้ SDK ของตัวเองแชร์โค้ดระบุตัวตนระหว่างแอปเนทีฟกับเว็บไซต์ผ่านลูกเล่นบน localhost ได้ โดยเฉพาะบน Android ดูตัวอย่างกรณีนี้ได้ที่นี่

• มีการชี้ว่าการให้เว็บไซต์มีสิทธิ์เข้าถึงเครือข่ายท้องถิ่นนั้นเป็นการอนุญาตที่หยาบเกินไปและกว้างเกินความจำเป็น เพราะเว็บไซต์ส่วนใหญ่ที่ต้องใช้สิทธิ์นี้จริง ๆ มักจำเป็นต้องเข้าถึงเพียงเซิร์ฟเวอร์ท้องถิ่นตัวเดียว การอนุญาตทุกอย่างใน local ขัดกับหลัก least privilege และผู้ใช้ส่วนใหญ่ก็ไม่รู้ด้วยซ้ำว่ามีอะไรทำงานอยู่บน localhost หรือในเครือข่ายของตน จึงแทบไม่รับรู้ความเสี่ยงอย่างถูกต้อง

  • คนส่วนใหญ่ไม่รู้ว่ามีอะไรทำงานอยู่บน localhost หรือบนเครือข่าย ดังนั้นต่อให้เบราว์เซอร์ขึ้นข้อความขออนุญาตเข้าถึงอย่าง http://localhost:3146 หรือ http://localhost:8089 ก็คงเดาไม่ออกว่ามันหมายถึงอะไร จึงมีความเห็นว่าแทนที่จะใช้ศัพท์เทคนิค ควรใช้ข้อความที่เข้าใจง่ายกว่าอย่าง "เว็บไซต์นี้กำลังพยายามเข้าถึงทรัพยากรบนเครือข่ายท้องถิ่น" จะดีกว่าสำหรับผู้ใช้

  • ถ้าจะทำให้ดีจริง ๆ ก็น่าจะต้องมีการควบคุมระดับใกล้เคียงไฟร์วอลล์ภายในเบราว์เซอร์ โดยมี API ที่กำหนดได้ละเอียดว่าอนุญาต CIDR ไหน พอร์ตไหน ฯลฯ และอยากให้ส่วนขยายเบราว์เซอร์ใช้ firewall API แบบนี้ได้ด้วย หรือไม่ก็มี UI พื้นฐานที่แยกขอบเขตอย่างชัดเจน เช่น เครื่องเฉพาะ (อย่างเราเตอร์), LAN, VPN, private network บน Windows เพื่อให้ขอสิทธิ์เข้าถึงแยกกันเป็นส่วน ๆ ได้

• มีข้อสังเกตว่าตั้งแต่ NPAPI plugin หายไป เว็บไซต์สาธารณะจำนวนมากที่ต้องเชื่อมต่อกับซอฟต์แวร์ในเครื่องก็แทบไม่มีทางเลือกนอกจากเปิด HTTP server บน localhost และถ้าทำให้การใช้งานลักษณะนี้ยุ่งยากขึ้นอีกก็จะไม่สะดวกอย่างมาก มีความเห็นว่านักพัฒนาเบราว์เซอร์ควรเตรียมเทคโนโลยีทดแทนมาตั้งแต่หลังยุค NPAPI แต่ตอนนี้สายไปแล้ว

  • ซอฟต์แวร์ส่วนใหญ่ชอบลงทะเบียน protocol handler กับ OS มากกว่า เช่น ให้เว็บไซต์ส่งลิงก์อย่าง zoommtg:// แล้วเบราว์เซอร์ก็เชื่อมต่อไปที่ Zoom เป็นต้น ส่วนกรณีอย่าง Jupyter Notebook ที่ใช้งานในเครื่องโดยไม่มี cross-origin request ก็ไม่ได้รับผลกระทบ และการล็อกอิน OAuth2 ที่ส่งกลับมาที่ URL บน localhost ก็น่าจะไม่มีปัญหาเพราะเป็นเพียงการ redirect ธรรมดา

  • มีคนมองว่าถ้าวิธีแบบนี้ (สื่อสารกับแอปในเครื่องผ่าน HTTP server) หายไปให้หมดได้ก็น่าจะยิ่งดี เพราะมันเป็นต้นตอของช่องโหว่ความปลอดภัยมาโดยตลอด

  • มีเทคโนโลยีอย่าง Mozilla Native messaging อยู่แล้ว ซึ่งแม้จะต้องติดตั้งส่วนขยายเพิ่ม แต่ก็ถือว่าเป็นวิธีที่ยุติธรรมเมื่อเทียบกับ NPAPI

  • ถ้าซอฟต์แวร์ในเครื่องเปลี่ยนเป็นใช้วิธี 'pull' (แอปคอยร้องขอออกไปภายนอกเป็นระยะ) ก็ไม่จำเป็นต้องเปิดเซิร์ฟเวอร์ขึ้นมา และยังช่วยลดปัญหาที่เว็บไซต์ไปสแกนเครือข่ายท้องถิ่นของผู้อื่นมั่ว ๆ ได้อีกด้วย

• ใน JavaScript ถ้าส่งคำขอ fetch หรือ POST โดยไม่มีตัวเลือก cors, CORS จะเพียงแค่ทำให้อ่าน response ไม่ได้ แต่ตัวคำขอจริงเบราว์เซอร์ก็ยังส่งออกไปอยู่ดี ถ้าแอปในเครื่องทำให้เซิร์ฟเวอร์เพิ่ม CORS header ผ่าน proxy ได้ เว็บไซต์ไหนก็เข้าถึงได้ผ่าน JS fetch/XMLHttpRequest และส่วนขยายเบราว์เซอร์ก็สามารถแก้ header เพื่อ bypass CORS ได้เช่นกัน การอาศัยการแก้ header เพื่อเลี่ยงข้อจำกัดทำได้ง่ายเกินไป ขณะที่ CSP (Content Security Policy) กลับถูกเลี่ยงได้ยากมากหรือแทบเป็นไปไม่ได้ แอปของ Facebook เองก็ยังรัน cors proxy server ของตัวเองเพื่อใช้โครงสร้างแบบนี้อยู่ และยังมี WebSocket อีก ดังนั้นถึง Chrome จะมี flag สำหรับบล็อก localhost ก็แทบไร้ผล การบล็อก localhost แบบสมบูรณ์กลับจะสร้างผลเสียมากกว่า เพราะผู้ใช้จำนวนมากใช้งาน self-hosted bookmark, notes, password manager และแอปอื่น ๆ ที่พึ่งพา local server จึงมองว่าการปิดกั้นกรณีเหล่านี้ไม่สมเหตุสมผล

• มีความกังวลว่าจะเกิดปัญหาในสภาพแวดล้อม IPv6 และตั้งคำถามว่าจริง ๆ แล้วมีวิธีแยกหรือไม่ว่า IPv6 address ไหนถือว่าเป็น local ถ้าไม่มี บนเครือข่าย IPv6 only ข้อเสนอนี้ก็น่าจะมีปัญหา มีคนเล่าว่าเคยเจอประเด็นนี้ในแอป IoT เพราะยากที่จะระบุว่า IPv6 address เป็น local หรือไม่ จึงเลือกวิธี redirect IPv6 ทั้งหมดไปยัง local ของ IPv4 แทน ส่วน IPv6 link local เองก็แทบไม่มีประโยชน์กับแอปทั่วไปอยู่แล้ว การถือว่าโดเมน .local เป็น local server ก็จัดการได้ยาก เพราะแต่ละ OS ตีความไม่เหมือนกัน เช่น บน Raspberry Pi OS "some_address" resolve ผ่าน mDNS ได้ แต่ "someaddress.local" ไม่ได้ ขณะที่ Ubuntu 24.04 ใช้ได้เฉพาะ "someaddress.local" แต่ "someaddress" ใช้ไม่ได้ และ "someaddress.local." ก็ใช้ไม่ได้เหมือนกัน สุดท้ายยังมีปัญหาว่าไม่สามารถใช้ private certificate กับ local network address ได้ด้วย จึงย้ำว่าปัญหาเรื่อง "บังคับ https กับ local address" ก็ต้องแก้เช่นกัน

  • มีคนอธิบายว่า IPv6 ก็ยังมีแนวคิดเรื่อง 'routable' อยู่ ดังนั้นในทางตรรกะอาจนิยามความเป็น site-local ได้ในระดับ routing table สมัย IPv4 เก่า ๆ มักใช้อ็อกเต็ตที่ 2 เป็น site และอ็อกเต็ตที่ 3 เป็น VLAN ส่วน IPv6 มีตัวเลือกมากกว่า ทุกอุปกรณ์ IPv6 จะมี link local address อยู่แล้ว (ภายใน VLAN เดียวกัน) และ .local เป็นคำที่เกี่ยวกับการแมปชื่อกับที่อยู่ใน Apple, DNS ฯลฯ ไม่ได้เกี่ยวกับ IP address โดยตรง สำหรับ https บนเครือข่ายท้องถิ่นก็สามารถทำ certificate ได้ผ่าน DNS-01 ของ Lets Encrypt, CNAME และวิธีอื่น ๆ แม้จะค่อนข้างยุ่งแต่ก็มีวิธีฟรีอยู่ และยังแนะนำเครื่องมืออย่าง acme.sh ด้วย พร้อมชี้ว่าควรแยกแนวคิดของ IPv4, IPv6, DNS, mDNS, Bonjour ฯลฯ ให้ชัดเจนกว่านี้ ก่อนจะรำลึกว่าครั้งหนึ่งแค่ packet capture ยังต้องใช้ของเสียเงิน แต่ตอนนี้อะไร ๆ ก็ดีขึ้นมากแล้ว

  • อีกความเห็นหนึ่งย้ำชัดว่าที่ปลายทางไม่มีวิธีบอกได้ว่า IPv6 address ใดเป็น "local" เพราะหลักการของ IPv6 คือการ global routing Google เองในบทความก็เหมือนจะสับสน โดยเริ่มจากการพูดถึงความหมายของ "local" แล้วกลางทางเปลี่ยนไปนิยามคำว่า 'private' แทน การสร้างขอบเขตความปลอดภัยแบบ CIDR ที่ไม่มาตรฐานผ่านส่วนขยายของ HTTP จึงดูเป็นแนวทางที่แปลกมาก และมองว่าแอปควรถูกออกแบบโมเดลความปลอดภัยโดยสมมติว่าเป็นบริการสาธารณะ ส่วน .local แม้อยู่ในข้อกำหนดของ mDNS แต่ในทางปฏิบัติก็มักถูกมองข้าม

• มีคนบอกว่าอยากให้วิธีนี้เกิดขึ้นจริงเร็ว ๆ โดยเฉพาะถ้าช่วยให้โดเมน HTTPS เข้าถึงเว็บไซต์ local ที่เป็น HTTP ได้ด้วย เพราะมีกรณีใช้งานที่น่าสนใจมากมาย เช่น smart home, media/entertainment และอื่น ๆ