[whatwg/storage] WebAppsWG TPAC F2F agenda (Fukuoka, Sep 19-20 2019)

[dmurph]

draft topics to talk about during the WebApps WG

Storage Buckets

Problem

TODO Maybe something along the lines of:
Developers have consistently wanted browser-supported ways of evictable storage, where it doesn't 'wake up' the website and just evicts things that the website explicitly wants evictable. Boxes allows this
Also - encryption?

Proposal

Spec: TODO
Tracking: TODO

Storage Corruption

Problem

All browsers must deal with the situation where bits on disk change resulting in corruption. Currently there is no specification of what should be done in these cases leading to each browser creating ad hoc solutions.

Proposal

To improve developer confidence in the platform we should:

1. Provide a mechanism to report storage corruption in a consistent manner to sites.
2. Attempt to standardize possible browser mitigations when corruption is encountered.

Spec: Explainer
Tracking: TODO

Low Disk Space Signal API

Problem

Some operating systems exhibit stability problems when free disk space becomes dangerously low. Web applications that want to offer a good UX need to be aware when the disk space is running low, so they can avoid causing more disk space consumption. We’d like to focus on the following use cases.

1. An application with offline functionality wants to hide the ”Enable Offline” UI for users who are low on disk space.
2. An application that syncs content for offline use wants to stop syncing new content and show a warning when disk space is running low.

We are aware of large Web properties that currently rely on Chrome’s quota reporting API to detect when free disk space is running low. In the future, we (the Chrome team) will change this API’s behavior, and applications will not be able to use it to detect free space.

Proposal

Spec: TODO
Tracking: TODO

A previously proposed approach involved waking up origins so they can reduce their disk usage, and was abandoned due to performance concerns. We would like to propose an approach that only sends low disk signals to origins with active execution contexts.

Storage Quota Behaviors

Problem

TODO

Proposal

Spec: https://github.com/whatwg/storage
Tracking: N/A

We would like to explore a cross-browser consensus on standardizing more behavior around quota.

We are starting by kicking off MDN documentation here that covers all browsers.

[dmurph]

Attaching to w3c/webappswg#10

[annevk]

Thanks @dmurph, these look like good topics to discuss.

cc @asutherland

[wanderview]

The explainer for the storage corruption reporting item is now available here:

https://github.com/wanderview/storage-corruption-reporting/blob/master/explainer.md

[annevk]

Should we have a dedicated thread on corruption? I personally somewhat like the idea of having API-surface around it.

[wanderview]

Should we have a dedicated thread on corruption?

We could. I'm personally a bit unsure how to move forward. In webapps wg we kind of leaned towards not using Reporting API and creating something on StorageManager. Later I spoke with mkwst, though, and he was very disappointed that Reporting API did not meet the needs of reporting these errors and encouraged me to get Reporting API to the point where it could support storage.

[annevk]

Given the use cases discussed reporting could work, but might be less useful than directly exposing it (and exposing control over it).

1. The application would not know which user's storage is corrupted.
2. The application would not be able to decide whether to clear the storage or keep it somehow for investigation.

Reporting could work for the case where you navigate to a document whose origin has corrupted storage, but that only gives you a fairly high-level signal.