search

w3c / resource-timing

Resource Timing
https://w3c.github.io/resource-timing/
Other
119 stars 35 forks source link

Access to the Remote Address information #180

Open gui-poa opened 5 years ago

gui-poa commented 5 years ago

I had a conversation with @yoavweiss a few weeks ago and we decided to bring it here.

It would be great to have access to the resource's remote address (IP) information by the API. Currently it's only possible to know through the devtools. image

Use case: It will be possible, by RUM, to know if the POP choosed to deliver the resource was the best choice for each user. (if isn't a multicast)

Even for third parties domain, I believe a new header could give access, how was thought with Allow-Timing-Origin.

What do you think?

igrigorik commented 5 years ago

We need security folks to chime in on this one. I believe one potential side effect here is that this information would expose users behind HTTP proxies: the UA would see and report cache/proxy IP address.

Alternatively, this use case can be addressed today via Server-Timing: the POP can emit relevant metadata through ST header to help identify which POP+route was chosen, whether there was a cache hit, and more.

gui-poa commented 5 years ago

The problem with the solution via Server Timing is that you should have access to the origin of the resource to add the header and this IP will not be the same as the POP.

The other way is the POP to add the header, but this connection should not be HTTPS.

igrigorik commented 5 years ago

Yes, the edge node would need to emit the Server-Timing header.

Practically speaking, if we're talking CDN use cases, you're talking about caching in addition to early termination, and as a result they're already hosting a cert for you / on your behalf. Which means they see the unencrypted response and can append the header — e.g. Akamai writeup.

gui-poa commented 5 years ago

Thanks, Ilya! Good to know this writeup from akamai.

I appreciate if any security folks could help here too.