☝️ Do you have a question that's not answered in this FAQ? Open an issue.
Disclaimer: Answers below are subject to substantial change.
At the time of writing (December 2020), the privacy budget is an early stage proposal and does not yet have a browser implementation.
Note on Chrome: A study is being conducted by Chrome to measure the identifiability of APIs exposed to websites. The next step for Chrome is to publish the findings from their measurement study (size of a feasible privacy budget, best ways to calculate and maintain the budget).
First, note that consuming some of your site's budget is not a problem. In many cases, sites are expected to consume some or even a large part of their budget, because they need to access some information about the agent to guarantee a great user experience or use specific features. You can think of it like an actual budget: it belongs to your site, and you as a site developer will decide how to allocate it.
How much budget specific APIs will consume isn't defined yet. Many APIs are expected to consume at least some of the privacy budget, but the handful of APIs that are likely to consume larger amounts of the privacy budget are APIs that access browser attributes, APIs that enable to read the WebGL render name or mobile phone device name, and others. Before the privacy budget is enforced, tooling should be made available to help you figure out which APIs consume your site's budget.
Not yet, as of December 2020 (see Status).
What will I need to do on my site to adjust to the privacy budget? What about APIs that are so powerful that they will blow through the budget, even if they're not used for tracking?
First, note that consuming some of your site's budget is not a problem. In many cases, sites are expected to consume some or even a large part of their budget, because they need to access some information about the agent to guarantee a great user experience or use specific features. You can think of it like an actual budget: it belongs to your site, and you as a site developer will decide how to allocate it. Limitations will kick in only if you spend all of your site's budget, because this will mean that your site is accessing a combination of APIs that can be used to uniquely identify users. Typically:
- Sites that covertly track users will hit their budget, and they'll need to change.
- Some applications, such as 3D games or video conferencing, may not be able to run within any reasonable privacy budget. For such applications, there may need to be an "escape valve": a permission prompt informing the user that granting additional API access may allow the site to identify them. Read more.
What can I do today to prepare for the privacy budget? What are alternatives to things that are consuming my budget?
There is no action to take that is specific to the privacy budget at this point. However, you can proactively start making use of less-identifying APIs in your site. For example, consider making use of User-Agent Client Hints over the User-Agent string to only request the specific bits of data you need. If you're implementing or proposing APIs, ensure that you are considering the identifying data the API may expose and how you can mitigate that. For example, consider designing a configuration that allows an API to expose only uniform functionality by default, but lets users optionally take advantage of platform-specific features if required.
The enforcement mechanisms for the privacy budget aren't defined yet. Potential options are to block API calls, to noise or uniformize the output of APIs, or to use another enforcement mechanism. This decision will be informed by measurements that will help to assess the impact of different enforcement mechanisms.
Browsers may consider adding a permission prompt informing the user that they can grant additional API access, and that this may allow the site to identify them. See details in What will I need to do to adjust?.
Generally, no, since this may allow sites to knowingly hinder user privacy. However:
- Sites that cannot operate within the budget because they need access to powerful APIs may rely on permissions.
- Browsers may offer mechanisms to prevent third-parties from spending a site's budget.
Browsers that implement the privacy budget will make tooling available (such as privacy budget controls) to facilitate local development.
Can I limit third-parties and iframes from using up my budget? What happens when a 3P library uses up my budget?
To help sites ensure that third-party content doesn't make them exceed their privacy budget, browsers may want to offer sites the ability to opt-in to certain constraints (such as iframe sandboxes or feature policies).
Is the privacy budget sufficient to prevent covert tracking, since IP Addresses can also be used to track users?
No, the privacy budget would need to be combined with other measures. There's a proposal to mitigate IP-based tracking: Willful IP blindness.
API "cost" = How much of the privacy budget would be spent when a site uses the API.
Identifiability of APIs and features will change with time as browser / device ecosystems and user populations change. In the long term, browsers will need to periodically adjust the costing strategy to keep up, which will in turn require periodic surveys. How and who will do this is not determined at this time. Any resulting changes to the costing strategy will be handled in the same way as an API change.
Will the privacy budget make web APIs less reliable? Will the APIs I'm using be constrained tomorrow even though I'm within the budget today?
API "cost" = How much of the privacy budget would be spent when a site uses the API.
Since an API's cost would affect its availability, it may effectively become part of the API surface. In this case: when an API's cost would change, the same process as for any other API change would need to be followed (public announcements, appropriate reviews...). Note: an API's cost change may be induced by an API change itself (e.g. if the API, for the sake of enabling more capabilities, accesses more browser information) or in more rare cases by browsers detecting that an API is more identifying than previously evaluated.
How will browser vendors maintain transparency and consistency over the privacy budget's costing strategy?
This is an open question, and it will need to be publicly established in the future. It depends on the approach different browser vendors decide to take.
FAQ Contributors: maudnals, jensenpaul, asankah, bslassey, rowan-m.