https://globalprivacycontrol.org/ goes kind of in that direction. It's a rebranded Do Not Track header, but referencing specific privacy rights under GDPR/CCPA. That hopefully makes it enforceable, whereas advertisers could just ignore Do Not Track.
I like the idea, but that protocol is too simple. For example, I don't have too much of a problem with Matomo tracking cookies, but I don't want Google Analytics to follow me around the web.
This header doesn't specify any of that, and I'd still need to give some kind of consent through a cookie pop-up to websites that want me to use that stuff.
I see your point, but one of the main problems of P3P was its complexity. There's more than two decades of privacy-enhancing technology research showing that privacy controls need to be fundamentally simple.
I think DNT/GPC can be more fine-grained than you make it out to be. The spec is simple, but there's nothing in there that stops you from developing a browser extension that only sends DNT/GPC signals to a curated list of known bad trackers. That would give you as an advanced user some configurability while it's a simple checkbox for most folks.
I agree that P3P was way too complex, but so are the cookie popups that plague us today. P3P was built around legalese and privacy statements rather than simple consent, I think a modern take can do much better.
The extension you propose would be my vision of a modern P3P, but with categories you can set up with defaults. You don't want to force a NoScript/uMatrix style screen onto users, so the browser should simplify a bit, but a header that says "yes for necessary services, yes for analytics, no for tracking, no for advertising" (or something like that) would fit my requirements.
I think websites should also have a way to show _why_ and _how_ they process data, because that's part of the informed consent users give. A simple text field with a maximum size to force short descriptions, maybe with a "more details" button next to the selected purpose could be enough.
I don't think just sending a header would suffice because you'd still get consent popups if there's no other way to get consent. A boolean "sell my data" kust doesn't encompass the consent you're giving websites when you allow/deny.
It's a challenge to keep simple, for sure, but the UI and server-side API can be simpler than the underlying protocol. Consider the browser language list that nobody uses: to the user it's just an ordered list of languages, but in the user agent headers each language gets a numeric weight added to it. Or Firefoxs's "block trackers" button that substitutes Javascript when you enable it and applies all kinds of weird rules and detections to work.