Commit the threat model from #422 #424

jyasskin · 2019-04-24T22:33:59Z

@johnwilander, here's an attempt to make your threat model a little more formal so that we can evaluate a range of attacks and mitigations against it. Did I capture roughly what the WebKit team is thinking? Thanks for engaging!

AdTech and News are specific examples of these.

yoavweiss · 2019-04-26T11:50:34Z

anti-tracking-threat-model.md

+
+## Attacker goals that we want to frustrate
+
+1. The user does not want AdTech to be able to augment its profile of them while


Nit: the points are not written as attacker goals

Indeed. https://increment.com/security/approachable-threat-modeling/ would call these "Invariants", but it's not clear that would be intuitive to random folks reading this. I'll rephrase them.

yoavweiss · 2019-04-26T11:54:16Z

anti-tracking-threat-model.md

+   to the `adtech.example` server. This could be cookies or a user ID encoded in
+   the query, path, or even hostname.
+1. Instead of signing `news.example`'s content directly, AdTech embeds the
+   user's identity in that content and signs the result on the fly.


With Server Timing, we have response headers that are directly readable from JS, so embedding the UID through them might be feasible even without on-the-fly signing. So we need to make sure that the distributor cannot add arbitrary non-signed headers to the internal response, as well as that the external response Server Timing headers are not exposed to the navigated page.
I believe that's already the case, tbh, but IMO it's worthwhile to explicitly note that.

It's a security requirement that the distributor can't add response headers to the post-redirect response. https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#signed-headers mentions that idea, although it's in a section nobody's implementing. The application/signed-exchange format just can't represent such unsigned post-redirect response headers.

I don't think Server-Timing response headers on a 303 response get exposed to the post-redirect javascript. So I'm not sure there's really anything to say here.

yoavweiss · 2019-04-26T11:57:45Z

anti-tracking-threat-model.md

+   aren't sent to the server and would be blocked after the redirect, if
+   necessary, by anti-tracking measures that are independent of web packages.
+1. The path of the package request must be the same as the path on the target
+   domain to prevent the distributor from encoding a user ID in the path.


It also seems like the distributor can use the referrer in order to include a UID (e.g. redirect through a unique path, and have a permissive ReferrerPolicy). Mitigation can be to enforce stricter ReferrerPolicy on redirects or in general.

As I'm saying in #424 (comment), I think we'll need to block that communication route on all redirects, so it's not special to web packages. Do you want me to add a separate attack describing it below?

johnwilander · 2019-04-26T17:03:10Z

anti-tracking-threat-model.md

+# Anti-tracking Threat Model
+
+WebKit and other browsers are trying to reduce websites' ability to track users
+across the internet. While the success of their effort remains to be seen, we


I'd say web rather than Internet since we're talking about web browsers here. I don't think the success of our efforts remains to be seen, and even if it were, this comment comes across as opinionated.

Sorry, removed.

johnwilander · 2019-04-26T17:03:30Z

anti-tracking-threat-model.md

@@ -0,0 +1,196 @@
+# Anti-tracking Threat Model
+
+WebKit and other browsers are trying to reduce websites' ability to track users


browsers –> browser engines

Isn’t this correct as is? For example, Brave shares the same Browser Engine as Edge and Chromium, but represent their own approaches to reduce tracking ability.

WebKit is an engine used in multiple browsers and web rendering applications. If the text should indeed refer to browsers, it should be Safari. But web technologies are mostly about engines.

+1 for being consistent, and I'm happy to follow John's preference to keep this with WebKit and "engines".

johnwilander · 2019-04-26T17:06:45Z

anti-tracking-threat-model.md

+when discussing how to evolve both this threat model and the Web Packaging
+proposals.
+
+Often when we criticize new, technically distinct tracking vectors, we are told


"We" has become confused here. It shouldn't be the same "we" criticizing tracking vectors and "we" are told. I would rewrite this without attribution.

Rewritten. I'm not sure if I've preserved the important bits from your original issue, so please double-check.

johnwilander · 2019-04-26T17:08:57Z

anti-tracking-threat-model.md

+personally identifiable information such as users' email addresses.
+
+Browsers are working hard to prevent cross-site tracking, including with new
+limits and restrictions on old technologies. Web Packaging must not add to that work, although it's acceptable for Web Packaging to prevent tracking only after that other work has been done.


I don't think "that other work" is defined here. The other work is potentially years into the future and I don't think we should indicate that Web Packaging can punt on tracking issues in wait for such "other work."

