Onboarding
By design, pibox is meant to be used freely by everybody in reach of its WiFi network. In practice, onboarding can be slightly complicated.
This issue's goal is to document current (2.0) behavior and agree on expected one.
Onboarding steps
- User notices a
Kiwix Plug
WiFi network and connects (either an Open network or a protected one, given he has the password) - User goes to the Home Page (ideascube homepage, at
http://kiwix-plug.lan
)
Here, kiwix-plug.lan
is dynamic and matches the WiFi name (Kiwix Plug
).
From there, we assume on-boarding is complete and ideascube takes user to content.
Technical limitations
- WiFi network can be either Open (no password) or Secured (WPA2, password set during configuration).
- OS react differently based on WiFi security
- Changing DNS response is technically a MITM (man in the middle) attack
- Browsers are increasingly less permissive regarding security in general and SSL in particular.
- OS tries to detect captive portals.
- Browsers (Firefox at least) tries to detect captive portals.
- Browser-level-only solution might be ignored by App users on phones.
Current behavior
Offline
Once connected to the Pi, Firefox notices its a closed network (fake DNS for its test address) and displays a ribbon on top of the window.
This happens before any request.
Every request redirects to kiwix-plug.lan
except HTTPS ones which results in an error message
Note that chrome redirects to kiwix-plug.lan
even on HTTPS without warning. That behavior is expected to change in newer versions though.
Online
Once connected, depending on the WiFi security, the system might open a popup with the captive portal invite. If not, the invite is displayed in the browser upon first request.
The invite show the URL and once clicked, redirects to it.
Issues
- Pibox image creators are not informed about the two different behavior and thus sees them as unexpected and random.
- Most websites are now using HTTPS so people connecting to a plug have greater chances to try an HTTPS URI.
- Captive portal is configured to reset idle connections every 5mn. Should a user not make any request for 5mn, he should be prompted again with the captive invite at the next request.
- For websites that use background requests (javascript), after idle reset, captive invite is not shown and user is not aware he is out of connection.
Suggestions
- Use a captive portal for all modes (online and offline)
- Use a longer idle time (15mn? 60mn?)
- Design the captive portal to be a real onboarding/prehome page:
- Welcome
- Explain it's a plug
- Clearly provide home URL
- Explain limitations: idle disconnect, SSL, background refresh and counter-measure (open a new browser tab).