Closed Bug 1323514 Opened 7 years ago Closed 7 years ago

[Captive portal] Banner shown on tabs when visiting local network sites

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: rillian, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxprivacy])

Thanks for adding captive portal detection. It's much nicer than the security warnings I sometimes get when joining such a network.

I noticed last week with the WestJet in-plane wifi service that we show the notification bar on all tabs (bug 989194?) even those which the portal allows access to. For example, in the plane www.westjet.com worked as a service directory, and there was a sign-up domain (with an apparently valid tls cert!) for general internet access.

I found this confusing UX. On the one hand it's good to know general internet access isn't available. On the other, the provider's walled garden was working just fine. In this case local services included movies and games intended as in-flight entertainment, so one can easily spend hours on the available sites without clearing the block to the pubic internet.
For this to work, there has to be a way for us to reliably detect these “walled gardens”. The question is how.

Normally, all walled gardens have some sort of an authentication step, and I wonder if there’s a way for us to reliably detect whether you’ve passed this step (even if you’re not connected to the Internet at large)?

* Can we detect a certain user behaviour? Maybe clicking a certain button to authenticate.
* Can we detect whether the connection has been mediated by a certain domain that gives a TLS cert different from a public internet? 
* Can we detect the moment when the management server requests your MAC address to be added to its list of allowed clients?
Flags: needinfo?(nhnt11)
(In reply to Ralph Giles (:rillian) needinfo me from comment #0)
> Thanks for adding captive portal detection. It's much nicer than the
> security warnings I sometimes get when joining such a network.

:)

> I noticed last week with the WestJet in-plane wifi service that we show the
> notification bar on all tabs (bug 989194?) even those which the portal
> allows access to. For example, in the plane www.westjet.com worked as a
> service directory, and there was a sign-up domain (with an apparently valid
> tls cert!) for general internet access.

The notification bar has nothing to do with individual tabs. It's intended as a kind of general message to the user that the internet is not accessible and they may need to log in.

> I found this confusing UX. On the one hand it's good to know general
> internet access isn't available. On the other, the provider's walled garden
> was working just fine. In this case local services included movies and games
> intended as in-flight entertainment, so one can easily spend hours on the
> available sites without clearing the block to the pubic internet.

What do you think is a better UX? We specifically say in the notification that *internet access* isn't available. We never say anything about the walled garden. Do you think we should? i.e., do you think it would benefit to mention that some URLs might be accessible? This is not very actionable, because there's no real way for us to possibly know what URLs the portal allows, or to cover all the walled gardens out there in the wild.

The one thing I can think of is to specifically detect popular in-flight portals (using a pre-composed list of some sort). In-flight walled gardens seem to maybe be a common enough case to be worth actioning.

(In reply to Bram Pitoyo [:bram] from comment #1)
> For this to work, there has to be a way for us to reliably detect these
> “walled gardens”. The question is how.

I think we should take a step back and define what "this" is, and when it "works".

> Normally, all walled gardens have some sort of an authentication step, and I
> wonder if there’s a way for us to reliably detect whether you’ve passed this
> step (even if you’re not connected to the Internet at large)?

I don't think so. For example, in airplanes where the walled garden gives you access to entertainment content, you don't usually have to log in or anything - your device just acts as a client and lets the airline avoid installing screens on every seat.

> * Can we detect a certain user behaviour? Maybe clicking a certain button to
> authenticate.

I don't see how this is possible, nor how one would define "authenticate". The current implementation distinguishes between two states: the internet is accessible, or it's not. Anything in between seems to me like trying to count every real number between two integers - it's impossible because there are infinitely many of them.

> * Can we detect whether the connection has been mediated by a certain domain
> that gives a TLS cert different from a public internet?

I don't understand this, can you rephrase and/or be more explicit?

> * Can we detect the moment when the management server requests your MAC
> address to be added to its list of allowed clients?

The MAC address is not "requested", it is broadcasted by the client's network interface at a low level.
Flags: needinfo?(nhnt11)
I think this is somewhat of an edge case, where a captive portal limits internet access, but you may be happily using the browser while confined in it. Since the notification bar can be easily dismissed, I assume that the "notification fatigue" you seem to have suffered from must be because you had multiple tabs with it that were working fine? Can you describe a bit the behavior of that captive portal that allowed you to open multiple tabs? What were the tasks you could perform and how common you think it will be for people to open multiple tabs?

If we determine that this is indeed a likely scenario for many people, perhaps we could limit the number of times (maybe 3?) we open the notification bar in a new tab if (and only if) it has been dismissed in another tab _and_ there has been no change in the captive portal detection in the meantime. Or some other similar heuristic.
(In reply to Panos Astithas [:past] from comment #3)
> I think this is somewhat of an edge case, where a captive portal limits
> internet access, but you may be happily using the browser while confined in
> it. Since the notification bar can be easily dismissed, I assume that the
> "notification fatigue" you seem to have suffered from must be because you
> had multiple tabs with it that were working fine? Can you describe a bit the
> behavior of that captive portal that allowed you to open multiple tabs? What
> were the tasks you could perform and how common you think it will be for
> people to open multiple tabs?
> 
> If we determine that this is indeed a likely scenario for many people,
> perhaps we could limit the number of times (maybe 3?) we open the
> notification bar in a new tab if (and only if) it has been dismissed in
> another tab _and_ there has been no change in the captive portal detection
> in the meantime. Or some other similar heuristic.

I just want to point out that the notification is shown in the global notification box of the window, not of individual tabs. Closing the notification in one tab closes it in all tabs in that window. It's a one-time dismissal.
Oh, in that case I don't see much cause for concern then.
(In reply to Nihanth Subramanya [:nhnt11] from comment #2)

> What do you think is a better UX? We specifically say in the notification
> that *internet access* isn't available. We never say anything about the
> walled garden. Do you think we should? i.e., do you think it would benefit
> to mention that some URLs might be accessible? This is not very actionable,
> because there's no real way for us to possibly know what URLs the portal
> allows, or to cover all the walled gardens out there in the wild.

I think what was confusing in this case is that *limited* internet access was available. Sites whitelisted by the walled-garden worked fine, but of course others did not. Because of the geographical constraint (being on a plane) it's possible to spend hours in this state. On the other hand, it's nice to know public internet access isn't available.

I think I expected the notification to expire after a while, or to show only on pages which were blocked by the gateway. I didn't try dismissing the notification manually.

UX ideas:

- expire notification bar after some time (e.g. enough to have bought access from the portal)
- Add content to the tls error page to remind that a portal is blocking general internet access.
(In reply to Ralph Giles (:rillian) | needinfo me from comment #6)
> - Add content to the tls error page to remind that a portal is blocking
> general internet access.

That was bug 989197 which landed on Nightly a few days before your report.
Ah, that's great! Thanks.
It seems to me that bug 989197 gave us a lot of what this bug was about and the rest of the suggestions aren't in a concrete enough form for us to work on. We also don't have a lot of time left on this project, so this exploratory type of work is unlikely to get traction.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.