As discussed in bug 562917 and elsewhere, a captive portal uses exactly the same techniques that a malicious network attacker would use when it attempts to redirect the user to the login/payment page for the captive portal. We don't want to make it easier for a network attacker to trick users, but we *do* want to make it easier for users to log into a "legit" captive portal. In bug 562917, Peter suggested that the UI be something like: > popup a window with differently themed chrome (perhaps > red decoration, or yellow-and-black warning stripes), and > an explanatory title like "this network is currently > interfering with your connections" and continue the > hijack-me.com load in that visible window > > Similarly to bsmith's step 3, the hijack-me.com load will > be hijacked in that window, and the user can click > "I agree", enter their CC details, or whatever the captive > portal demands I agree with Peter that we should have some special indication that, if we navigate automatically to a captive portal login page that we should give the user some warning/indication that we're taking them to a page that they didn't expect to go to. On February 1, I got an email from Larissa "Captive Portal Detection in FF" saying that some Firefox people were looking into captive portal stuff then. I'm not sure what the current state of things is.

By the way, we did do some captive portal detection work for B2G. There was an email thread about it, "Draft of Captive Portal Spec for FFOS," which included this link: http://people.mozilla.com/~lco/Captive_Portal_B2G/. The B2G work was tracked in bug 752982. FWIW, I do not think that (desktop) Firefox should use a popup window for captive portals, because popup windows don't work on phones and tablets, and we have to solve the same problem for those form factors too (perhaps in a different bug).

I'm happy to propose a design for this if we're interested in implementing it and the discussion on bug 562917 has a technical solution that people are happy about. I don't currently know if the UI solution Peter and Brian are proposing is the best one, but I can work with them to figure something out.

I've started my work in the following GitHub repo: https://github.com/vtsatskin/FX-Captive-Portals-Design So far I've outlined the background and user scenarios surrounding the problem. It's a draft document currently, so don't treat it as a final spec whatsoever.

Ioana, can you assign a QA contact? Thanks!

(In reply to Valentin Tsatskin [:vt] from comment #3) > I've started my work in the following GitHub repo: > https://github.com/vtsatskin/FX-Captive-Portals-Design > > So far I've outlined the background and user scenarios surrounding the > problem. It's a draft document currently, so don't treat it as a final spec > whatsoever. Just to follow up, Valentin is taking this bug and I'm going to be on an adviser/mentor role to its completion. You can see Val's work so far in his link https://github.com/vtsatskin/FX-Captive-Portals-Design. We discussed this last week, and are centering around proposing the following: 1. Opening a new tab, rather than a new window, with the captive portal displayed. Not on every page, but just on the active tab. A visual indicator in the URL bar would designate the page as captive. 2. In addition to the captive portal loaded in a new tab, a dropdown-type notification would appear on every page that explains the internet is blocked and would link back to the captive portal. If the user dismisses this notification, it would similarly disappear from every page. 3. If the user opens a new window or a new tab, they'd see the captive portal on that page rather than about:home or about:newtab 4. If the user's completing an automatic session restore, the captive portal would not load in every page, but in only a tab in the top page. Other pages, if they can be loaded via cached data, would load cached in the background. If they cannot be loaded with cached data, they'd be shown in a session-restore "this is embarrassing" screen to the left of the captive portal tab, but with different copy to indicate it's being shown because of a captive portal and not a crash. The best part of the above solution is that it streamlines the most common use cases: 1a. The user wants to log in via the captive portal to get online 2a. The user wants to see the captive portal before deciding whether or not to use it to get online What it doesn't do is place an additional step between the user an online access. It doesn't give a dropdown on a captive portal, for instance, which would present two calls of action to the user: "deal with this Firefox notification" and "log in to Coffee Shop wifi." A visual indication, noted in #1 above, would present simply that the portal is captive... but frankly, the user will likely know that simply by seeing the portal.

q

After review from Boriss and critique from the UX team, I think the spec is complete to move forward with. The spec can be found on this page: https://github.com/vtsatskin/FX-Captive-Portals-Design/blob/master/design/spec.md There is more write up and discussion which can be found from reading the main README and following the appropriate links from here: https://github.com/vtsatskin/FX-Captive-Portals-Design

Marking bug as [qa-] as scope of work only involves the design of the intended behavior and not implementation.

I made this bug block the development follow-ups I found so it's easier to find related bugs from each other.