Add Privacy and Security Considerations #142

bvandersloot-mozilla · 2022-12-05T15:30:56Z

Editorial change, deleting the PR template...

Hopefully this represents a good first draft. Aiming to resolve #115.

johannhof

Thanks for giving this a stab, Ben! I had a couple of comments.

I still think we could add some more content in the future, but we shouldn't iterate on this PR forever. So I'm happy to merge once those comments are fixed :)

storage-access.bs

johannhof · 2022-12-09T10:21:07Z

storage-access.bs

@@ -310,17 +310,47 @@ The Storage Access API defines a [=policy-controlled feature=] identified by the

 <h2 id="privacy">Privacy considerations</h2>

-ISSUE: Write this section.
+The Storage Access API is meant able to enable the process of third-party cookie deprecation. Specifically, it enables the authenticated embed use case to continue to work, albeit under further constraints. When evaluating the privacy properties of the Storage Access API it is important to consider the pre-deprecation world of third-party cookies as the baseline. However, we aim to provide strong anti-tracking protections to users, as to not undermine the gains of third-party cookie deprecation.


"the process of" feels a bit unnecessary to me here

johannhof · 2022-12-09T10:21:32Z

storage-access.bs

@@ -310,17 +310,47 @@ The Storage Access API defines a [=policy-controlled feature=] identified by the

 <h2 id="privacy">Privacy considerations</h2>

-ISSUE: Write this section.
+The Storage Access API is meant able to enable the process of third-party cookie deprecation. Specifically, it enables the authenticated embed use case to continue to work, albeit under further constraints. When evaluating the privacy properties of the Storage Access API it is important to consider the pre-deprecation world of third-party cookies as the baseline. However, we aim to provide strong anti-tracking protections to users, as to not undermine the gains of third-party cookie deprecation.


I think we've been calling it "authenticated embeds"

johannhof · 2022-12-09T10:29:15Z

storage-access.bs

@@ -310,17 +310,47 @@ The Storage Access API defines a [=policy-controlled feature=] identified by the

 <h2 id="privacy">Privacy considerations</h2>

-ISSUE: Write this section.
+The Storage Access API is meant able to enable the process of third-party cookie deprecation. Specifically, it enables the authenticated embed use case to continue to work, albeit under further constraints. When evaluating the privacy properties of the Storage Access API it is important to consider the pre-deprecation world of third-party cookies as the baseline. However, we aim to provide strong anti-tracking protections to users, as to not undermine the gains of third-party cookie deprecation.


Gave it a shot at refactoring this sentence a bit :)

Suggested change

The Storage Access API is meant able to enable the process of third-party cookie deprecation. Specifically, it enables the authenticated embed use case to continue to work, albeit under further constraints. When evaluating the privacy properties of the Storage Access API it is important to consider the pre-deprecation world of third-party cookies as the baseline. However, we aim to provide strong anti-tracking protections to users, as to not undermine the gains of third-party cookie deprecation.

The Storage Access API is meant able to enable the deprecation of third-party cookies. Specifically, it allows the authenticated embeds use case to continue to work. As such, the API provides a way for developers to re-gain access to third-party cookies, albeit under further constraints. While that comes with a risk of abuse by third parties for tracking purposes, it is an explicit goal of the API and a key to its design to not undermine the gains of third-party cookie deprecation.

johannhof · 2022-12-12T09:09:30Z

storage-access.bs

-ISSUE: Write this section.
+The Storage Access API is meant able to enable the process of third-party cookie deprecation. Specifically, it enables the authenticated embed use case to continue to work, albeit under further constraints. When evaluating the privacy properties of the Storage Access API it is important to consider the pre-deprecation world of third-party cookies as the baseline. However, we aim to provide strong anti-tracking protections to users, as to not undermine the gains of third-party cookie deprecation.
+
+Importantly, we do not degrade privacy properties when compared to pre-deprecation of third-party cookies. This follows from a lack of platform-specific information used in the spec to prevent stateless tracking and the only state added being a permission scoped to the [=site|sites=] of the embedding and embedded [=Document=].


