Guarding against that would only be a heuristic anyway, as we can't tell that the app didn't just query every extension, ignore the results and request some others. I think it should be a browser warning.

Let me explain in a bit more detail how I see this and the limits changes. The privacy budget idea makes the user agent to adjust the result of queries based on the very act of querying. This is a classical quantum behavior! Essentially, device geometry properties do not exist until discovered. So this is not a heuristic, it's somewhat straightforward: if you don't check for extension X (or limit L), then it's not there. If an app wants to check for all extensions, its their choice, but they should be aware that the privacy budget will quickly be depleted, and they aren't going to get all the extensions anyway.

It's well-defined, but it's still a heuristic relative to the behaviors we want to prevent (assuming capabilities that you don't know exist, and requesting capabilities that you don't need). It's not the only reasonable well-defined behavior, and I prefer a model where the state of the adapter is not mutable in that way, like:

• Checking for a capability spends privacy budget
• Enumerating the extensions spends privacy budget (same bits as checking the extensions set for exactly every extension known by the UA)
• Attempting to create a device spends privacy budget (same bits as checking for all the capabilities requested by the device, even though that's more than the actual info you get from requesting a device and seeing if it succeeds)

Matrix chat discussion. I think @kvark and I are on the same page now.

Resolved: It's agreed this is a strict improvement, so accepted. There's mixed desire to remove the possibility to enumerate the set, but it can be a later increment.