Intent to Implement and Ship nextHopProtocol (in Resource Timing)

[Shubhie Panicker]

Contact emails

pani...@chromium.org, sun...@chromium.org, igri...@chromium.org

Spec

https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-nexthopprotocol

Summary

nextHopProtocol returns the network protocol used to fetch the resource (as identified by the ALPN Protocol ID (RFC).

nextHopProtocol will be determined based on ALPN (and connection info). For details see:

https://docs.google.com/document/d/1qcpmh4K9yhGiJGduo5M71PLepKsyRHilvvZkQfz0880/edit

Motivation

The network protocol information is useful to monitor as RUM (real user measurement) API.

It is actively used in the non-standardized chrome.loadtimes API (fields: connectionInfo, npnNegotiatedProtocol, wasNpnNegotiated) and we want to deprecate chrome.loadtimes API in the future.

Interoperability and Compatibility Risk

Low. 

However there is the following consideration covered in the proposal:

when the transport is QUIC, we’d like to indicate this in nextHopProtocol even though IETF has not made a determination yet.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=663175

Requesting approval to ship?

Yes.

[ben.m...@gmail.com]

One thing that's a bit unclear about this spec is how it would handle cached loads. Would it return the nextHop for the original fetch or would it return a value like "cache". FWIW at FB we're already differentiating cache via transfer_size = 0.

[Ilya Grigorik]

That's a good catch Ben. I agree, we should clarify this in the spec. 

Opened: https://github.com/w3c/resource-timing/issues/73 - let's take the discussion there and we can followup on this thread once that's resolved.

[Philip Jägenstedt]

This didn't end up in https://bit.ly/blinkintents because of a missing colon, I've added it now. Strict parsing like it's 1999 :)

The spec says "as identified by the ALPN Protocol ID [RFC7301]" but which bit of https://tools.ietf.org/html/rfc7301 should one be looking at to understand what kinds of strings these are?

The doc says to make certain conversions for QUIC, but masking SPDY seems a bit odd. Are you concerned that people could somehow come to depend on SPDY being truthfully reported, so that removing SPDY support becomes more difficult?

Also, what kinds of determination are you counting on the IETF to make? If they make the "wrong" determination, what compat risk would we face in trying to change to adapt?

[Bence Béky]

Hi Philip,

I'm working with Shubhie, Jian, and Ilya on this, doing some of the backend work in the network stack to surface the protocol string, so I might be able to answer some of the questions.  I hope they will correct me if I'm mistaken.

RFC 7301 defines an IANA entry for ALPN, and defines the strings "http/1.1", "spdy/1", "spdy/2", and "spdy/3".  The first one is indeed reported by nextHopProtocol when HTTP/1.1 is used.  SPDY major versions 1, 2, and 3 are all removed from Chromium, so these strings should never show up, but they did until very recently in the form of "quic/1+spdy/3".

RFC 7540 defines the ALPN string "h2" for HTTP/2, and that is the value of nextHopProtocol in case HTTP/2 over TCP is used.

QUIC is has its own crypto handshake, it does not use ALPN, and therefore there was no need to define an ALPN string for it so far, although there was some discussion at IETF about defining ALPN strings for purposes other than protocol negotiation.  It does not seem to be clear at this point of ALPN strings will ever be defined for QUIC.

Philip: You are asking about masking SPDY.  Any string "spdy/1" or "spdy/3" produced by Chromium network stack is out of date, because these SPDY versions are not supported any more.  The logic to remove such strings is there to work around these outdated strings, and it can soon be removed.  Also, there is no other version or flavor of SPDY that we plan to remove from the network stack in the foreseeable future.  Instead, the intention here is to report the protocol as truthfully as possible.

I hope this answers some of your questions.  Cheers,

Bence

[Philip Jägenstedt]

OK, it sounds like the SPDY things are internal considerations only, it has nothing to do with pretending that one protocol is another.

For QUIC then, does any spec define the strings that you intend to return, and is there any active debate about those? I'm trying to gauge the risk of shipping with some string format, and the specs and other implementation taking a different turn. It sounded from "even though IETF has not made a determination yet" that there is such a risk. If so, the most important thing, I'd say, is getting buy-in from other vendors who might ship this. And having shared tests to lock down the behavior, if at all practical.

[Shubhie Panicker]

Thanks, Philip.

We will run this by other vendors, and loop back.

--
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.

[rsl...@chromium.org]

Would it be better to discuss here or on the GitHub?

I'm hoping that someone could explain more the value proposition of the nextHopProtocol versus the privacy risk.

There are two types of connections: Those without intermediaries, and those with. For the connections without intermediaries, the receiving server already knows the nextHopProtocol, and can always echo that back to the client if it's useful/valuable. For connections with intermediaries - whether it be locally installed intermediaries (e.g. antivirus), enterprise mandated intermediaries (e.g. DLP), or server-supported intermediaries (e.g. a CDN) - it seems that there's a privacy risk, in that this provides new information that the receiving server would otherwise not have access to.

This is similar to the discussion in https://groups.google.com/a/chromium.org/d/msg/net-dev/guHBb7J4OMc/pHS_OddqAwAJ about revealing on-path information, and has come up when doing privacy reviews of other features, like Navigation Error Logging (e.g. https://chromium.googlesource.com/chromium/src.git/+/563dc47699901e4c54b1b2121262c679fb355d72 ).

It seems like it'd be useful to

1) See an explainer for why this is useful to add as part of the platform (given the compat risks we see, e.g. with QUIC) and the existing availability to the server (via it's own observation of the negotiated platform)

2) Ensure we have a consistent privacy story around whether or not it's suitable to reveal the fact that there may be on-path intermediaries.

