|
|
|
|
|
by palmscenter
840 days ago
|
|
The main problem with these projects - which was not much of an issue when the projects started - is that mobile phones of today seek access to web servers at vendors, including the OS source and possibly others such as the phone manufacturer and ISP. The phones balk if they don't connect to those servers. PirateBox and LibraryBox are not just captive portals to Internet connections, they are local content and app servers and don't need the Internet. So when you connect to a Box via Wi-Fi your phone demands to connect to Internet hosts even though this is unnecessary for this use case. This behavior is confusing to the user. Some early solutions involved trying to spoof Apple servers for example, but the names and IPs of these servers kept changing and this kluge became ineffective. The only solution I am aware of is to pre-inform users of a local IP address to browse to once their Wi-Fi is connected to the Box. But depending on the occasion and venue, getting such instructions to the audience and having them follow it, can be its own problem. |
|
Captive portals sound nice until you find out how limited they are -- a lot of styling, JS and browser features are simply unavailable. So, you need to tell users "Close this, then go open this site in your real browser"...
Of course, you can't and probably don't want to redirect HTTPS traffic since you don't have the matching cert for e.g. https://google.com