This is okay for now but it might be better to factor this point out into a separate header, such as "Do not introduce additional cross-site state or fingerprinting surfaces". It might make sense to just create this header even if we just have one paragraph about it.

johannhof · 2022-12-12T09:21:07Z

storage-access.bs

-ISSUE: Write this section.
+It is important that this spec not degrade security properties of the web platform, even when compared to post-deprecation of third-party cookies. Third-party cookie deprecation has potential benefits for security, specifically in mitigating attacks that rely upon authenticated requests, e.g. CSRF. We do not wish the Storage Access API to be a foothold for such attacks to leverage.
+
+To this end, we limit the impact of a "<code>storage-access</code>" permission grant to only give access to [=unpartitioned data=] to the iframe that called {{Document/requestStorageAccess()}} and only until the iframe navigates across an [=url/origin=] boundary. This ensures that only [=url/origin||origins=] with a page that call {{Document/requestStorageAccess()}} will be making credentialed requests, and moreover the embedee page can control which embedder it permits via the Content Security Policy "<code>frame-ancestors</code>" directive. This retains an [=url/origin=]-scoped control for security purposes by the embedee.


Should those origin references just point to [=origin=]?

I get the following error from BS with that:

LINE ~346: Multiple possible 'origin' dfn refs. Arbitrarily chose https://dom.spec.whatwg.org/#concept-document-origin To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block: spec:dom; type:dfn; text:origin spec:fetch; type:dfn; text:origin spec:html; type:dfn; for:/; text:origin spec:html; type:dfn; for:environment settings object; text:origin spec:service-workers; type:dfn; text:origin spec:url; type:dfn; text:origin [=origin=]

Ah, yes, try [=/origin=]

That works perfectly. Thank you for the help with the dark magic of Bikeshed

johannhof · 2022-12-12T09:22:55Z

storage-access.bs

+
+To this end, we limit the impact of a "<code>storage-access</code>" permission grant to only give access to [=unpartitioned data=] to the iframe that called {{Document/requestStorageAccess()}} and only until the iframe navigates across an [=url/origin=] boundary. This ensures that only [=url/origin||origins=] with a page that call {{Document/requestStorageAccess()}} will be making credentialed requests, and moreover the embedee page can control which embedder it permits via the Content Security Policy "<code>frame-ancestors</code>" directive. This retains an [=url/origin=]-scoped control for security purposes by the embedee.
+
+This also is effective at preventing another attack: one on the embedee's reputation. We consider any third-party authenticated request to have potential reputational harm as consumers become more privacy conscious. Therefore a first-party or sibling third-party causing an embedded resource to be requested with the user's authentication cookies would constitute an attack on the reputation of that third-party's owner. This is also a reason we require this API to be used in a [=secure context=]: so a network adversary cannot induce an embedee to use this API.


Should be a separate subsection :)

johannhof · 2022-12-12T09:23:32Z

storage-access.bs

+
+The embedder has control over which iframes have the ability to become authenticated, or even display a permission request to the user via the Permission Policy and iframe sandboxing.
+
+We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This attacks such as re-requesting a permission immediately after the user denies it.


Should be a separate subsection. Again, I think it's fine to just add a header and have this sentence there for future improvement.

johannhof · 2022-12-12T09:24:38Z

storage-access.bs

+
+The embedder has control over which iframes have the ability to become authenticated, or even display a permission request to the user via the Permission Policy and iframe sandboxing.
+
+We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This attacks such as re-requesting a permission immediately after the user denies it.


Should we drop the "we also consider ... to be in-scope"? In scope of what?

Re-worded. I was thinking in-scope of the tradeoffs considered... but that is really confusing and doesn't make much sense.

johannhof · 2022-12-12T09:25:09Z

