element-timing icon indicating copy to clipboard operation
element-timing copied to clipboard

What is "load time"?

Open annevk opened this issue 4 years ago • 13 comments

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?

annevk avatar Oct 22 '21 12:10 annevk

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

npm1 avatar Oct 25 '21 14:10 npm1

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?

annevk avatar Oct 25 '21 14:10 annevk

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

npm1 avatar Oct 25 '21 15:10 npm1

What time can they not get?

annevk avatar Oct 25 '21 15:10 annevk

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.

npm1 avatar Oct 25 '21 15:10 npm1

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 avatar Oct 25 '21 15:10 annevk

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

annevk avatar Oct 25 '21 15:10 annevk

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.

npm1 avatar Oct 25 '21 15:10 npm1

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

annevk avatar Oct 25 '21 15:10 annevk

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.

npm1 avatar Oct 25 '21 17:10 npm1

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

@domenic thoughts?

annevk avatar Oct 25 '21 18:10 annevk

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.

domenic avatar Oct 25 '21 19:10 domenic