I know #2 is a bit controversial - from a personal standpoint, I can't stand such intermediaries, because they cause significant pain to the ecosystem, but it seems like we're going to be revealing more information about the user and their network configuration that would otherwise not be accessible, and that's at least meaningful to evaluate whether we have a consistent story around that - for RT, for NEL, and for any other features that may come up in between.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

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?

[Ryan Sleevi]

On Wed, Nov 16, 2016 at 2:13 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

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?

That's the problem - I'm not sure who the 'right people' are to decide Chromium philosophy on revealing information about on-path intermediaries. That sounds like it's related to Chrome's privacy team, but that only succeeds well if Blink API OWNERs (and our feedback to the TAG) are kept in sync with that, and it may be that other Blink-based vendors feel differently on privacy grounds.

To put a different spin on it: What would not otherwise be possible if we didn't ship this? That is, what's the explainer for the feature, other than it reflected something Chrome happened to expose via a vendored-extension? If the ability for the server to get this information is already available (via the server examining the ALPN string it negotiates), then shouldn't there be a relatively high bar for exposing it in the platform simply from first principles, independent of where the privacy concerns land? I'm particularly thinking of https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 in this context.

[Philip Jägenstedt]

OK, so to start with I've emailed Chrome's privacy team to ask for feedback on this specifically and the more general "are we in sync" question, let's see what happens with that.

There's certainly a cost and a risk to any new feature. Here, I'd say the interop risk is worth worrying about, i.e. the risk that this won't get implemented everywhere for one reason or another. Shubhie is already reaching out to other vendors, hopefully we'll get some signals. If all other vendors carefully consider the privacy trade-offs and would be OK with it, that would count for something.

[vas...@chromium.org]

We, Chrome Privacy team, would also like to see the explainer about how nextHopProtocol is useful for the server. Revealing the client's view of the network to the server is controversial even for such a small piece like the protocol used. An alarming fact is that the server already knows the protocol used from its side and in most of the cases it's the same value. Then why isn't it enough for debugging purpose?

[ben.m...@gmail.com]

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.

-b

[Shubhie Panicker]

Looking at current usage based on usecounter for chrome.loadtimes(), the usage is relatively high:

WasNpnNegotiated: 0.98%

NpnNegotiatedProtocol: 0.13%

WasAlternateProtocolAvailable: 0.98%

ConnectionInfo: 0.08%

Thanks Ben for the testimonial. We've had similar feedback from major analytics such as SOASTA (representing large swathes of e-commerce sites etc).

Echoing Nic's (from SOASTA) comments here:

"Developers want to know which of their own &  third party resources are served from H2.

Many are using CDN and may be experimenting with turning on H2 at their CDN level, and want to A/B test customers getting H2 versus not. 

Right now there's no way for the CDN to expose whether the core page and other resources are served on H2 unless the CDN is also rewriting the HTML of the page to expose this, i.e. via a JS variable.

They may also have one class of visitors getting H2 and another class (e.g. older browsers) not, and want to do comparisons (performance vs. conversion rate) on their experiences.  Again, since it's hard to communicate exactly how content was served from the server to client JS, it'd be a lot easier if we could capture this directly via Resource Timing.

Customers also want to get a better understanding of how 3p content performs, and knowing which of their 3p resources are using "modern technology" can be useful."

Does this sufficiently explain the value of the API? Or should I write a one-pager?

--
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.

[PhistucK]

On Fri, Nov 18, 2016 at 12:05 AM, 'Shubhie Panicker' via blink-dev <blin...@chromium.org> wrote:

and knowing which of their 3p resources are using "modern technology" can be useful

​This, specifically, can be checked even without a browser.​

☆PhistucK

[Ryan Sleevi]

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. 

[Ryan Sleevi]

On Thu, Nov 17, 2016 at 2:05 PM, 'Shubhie Panicker' via blink-dev <blin...@chromium.org> wrote:

