--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
If there's any of this that could amount to a spec change, the a GitHub issue is appropriate. But if there's nothing that could be done to mitigate short of not shipping, then yeah, we really need to figure out what the right trade-off is here. This is not my area of expertise, so Ryan and Shubie, could you work together to make sure the right people are aware of this and can advise?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
and knowing which of their 3p resources are using "modern technology" can be useful
Some context on why sites might want this information (as well as other connection oriented info)First of all, wiring up server information is not always practical -- many sites would rely on 3rd party software to measure performance and this software is mostly easily written on the client side. Most sites do not control their CDN and may need to figure out what protocols are used for CDN content or other 3rd party content such as ad networks.
For more sophisticated sites, such as facebook, we want to do more detailed analysis of the reasons why somebody might not use HTTP2 / QUIC / etc. Understanding if an intermediary exists allows us to isolate bugs caused by these intermediaries.
We also want to understand how requests map to physical connections. For example, we had to spend a long time debugging the fact that crossorigin=anonymous resource did not share a socket with resources that did not have that specified. It can also be difficult to determine if a browser is reusing the same socket for multiple domains (based on the DNS being the same).
FWIW, I think that in the vast majority of cases a sophisticated site can determine if the browser is using an intermediary via a combination of fingerprinting headers, ssl properties, and other quirks these intermediaries add. I see this more as a way of helping make this information more definative and easy to use.
Does this sufficiently explain the value of the API? Or should I write a one-pager?
On Thu, Nov 17, 2016 at 10:33 AM, <ben.m...@gmail.com> wrote:Some context on why sites might want this information (as well as other connection oriented info)First of all, wiring up server information is not always practical -- many sites would rely on 3rd party software to measure performance and this software is mostly easily written on the client side. Most sites do not control their CDN and may need to figure out what protocols are used for CDN content or other 3rd party content such as ad networks.So your explicit goal is to find out about the information about other origins' connections? I'm not sure how either 3P software or 3P content come in to play, unless it's tied to cross-origin information.I'm wanting to double check - because it seems like the argument is "While it could be exposed back to the origin, we can't find information about 3P unless 3P tell us, and since 3P don't tell us, it'd be ideal if the browser told us what they're doing with the 3P"
For more sophisticated sites, such as facebook, we want to do more detailed analysis of the reasons why somebody might not use HTTP2 / QUIC / etc. Understanding if an intermediary exists allows us to isolate bugs caused by these intermediaries.So to try to rephrase: Sites should know about the users' personal configuration so that they can debug the users' personal configuration for the user?
We also want to understand how requests map to physical connections. For example, we had to spend a long time debugging the fact that crossorigin=anonymous resource did not share a socket with resources that did not have that specified. It can also be difficult to determine if a browser is reusing the same socket for multiple domains (based on the DNS being the same).This doesn't seem at all related to the discussion - or at least, it's a request for a very different feature?
FWIW, I think that in the vast majority of cases a sophisticated site can determine if the browser is using an intermediary via a combination of fingerprinting headers, ssl properties, and other quirks these intermediaries add. I see this more as a way of helping make this information more definative and easy to use.This seems like a very troubling argument. We know that browsers leak a lot of fingerprinting information - but that doesn't mean we should just give up and expose a unique user ID to every site on every request just because of that.
Vasilii Sukhanov
Software Engineer
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/Hs5-wPpCPZc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
- For QUIC we'll report the empty string (for now): version numbers don't have consistent meaning across browsers; QUIC is not (yet) using TLS1.3 and hence doesn't have valid ALPN mappings. Once both of these are resolved, we can update the implementation to show more details about QUIC.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Currently, Chrome is reporting a non-empty string for QUIC. And once a valid ALPN identifier is defined, we'll report a non-empty string. But in the mean time, we're going to report an empty string?
Can I suggest that we continue reporting the current value until that time?
LGTM3
On Fri, Mar 3, 2017 at 9:16 AM, Chris Harrelson <chri...@chromium.org> wrote:LGTM3Thanks all! Once we resolve the QUIC case above, we'll make it live :-)