What is "load time"?

[annevk]

I'm trying to wrap my head around https://wicg.github.io/element-timing/#sec-security and failing.

Is "load time" different from Fetch's timing info's end time somehow?

[npm1]

I think it is different. An image is considered load until it's decoded, right?

[annevk]

Do you mean not considered loaded? I don't think that's necessarily correct. There's decode() for a reason.

Edit: but even then, can you explain the security angle?

[npm1]

Sure, an attacker can already obtain arbitrarily accurate image load times using an image onload handler.

[annevk]

What time can they not get?

[npm1]

The time when the browser paints the image once it's loaded is much harder to obtain. This is why we gate the renderTime on headers.

[annevk]

Okay, so I think my confusion here is with the first two paragraphs in that section only talking about a single timing channel apparently. I thought they tried to talk about a couple of them...

[annevk]

I have to admit I also don't understand the security issue with renderTime or how TAO helps with that.

[npm1]

There is no API today that allows computing renderTime, and allowing arbitrary embedders to compute it may introduce some privacy concerns. For instance, image an image that takes longer to render if the user is logged in vs if it's not. The attacker could then deduce the user logged in state by using renderTime. This is mitigated via TAO headers as in this case the image trusts the embedder and allows it to monitor the timing of such image. Does that make sense? I can expand the section to explain what the issue is.

[annevk]

I guess that's somewhat fair. Though why would decode() not expose that as well?

[npm1]

I'm not very familiar with decode(), but it seems like it might expose that too. We could consider removing the TAO requirement if that API is not going to be removed anytime soon.

[annevk]

I doubt we can remove decode() and I don't immediately see how we'd address this.

@domenic thoughts?

[domenic]

decode() seems fuzzable if there's a security concern, i.e., we could introduce arbitrary delays before the returned promise resolves.

I doubt we could break decode() for non-TAO images to reject, without compat concerns. Although maybe we could implement something like having it always resolve at load time for such images, or always resolve at load time + 100 ms or something like that.