Closed
Bug 1341460
Opened 7 years ago
Closed 5 years ago
Consider support for detecting captive portals in web extensions
Categories
(WebExtensions :: General, enhancement, P5)
WebExtensions
General
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1545159
People
(Reporter: jkt, Unassigned, NeedInfo)
Details
(Whiteboard: [design-decision-needed][privacy])
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•7 years ago
|
||
I know that Osmose was working on something like this recently.
Comment 2•7 years ago
|
||
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.
Updated•7 years ago
|
Priority: -- → P3
Whiteboard: [triaged]
Reporter | ||
Comment 3•7 years ago
|
||
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•6 years ago
|
||
How'd that experiment go? Is this something we should still consider?
Blocks: webextensions-chrome-gaps
Severity: normal → enhancement
Flags: needinfo?(mkelly)
Flags: needinfo?(jkt)
Keywords: parity-chrome
Priority: P3 → P5
Whiteboard: [triaged] → [design-decision-needed]
Comment 5•6 years ago
|
||
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.
Flags: needinfo?(mkelly) → needinfo?(glind)
Reporter | ||
Comment 6•6 years ago
|
||
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.
Flags: needinfo?(jkt) → needinfo?(nhnt11)
Comment 7•6 years ago
|
||
(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.
Keywords: parity-chrome
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Updated•6 years ago
|
No longer blocks: webextensions-chrome-gaps
Whiteboard: [design-decision-needed] → [design-decision-needed][privacy]
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Updated•4 years ago
|
Flags: needinfo?(nhnt11)
You need to log in
before you can comment on or make changes to this bug.
Description
•