search

WICG / element-timing

A proposal for an Element Timing specification.
https://wicg.github.io/element-timing/
Other
58 stars 15 forks source link

What is "load time"? #65

Open annevk opened 2 years ago

annevk commented 2 years ago

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 commented 2 years ago

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

annevk commented 2 years ago

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 commented 2 years ago

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

annevk commented 2 years ago

What time can they not get?

npm1 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

npm1 commented 2 years ago

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 commented 2 years ago

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

npm1 commented 2 years ago

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 commented 2 years ago

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

@domenic thoughts?

domenic commented 2 years ago

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.