[HN Gopher] Changing the Android captive portal page (2020)
___________________________________________________________________
Changing the Android captive portal page (2020)
Author : transpute
Score : 84 points
Date : 2023-07-24 12:07 UTC (10 hours ago)
(HTM) web link (www.encrypted.at)
(TXT) w3m dump (www.encrypted.at)
| lucb1e wrote:
| I was about to go do this, because it seems cool to have a log of
| all the IPs that my phone has been on and not to leak this data
| to Google
|
| 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
| phh wrote:
| > 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
|
| 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).
| bartvk wrote:
| What do you use to self-host your grocery lists?
| lucb1e wrote:
| Something I wrote across about eight years, trying different
| things and never cleaning up unused parts, so the code is a
| mess but this is it: https://github.com/lgommans/mpgroceries
|
| 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)
| dugite-code wrote:
| I've been using the homeassistant shopping list integration
| but I'm planing to switch to "Specifically Clementines" [1]
| it's not as complete as grocy [2] but that's a feature. My
| partner will add to a list, not use an inventory managment
| system.
|
| 1. https://github.com/davideshay/groceries
|
| 2. https://github.com/grocy/grocy
| esskay wrote:
| Thanks for sharing this. I've tried to get on with Grocy
| but it's UI really put me off, it felt very unintuitive,
| cluttered and a bit like an app that had long since
| outgrown the initial hacked together layout.
| tcrenshaw wrote:
| not OP, but I use tandoor to host my recipes and it generates
| a shopping list based on what I've picked to cook this week
| lucb1e wrote:
| this was nearly impossible to find on duckduckgo
| https://tandoor.dev What a name, the only thing you get
| when looking for 'tandoor' or 'tandoor grocery list' are
| recipes for tandoori
|
| In my quest, I've also come across other promising-looking
| things https://kitchenowl.org and https://recipesage.com
| LegitShady wrote:
| dead trees, strained
| appplication wrote:
| The fridge. Integrations aren't great, but 9x9's uptime is
| incredible.
| raspyberr wrote:
| This is done on GrapheneOS by default. It also allows you to
| change the URLs without connecting your phone and using adb.
|
| https://grapheneos.org/faq#default-connections
| palata wrote:
| Note that ROMs like GrapheneOS or /e/OS do not connect to the
| Google connectivitycheck server (instead they use their own
| servers).
| SubzeroCarnage wrote:
| Except /e/OS then throws that out the window because it
| installs and enables microG by default which immediately
| connects directly to Google:
| https://github.com/microg/GmsCore/wiki/Google-Network-Connec...
|
| And /e/OS is still 224 days behind Chromium updates:
| https://divestos.org/misc/ch-dates.txt
| Raed667 wrote:
| neverssl.com has been my go-to captive portal for many years now.
| pests wrote:
| I use aol.com !
| SubzeroCarnage wrote:
| Or switch to a custom OS that provides controls for this and
| more:
|
| - 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]
| c4mpute wrote:
| Note that some captive portals will break here, because they will
| use various kinds of redirections for everything except the well-
| known Google and Apple captive portal check URLs.
| account42 wrote:
| Wouldn't such redirections break Google/Apple's checks? The
| whole point of this URL is to test if you can actually connect
| to the internet - if random urls are intercepted/broken then
| the test _should_ fail.
| izacus wrote:
| The attack surface could probably be lowered a bit by configuring
| the HTTP server (nginx, etc.) to return 204 instead of running
| PHP behind it.
|
| Still, neat :)
| sp1rit wrote:
| I don't think this has anything to do with "attack surface".
| This is simply to avoid google collecting ip addresses.
|
| 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).
| jeroenhd wrote:
| On the one hand, this denies Google the metadata from your
| connectivity check.
|
| 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.
| SubzeroCarnage wrote:
| Not all of these return 204, some just return 200 with an "OK"
| or "success". $ curl --verbose
| "https://detectportal.firefox.com" < HTTP/2 200
| success
| veave wrote:
| You don't need a die(); when you're at the end of the script
| already...
| account42 wrote:
| You also don't need PHP to return a static status code with no
| content.
| neoxeon wrote:
| IIRC, calling die() or exit() explicitly when you know it's
| time to _end_ is a good practice to prevent erroneous or malice
| including.
| geokon wrote:
| Not to be conspiratorial, but captive portals always felt like a
| little broken piece of internet technology that's never been
| fixed bc it benefits Google
|
| 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 !
| izacus wrote:
| > Not to be conspiratorial, but captive portals always felt
| like a little broken piece of internet technology that's never
| been fixed bc it benefits Google
|
| Against my better judgement and for my grim fascination, I'd
| love to hear a full explanation of this conspiracy theory. Can
| you elaborate?
| stavros wrote:
| How do captive portals benefit Google?
| acover wrote:
| > But, why should I change it?
|
| > 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.
| stavros wrote:
| Yeah, that's not Google having a say on whether captive
| portals exist and deciding to keep them there, that's just
| Google deciding that it wants to know your IP whenever you
| connect to a network.
|
| 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.
| duskwuff wrote:
| > that's just Google deciding that it wants to know your
| IP whenever you connect to a network.
|
| 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.
| charcircuit wrote:
| Google already knows every IP address. There is a fixed
| amount. Anyone can send a request to that address.
|
| This doesn't give Google any new information either.
| hackmiester wrote:
| I guess that is true, but the IP address space today is
| so large as to be unscannable. Practically speaking, you
| have to have some evidence that some host is there before
| you can start prodding at that host.
| philipkglass wrote:
| Do you mean the IPv6 space? The full Ipv4 space has been
| practically scannable for quite a while now.
|
| https://zmap.io/
|
| _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._
| hackmiester wrote:
| Yes of course. Most devices on the Internet don't have
| IPv4 addresses.
| kevincox wrote:
| > bc it benefits Google
|
| 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.
| Pxtl wrote:
| I find NeverSSL.com is a short, easy-to-remember URL for "oh
| crap am I in a captive portal or not".
| SubzeroCarnage wrote:
| AOSP actually has handling when it detects a SIM MCC matching
| China:
| https://cs.android.com/android/platform/superproject/+/main:...
| callumjones wrote:
| gstatic.com - the backbone of the internet.
| deusum wrote:
| Just marvel at how much data/metadata they get from that little
| trick when multiplied by millions users.
| throwawaaarrgh wrote:
| I just realized, they (or a government mandate) could force a
| redirect under specific circumstances to a site under
| google.com, and if they're using the browser engine for the
| request, they'd get the cookies of that user as soon as they
| get on the internet. Maybe even trigger an exploit in the
| browser.
|
| 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.
| pritambaral wrote:
| > could force a redirect under specific circumstances to a
| site under google.com, and if they're using the browser
| engine for the request, they'd get the cookies of that user
| as soon as they get on the internet
|
| 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.
| mschuster91 wrote:
| It's _amazing_ we 're still using captive portals instead of a
| DHCP option that's pushed to the client in 2023. Wtf.
| ajsnigrutin wrote:
| The point of captive portals is to get the user to either click
| "I agree" (to the terms,..) or enter a code/pay for the
| internet.
|
| 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.
| mschuster91 wrote:
| It would nevertheless be the _cleaner_ option. Had this been
| proposed and implemented six years ago, by now almost all
| devices would have supported it.
| ajsnigrutin wrote:
| IPv6 standard came out in 1998, and a lot of devices still
| don't support it.
| jeroenhd wrote:
| I don't see a lot of devices that don't support IPv6
| these days. Linux supports it, so most terrible IoT
| crapware works perfectly fine, and esp-idf enables it by
| default (solving the problem for a ton of cheap smart
| home crap).
|
| There are still devices that don't support hardware IPv6
| acceleration but at this point even those are becoming
| rare.
___________________________________________________________________
(page generated 2023-07-24 23:01 UTC)