Re: [whatwg/storage] Moving text from HTML's web storage into the Storage Standard (#95)

Sorry for the delay here!

(FWIW, tracking multiple points across multiple replies has been difficult for me. Thank you @annevk for introducing a numbering scheme!)

1. Eviction unit: I think that "Whenever a storage bucket is cleared by the user agent, it must be cleared in its entirety." (from #93) says that the smallest unit of eviction is the bucket. This matches Chrome's perspective -- we think that more fine-grained eviction wouldn't be Web-compatible, and bucket-scoped eviction is Web-compatible. IOW, we think that the current phrasing is the most permissive we can get away with, and we like that.

2. Total quota restrictions: Chrome agrees with #108 in that it's not currently safe to expose the amount of free space to applications. We think that web applications should not be more restricted than native applications, so we're happy with the current recommendation that total quota should be less than the total disk space. We don't see a good reason to be more restrictive.

3. Per-origin / per-site quota restrictions: We don't have a good answer here. (I think that sharing quota usage across origins (even in the same site / eTLD+1 / whatever) would go against the Same Origin Policy, as it would allow an origin to learn information about another origin. At the same time, I think that having per-eTLD+1 quota would be attractive.) We don't see a good reason for the specification to say that implementations "should" mitigate a problem, given that we haven't found a solid mitigation yet. I think we should acknowledge this as an open problem in a spec issue.

4. Prompts for quota increase: Chrome UX currently thinks that there is no good way to get an informed user decision on increasing quota via a prompt -- we haven't found a message that we'd be happy with. Therefore, we are not prompting, and don't have any plans to implement prompting. We are not opposed to leaving room in the spec for other implementations to prompt -- some experimentation might be good here. From a different angle, all storage APIs with non-trivial quotas are async, so browsers can theoretically prompt at any point. We don't see a good reason to prohibit that behavior in a spec. 

5. Storage management UI: Chrome currently happens to meet the requirement that "User agents should allow users to see how much space each *domain* is using." That being said, *domain* seems overly specific -- I don't have a good understanding of why "domain" is better than "origin", or "host", or "(first-party origin, third-party origin)". Chrome is not willing to commit to following this recommendation in the future. I think that the golden age of Web storage is yet to come, so I don't think we have the experience to be prescriptive around the right granularity for a storage management UI.

6. Measuring quota usage: Chrome currently measures the space used by the underlying storage implementation. This isn't even guaranteed to be consistent across Chrome versions, as we may switch between internal representations, adopt better compression, etc. We think the spec should currently document this reality -- usage is implementation-specific. At the same time, we recognize the benefits of achieving interoperability here -- we received many developer complaints about the lack of predictability in this area. We would be willing to invest in a predictable, cross-browser quota measurement system, if the other engines would be likely to adopt it as well. This would be a significant undertaking for us, and it's only worthwhile if we achieve cross-browser interop.

I tried to separate clear Chrome position (Chrome / we) from the parts that may only represent personal opinion (I). Sorry for the shifts in voice resulting from this. Please don't hesitate to ask follow-up questions if my answers are not clear, or if I misunderstood the points being discussed here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/95#issuecomment-656555686

Received on Friday, 10 July 2020 08:30:54 UTC