Blink Process for externally visible network features

[Chris Bentzel]

tl;dr: Let's use the Blink process for externally visible network changes going into the future.

--

The Blink process was created to help manage the tension between moving the web forward and preserving compatibility.

Even though networking layer changes are frequently done outside of the Blink code base, we face similar tensions - from entirely new transport protocols, to TLS changes, to support for new headers. Following the Blink process makes a lot of sense. This also has the added bonus of making platform changes more transparent and easy to track. 

Examples of networking changes which are externally exposed include:

• Cookie attributes such as First-Party-Only.
  
• HTTP headers such as Client-Hints.
• Deprecation of TLS ciphers like RC4.
• New transport protocols like QUIC.

In these cases, follow the Blink process. Send Intent to Implement/Ship/Deprecate emails to blink-dev and cc:net-dev when doing it.

--

Not all networking changes are subject to the Blink process. Some examples include:

• Extension APIs such as webRequest.
  
• Performance optimizations like a new cache backend.
  
• UI changes such as error page auto-reload.
  
• Domain Reliability, since domains are restricted at this point. Network Error Logging however would go through the Blink process.

If you are doing launches or changes to a feature, please follow the New Feature process, sending mail to chromium-dev and cc'ing net-dev.

--

Thanks for reading so far!

Any questions or concerns?

[Mike West]

On Fri, Apr 10, 2015 at 1:18 AM, 'Chris Bentzel' via net-dev <net...@chromium.org> wrote:

tl;dr: Let's use the Blink process for externally visible network changes going into the future.

I'm very supportive of this. Thanks, Chris!

The only suggestion I'd make would be some sort of explicit recognition that the Blink folks ought to loop in relevant //net OWNERs as subject area experts when making decisions about changes in the network stack.

-mike

[Chris Bentzel]

On Fri, Apr 10, 2015 at 4:32 AM Mike West <mk...@chromium.org> wrote:

On Fri, Apr 10, 2015 at 1:18 AM, 'Chris Bentzel' via net-dev <net...@chromium.org> wrote:

tl;dr: Let's use the Blink process for externally visible network changes going into the future.

I'm very supportive of this. Thanks, Chris!

Thanks for advocating for it! 

 

The only suggestion I'd make would be some sort of explicit recognition that the Blink folks ought to loop in relevant //net OWNERs as subject area experts when making decisions about changes in the network stack.

Yes. We had that discussion Google-internal and that's the plan.  Good to publicly acknowledge that as well. Thanks!

-mike

[Chris Bentzel]

There's one open question I'm interested in feedback on.

Most of the Blink features in the pre Intent-to-Ship phase are gated by the experimental web features flag.

Should the networking features also be gated by this flag as well?

There are some cases where we would _not_ want to do this when trying to determine how useful a feature is. QUIC is the obvious example where we really do need to roll it out to a subset of users to understand performance in the wild. But I wonder if that should be an exceptional case.

[Matt Menke]

What's the definition of a "web visible" feature?

A couple examples of changes, all technically web-visible:

1)  We weren't sending keep-alives on OS.  Recently fixed.  Not the most web visible, but if a third party really wanted to, it could watch for them.

2)  HttpStreamParser hack 1:  We currently allow a couple bonus characters at the start of an HTTP response.  This logic triggers for a bit under 1 in 2 million HTTP 1.x responses on Canary.  How rarely it triggers may be related to the fact we generally close sockets rather than reuse them if they have extra cruft when the previous response is complete.  If we get rid of this hack, should there be an intent to ship email?  Getting rid of this is a bit more visible than 1).

3)  HttpStreamParser hack 2:  If we received a partial set of headers in an HTTP response, we treat it as a full HTTP response.  I assume this is mostly for redirects and HEAD responses where the server is failing to send a CRLF.  Logic triggers in about 1 in 75,000 HTTP 1.x responses on Canary.  If we get rid of this hack, should there be an intent to ship email?

4)  HTTP/0.9 is used for 1 in 4500 of [HTTP<2.0] responses on Canary (About 0.02% of them).  I'm pretty sure if we ever decide to get rid of support for it, it would be worth an intent to ship email.

(And for the curious, I'd really like to get rid of both hacks and HTTP/0.9 support, but given the usage, I think we're best off keeping HTTP/0.9 support for now.  Want numbers from stable before deciding anything, though)

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAAuiYA8bnpEk2ATev2BOcykO%2BLW1N-tTF_Z06%2BngPRdoUfQenQ%40mail.gmail.com.

[Mike West]

On Sun, Apr 19, 2015 at 9:32 PM, Matt Menke <mme...@chromium.org> wrote:

What's the definition of a "web visible" feature?

Blink OWNERS can answer more authoritatively than I can, but my impression is that Blink has one of those exciting "You know it when you see it" processes.

https://www.chromium.org/blink#new-features distinguishes "trivial" changes as not needing to go through a shipping approval process, but leaves it more or less up to you and your reviewer(s) to decide whether a particular CL is trivial or not.

1)  We weren't sending keep-alives on OS.  Recently fixed.  Not the most web visible, but if a third party really wanted to, it could watch for them.

2)  HttpStreamParser hack 1:  We currently allow a couple bonus characters at the start of an HTTP response.  This logic triggers for a bit under 1 in 2 million HTTP 1.x responses on Canary.  How rarely it triggers may be related to the fact we generally close sockets rather than reuse them if they have extra cruft when the previous response is complete.  If we get rid of this hack, should there be an intent to ship email?  Getting rid of this is a bit more visible than 1).

