Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits.
In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie.
If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session.
If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you.
Of course this can be abused, but not nearly as much as cookies are abused today.
But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.
More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id.
If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.
That could also just by achieved by disallowing third party cookies though - feels on the cusp of being a browser implementation problem (just stop allowing third party cookies).