We're talking about a theoretical situation where we gate the canvas and audio api behind a permission prompt. My "presumably" is about how that would be theoretically implemented.

Except prompt spam is a real issue too. Very quickly you can end up like Windows' UAC that basically trains people to blindly click "yes" on any dialog they see. Putting a permission prompt for every tiny little thing a browser can do isn't a good experience for the user, and most people will have no clue what "allow access to canvas/audio api" means.

Except that with a prompt for a specific API, you can get specific on when it's appropriate. E.g.

"This website has asked for permission to use the Audio API. If they aren't actively doing audio processing, this may be an attempt to identify and track you. If you haven't been presented by the site with a good reason why to allow this access, and it's not immediately obvious (such as for a music service), consider whether you want them to have access."

This accomplishes a few things. First, it's very clear about the implications and when it's obvious it should be allowed. Second, it gently suggests the default behavior for people should be to deny unless needed. Thirdly, it communicates to sites (through users the appropriate way to ask for permissions if hey have a legitimate reason, which is to let users know why they need access. Lastly, if sites lie to users about why they need access, they can be called out on that. People don't like being lied to.

Now imagine getting 10 of these, as a user who has no idea what those words mean, nor care, because you just want to see the latest meme on Facebook, and you just blindly press Allow on everything and quickly become desensitized to all prompts.

Gating the API behind a permissions dialog or permission setting. The difference being that an end site either uses it and gets valid data (because the user allowed it, the default without a dialog today), or gets errors letting them know the data can't be relied upon.

If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you.

The canvas api might be a little more likely to be allowed by the average person, but enough might disallow or ask about it that sites that have a valid use for it will put up a banner noting why it's important, making sites using it for tracking stand out all the more.

The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions.

> Gating the API behind a permissions dialog or permission setting.

Those dialogs and settings are controlled by the Permissions API today.

> If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you.

You and I might disable it. Overwhelmingly, the majority of the public click "enable" or "yes" on permission pop-ups. And tend to make sure "enable forever" is ticked.

> The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions.

I don't disagree. The problem here is that the permission model itself has been broken, and won't be repaired because of backwards compatibility, and a lack of incentive.