1341460 - Consider support for detecting captive portals in web extensions

Status: RESOLVED DUPLICATE of bug 1545159

(WebExtensions :: General, enhancement, P5)

Description

[Jonathan Kingston [:jkt] he/him]

Currently in a web extension a developer could reimplement their own detection however providing an API would simplify this process.

browser.captivePortal.onStatusChange((e) => {
  // Do something here
});

My personal use-case is to detect when a captive portal has been resolved and start blocking all HTTP traffic but allow when the user has a captive portal and allow HTTP traffic but make it clear to the user they might be monitored.

So I would like to know the following:
- When the user has a captive portal
- When the captive portal is shown / when the user has full internet access again
- When the browser is about to check for a portal (so I can allow HTTP again)

Comment 1

[Kris Maglione [:kmag]]

I know that Osmose was working on something like this recently.

Comment 2

[Osmose [:osmose, :mkelly]]

There's an experiment in development looking at activating a VPN when the user is on public wifi, and captive portal detection is one method for this. We decided to not implement that for the first run of the experiment, but having that API available would be very helpful. in the future.

Here's some potentially useful code, including some events that would help implementing this API for web extensions: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser-captivePortal.js

That's about all the productive info I have.

Comment 3

[Jonathan Kingston [:jkt] he/him]

Also worth noting Chrome OS addons can access a similar API for doing this:
https://developer.chrome.com/extensions/networking_config#event-onCaptivePortalDetected

The event fires when the network matches a filter which I don't think we have any code that caters for wifi SSID's.

However if we did support this we might gain some support for automatically logging people into public wifi etc.

Comment 4

[Shane Caraveo (:mixedpuppy)]

How'd that experiment go?  Is this something we should still consider?

Comment 5

[Osmose [:osmose, :mkelly]]

The iteration of the experiment I was helping out with wasn't finished before our intern left. I dunno if we ever followed up (I switched teams), but gregglind might.

Comment 6

[Jonathan Kingston [:jkt] he/him]

I didn't experiment with this however Nihanth worked on the portal code so might know how possible this is.

Chrome OS allows configuring these portals and detecting their state: https://developer.chrome.com/extensions/networking_config
I'm not sure this needs the parity-chrome keyword.

Comment 7

[Kris Maglione [:kmag]]

(In reply to Jonathan Kingston [:jkt] from comment #6)
> I'm not sure this needs the parity-chrome keyword.

It doesn't. Parity with Chrome OS and Chrome app APIs is explicitly a non-goal.