- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Tue, 08 Feb 2022 10:05:58 -0800
- To: whatwg/storage <storage@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 8 February 2022 18:06:11 UTC
@mkruisselbrink commented on this pull request. > @@ -203,6 +203,16 @@ anticipated that some APIs will be applicable to both <a>storage types</a> going <p class=XXX>This is expected to change; see <a href="https://privacycg.github.io/storage-partitioning/">Client-Side Storage Partitioning</a>. +<p>To <dfn export>obtain a storage key for non-storage purposes</dfn>, given an <a>environment +settings object</a> <var>environment</var>, run these steps: + +<ol> + <li><p>Let <var>key</var> be <var>environment</var>'s + <a for="environment settings object">origin</a>. > Now if site is an opaque origin the algorithm below will need to return failure as well. Off-topic for this PR, but I don't think we (Chrome) are currently planning to block storage in an embedded iframe merely because the top-level site has an opaque origin (i.e. as long as origin isn't opaque, the opaqueness of the site shouldn't matter). -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/storage/pull/132#discussion_r801919521 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/storage/pull/132/review/876452710@github.com>
Received on Tuesday, 8 February 2022 18:06:11 UTC