3)  HttpStreamParser hack 2:  If we received a partial set of headers in an HTTP response, we treat it as a full HTTP response.  I assume this is mostly for redirects and HEAD responses where the server is failing to send a CRLF.  Logic triggers in about 1 in 75,000 HTTP 1.x responses on Canary.  If we get rid of this hack, should there be an intent to ship email?

4)  HTTP/0.9 is used for 1 in 4500 of [HTTP<2.0] responses on Canary (About 0.02% of them).  I'm pretty sure if we ever decide to get rid of support for it, it would be worth an intent to ship email.

(And for the curious, I'd really like to get rid of both hacks and HTTP/0.9 support, but given the usage, I think we're best off keeping HTTP/0.9 support for now.  Want numbers from stable before deciding anything, though)

If you're asking me, #4 in your list is certainly worth an "Intent to Deprecate" (which is nice to do, because the `chromestatus.com` entry helps inform other browser vendor's decisions about deprecations). #1-3 all feel like bug fixes with relatively low impact on either users or servers, and feel pretty trivial.

That said, erring on the side of over communication isn't a bad thing: I'm sure folks would be interested in learning about upcoming changes to the network stack. :)

-mike

[PhistucK]

Note that the process for trivial changes is being reconsidered, given that chromestatus.com has become a crucial documentation and announcement resource and that trivial changes also cause breakages (even if small ones, people will come and complain).

You are encouraged to announce any web facing change, basically. If not as an "intent", than as a public service announcement. I know I would like to know when anything changes so I could make sure my properties are safe.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAKXHy%3DcemkeoZ3M64uObGA0KwGJP7P5uC5MuEfcSxHGb6%3DMmGA%40mail.gmail.com.

[Philip Jägenstedt]

Where is the discussion on the process for trivial changes taking place?

I think announcing all Web-exposed changes is out of the question, as almost every commit that touches LayoutTests/ has some Web-facing change of behavior. Even if grouped by task I think that's a far bigger fire-hose than would be useful for Blink developers, which is the main target audience of blink-dev.

Are there concrete examples of cases that were not announced that didn't go well that we could learn from? (I have nothing useful to say about the trade-offs in the abstract.)

Philip

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

[Alex Komoroske]

On Mon, Apr 20, 2015 at 8:34 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Where is the discussion on the process for trivial changes taking place?

I think PhistucK is referring to this thread, including my off-hand comment about ChromeStatus (and, I see now, a massive typo on my part. I swear my thoughts actually make sense inside my head, even if they get garbled on delivery...)

[PhistucK]

​I remember a post from the last year or two that discussed a website issue due to a web facing change that was made to Range or something like that. I think we started throwing exceptions for things we did not throw before (the other browsers already threw), but I cannot find that thread at the moment.

A more recent example seems to be (though I have not searched for the change and it might be a bug, though I do not think so) -

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/phistuck$20-subject$3Aintent%7Csort:date/blink-dev/NZJQHRHrMpY/1yoS9TKtLscJ

(A less relevant example would be the deprecations that were announced as intents but did not appear on chromestatus.com, but those were just oversights since the intent was at least announced)

Unfortunately, developers are relying on our quirks. When we do not announce these changes, it makes a lot of people sad (or even angry) and frankly, it adds a burden to the people on technical support groups (such as blink-dev, chromium-discuss and in the broader sense, StackOverflow and similar) that must figure out what has happened, whether it is a bug or intended. If we are lucky, the change is very clear and you can look it up quickly in blink-checkins, but oftentimes, it is not so clear and straightforward at all and we either put a lot of time into looking it up, or give up and let the poster look for an issue (or create an issue that might not even be triaged in the next year, due to enormous amount of existing, false-or-true issues).

If you think this is an overkill for blink-dev, perhaps there should be a group for those (or better yet, add entries to chromestatus.com for each of them, but have an option to mark a change as small so it will appear accordingly, instead of shadowing big changes).

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMQvoCkMKozS-t%3D__MmymQ_5_WeONVUtFdKFw9yiZZJO%3DJuQOg%40mail.gmail.com.

[Philip Jägenstedt]

My thinking is that changes that have a non-trivial chance of breaking things should be measured (where possible) and typically go through the intents process. (This is already the case.) What remains are the majority of Web-facing changes, where each individual change has a very low likelihood of affecting any specific Web site or app. I don't doubt that if all of these were meticulously documented, it would be of some use to someone. However, how would anyone find the very rare cases that will affect them in such a huge set of data? And who's job would it be to meticulously document these changes?

While I am skeptical, I certainly support anyone who wants to try to provide very detailed lists of changes, maybe it can be done.

Philip

[PhistucK]

You can take, for example, the developer release notes of Firefox, which are pretty extensive with additions, changes and removals, even trivial ones.

https://developer.mozilla.org/en/Firefox/Releases

Since they also have a documentation venue of themselves (MDN), they generally document these changes in the relevant articles as well.

☆PhistucK

[Philip Jägenstedt]

That is very high quality documentation. However, I don't see that many trivial changes, and a lot of things that would have intents to implement/ship/deprecate/remove in the Blink process. I'm guessing that a full list of Web-observable changes between two versions of Chromium (or Firefox) would be much, much longer.

Philip