[saag] Re: Covert Web-to-App Tracking via Localhost

On Wed, Jun 04, 2025 at 04:38:07PM -0400, Michael Richardson wrote:
> John, this "localmess" seems to be about "native" apps that listen on
> 127.0.0.1, to which mobile browers seem not to filter access, or restrict.
> Seems very serious to me.  
> 
> (Don't install apps to which one can not review/audit their source code. But,
> that's never been a IETF responsability)
> 
> I don't see how this an IETF *specific* concern, nor do I see how this is
> enabled by any current IETF process or policy.

Agreed.

There are two apps in this case: the browser, whose behavior is governed
mainly by W3C specs, and the native app listening on localhost.  What
can the IETF do about that??  Nothing, really, except maybe publish a
BCP or FYI, and then what?

Basically this one is a permissions problem in the user-agent (the
browser).  As well an operating system with more isolation might
independently not allow the user-agent to talk to that native app w/o
the user approving it.  Neither of those two solutions fall within the
IETF's remit.

> John Mattsson <[email protected]> wrote:
>     > I urge the broader Internet community to reevaluate current approaches,
>     > and to prioritize user privacy and safety over monetary donations from
>     > data-hoarding, surveillance-driven tech giants.

If the IETF were in the business of specifying Internet protocols _and_
operating system behaviors and authorization systems and policies, then
the IETF could have something to say about this.  But clearly the IETF
can't even begin (today) to evolve to expand its remit in this way, and
probably none of the IETF's participants want to do that anyways.

So what do you propose the IETF do to "prioritize user privacy and safety
over ..." that would help in this particular case, and what do you
propose more generally?  If you're merely complaining and pointing your
finger, that's not constructive.  Give us some ideas.

> Except that maybe we shouldn't accept statements like "TLS 1.3 in widely
> deployed", yet it's only really browsers, and they (browsers) don't seem to
> support useful TLS features like mutual authentication with 1.3.

Client certs are very poorly supported in general.  What I'd like to see
is that libraries apply name constraints to SANs, expressive local
policy, as well as any local mappings of of the client cert's identity,
and also for them to also provide the application with the raw client
certificate _and_ the trust anchor to which it was validated.  In
practice nothing of the sort exists, and almost all applications that
purport to support client certificates can only be constrained by the
use of trust anchors and they only provide the CN attribute of the
certificate's distinguished name (which is totally useless -- SANs are
far more useful).

> The HTTP client authentication gap is a problem that seems to be
> nobody's problem.

Ain't that the truth.  Though what the relation to this thread is I
don't know.

If we're going to expand this thread to HTTP client authentication...
what I most want is an extension that allows clients to figure out how
to fetch the [Bearer, like JWT] rocks the servers want.

Nico
-- 

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]