Does this sufficiently explain the value of the API? Or should I write a one-pager?

I suspect we might want to expand to a one-pager. I'd be happy to continue discussion upstream on the spec. 

[Ben Maurer]

On Thu, Nov 17, 2016 at 5:01 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

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"

Keep in mind that all of this is only enabled with the Timing-Allow-Origin header. This header explicitly states that the 3P resource is opting in to allowing the origin resource to gather performance information about the resource. 

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?

When a site like Facebook is the first to use a new feature (say HTTP2 or brotli) and we trigger previously undiscovered bugs in users' configurations, users think "Facebook doesn't work. Facebook sucks". So it becomes part of our mission to debug these issues -- even if they aren't directly our fault. In many cases we're able to make the ecosystem better. For example, when Kaspersky's software caused any site using brotli to break we were able to contact Kaspersky and they fixed the issue quickly. It was really hard for us to debug this issue -- we had to directly reach out to affected users and ask them to send screenshots of their SSL certificate. If we can debug these issues in more automated ways we are likely to be able to catch issues so that new technology doesn't come at the cost of reliability.

 

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?

The point I'm trying to make is that broadly we want information about the *connection* a user has (how it was negotiated, which request went over which connection, etc) in addition to information about the request. This is indeed a different piece of information but I think it is useful to provide context on why this family of features is important.

 

 

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. 

True, but the fact that much of this information can already be inferred does seem relevant in the conversation.  

[Vasilii Sukhanov]

I'm concerned about the "we need to debug" argument. It easily applies to requesting user's router model, hardware info, firewalls/antiviruses installed etc. While the intent is noble, you didn't get a user's consent on debugging on their behalf.

Vasilii Sukhanov

Software Engineer

vas...@google.com

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

[ben.m...@gmail.com]

Sorry if I came across as saying that the ends justify the means. I think we're all on the same page that browsers can't provide every debugging functionality well meaning sites need due to privacy.

My point here is to focus on the converse of this -- if a piece of functionality is not useful there's no purpose in exploring if it should be added to the platform. I believe (and SOSTA concurs) that APIs that give information about the user's connection serve a purpose. Thus I believe it is worth exploring how we could meet this need while still handling privacy considerations. 

[vas...@chromium.org]

The only privacy concern seems to be that the server in some cases may reveal presence of a proxy (may be antivirus software). On the other hand, the use cases show that nextHopProtocol can help in debugging performance issues.

Given that the privacy risk is minimal and the use cases are justified, I'm leaning towards "OK".

On Tuesday, November 8, 2016 at 1:42:59 AM UTC+1, Shubhie Panicker wrote:

[Yoav Weiss]

Just to emphasize: the use case goes beyond debugging and into reporting, as it enables analytics providers to deploy new protocols (e.g. H2, QUIC) on segments of their users, and correlate analytics data and metrics with the protocol used. 

[ben.m...@gmail.com]

How would you feel about a hypothetical resource timing extension that gave a definitive read as to the existence of MITM interception of the request? This could either take the form of (1) exposing information about the TLS session (some sort of user-agent like identifier from the server) or (2) giving information about the certificate used by the server (eg the hash of the certificate). 

(1) seems to have minimal additional risk in addition to next hop. (2) is riskier (a piece of software may issue a unique certificate per user). However, this could aid in diagnosing situations where users encounter proxies that reduce their security or introduce bugs and is comparable to what can be done today in flash. Perhaps there's a compromise here (such as only exposing the hash if the certificate uses CT and is thus not going to be unique per-user, but still exposing the subject so that the website can debug what the certificate is)

[Ryan Sleevi]

We've explicitly treated (2) as PII, and won't expose this information to Google - so I would be shocked and dismayed if we exposed this information to third-parties. And in the ongoing discussions of certificate transparency redaction, (2) would still potentially represent a concern and is still potentially identifying.

