Changing the Android captive portal page (2020)
encrypted.at
encrypted.at
Then I remembered how much trouble I already have when my server is offline for any reason: no email, no grocery list, no backups, no VPN, no git, no link shortener, no IRC, no website with various tools like 'what is my IP' or bidirectional latency testing... self hosting is great but you're also on the hook for everything and it all has a single point of failure unless you want to run a dual-uplink server farm.
And yet I am still tempted to add this 204 service, but maybe then I also don't have internet on my phone anymore because it keeps believing it's behind a captive portal when the service is offline
In my quest, I've also come across other promising-looking things https://kitchenowl.org and https://recipesage.com
The name (multiplayer groceries) refers to the original idea of having the software assign random items to random people, so you can both go through the store independently and not get duplicate items, for maximum efficiency, but I don't think I've used that more than once.
Probably I could write a small book about all the things that you shouldn't do, like making a store layout and mapping where all the items are and then making it sort by nearest item...which, turns out, is somehow always on the other side of a wall. This routing is better than nothing, but it turns out that categorizing ("freezer", "candy", "fruit/veg") is: much simpler for the user, portable across stores, and more effective for routing as well.
I've started on a rewrite with a friend, but it's very early stages and the primary purpose of the new project is to turn a list of meals into a grocery list rather than being a grocery list that you add random items to: https://codeberg.org/lucg/MealsUnveiled The old project can also add a recipe to your grocery list, but I never wrote the code to add up amounts (it'll ignore duplicates instead)
Try it. Normally Android will say "This connection doesn't give you internet, connect anyway?" then you press yes, and everything works. (Except if you're on a captive portal, in which case you'll need to type example.com in your browser to access the captive portal).
Still, neat :)
Running nginx might be marginally faster than PHP, but I believe the latency to your server will be far greater than the time it takes the server "to spin up the php interpreter" (doesn't even happen anymore when using FastCGI).
This has a very cryptic failure mode if you travel to China. Android will just tells you you can't connect to the internet :)
It's pretty easy to work around. You just go to detectportal.firefox.com/
But naturally you need to know what's gone wrong in the first place !
Against my better judgement and for my grim fascination, I'd love to hear a full explanation of this conspiracy theory. Can you elaborate?
> Well, on Android 6 or higher, every time you switch networks, your phone tries to access the following URL:
> http://connectivitycheck.gstatic.com/generate_204
> As we can see, gstatic.com – Google’s servers. We might not want Google to know our new IP address or when we switched between networks. So… Why don’t we just self-host it? It’s pretty easy.
I don't know why this is such a big issue, given that they have your more or less exact location at all times, but changing it is so easy that, why not.
No, it's Google wanting Android users to be notified when they sign in to a wifi network that uses a captive portal, rather than having all network requests silently fail because they're being redirected.
Fixing the (generally terrible) user experience of captive portals is the primary goal of this feature. Any data collection is secondary.
This doesn't give Google any new information either.
ZMap is a fast single-packet network scanner optimized for Internet-wide network surveys. On a computer with a gigabit connection, ZMap can scan the entire public IPv4 address space on a single port in under 45 minutes. With a 10gigE connection and PF_RING, ZMap can scan the IPv4 address space in 5 minutes.
I doubt this is the reason. It seems more likely that no one has bothered to fix it. I agree that captive portals are a big hack with poor UX. This auto-detection does mitigate it but it is still very annoying especially if you have secure setups like encrypted DNS so the basic hijacking doesn't work properly.
Putting the url in a dhcp option wouldn't change that, wouldn't work with older devices (so a redirect would still be needed), and the only change is, that you'd have two ways to reach the same captive portal page, that you'd have to configure on two (or three, with ipv6) devices/config files.
There are still devices that don't support hardware IPv6 acceleration but at this point even those are becoming rare.
It's a generic user agent I believe and there's billions of (simple) HTTP requests hitting that endpoint. If you're using a stock Android (or even worse, like Samsung) it's the Play services and unkillable vendor background apps you should be worried about.
I'd argue it's a lot more conspicuous to network operators if you're using non-standard captive URLs.
On the other hand, using your own site uniquely identifies you on each network (negating the privacy improvements through random MAC addresses and such).
I would much rather use a site I can trust. Mozilla offers a 204 service for Firefox, for example, that's a lot less obvious for trackers.
You could also try to confuse the system by using iOS' 204 URL for your Android devices.
$ curl --verbose "https://detectportal.firefox.com"
< HTTP/2 200
successAnd /e/OS is still 224 days behind Chromium updates: https://divestos.org/misc/ch-dates.txt
I checked your link, I don't see the connectivity check listed there. Can you please elaborate?
> And /e/OS is still 224 days behind Chromium updates
Did I mention anything at all about Chromium updates? Or is it just to add a link to your website?
/e/OS changes the connectivity check from Google to their own server, great, but then it still connects to Google services via microG. So why bother changing the connectivity check?
> Chromium updates
Your comment was recommending an operating system that is actively harmful to its users by falling behind basic security updates that every single other OS has done.
edit: aside from that, what are your thoughts on their upcoming license key system for OTAs that give users a persistent identifier? https://gitlab.e.foundation/e/os/android_packages_apps_Updat...
So you actually do agree that /e/OS changes the connectivity check, don't you?
> Your comment was recommending an operating system
Not at all. My comment was mentioning that at least some custom ROMs I know do remove the connectivity check, which is the topic of that post ("Changing the Android captive portal page").
In that particular post, I did not recommend /e/OS, I just stated a fact. But if it's about recommendation, I would recommend against DivestOS, because the author is really toxic. That may be harmful to users, too.
- my DivestOS (includes nine presets): https://divestos.org/pages/network_connections
- GrapheneOS (includes two presets): https://grapheneos.org/faq#default-connections
also if you do want to setup your own portal there is a simpler method than invoking php each time:
RewriteEngine on
RewriteRule ^/generate_204$ - [END,NE,R=204]This is the most fantastic way to target and exploit any single Android user anywhere in the world that I've ever heard of. Automatic, hard to avoid, easy to implement, and the user has no idea.
At first, I thought this can't be true because, surely, Google marks its cookies as HTTPS-only, right? So I checked, and turns out about half the cookies google.com has in my browser are not HTTPS-only. In fact, the HTTPS-only cookies it does have seem to be the same set of cookies, just with a '__Secure-' prefix. Similarly, about half (different set) of the cookies JS accessible.