Hacker News Reader

Comment by altairprime | Hacker News Reader

Client TLS is rather unusable on the Internet by a typical random end user visiting a random public site, so that should at least keep the specific scenario you describe at bay.

View on HN

Currently yes, but there's not much stopping Chrome etc. from adding a new feature that has a way of presenting a client certificate to a website in a backwards-compatible manner.

Of course the website itself would need to support that, but it's all possible in time.

Chrome would be more likely to implement a persistent and identifiable (to Google alone) tracking cookie replacement and ship it worldwide, which iirc they did — and then cancelled, of course. They seem to be focusing instead on improved tracking of Android users from the kernel up, rather than browsers from the headers down; GrapheneOS is, presumably, viewed as a serious threat to their advertising revenue.

https://privacysandbox.google.com/blog/update-on-plans-for-p...

Yes that's what I'm saying this could be used for. Browser generates a client-side key (or any kind of identifier, possibly derived from the site's TLS cert/domain or some other info) for the current browser/user/device/whatever and just offer that to every website as an extra header so that whoever wants to track you, can.

Wouldn't this in practice be a lot like Passkeys? But it might be more difficult to integrate this kind of approach to the stacks we use, whereas Passkeys fits in relatively easily.

I suppose client cert would protect against from a MitM attack, if the client failed to notice it, or if the MitMer has the website keys to make a perfect attack.

Reply on news.ycombinator.com