省财政厅、教育厅联合印发《广东省城乡义务教育补助经费管理办法》

3. Algorithms

3.1. Parsing

3.1.1. Which data types ought to be removed for response? x

1. If response does not contain a Clear-Site-Data header, return an empty list.

2. Let types be the value of response’s Clear-Site-Data data-type-list component, split on spaces.

3. If types contains a single entry whose value is *:

   1. Append cache, cookies, domStorage, and executionContexts to remove.

   2. Return remove.

4. Let remove be an empty list.

5. For each token in types:

   1. If token is a valid type, append it to to remove.

   2. Otherwise, ignore token.

6. Return remove.

3.1.2. Should subdomains' data be cleared for response

1. Let extensions be the list of response’s Clear-Site-Data extension components.

2. If extensions contains includeSubdomains, return Include Subdomains.

3. Otherwise, return Exclude Subdomains.

3.1.3. Does origin match origin to clear and subdomain state

Given an origin, the origin to clear, and the "include subdomains" flag, return Matches or Does Not Match.

1. If either origin or origin to clear are globally unique identifiers, return Does Not Match.

2. If origin is the same as origin to clear, return Matches.

3. If subdomain state is Exclude Subdomains, return Does Not Match.

4. Let labels to clear be the host component of origin to clear split into labels, and labels be the host component of origin, split into labels.

5. If labels does not have more entries than labels to clear, return Does Not Match.

6. While labels to clear is not empty:

   1. If the final entry of labels to clear does not exactly match the final entry of labels, return Does Not Match.

   2. Remove the final entry of labels to clear, and of labels.

7. Return Matches.

3.2. Clear data for response

Given a response (response), this algorithm parses the Clear-Site-Data header to determine what needs to be cleared, which origins are affected, and then executes those requests.

1. If response’s URL is a priori insecure, skip the remaining steps of this algorithm.

   Some have suggested that this might not be a restriction we want (see Martin Thomson’s public-webappsec post on the topic, for example).

2. Let types be the result of §3.1.1 Which data types ought to be removed for response? executed on response.

3. Let subdomain state be the result of §3.1.2 Should subdomains' data be cleared for response executed on response.

4. Execute §3.4 Clear types for origin with subdomain state on types, response’s url's origin, and subdomain state.

Note: Especially given the cross-context implications, user agents are are encouraged to give web developers some mechanism by which the clearing operation can be debugged. This might take the form of a console message or timeline entry indicating success.

3.3. Clear data for storageRequestOptions

Given a StorageClearOptions (options), this algorithm determines what needs to be cleared, returns a Promise, and executes the request asynchronously.

1. If the incumbent settings object is not a secure context, return a Promise rejected with NotSupportedError.

2. Let promise be a newly created Promise object.

3. Return promise, and execute the remaining steps asynchronously.

4. Let subdomain state be Include Subdomains if options' includeSubdomains property is true, and Exclude Subdomains otherwise.

5. Let types be an empty list.

6. If options' types is an empty sequence:

   1. Append cache, cookies, domStorage, and executionContexts to types.

7. Otherwise, for each StorageClearType type in options' types property:

   1. Append type to types.

8. Execute §3.4 Clear types for origin with subdomain state on types, the incumbent settings object’s origin, and subdomain state.

9. Resolve promise with undefined.

3.4. Clear types for origin with subdomain state

1. If types contains "executionContexts", execute §3.4.1 Neuter browsing contexts matching origin with subdomain state on origin, with subdomain state.

2. If types contains "cookies", execute §3.4.4 Clear cookies for origin with subdomain state on origin, with subdomain state.

3. If types contains "domStorage", execute §3.4.5 Clear DOM-accessible storage for origin with subdomain state on origin, with subdomain state.

4. If types contains "cache", execute §3.4.3 Clear cache for origin with subdomain state on origin, with subdomain state.

5. If types contains "executionContexts", execute §3.4.2 Reload browsing contexts matching origin with subdomain state on origin, with subdomain state.

3.4.1. Neuter browsing contexts matching origin with subdomain state

Given an origin (origin) and a subdomain state of either Include Subdomains or Exclude Subdomains, this algorithm walks through the set of browsing contexts which the user agent knows about, and sandboxes each in order to prevent them from recreating cleared data (from in-memory JavaScript variables, for instance). Once data is cleared, the affected browsing contexts will be hard-reloaded, as defined in §3.4.2 Reload browsing contexts matching origin with subdomain state:

1. For each context in the user agent’s set of browsing contexts:

   1. Let document be context’s active document.

   2. While document is an iframe srcdoc document, let document be the active document of document’s browsing context container.

   3. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on context’s origin, origin, and subdomain state:

      1. Parse a sandboxing directive using the empty string as the input, and document’s active sandboxing flag set as the output.

3.4.2. Reload browsing contexts matching origin with subdomain state

Given an origin (origin) and a subdomain state of either Include Subdomains or Exclude Subdomains, this algorithm walks through the set of browsing contexts which the user agent knows about and reloads each of them:

1. For each context in the user agent’s set of browsing contexts:

   1. Let document be context’s active document.

   2. While document is an iframe srcdoc document, let document be the active document of document’s browsing context container.

   3. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on context’s origin, origin, and subdomain state:

      1. Navigate context to document’s URL with replacement enabled and exceptions enabled. The source browsing context is context. This is a reload-triggered navigation.

3.4.3. Clear cache for origin with subdomain state

