You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Some environments, such as workplace or hotel rooms or cafes, offer wifi internet connections that makes use of a "captive-portal" RFC7710 wherein after your device has associated, you are still kind of “sandboxed” by routing all traffic to a "portal" webpage until you click on some kind of “Accept” button (perhaps attached to a liability waiver and good-behavior policy acknowledgement). I find that I am unable to get my mycroft mkII connected to the internet in such an environment.
Also, in many cases captive-portal style APs do not require a password at all. I have noticed that currently, the start.mycroft.ai page (which, funny enough, is clearly a localized captive portal of its own) disallows empty passwords by disabling the "Connect" button if I do not enter anything in the password input box. So actually I have not been able to test whether mycroft has general captive portal support, but I suspect that it does not.
Describe the solution you'd like
The start.mycroft.ai page should allow empty passwords
After associating (and perhaps any time internet appears to be down), mycroft should attempt to detect captive portals and if detected, present the portal page on-screen so that the user can click accept and thus get mycroft connected to the internet.
Describe alternatives you've considered
No alternative is possible yet due to problem 1.
Additional context
Mobile phone experience/processflow is a reasonable example of how a user would expect to work through a captive-portal.
The text was updated successfully, but these errors were encountered:
I have just discovered another, related deficiency. Start.Mycroft.ai instructs me to "Please choose your WiFi from the list below." It does not offer an option to enter a hidden/non-broadcast SSID. I just noticed that #14 reports exactly that problem, but thought I would highlight that in case these are interrelated enough to need to be handled simultaneously.
After some more rumination, it seems to me that after initial acceptance of captive portal agreement via GUI, Mycroft should ask permission to automatically renew the TOS acceptance on your behalf, and attempt to do so each time general network connectivity appears to fail. This is an Artificial Intelligence, after all.
So that would require a stateful record of user permission, per SSID, and some kind of fancy dynamic DOM navigator (e.g., injected javascript or some kind of hack on a "testing framework" like selenium, WebDriver, protractor, etc.) that will fairly reliably identify and "click" checkboxes and/or a button or button-like-html-element that says something like "I agree" or "Accept" or "Continue" or "Confirm", etc. And of course fall-back to asking the human user for help if it doesn't work out.
Would need to look at the legal around this but you're essentially caching a response, with permission. So would also want to verify that the agreement itself hadn't changed. Which could actually be a feature in itself:
Hey, you said to auto-accept but the Terms of Service have changed - we've emailed you a diff showing exactly what has changed.
In case this does not bubble up on its own: I did notice some Mark 1 work appears to have been done on this whole issue: MycroftAI/mycroft-wifi-setup#26 though its not clear to me what the end result was.
Is your feature request related to a problem? Please describe.
Some environments, such as workplace or hotel rooms or cafes, offer wifi internet connections that makes use of a "captive-portal" RFC7710 wherein after your device has associated, you are still kind of “sandboxed” by routing all traffic to a "portal" webpage until you click on some kind of “Accept” button (perhaps attached to a liability waiver and good-behavior policy acknowledgement). I find that I am unable to get my mycroft mkII connected to the internet in such an environment.
Also, in many cases captive-portal style APs do not require a password at all. I have noticed that currently, the start.mycroft.ai page (which, funny enough, is clearly a localized captive portal of its own) disallows empty passwords by disabling the "Connect" button if I do not enter anything in the password input box. So actually I have not been able to test whether mycroft has general captive portal support, but I suspect that it does not.
Describe the solution you'd like
Describe alternatives you've considered
No alternative is possible yet due to problem 1.
Additional context
Mobile phone experience/processflow is a reasonable example of how a user would expect to work through a captive-portal.
The text was updated successfully, but these errors were encountered: