[IgorPartola]

This is the correct goddamn answer. Or, better yet, get rid of cookies as a thing. The one and only legitimate use for them is session tracking, so why not provide a session storage mechanism instead? Every website gets a standard login/logout button with pluggable functionality for how you authenticate. And maybe, just maybe, we can then also have Persona-type identities that are stored and synced across all your devices so you just choose from a drop down of which identity you want to use to log in rather than typing usernames and passwords.

[scubbo]

What makes you think that those sessions wouldn't get (ab)used in exactly the same way that cookies now are?

[IgorPartola]

Because when I hit the logout button, the local session ID is deleted from my browser session storage (because that action would be performed by the browser and not by the website’s code under this system), so I would look like a brand new user to the site (setting aside other identifying stuff like IP address, etc.). All the session store should hold is an opaque ID for the session and it’s expiration info and it would be sent to the web server as a header (Session: djsisnxidnskxjf). The server would store all the info about you but if you don’t send that header, the server has no idea who you are.

[scubbo]

OK - so instead of cookies storing information on who you are and sending that back to the service, you instead have your browser telling the service who you are and the service storing that information on you?

I'm still not seeing the advantage. This isn't me arguing with you and telling you that you're wrong - I just genuinely don't see the difference and would like to understand better. This hypothetical service will still have the same amount of information on you either way (just stored service-side rather than in cookies), right? Unless you're claiming that the service wouldn't associate your various sessions with one another, which seems both incorrect (they certainly would, if they possibly can - as you say, via IP address, etc.) and undesirable (almost all moderately-sized-or-larger web services would feature some kind of persistent settings, at least).

[marcosdumay]

Any browser authentication functionality you create will track people exactly as well as 1st party cookies. So, just disallow 3rd party cookies, and get the exact same level of privacy.

Firefox does the "synchronize the authentication data across devices" thing too.

[IgorPartola]

If I hit “logout” in the browser under this system, I would be assured that my session ID is erased and not sent to the server. As is, a website can have a logout button that erases a session cookie but keeps tracking cookies.

[marcosdumay]

Oh, ok, so you want a button to delete your cookies. That should be reasonably easy to do in an extension.

I would probably use such thing too, and not only for privacy reasons. Bonus if it deleted stored data, cache, and everything else related to the site.

[IgorPartola]

Almost. Cookies are way too permissive and complex. What I am thinking of is essentially a Session: abcdef12345 type of header that would be used for authentication/sessions. This header would be directly tied to the domain I am talking to and should have a simple expiration (or not) policy that the web server may suggest but I can override. No more X-PHP_Session_widget_co-referer: … type crap. No multiple cookies. No large storage. No HTTP vs HTTPS, no HTTP-only, no third party anything. path is the only thing I am somewhat ambivalent about because it does present a certain complication but also allows you to have applications that aren’t at the top of the domain.

Along with this we have a browser API we can call Authentication with something like Authenticate.prompt() and Authenticate.clear(). prompt() would bring up the standard browser UI for logging in and the parameters to it would dictate how the authentication should happen: username and password, 2FA options, private/public key, client certificate, etc. Registration could be handled in the same UI or have a separate API. clear() lets you have an internal logout button or mechanism on the site. The same APIs should be available via HTTP headers for non-JS usage.

As a bonus, we can then develop a mechanism for creating a session ID based on me having a private key that has an associated identity with with. So when I am prompted with a login UI instead of entering usernames and passwords I can simply choose from a drop down which identity I want to use for this site. Of course the problem of syncing private keys across devices is hard, but not any harder than what password managers currently do with my passwords.