Re: [spec-reviews] Storage persistence (#85)

As a minimal subset of the Storage API, this looks good. A few questions:

 - these APIs look good, particularly as they don't put any constraints on browsers about UI and actual decisions about storage
 - would like to see a callout to the [TAG finding on Unsanctioned User Tracking and positive user controls](https://www.w3.org/2001/tag/doc/unsanctioned-tracking/#findings) so that implementers understand that they need to allow users control over this.
 - what is the reflection of the `persistentPermission()` in the [Permissions API](https://w3c.github.io/permissions/#permission-registry)? If there isn't one, I'd like to see it proposed soon.
 - the text in the Storage spec around quota is...odd? It doesn't seem to relate in any way to existing Quota drafts and proposes a whole set of box-specialized methods (`estimate()` and `persistentEstimate()`) without any sort of explainer or example code to illustrate how they'd work in common scenarios which developers encounter. Which brings us to...
 - ...this spec doesn't have an explainer and a single example which covers almost none of the draft feature capability. This is a red flag.

As Chrome is only interested in `requestPersistent()` and `persistentPermission()` for now, the rest of the spec seems out of scope for this request and not controversial, but we'd like to be informed if implementers are considering the rest as it raises many concerns.

/cc @kinu @inexorabletrash @khuey @travisleithead 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/85#issuecomment-171486711