How to do local services safely [LWN.net]

How to do local services safely

Posted Jun 11, 2025 13:36 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (17 responses)

It just needs to require explicit user permission, same as accessing your webcam.

How to do local services safely

Posted Jun 11, 2025 13:41 UTC (Wed) by xav (guest, #18536) [Link] (15 responses)

Sure, but no regular user would be able to understand that concept.

How to do local services safely

Posted Jun 11, 2025 15:02 UTC (Wed) by ms (subscriber, #41272) [Link]

Maybe the browser should only be able to connect to localhost if the whole phone is in developer mode. No normal user is going to accidentally do that, and connections to localhost are useful if you're doing app development or similar.

How to do local services safely

Posted Jun 11, 2025 16:51 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (4 responses)

Part of our job sometimes is to explain and educate. I'm sure someone could come up with a prompt that a lot of people would understand - and technical literacy does increase over time, and privacy is an issue that lots of uses care about.

How to do local services safely

Posted Jun 12, 2025 6:44 UTC (Thu) by marcH (subscriber, #57642) [Link]

Something like "Do you allow X to communicate with apps/pages on your phone? should do. I don't think "localhost" and "socket" are needed much here. In fact, you'd want this same permission to apply outside TCP/IP too.

How to do local services safely

Posted Jun 13, 2025 6:54 UTC (Fri) by oldtomas (guest, #72579) [Link]

This is very important.

Education should not just focus on (individual) users [1], but also on society in general. Elsewhere in the commentary there are good contributions as to how lawmakers shouldn't let those bad actors get away with it: but then, lawmakers should understand what's at stake!

I see that as a corollary of the old saw "you can't solve social problems by technological means".

[1] But this part is essential, too!

How to do local services safely

Posted Jun 13, 2025 20:37 UTC (Fri) by bmur (guest, #52954) [Link]

It's much simpler than that.

All the message needs to say is:

"Allow this permission to continue using Facebook."

Everyone: *shrug* Allow.

How to do local services safely

Posted Jun 14, 2025 10:37 UTC (Sat) by Wol (subscriber, #4433) [Link]

> and technical literacy does increase over time,

Are you sure?

Ime literacy generally (and technical is included) goes down over time WITHIN A COHORT.

That's why IQ tests don't measure "the general populace", rather they measure the general populace against their own age group. Different age groups score differently, but individuals tend to score consistently against their peers.

Cheers,
Wol

How to do local services safely

Posted Jun 11, 2025 18:14 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (8 responses)

Can't Android know what app/activity is on the other end of that socket and make a nice "Do you want $BROWSER to be able to interact with the $INVASIVE_AD_TROJAN app?" permission rather than mentioning anything like "localhost" or a random port number?

How to do local services safely

Posted Jun 11, 2025 21:18 UTC (Wed) by fraetor (subscriber, #161147) [Link] (7 responses)

I can't remember where I saw it, but "a user shouldn't be able to opt-in to insecurity."

In the case of this specific proposal, perhaps you don't mind facebook.com in your browser talking to the Facebook app, but would for other origins.

Various cross-site request forgery prevention mechanism exist to prevent a random site from affecting another site, but in this case the localhost server wants to be affected, which means you would have to prevent the entire request.

A static permission on the app sounds like a sensible step, as it would allow app store review to catch malicious code while still allowing origins to opt-in.

How to do local services safely

Posted Jun 12, 2025 5:29 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Sure, setting up the socket should *also* have a permission. But just because the socket is up doesn't mean I want any app/website to communicate with it at any time.

How to do local services safely

Posted Jun 15, 2025 16:26 UTC (Sun) by KJ7RRV (subscriber, #153595) [Link] (5 responses)

Couldn't this be a browser-level permission given to Web sites, rather than an OS-level one given to the browser?

> Do you want to allow facebook.com/legit-site-with-ads.com/sketchy-site.com to connect to the Facebook app on your phone? Tap "Deny" unless there is a clear reason that you understand why this is needed, because this can enable trackers to break privacy protections and see your activity across the Internet.

> [Protect my privacy: *Deny*]
> [I understand the risk; *Allow*]

How to do local services safely

Posted Jun 15, 2025 16:47 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (4 responses)

How is the browser supposed to know what app is behind `localhost:12345`?

How to do local services safely

Posted Jun 15, 2025 17:40 UTC (Sun) by notriddle (subscriber, #130608) [Link] (2 responses)

https://www.man7.org/linux/man-pages/man8/lsof.8.html

How to do local services safely

Posted Jun 15, 2025 18:44 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

Sure…but is that reliable on Android?

How to do local services safely

Posted Jun 15, 2025 19:11 UTC (Sun) by johill (subscriber, #25196) [Link]

IIRC each app install gets its own UID, so all it needs to identify is the UID of the listening socket. Should be really simple to do especially on a tightly controlled system like Android.

How to do local services safely

Posted Jun 16, 2025 8:46 UTC (Mon) by farnz (subscriber, #17727) [Link]

The system as a whole knows (if nothing else, the kernel knows the process that's got the socket open), and thus Android could provide an API that maps from local socket to Android application that has the socket open.

If I were implementing this, I'd implement two things:

An API that takes a struct sockaddr_t, and tells you the listener's identity - either a local identifier, or "not a loopback socket/pipe".
An API that takes an fd, and tells you either the listener's identity, or "not a loopback socket/pipe".

With this in place, API 1 lets the browser prompt you before you connect. API 2 lets the browser drop the connection and warn the user that the applications identified by API 1 and API 2 are potentially malicious before transferring data, thus deterring "clever" ideas around transferring a socket between applications.

How to do local services safely

Posted Jun 11, 2025 17:44 UTC (Wed) by notriddle (subscriber, #130608) [Link]

Warning fatigue is already one of the web's most severe misfeatures.

And, in this case, it doesn't seem necessary. Instead of having the website ask permission to talk to the app, the app should ask permission to provide services to websites. That makes it a lot easier to build the feature in a fine-grained, legible way, because the storefront can refuse to ship an app if it breaks when the user says "No", can allow an app to expose services only to certain top-level origins (and make the warning a lot more obnoxious if an app wants to provide a service to every domain on the web), and can track historical changes to the policy for all distributed versions of the app (no gaslighting people by doing the attack on a random 1% of the population).

That's already how it works if an app wants to replace a website wholesale[^1]. They should just extend it to do the same thing with apps that want to provide services to a website without replacing it.

[^1]: https://developer.android.com/training/app-links

How to do local services safely

Posted Jun 11, 2025 14:32 UTC (Wed) by DemiMarie (subscriber, #164188) [Link]

This should be done via an embedded webview.

Crossing security domains

Posted Jun 11, 2025 15:39 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

The underlying problem here is that you're silently crossing security domains. You think you're accessing https://news-site.example.com/, but you're actually accessing both https://news-site.example.com/ and something on localhost (in the case of Yandex, a HTTPS listener, in the case of Meta, a STUN listener).

I'd therefore guess that you could restrict this sort of exploit without completely prohibiting access to local services in a similar way to the way that you can't use file:/// URLs in a document served over HTTPS. You'd have rules that say things like "if you fetched the top-level document over loopback, then you can also connect to services over loopback. Otherwise, traffic over loopback interfaces is blocked"; then, if I set up the DNS label my-service.example.com to point to a loopback address, and I have my app listen to loopback, you can go to https://my-service.example.com/ and have access to loopback services, but if you instead navigated to https://new-customer.example.com/ (connecting over the network to my webserver), you'd have no access to loopback services, even if you accessed them via the name my-service.example.com.

This would let a legitimate app serve up a web page locally that you could use to access loopback services, but would prohibit me from doing so from a remote site; I'd have to set up a local proxy, and have the browser UI show that you're accessing something like https://my-service.example.com:12345/proxy/new-customer.example.com/site/etc

You're still not fully protected, but it at least stops malicious actors doing this stealthily.

Crossing security domains

Posted Jun 12, 2025 0:42 UTC (Thu) by wahern (subscriber, #37304) [Link] (2 responses)

See this recent proposal: https://github.com/explainers-by-googlers/local-network-a...

Crossing security domains

Posted Jun 12, 2025 8:50 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

That proposal does, unfortunately, run into the "prompt for insecurity" problem, which means that it doesn't fully block the described exploit - not least because sites using the exploit could socially engineer their way to local network access.

It's a distinct improvement, however.

Crossing security domains

Posted Jun 12, 2025 10:12 UTC (Thu) by Funcan (guest, #44209) [Link]

Any prompt stops mass attacks of this because at least some of the people promoted will be technically skilled enough to be suspicious and follow up