Should navigator.storage.estimate() be available on insecure contexts?

[michael-nordman]

Limiting persist() and persisted() to secure sites makes sense, but given that some storage apis are available on insecure sites would it make sense to enable estimate() for http?

[annevk]

I'd rather we did not do that. It adds complexity and HTTP is meant to go away anyway. It's also a fingerprinting vector.

[sicking]

Under the condition that we're already exposing the UA-string, what type of fingerprinting can be done using .estimate()?

[annevk]

Device storage characteristics?

[sicking]

Could you expand on that? Or provide an example even?

[annevk]

Different devices will have a different total estimate. This could also widely vary even if the user agent is the same, if it's some kind of percentage game, or if the user agent generally allows each website to use a very large storage amount and then quickly throws them out when some other site becomes more dominant.

[sicking]

Ah, I forgot that .estimate() returns the quota. That does indeed expose some amount of fingerprinting. If we were to just expose the usage that would not enable any fingerprinting as far as I can see.

I'm personally not particularly opinionated if it's more important to hide fingerprinting bits from http websites than from https websites.

[inexorabletash]

ISTM we should launch with this restricted to secure contexts and revisit based on feedback. Chrome has a webkit-prefixed API for querying quota that works in non-secure contexts but that isn't exposed to Service Workers. If/when we deprecate the prefixed one we'll get usage statistics and get feedback.

[annevk]

Sounds good to me. Feel free to reopen when that happens.