> with TLS in place, it becomes easy and commonplace to send stored authentication credentials in those requests, without visibility, and without the ability to easily reset those credentials (unlike in-the-clear cookies).?
Cookies are orthogonal to presence of TLS, I thought (unless they're marked as secure, in which case they are only supplied to https hosts?)
Is there some other way of identifying a particular user/browser/session[1] other than the quirks & features enumerator along hte lines of Panopticlick?
If there is (ISTR some 'session storage' for resuming TLS in nginx), is that cross-trackable across different services (potentially all TLS-terminating in the same place, such as Cloudflare or AWS)?
One good point is that I hadn't considered is that the lack of proxyability means every request which can't be filled from the browser cache must hit the actual endpoint, making it easier for them to follow along action-by-action when it might otherwise have been served up before getting to them by a caching middle-proxy.
My (limited) understanding is that you're potentially providing more information to the remote service, but are better secured against people snooping on your traffic as it flows between you and them.
[1] also not including client certificates, because exactly 1 site on the internet actually uses them :P