xyaoinum
commented
3 years ago I also want to add that shared storage can be used in 2 scopes: the DOM window scope and the worklet scope, and there are a couple of APIs (setters, getters, runOperation, addModule); some only exists in one scope, and some behaves differently (e.g. the setters always resolve with null in windows scope, but they could reject with explicit reason in worklet scope).
My view: If we worry about fingerprinting: since addModule returns asynchronously, we will likely leak (part of) the permission bit through the timing of addModule regardless. Thus, making the API unavailable seems to be the cleanest solution.
It doesn't feel natural to me to wipe the database if we just disable the setting, unless we explicitly state it. I feel we could provide multiple settings, one for disabling the API and one for clearing the database, etc.
We have filed a bug to add a setting in the Chrome Privacy Sandbox Settings (chrome://settings/privacySandbox) that would toggle whether Shared Storage was enabled or not, so that a user could disable it. But we haven't worked out exactly what it means for Shared Storage to be disabled.
Does this mean that the API is not available? Or that the API is available, but that all promises are rejected? Or that the API is available, promises are resolved and rejected almost as usual, with the caveat that resolved promises are dummy/null values undetectable to the caller?
In any case, when Shared Storage is disabled, we should not actually store data in or read data from the backend database. Probably this database shouldn't exist anymore and should be wiped at the moment that the user disables Shared Storage. We already have prototype code for clearing the Shared Storage database based on user initiation through Site Settings.
If at some point the user re-enables Shared Storage, then the database can be re-created.