Indeed. I was trying to get at the idea that we can assume the other changes are done when designing fixes for Web Packaging, but I'm not sure the best way to say that.

For example, if AdTech can convey user IDs through the Referer header, we'll want to strip that header when redirecting cross-origin regardless of the cause of the redirect. The Web Packaging design should be able to assume that's done, rather than adding a special case for just the redirect embedded in the Web Packaging processing model.

Maybe the new text explains that thought better?

johnwilander · 2019-04-26T17:11:07Z

anti-tracking-threat-model.md

+   multi-keyed caches.
+1. AdTech can convince News to give them a `news.example` certificate's private
+   key or to tell a CA that AdTech has permission to receive certificates valid
+   to sign exchanges for `news.example`.


We should add that AdTech can help or convince News to set up a signing service as an alternative to handing over keys. With such a service, AdTech can create the package, calculate its hash, and send the hash over for signing, all on the fly.

Also, we should stick to one term. Currently we mention both certificates and private keys. I think private keys are the most accurate term.

I think there’s value in continuing to separate these concepts.

It would seem that your threat considerations consider the following scenarios:

AdTech creates a private key and obtains a certificate on News’ behalf (e.g. as CDNs commonly do)

News generates the key and then shares with AdTech

News holds the private key, but then signs on AdTech’s behalf (as commonly practiced by CDNs, typically called Split-TLS)

TLS Delegated Creds have a fourth model, where News generates the key, and then authorizes a key for AdTech

These each seem to represent different combinations, with the last being particularly relevant in the discussion of certificates and keys

I've elaborated this section with @sleevi's 4 possibilities. I think they mostly differ in how visible AdTech's misbehavior would be to News, and how long that misbehavior could keep affecting users after News terminated the relationship with AdTech.

I agree that we need to be precise about which of "certificate" or "private key" is correct in each location, but because they mean different things, I don't think we can talk about just one of them. I'm using phrasing that implies that a certificate signs the package, which matches https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req, but strictly a private key (or keypair?) signs the package and the certificate just vouches for the authority of that key. I'm happy to take better wording.

johnwilander · 2019-04-26T17:12:41Z

anti-tracking-threat-model.md

+   1. This link can point to a resource that redirects to `news.example`.
+   1. This link can point to a signed exchange or web package containing
+      content signed by `news.example`'s certificate.
+1. AdTech can make any number of signatures with private keys it controls.


See my comment above on certificates vs private keys.

johnwilander · 2019-04-26T17:14:07Z

anti-tracking-threat-model.md

+1. AdTech convinces News to give AdTech a package-signing certificate for
+   `news.example`, perhaps by offering to handle the technical complications of
+   signing packages.
+   1. Alternately, News could set up a service that signs packages AdTech sends


Here the potential for a service is mentioned. See my comment on this above.

I've rephrased this as a reference to the new wording in Attacker Capabilities and removed the sub-item.

johnwilander · 2019-04-26T17:18:25Z

anti-tracking-threat-model.md

+
+#### Make package loads stateless
+
+When requesting a signed package:


I've only given casual thought to how a webpage can instruct the browser to restrict a load because it is for a signed package. Two ideas: 1) a /.well-known/ location or 2) a special HTTP redirect similar to an upgrade.

I don't think we need to write down all the details in this document, but I'm thinking of:

In https://wicg.github.io/webpackage/loading.html#mp-http-network-or-cache-fetch 20.2, add

httpRequest’s credentials mode is "omit""

httpRequest’s method is GET

etc.

to the constraints on "setting response to httpRequest’s stashed exchange's response."

Add an attribute to <a> tags to let them cause credential-less fetches, and similarly anywhere else we want to enable signed packages that crossorigin isn't sufficient. There may be a more ergonomic way to do this with /.well-known/ or origin policy.

If we wind up thinking this is the right mitigation for this problem, I think we'll propose and discuss the new credentials="omit" mechanism in a separate repository, since it could also be useful independent of web packaging.

jyasskin · 2019-05-01T19:45:20Z

How is this doing as a first draft of the anti-tracking threat model? I'm hoping to send some more PRs digging into the proposed mitigations, but I'd like to have rough agreement on the base first.

martinthomson · 2019-05-10T01:35:37Z

Jeffrey cited this PR in an email, and just reading through the text, I'm confused. Are you really attempting to prevent two cooperating origins from exchanging information?

