Re: Requesting privacy review of IndexedDB API

On 07/11/2016 13:03, Léonie Watson wrote:
> Hello privacy people,
Hello again, and belated happy NY.

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

> 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.

We didn't hear from you, so we'll be moving this spec forward on the 
assumption that all is ok from the privacy point of view. Please do let 
me know if it is otherwise. Thanks.

Léonie.



>
> 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.
>

Received on Friday, 13 January 2017 14:07:28 UTC