Skip to content
This repository has been archived by the owner on Jun 26, 2019. It is now read-only.

CSS property for TSP? #13

Closed
jkarlin opened this issue Aug 16, 2017 · 11 comments
Closed

CSS property for TSP? #13

jkarlin opened this issue Aug 16, 2017 · 11 comments

Comments

@jkarlin
Copy link
Collaborator

jkarlin commented Aug 16, 2017

Let's say you want to enforce a TSP policy only on iframes in a div on your page, even those frames that third-party script inject. How would you do that? You could use the response header and list iframes by origin, but that's rather coarse and might be used outside of the div. It would be really nice if you could use CSS instead, like so:

#divId iframe { max-transfer-size: 100KB }

I'm not a CSS expert, is this crazy talk?

@jkarlin
Copy link
Collaborator Author

jkarlin commented Aug 16, 2017

@ojanvafai @igrigorik Any thoughts?

@igrigorik
Copy link
Member

Wouldn't this make it trivial to circumvent such policy? E.g. if you have top-level script on the page that injects frames, what stops it from injecting just outside your "enforced region"? It seems that if you want the policy to stick against mis-behaving players, you have to enforce it document wide, or isolate them within an isolated sandbox.. at which point you're back to document-wide.

In short, my hunch is that this is both weak and unnecessary?

@jkarlin
Copy link
Collaborator Author

jkarlin commented Aug 29, 2017

An adversarial script could get around it. Presumably you'd expect the third-party script on your page to behave. If you caught it misbehaving you could stop using it, or complain.

For cases where you completely distrust the script, you could use the response-header.

@igrigorik
Copy link
Member

Presumably you'd expect the third-party script on your page to behave. If you caught it misbehaving you could stop using it, or complain.

In practice, neither of those are true.. hence why we're having this discussion. I add a script that adds a script that loads an iframe with a script that loads an iframe coming from fifth party in the chain with super heavy creative. Tracking that down is nearly impossible, since we isolate origins and I can't monitor sizes of arbitrary resources.

Stepping back: I'm sure there is some use case for this functionality.. But, in the spirit of focusing on shipping a v1 MVP, personally I don't think this is critical or necessary. That said, happy to be convinced otherwise. :)

@jkarlin
Copy link
Collaborator Author

jkarlin commented Aug 29, 2017

It's still trivial for a third-party to circumvent the response headers. Just avoid making the frame in the first place, or create a same-origin frame if a frame is necessary.

Ideally the last trusted party in the chain (perhaps the ad server script) should create an x-origin iframe to stuff untrusted code in. If they don't do that (and they usually don't), then there isn't much that can be done today.

@igrigorik
Copy link
Member

It's still trivial for a third-party to circumvent the response headers. Just avoid making the frame in the first place, or create a same-origin frame if a frame is necessary.

Good point.

Coming back to the beginning: I guess this boils do (a) whether selector targeting is critical for the use case, and (b) if CSS is appropriate.. E.g. what stops a page from creating a mutationobserver and applying a policy on the fly as iframes are appended?

@jkarlin
Copy link
Collaborator Author

jkarlin commented Aug 30, 2017

In terms of its criticality for the use-case, it seems far more developer-friendly than response headers. The only place I see an issue with it is if the first party doesn't know where the script wants to insert elements into the dom.

I expect TransferSizePolicy will be set once per frame, when it's created. This is how FeaturePolicy behaves. Can you allow features via FeaturePolicy via mutationobserver or is it too late at that point?

Paging @domenic and @ojanvafai for more input on the idea of setting TransferSizePolicy via CSS.

@igrigorik
Copy link
Member

Re, FP policy: you can set it via a response header as a document wide policy, and you can target individual frames via allow -- see examples... I think we should align with FP capabilities here. /cc @clelland

@clelland
Copy link

FP is definitely immutable once the document has been loaded, by design.

We do have the allow attribute, which sets a 'container policy' for individual frames. I don't know whether extending that attribute, or adding another attribute for TSP would make more sense.

CSS seems totally crazy-talk, BTW. :)

I would just wait for something like

iframe:nth-child(2) {
   max-transfer-size: 100KB;
}

div div span iframe {
  max-transfer-size: 50KB;
}

iframe:hover {
  max-transfer-size: 200KB;
}

a:visited + iframe:target {
  max-transfer-size: 1GB;
}

or similar crazy :)

@coreyworrell
Copy link

coreyworrell commented Sep 1, 2017

Cascading Style Sheets.

What about "max transfer size" equals "style"?

@jkarlin
Copy link
Collaborator Author

jkarlin commented Oct 3, 2017

It's certainly not style. I'm just trying to find the webby way to apply something to a subset of elements on a page, but will stick with response headers for now.

@jkarlin jkarlin closed this as completed Oct 3, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants