Yes, it makes sense to me to threshold/round the underlying quota budget. We already do this to some extent since we cap the limit to 2GiB[1] and we quantize mTemporaryStorageLimit in 10MiB chunks[2]. Because of the 0.2 scaling factor we apply to mTemporaryStorageLimit[1], this means we're exposing a granularity of 2MiB to content, which means there are 1020 discrete values that can be exposed to content if my math is right[3]. The abuse vectors I'm aware of for the `StorageEstimate.quota` (versus `StorageEstimate.usage` which is what https://github.com/whatwg/storage/issues/31 and Bug 1383656 are about) are: 1. The amount of free space on a user's device and values derived from it are a potential fingerprinting vector. 2. Being able to observe changes in the amount of free space at any granularity may provide information about the activity of other programs in the system or the user's actions. Of concern are both the direct values exposed by `StorageEstimate.quota` as well as the ability of an attacker to extract additional entropy by performing actions and observing changes in `StorageEstimate.quota`. Also, we obviously need to be enforcing against the `quota` we claim or an attacker will just attempt to allocate storage to see what the values are. Because QuotaManager already factors in existing QM usage when adjusting the quota limit, the good news is that QM clients can't be used to directly impact the calculation. Also, it's the case that mTemporaryStorageLimit is initialized once at startup and not updated dynamically[4]. This means that using APIs not managed by QM also won't impact the `StorageEstimate.quota` value (which will remain constant until Firefox is restarted). Back to thresholding. Arguably, 2MiB of granularity is more than content needs. Since we do need to be altering the actual quota, our options are: 1. Quantize at a larger chunk-size than our emergent 2MiB value. And perhaps do it explicitly rather than having it by a byproduct of `mTemporaryStorageLimit` being quantized. 2. Move towards a more explicit budget-based mechanism that effectively takes free disk space out of the picture. While we'd probably need a second set of constants for very resource-constrainted devices, one could imagine granting every top-level origin an initial quota of 100MiB and every third-party iframe has an initial quota of 10MiB. APIs like https://wicg.github.io/background-fetch/ would grant explicit additional quota[5]. Other additional quota would need to be procured via other new APIs that allocate discrete storage buckets that can be independently evicted. The latter is a huge change and needs to involve cross-browser discussions about storage buckets, so I think the first option is the only real option at this time. We could certainly round down to the nearest 10MiB. 1: https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/quota/ActorsParent.cpp#5993 2: https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/quota/ActorsParent.cpp#2338 3: `2**31/2**21` => 1024, and it's an inclusive range of [0, 2**31] rather than exclusive so we add 1 to get to 1025. But we min() against 10MB which cuts off [0, 8MiB] = 5 values, leaving us with 1020. 4: https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/quota/ActorsParent.cpp#5877 5: I'm doing some hand-waving here, but Background Fetch explicitly calls for UI that surfaces the download to the user and makes it abortable at https://wicg.github.io/background-fetch/#privacy-and-bandwidth-use. One could imagine effectively treating the downloads like they were explicit storage buckets whose grants could be individually removed. (Practically speaking, we would want API surface related to this, as without actual separate storage buckets and/or some way of alerting the SW that the user wants to delete a downloaded thing, there would be real UX problems if the user thinks they are deleting things but it's really just decreasing the origin's quota until the whole thing gets evicted.)
Bug 1552848 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Yes, it makes sense to me to threshold/round the underlying quota budget. We already do this to some extent since we cap the limit to 2GiB[1] and we quantize mTemporaryStorageLimit in 10MiB chunks[2]. Because of the 0.2 scaling factor we apply to mTemporaryStorageLimit[1], this means we're exposing a granularity of 2MiB to content, which means there are 1020 discrete values that can be exposed to content if my math is right[3]. The abuse vectors I'm aware of for the `StorageEstimate.quota` (versus `StorageEstimate.usage` which is what https://github.com/whatwg/storage/issues/31 and Bug 1383656 are about) are: 1. The amount of free space on a user's device and values derived from it are a potential fingerprinting vector. 2. Being able to observe changes in the amount of free space at any granularity may provide information about the activity of other programs in the system or the user's actions. Of concern are both the direct values exposed by `StorageEstimate.quota` as well as the ability of an attacker to extract additional entropy by performing actions and observing changes in `StorageEstimate.quota`. Also, we obviously need to be enforcing against the `quota` we claim or an attacker will just attempt to allocate storage to see what the values are. Because QuotaManager already factors in existing QM usage when adjusting the quota limit, the good news is that QM clients can't be used to directly impact the calculation. Also, it's the case that mTemporaryStorageLimit is initialized once at startup and not updated dynamically[4]. This means that using APIs not managed by QM also won't impact the `StorageEstimate.quota` value (which will remain constant until Firefox is restarted). Back to thresholding. Arguably, 2MiB of granularity is more than content needs. Since we do need to be altering the actual quota, our options are: 1. Quantize at a larger chunk-size than our emergent 2MiB value. And perhaps do it explicitly rather than having it be a byproduct of `mTemporaryStorageLimit` being quantized. 2. Move towards a more explicit budget-based mechanism that effectively takes free disk space out of the picture. While we'd probably need a second set of constants for very resource-constrainted devices, one could imagine granting every top-level origin an initial quota of 100MiB and every third-party iframe has an initial quota of 10MiB. APIs like https://wicg.github.io/background-fetch/ would grant explicit additional quota[5]. Other additional quota would need to be procured via other new APIs that allocate discrete storage buckets that can be independently evicted. The latter is a huge change and needs to involve cross-browser discussions about storage buckets, so I think the first option is the only real option at this time. We could certainly round down to the nearest 10MiB. 1: https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/quota/ActorsParent.cpp#5993 2: https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/quota/ActorsParent.cpp#2338 3: `2**31/2**21` => 1024, and it's an inclusive range of [0, 2**31] rather than exclusive so we add 1 to get to 1025. But we min() against 10MB which cuts off [0, 8MiB] = 5 values, leaving us with 1020. 4: https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/quota/ActorsParent.cpp#5877 5: I'm doing some hand-waving here, but Background Fetch explicitly calls for UI that surfaces the download to the user and makes it abortable at https://wicg.github.io/background-fetch/#privacy-and-bandwidth-use. One could imagine effectively treating the downloads like they were explicit storage buckets whose grants could be individually removed. (Practically speaking, we would want API surface related to this, as without actual separate storage buckets and/or some way of alerting the SW that the user wants to delete a downloaded thing, there would be real UX problems if the user thinks they are deleting things but it's really just decreasing the origin's quota until the whole thing gets evicted.)