Given an origin (origin) and a subdomain state of either Include Subdomains or Exclude Subdomains, this algorithm removes data from the user agent’s local caches that matches the origin and subdomain state.

1. Let host be origin’s host, canonicalized as per Section 5.1.2 of [RFC6265].

2. If subdomain state is Include Subdomains, then let cache list be the set of entries from the network cache whose target URI’s host domain-matches host when canonicalized as per Section 5.1.2 of [RFC6265]

3. Otherwise, subdomain state is Exclude Subdomains, so let cache list be the set of entries from the network cache whose target URI host is identical to host when canonicalized as per Section 5.1.2 or [RFC6265].

4. Remove each entry in cache list from the network cache.

5. If a user agent implements caches beyond a pure network cache, it MUST remove all entries from those caches which match origin and subdomain state.

   We’re dealing with the network cache here, as defined in [RFC7234], but that’s not nearly everything a user agent caches. How hand-wavey with the vendor-specific section can we be? For instance, Chrome clears out prerendered pages, script caches, WebGL shader caches, WebRTC bits and pieces, address bar suggestion caches, various networking bits that aren’t representations (HSTS/HPKP, SCDH, etc.). Perhaps [STORAGE] will make this clearer?

3.4.4. Clear cookies for origin with subdomain state

Given an origin (origin) and a subdomain state of either Include Subdomains or Exclude Subdomains, this algorithm removes cookies from the user agent’s cookie store whose domain attribute matches the origin and subdomain state.

Note: This algorithm assumes that the user agent has implemented a cookie store (as discussed in Section 5.3 of [RFC6265]), which offers the ability to retrieve a list of cookies by host, and to remove individual cookies.

1. Let host be origin’s host, canonicalized as per Section 5.1.2 of [RFC6265].

2. If subdomain state is Include Subdomains, then let cookie list be the set of cookies from the cookie store whose domain attribute is domain-matched by host.

   Note: The direction of the matching is important. If subdomain.example.com delivers the Clear-Site-Data header and includes subdomains, then cookies for .another.subdomain.example.com will be cleared, but cookies for .example.com will not.

3. Otherwise, subdomain state is Exclude Subdomains, so let cookie list be the set of cookies from the cookie store whose domain attribute is identical to host.

4. Remove each cookie in cookie list from the cookie store.

3.4.5. Clear DOM-accessible storage for origin with subdomain state

1. For each area in the user agent’s set of local storage areas [HTML]:

   1. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on area’s origin, origin, and subdomain state:

      1. Execute clear() on the Storage object associated with area.

2. For each area in the user agent’s set of session storage areas [HTML]:

   1. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on area’s origin, origin, and subdomain state:

      1. Execute clear() on the Storage object associated with area.

3. For each database in the user agent’s set of Indexed Databases [INDEXEDDB]:

   1. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on database’s origin, origin, and subdomain state:

      1. Set database’s delete pending flag to true.

      2. For each connection in the set of all IDBDatabase objects connected to database:

         1. Execute the database closing steps on connection.

      3. Execute the database deletion steps on database, passing in database’s origin and name.

4. For each database in the user agent’s set of WebSQL databases [WEBDATABASE]:

   1. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on database’s origin, origin, and subdomain state:

      1. Delete database.

         The [WEBDATABASE] spec is fairly unhelpful here with regard to deletion details.

5. For each registration in the user agent’s set of registered service worker registrations:

   1. If §3.1.3 Does origin match origin to clear and subdomain state returns Matches when executed on registration’s scope URL’s origin, origin, and subdomain state:

      1. Execute unregister() on registration.

We still need to spell out Filesystems, Dedicated Workers, Shared Workers, etc. (This isn’t an exhaustive list. We should fix that too.)

How do we say something about plugins here? Point out to NPP_ClearSiteData?

4. Privacy Considerations

4.1. Web developers control the timing.

If triggered at appropriate times, Clear-Site-Data can increase a user’s privacy and security by clearing sensitive data from their user agent. However, note that the web developer (and not the user) is in control of when the clearing event is triggered. Even assuming a non-malicious site author, users can’t rely on data being cleared at any particular point, nor are users in control of what data types are cleared.

If a user wishes to ensure that site data is indeed cleared at some specific point, they ought to rely on the data-clearing functionality offered by their user agent.

At a bare minimum, user agents OUGHT TO (in the [RFC6919] sense of the words) offer the same functionality to users that they offer to web developers. Ideally, they will offer significantly more than we can offer at a platform level (clearing browsing history, for example).

4.2. Remnants of data on disk.

While Clear-Site-Data triggers a clearing event in a user’s agent, it is difficult to make promises about the state of a user’s disk after a clearing event takes place. In particular, note that it is up to the user agent to ensure that all traces of a site’s date is actually removed from disk, which can be a herculean task (consider virtual memory, as a good example of a larger issue).

In short, most user agents implement data clearing as "best effort", but can’t promise an exhaustive wipe.

If a user wishes to ensure that site data does not remain on disk, the best way to do so is to use a browsing mode that promises not to intentionally write data to disk (Chrome’s "Incognito", Internet Explorer’s "InPrivate", etc). These modes will do a better job of keeping data off disk, but are still subject to a number of limitations at the edges.

5. IANA Considerations

The permanent message header field registry should be updated with the following registration: [RFC3864]

5.1. Clear-Site-Data

Header field name

Clear-Site-Data

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See §2.1 The Clear-Site-Data HTTP Response Header Field)