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.
- User notices a
Kiwix PlugWiFi 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
kiwix-plug.lan is dynamic and matches the WiFi name (
From there, we assume on-boarding is complete and ideascube takes user to content.
- 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.
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.
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.
- 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.
- 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:
- Explain it's a plug
- Clearly provide home URL
- Explain limitations: idle disconnect, SSL, background refresh and counter-measure (open a new browser tab).