jyasskin · 2019-05-13T18:56:27Z

My understanding from #422 is that @johnwilander and Safari's ITP2 are indeed trying to prevent two cooperating origins from exchanging information. Specifically, when following a link from AdTech to News, if AdTech can send AdTech's notion of the user's ID to News in any request where News also gets its own notion of the user's ID, then News can remember that association and use it augment AdTech's profile of the user or request user-specific ads from AdTech on all subsequent pages.

There may be limitations on AdTech's ability to get News to cooperate (see "Attacker Non-Capabilities"), but I haven't been able to get a description of those that I believe in.

hayatoito · 2021-12-01T02:04:00Z

It seems I forgot to add a comment to this PR when adding consider-closing label.

[PR Triage]
I'm marking a label of "consider closing" for a PR which has not been active recently.
If there is no activity in a month, we will close PRs tentatively. Thanks!

hayatoito · 2021-12-01T02:04:12Z

Closing.

jyasskin added 11 commits April 24, 2019 10:59

Add an initial anti-tracking threat model from WICG#422.

53db6c2

Formatting.

0d4bd0e

Add generic "distributor" and "publisher" actors.

d209027

AdTech and News are specific examples of these.

Move the overall justification to the top.

7580380

Reword overall justification.

8f75c94

Formalize the threat model.

31f5f9c

Distinguish separate mitigations.

a40a64d

Add the mitigation from WICG#423.

2ce2603

Elaborate the stateless-package-loads mitigation.

7d96c0c

Explain attack and mitigations better.

bb3c806

Sketch 2 more attacks that don't use web packaging.

32627f6

jyasskin mentioned this pull request Apr 24, 2019

Avoiding Built-In Tracking in Signed Packages #422

Open

yoavweiss reviewed Apr 26, 2019

View reviewed changes

johnwilander reviewed Apr 26, 2019

View reviewed changes

Respond to a round of comments.

4aa4813

lidel mentioned this pull request May 3, 2019

Signed/Bundled HTTP Exchanges and WebPackage ipfs/in-web-browsers#121

Open

jyasskin mentioned this pull request May 8, 2019

Design questions for Signed Exchanges w3ctag/design-reviews#354

Closed

3 tasks

jyasskin mentioned this pull request May 13, 2019

Is it OK to let the publishers know the SXG distributor's URL? #433

Open

Base automatically changed from master to main February 17, 2021 00:19

hayatoito added the consider closing label Oct 26, 2021

hayatoito closed this Dec 1, 2021

WICG deleted a comment Mar 2, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Commit the threat model from #422 #424

Commit the threat model from #422 #424

jyasskin commented Apr 24, 2019

yoavweiss Apr 26, 2019

jyasskin Apr 26, 2019

yoavweiss Apr 26, 2019

jyasskin Apr 26, 2019

yoavweiss Apr 26, 2019

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019 •

edited

Loading

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019

sleevi Apr 26, 2019

johnwilander Apr 26, 2019

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019 •

edited

Loading

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019 •

edited

Loading

sleevi Apr 26, 2019

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019

johnwilander Apr 26, 2019

jyasskin Apr 26, 2019

johnwilander Apr 26, 2019

jyasskin Apr 26, 2019

jyasskin commented May 1, 2019

martinthomson commented May 10, 2019

jyasskin commented May 13, 2019

hayatoito commented Dec 1, 2021

hayatoito commented Dec 1, 2021


		## Attacker goals that we want to frustrate

		1. The user does not want AdTech to be able to augment its profile of them while

		@@ -0,0 +1,196 @@
		# Anti-tracking Threat Model

		WebKit and other browsers are trying to reduce websites' ability to track users


		#### Make package loads stateless

		When requesting a signed package:

Commit the threat model from #422 #424

Commit the threat model from #422 #424

Conversation

jyasskin commented Apr 24, 2019

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

johnwilander Apr 26, 2019 • edited Loading

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

johnwilander Apr 26, 2019 • edited Loading

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

johnwilander Apr 26, 2019 • edited Loading

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

jyasskin commented May 1, 2019

martinthomson commented May 10, 2019

jyasskin commented May 13, 2019

hayatoito commented Dec 1, 2021

hayatoito commented Dec 1, 2021

johnwilander Apr 26, 2019 •

edited

Loading

johnwilander Apr 26, 2019 •

edited

Loading

johnwilander Apr 26, 2019 •

edited

Loading