storage-access.bs

+
+The embedder has control over which iframes have the ability to become authenticated, or even display a permission request to the user via the Permission Policy and iframe sandboxing.
+
+We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This attacks such as re-requesting a permission immediately after the user denies it.


Suggested change

We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This attacks such as re-requesting a permission immediately after the user denies it.

We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This mitigates attacks such as re-requesting a permission immediately after the user denies it.

annevk

I think it's worth thinking about the end state and writing this section from that perspective. I.e., assume cross-site cookie removal happened. And perhaps highlight issues if that hasn't happened yet. Ideally we don't have to rewrite things too much once that has happened everywhere, though removing certain bits seems okay.

annevk · 2022-12-13T16:24:06Z

storage-access.bs

@@ -20,8 +20,6 @@ Complain About: accidental-2119 true

 <!-- File issues on HTML to export each of these -->
 <pre class=link-defaults>
-spec:html; type:dfn; text:session history; url:https://html.spec.whatwg.org/multipage/history.html#session-history
-spec:html; type:dfn; text:current entry; url:https://html.spec.whatwg.org/multipage/history.html#current-entry


storage-access.bs

annevk · 2022-12-13T16:27:01Z

storage-access.bs

@@ -310,17 +310,52 @@ The Storage Access API defines a [=policy-controlled feature=] identified by the

 <h2 id="privacy">Privacy considerations</h2>

-ISSUE: Write this section.
+The Storage Access API is meant able to enable the deprecation of third-party cookies. Specifically, it allows the authenticated embeds use case to continue to work. As such, the API provides a way for developers to re-gain access to third-party cookies, albeit under further constraints. While that comes with a risk of abuse by third parties for tracking purposes, it is an explicit goal of the API and a key to its design to not undermine the gains of third-party cookie deprecation.


"cross-site cookies", right? Avoiding "third party" in the specification is probably a good idea given https://tess.oconnor.cx/2020/10/parties.

Also:

removal, not deprecation

I think it would be good to flush this out a bit with a more worked out example of https://website.example and https://authenticated-widget.example and how cookies end up being impacted here. (And perhaps also stipulate these are the same cookies as you'd get with a direct navigation to the embed?)

annevk · 2022-12-13T16:32:40Z

storage-access.bs

+
+Our privacy considerations are more challenging where default third-party cookies are already deprecated. The challenge is to decide when and how to permit the Storage Access API to be used to revert a cookie-less (or cookie-partitioned) iframe to a pre-deprecation state, giving it access to its [=unpartitioned data=].
+
+In an ideal case, an iframe would only be able to gain access to its [=unpartitioned data=] if:


I think we should talk about a nested document here. "iframe" isn't really a term-of-art and also doesn't hold the authority.

annevk · 2022-12-13T16:34:44Z

storage-access.bs


 <figure id=example-prompt>
 <img src=images/storage-access-prompt.png
     alt="A modal dialog box which states 'Do you want to allow “video.example” to use cookies and website data while browsing “news.example”? This will allow “video.example” to track your activity.' and which has two buttons, “Don’t Allow” and “Allow”.">
 <figcaption>An example prompt which could be shown to the user when a site calls `document.`{{Document/requestStorageAccess()}}.</figcaption>
 </figure>

+Thus, the last two points represent a key point of compromise. We permit [=implementation-defined=] behavior on when to grant or deny requests for [=unpartitioned data=] without requiring user choice so long as they meet all other requirements. This compromise weakens the privacy guarantees of this proposal, specifically point 4, to a degree under the control of the implementer and gives the implementer the power to render it impossible to get storage access with this API. However, this has proven necessary to enable condition 5 to be possible given our implementers' differing stances on the compromise between these two points.
+
+An important avenue for improvement is the removal of the [=implementation-defined=] silent grants and denies. This would improve the developer experience using the API across platforms.


Phrasing this as an encouragement on user agents to do better on this makes more sense to me as well.

