CSS property for TSP? about transfer-size

[igrigorik]

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]

@ojanvafai @igrigorik Any thoughts?

[igrigorik]

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]

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.

[jkarlin]

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]

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]

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]

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]

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]

Cascading Style Sheets.

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

[jkarlin]

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.