Requesting privacy review of IndexedDB API

Hello privacy people,

The WebPlat WG would like to request a privacy review of the IndexedDB 
API specification [1].

We have completed the privacy and security questionnaire. Answers at the 
end of this email.

Please could you file your comments as Github issues [2]. An email 
summary to public-webapps@w3.org
  is welcome, but the editors focus on Github for issue tracking.

If it is possible for you to complete the review by 8th January 2017, we 
would appreciate it. If this does not give you enough time, please let 
me know.

Thanks.
Léonie on behalf of the WebPlat chairs & IndexedDB editors

  [1] https://www.w3.org/TR/IndexedDB-2/
[2] https://github.com/w3c/IndexedDB/issues/

Questionnaire responses...

3.1 Does this specification deal with personally-identifiable information?
No.

3.2 Does this specification deal with high-value data?
No.

3.3 Does this specification introduce new state for an origin that 
persists across browsing sessions?
Yes - it defines a storage API, equivalent in persistence behavior to 
Web Storage's localStorage API.

3.4 Does this specification expose persistent, cross-origin state to the 
web?
Through the use of quota probing (e.g. store data incrementally until 
QuotaExceededErrors are returned) it may be possible to estimate the 
amount of storage
available on the device, depending on the heuristics the user agent uses 
to allocate quota to storage APIs and origins. If the storage amount is 
stable
it could be used for fingerprinting. This can be mitigated by decreasing 
entropy (e.g. binning values to make it more difficult to distinguish 
users).

3.5 Does this specification expose any other data to an origin that it 
doesn’t currently have access to?
No.
As an aside, Indexed DB does not currently allow the storage of Response 
objects (opaque or otherwise) since they are not currently "structured 
cloneable".
Therefore, storage quota side-channel attacks against cross origin data 
that affect the Cache API (from Service Worker spec) do not apply; see
https://tom.vg/2016/08/request-and-conquer/
  for more details.

3.6 Does this specification enable new script execution/loading mechanisms?
No.

3.7 Does this specification allow an origin access to a user’s location?
No.

3.8 Does this specification allow an origin access to sensors on a 
user’s device?
No.

3.9 Does this specification allow an origin access to aspects of a 
user’s local computing environment?
No.

3.10 Does this specification allow an origin access to other devices?
No.

3.11 Does this specification allow an origin some measure of control 
over a user agent’s native UI?
No.

3.12 Does this specification expose temporary identifiers to the web?
No.

3.13 Does this specification distinguish between behavior in first-party 
and third-party contexts?
The specification allows user agents to restrict access to the database 
objects to scripts originating at the domain of the top-level document 
of the browsing
context, for instance denying access to the API for pages from other 
domains running in iframes.
(Called out in Privacy/User tracking section)

3.14 How should this specification work in the context of a user agent’s 
"incognito" mode?
Browsers may implement an "memory-backed" store rather than 
"disk-backed" store in incognito/private browsing mode. This allows the 
feature to exist and
function in such a mode.
Note that probing through timing (RAM is usually faster than disk) or 
quota (memory may be more limited than disk) it may be possible to 
distinguish this
approach; this potentially affects all storage APIs.

3.15 Does this specification persist data to a user’s local device?
Yes. "Clear browsing data" for an origin must remove all Indexed DB data 
for the origin (all databases, and all data and metadata within those 
databases).

3.16 Does this specification have a "Security Considerations" and 
"Privacy Considerations" section?
Yes.

3.17 Does this specification allow downgrading default security 
characteristics?
No.

-- 
@LeonieWatson tink.uk Carpe diem

Received on Monday, 7 November 2016 13:04:24 UTC