Partially addresses Issue 275

[mfoltzgoogle]

This PR implements parts of the resolution for Issue #275: User Data Controls in Web Browsers guidelines. It also updates the list of site data to reflect implementation status in the receiving user agent.

The parts remaining to be done include:

• Add a non-normative link to a reference list of site data when available.
• Add some text for Web Workers and Service Workers. I would like to give this some more thought and possibly punt to separate issue.

[tidoust]

Typo: drop "and"

[mfoltzgoogle]

Addressed comments by @tidoust. Note that PERMISSIONS is a Working Draft, so it may need to be converted back to an informative reference (and the algorithm updated), depending on the outcome of #295.

[tidoust]

In the note, instead of "The receiving browsing context", I would rather use "This algorithm" (or "These steps").

Also, readers won't have the full context of WG discussions, and "private browsing session" comes a bit out of the blue here. I would simply strike that part and simply assert the intent.

Where do we say that navigation is not allowed in a receiving browsing context? The auxiliary navigation browsing context flag merely prevents the creation of additional browsing contexts, for instance. What the spec rather says is that the receiving user agent must terminate the presentation in case of navigation.

All in all, I would simplify the note to:

<p class="note">  
  This algorithm is intended to create a well defined environment to allow interoperable behavior for 1-UA and 2-UA presentations.
</p>  

[tidoust]

Thanks @mfoltzgoogle. See additional comment on the note. The pull request looks good to me otherwise.

Not directly related to this pull request, but re-reading the algorithm, I think it does not really achieve what we'd like it to do. My understanding is that we'd like the user agent to create or use dedicated storages in the 1UA case. However:

1. The notion of dedicated storages (per browsing context) or even the notion of storage per se may not exist in the specs that are referenced. More precisely:
   1. There is only one cookie store per user agent in the cookies RFC, not one per browsing context. "Set the cookie store for C to an empty cookie store" does not mean much and implies emptying the cookie store of the controlling side as well in the 1UA case.
   2. IndexedDB databases are per origin, not per browsing context. "Set the IndexedDB databases for C to an empty set of databases" does not mean much and could be interpreted as requiring user agents to drop the contents of IndexedDB databases for all future connections, even those coming from regular (non receiving) browsing contexts. There is no notion of a storage that contains all IndexedDB databases in the IndexedDB spec.
   3. Unless I missed something, the HTML spec implicitly assumes that there is but one storage place for application caches. It does not explicitly define a term for that storage.
   4. Same thing for HTTP authentication state, where our goal is only to reset data for this browsing context, not for all browsing contexts.
2. Some properties are set by relevant algorithms during navigation, e.g. when the Document is created. Setting them to some empty storage beforehand won't do much, unless we also explicitly say that navigation should not affect these properties. Typically:
   1. sessionStorage and localStorage are set when the Document is created, which happens during navigation, c.f. two paragraphs below: http://www.w3.org/TR/webstorage/#dom-sessionstorage
   2. the application cache is selected during navigation or when the HTML document is parsed, c.f. one line below: http://www.w3.org/TR/html5/browsers.html#cache-host

Perhaps we can assume that the notion of storage is straightforward to grasp and tell the user agent to create new empty storages for the receiving browsing context in all cases, as in:

<ol>
  <li>Create a new <a>top-level browsing context</a> <var>C</var>,
  set to display content on <var>D</var>.</li>
  <li>Set the <a>session history</a> of <var>C</var> to be the empty
  list.</li>
  <li>Set the <a>sandboxed auxiliary navigation browsing context
  flag</a> on <var>C</var>.</li>
  <li>Create a new empty <a>cookie store</a> for <var>C</var>.</li>
  <li>Create a new empty store for <var>C</var> to hold
  <a>HTTP authentication</a> states.</li>
  <li>Create a new empty <a>application cache</a> storage for <var>C</var>.</li>
  <li>If the <a>receiving user agent</a> implements [[!PERMISSIONS]],
  set the <a>permission state</a> of all <a>Permissions</a> for <var>
    C</var> to <code>"denied"</code>.</li>
  <li>If the <a>receiving user agent</a> implements [[!INDEXEDDB]],
  create a new empty storage for IndexedDB <a>databases</a> for <var>C</var>.</li>
  <li>If the <a>receiving user agent</a> implements [[!WEBSTORAGE]],
  create a new empty storage for session storage areas and local storage
  areas for <var>C</var>.</li>
  <li><a>Navigate</a> <var>C</var> to <var>presentationUrl</var>.</li>
  <li>Start <a>monitoring incoming presentation connections</a> for
  <var>C</var> with <var>presentationId</var>.</li>
</ol>

I don't find that entirely satisfactory though. Any better idea?

[anssiko]

@tidoust's proposed text looks pretty good to me (copy-paste-able proposals in HTML are nice :-)).

@mfoltzgoogle, given no concerns in 12 days after the @tidoust's proposal was aired, I suggest you update the PR with #308 (comment) and merge (after rebase & resolve merge conflicts).

[anssiko]

To clarify, @tidoust noted Service Workers-provided dedicated storage (the Cache interface, any others?) is the only remaining unaddressed part in this PR.

To not block CR on the Service Workers considerations, we can note that in the SoTD as a WIP issue, unless we address this soon.

[mfoltzgoogle]

I'm okay with the text suggested by @tidoust in #308 (comment) and #308 (comment). I think it's the best that can be done given the specs we are referring to here, and vendors will have to interpret the spirit of the spec going forward as new storage APIs get deployed.

[mfoltzgoogle]

Adopted proposals from @tidoust with some minor edits to define local storage and session storage areas. Merging.