Hopefully this represents a good first version. Aiming to resolve privacycg#115.

johannhof

Thanks Ben! I'll merge this, and let's keep iterating on these as needed going forward.

storage-access.bs

johannhof requested changes Dec 12, 2022

View reviewed changes

annevk reviewed Dec 13, 2022

View reviewed changes

bvandersloot-mozilla force-pushed the snp_considerations branch 2 times, most recently from 5bfb791 to 346955b Compare December 14, 2022 13:58

Add Privacy and Security Considerations

5e05619

Hopefully this represents a good first version. Aiming to resolve privacycg#115.

bvandersloot-mozilla force-pushed the snp_considerations branch from 346955b to 5e05619 Compare December 14, 2022 14:01

johannhof approved these changes Dec 14, 2022

View reviewed changes

storage-access.bs Outdated Show resolved Hide resolved

storage-access.bs Outdated Show resolved Hide resolved

johannhof added 2 commits December 14, 2022 15:29

Update storage-access.bs

a4ad823

Update storage-access.bs

d08ac85

johannhof merged commit e411787 into privacycg:main Dec 14, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Privacy and Security Considerations #142

Add Privacy and Security Considerations #142

bvandersloot-mozilla commented Dec 5, 2022 •

edited by pr-preview bot

Loading

johannhof left a comment

johannhof Dec 9, 2022

johannhof Dec 9, 2022

johannhof Dec 9, 2022

johannhof Dec 12, 2022

johannhof Dec 12, 2022

bvandersloot-mozilla Dec 12, 2022

johannhof Dec 12, 2022

bvandersloot-mozilla Dec 12, 2022

johannhof Dec 12, 2022

johannhof Dec 12, 2022

johannhof Dec 12, 2022

bvandersloot-mozilla Dec 12, 2022

johannhof Dec 12, 2022

annevk left a comment

annevk Dec 13, 2022

annevk Dec 13, 2022

annevk Dec 13, 2022

annevk Dec 13, 2022

annevk Dec 13, 2022

johannhof left a comment


		To this end, we limit the impact of a "<code>storage-access</code>" permission grant to only give access to [=unpartitioned data=] to the iframe that called {{Document/requestStorageAccess()}} and only until the iframe navigates across an [=url/origin=] boundary. This ensures that only [=url/origin\|\|origins=] with a page that call {{Document/requestStorageAccess()}} will be making credentialed requests, and moreover the embedee page can control which embedder it permits via the Content Security Policy "<code>frame-ancestors</code>" directive. This retains an [=url/origin=]-scoped control for security purposes by the embedee.

		This also is effective at preventing another attack: one on the embedee's reputation. We consider any third-party authenticated request to have potential reputational harm as consumers become more privacy conscious. Therefore a first-party or sibling third-party causing an embedded resource to be requested with the user's authentication cookies would constitute an attack on the reputation of that third-party's owner. This is also a reason we require this API to be used in a [=secure context=]: so a network adversary cannot induce an embedee to use this API.


		The embedder has control over which iframes have the ability to become authenticated, or even display a permission request to the user via the Permission Policy and iframe sandboxing.

		We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This attacks such as re-requesting a permission immediately after the user denies it.


		Our privacy considerations are more challenging where default third-party cookies are already deprecated. The challenge is to decide when and how to permit the Storage Access API to be used to revert a cookie-less (or cookie-partitioned) iframe to a pre-deprecation state, giving it access to its [=unpartitioned data=].

		In an ideal case, an iframe would only be able to gain access to its [=unpartitioned data=] if:

Add Privacy and Security Considerations #142

Add Privacy and Security Considerations #142

Conversation

bvandersloot-mozilla commented Dec 5, 2022 • edited by pr-preview bot Loading

johannhof left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johannhof left a comment

Choose a reason for hiding this comment

bvandersloot-mozilla commented Dec 5, 2022 •

edited by pr-preview bot

Loading