It's also noted that I'm opposed to (1), which is less hypothetical ( https://github.com/w3c/resource-timing/issues/75 and https://github.com/w3c/resource-timing/issues/74 )

I'm particularly concerned towards an argument that reducing privacy by exposing more information about the user is useful for the server to debug. This seems to be something that the user and user agent should be involved in, not the server. The argument that it can be done in Flash doesn't seem particularly compelling - there are a number of security or privacy mistakes that were made over the years, but we shouldn't re-introduce them to the platform, otherwise, we're just reintroducing the security and privacy issues that are being deprecated.

For the case you're raising, arguably, something like HPKP's Report-Only mode - which explicitly through its contract tries to respect the user's privacy - are arguably more suitable for use here.

--
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.

[ben.m...@gmail.com]

As I mentioned in the previous email, I'm not suggesting that the desire to debug privacy or reliability issues introduced by proxies is justification for these features. It is only a motivation for discussing the feature. I am not implying that it overrides privacy concerns. 

I'd point out that there are many other platform features that could expose PII -- for example, being able to read headers via CORS could allow a client to read a header injected by the proxy that uniquely identifies the user.

Facebook's paper on analysis of MITM certificates using the flash approach I mentioned before found that 99.8% of users had an authentic certificate (and were not being MITMed). Table VIII in the paper analyzes the issuer of those certificates and finds that all are generic names of pieces of software and do not identify individual users.

Given the low frequency of forged certificates and the the fact that forged certificates seem to have attributes such as issuer which are not personally identifying I think it could be worth having a deeper discussion, particularly keeping in mind the motivations of debugging reliability and privacy issues introduced by MITM interception.

-b

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[Ilya Grigorik]

Ben, Ryan: is it worth splitting the TLS / MITM discussion into a separate thread? Or continue it on one of the linked GH issues?

Here's a quick summary doc of the use cases and motivation for nextHopProtocol, plus some notes on privacy/security exposure:

https://docs.google.com/document/d/1rgfi8KwdQ6_HbOIauv7bWSl6XnRPboNqenPsgk58bf0/edit

As Vasilii noted above, nextHopProtocol can reveal presence of an HTTP/SOCKS proxy in some cases. However, it doesn't expose any detailed TLS-related information discussed earlier in the thread -- that's an orthogonal discussion, we should split it into a separate thread. The question we need to answer here is whether the "can reveal presence of an HTTP/SOCKS proxy" is something we're comfortable with vs. the value of enabling the use cases outlined in the doc. 

Personally, having spent a lot of time helping developers adopt/measure/motivate the ROI of protocols such as H2/QUIC, and debugging to understand what the right best practices and tradeoffs are for each protocol... RUM data is critical to make informed decisions in this space because the answers often depend on type of content, demographic of users, and so on. Within Chrome we rely a great deal on UMA to answer such questions, and site owners need a similar data to understand the tradeoffs for their own content.

Last but not least, it's also worth noting that we (Chrome) have already been making this data available for a while via chrome.loadTimes().npnNegotiatedProtocol. I realize this is not an argument in itself for continuing to expose this data, but still a data point worth keeping in mind as we evaluate risks vs benefits.

ig

[Ilya Grigorik]

*post holiday bump* :-)

[Philip Jägenstedt]

Is this still waiting to be resolved, or was the thread forked?

+Dru Knox, is this in the intent "ice box", or is there some other kind of tracking for it?

[Ilya Grigorik]

Hey all, apologies about the radio silence. 

We forked the thread to go through a security/privacy review of the feature, use cases, and privacy+security considerations. The resolutions are:

1. Privacy team OK'ed the feature.
2. 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.

If that sounds reasonable to everyone, I'd love to proceed with the intent to ship.

p.s. Ryan, Shubhie: please chime if I'm forgetting anything.

[Philip Jägenstedt]

OK, I think there is nothing further here, seems like all the appropriate review has happened. LGTM1, thanks for being patience everyone!

[TAMURA, Kent]

LGTM2.

The document is very helpful to understand the feature and issues.  I confirmed Firefox already had nextHopProtocol.

--

TAMURA Kent
Software Engineer, Google

[Ryan Hamilton]

On Mon, Feb 27, 2017 at 5:32 PM, Ilya Grigorik <igri...@google.com> wrote:

1. 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.

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?

[Chris Harrelson]

LGTM3

--

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.

[Ilya Grigorik]

On Fri, Mar 3, 2017 at 6:45 AM, Ryan Hamilton <r...@google.com> wrote:

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?

Right, that's the proposal.

 

Can I suggest that we continue reporting the current value until that time?

I suggested that earlier but rsleevi@'s objection to reporting "quic" is that it's not a valid ALPN token and hence violates the definition of the attribute... which is fair, I think. 

On Fri, Mar 3, 2017 at 9:16 AM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

Thanks all! Once we resolve the QUIC case above, we'll make it live :-)

[Ilya Grigorik]

On Sat, Mar 4, 2017 at 5:26 AM, Ilya Grigorik <igri...@google.com> wrote:

On Fri, Mar 3, 2017 at 9:16 AM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

Thanks all! Once we resolve the QUIC case above, we'll make it live :-)

Chatting out of band with rch@ and shubhie@... 

He pointed out that draft-ietf-quic-http-02 registers "hq" (HTTP over QUIC) ALPN token:

https://tools.ietf.org/html/draft-ietf-quic-http-02#section-9.1

We'll proceed with "hq" for QUIC connections. In parallel, there is an IETF sync in Chicago next week where we expect this draft to be adopted.. we'll wait to land and enable "hq" until we see notes and resolutions from that.