PSAs for Non-Blink, Web-Facing Chromium Changes

[Max Heinritz]

Hi chromium-dev (CC blink-dev),

We'd like to be transparent about Chromium features that expose functionality to the open web.

For web-facing changes that require Blink patches, we have an "intent" review system on blink-dev.  There are some changes that for technical reasons are not implemented in Blink, but are nevertheless exposed to web developers.  For those changes, we've updated the guidelines:

If your change cannot be implemented in Blink but still exposes functionality to the open web, add an entry on chromestatus.com, send a "Web-Facing Change PSA" email to chromium-dev (CC blink-dev), and skip the rest of this process.

The public service announcements will allow us to stay up-to-date about new APIs.  They have no predefined structure but should strive to follow the spirit of both Chromium and Blink.

Questions and feedback welcome!

Max

[Paweł Hajdan, Jr.]

[chromium-dev only, removing blink-dev to avoid cross-posting]

Max, for those not very familiar with technical details, could you provide some examples of a web-facing change which is implemented outside of Blink?

Paweł

[Adam Barth]

A recent example is the Cookie Retention Priority Attribute:

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/xK4IJ1-5oJE

Cookie handling is implemented in the network stack, not in Blink.

Adam

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Max Heinritz]

Other examples include 1) PNaCl and 2) a (forthcoming?) Extension API that enables direct communication between injected scripts and host pages.

Adam's link reminded me of something else: authors of web-facing changes outside of Blink are welcome to follow the full Blink launch review process if they'd like extra feedback.

[Emil A Eklund]

How come we have a different set of policies for features based on
where they are implemented? Shouldn't all web facing changes go
through the same process?

[Peter Kasting]

On Mon, Jun 10, 2013 at 1:54 PM, Emil A Eklund <e...@chromium.org> wrote:

How come we have a different set of policies for features based on
where they are implemented? Shouldn't all web facing changes go
through the same process?

Indeed, and [P]NaCl was precisely the example which Robert O'Callahan recently complained did not follow this process (and would not be being exposed to the web if it had).

PK 

[Max Heinritz]

That's a great question.  Here's how I see things:

Reasons to extend the full Blink launch process to all web-exposed Chromium features:

• Different policies, same end result:  At the end of the day, what matters is Chromium's web-exposed API surface (not our internal organizational structure).
  
• Policy backdoor:  By treating non-Blink web-exposed APIs differently, we might allow our future selves to "sneak" non-compatible APIs into Chromium by deliberately not implementing them in Blink.

Reasons not to extend the full process:

• More powerful gatekeepers:  New Blink features require the explicit approval of 3 API Owners.  These gatekeepers derive their authority from (a) a track record of web citizenship and/or (b) technical prowess in the Blink and WebKit codebases.  It's not clear to me that the latter source of power extends to features outside Blink, or that we should unduly expand their control.
  
• New process burden:  The Blink launch process was originally designed to ensure that Blink didn't lose sight of compatibility after parting ways with WebKit.  Non-Blink changes were explicitly out of scope.  I think the "Web-facing Change PSA" policy is a good way to bring the spirit of the Blink launch process to other web-facing parts of Chromium without imposing a lot of process.  Pre-Blink, there was little or no oversight as far as I can tell.  PSAs will at least start a public conversation.

Of course, the guidelines are new and we can iterate as appropriate.

[William Chan (陈智昌)]

I think it's awesome that we're having this discussion, and that the new guideline is a good start. Eventually though, I think that something more akin to the Blink launch process is what we ultimately want for all web-exposed Chromium features. Just my two cents.

PS: FWIW, I also think it'd be cool to see such a Web-Facing Change PSA thread for [P]NaCl.

[Chris Bentzel]

What counts as an open-web-facing change, particularly for networking?

Is this predominantly at the HTTP layer? I can imagine that any new
headers, or deprecation of headers (such as Accept-Charset) would
count.

Not sure about a few other cases:

- For example, work is underway to add TLS 1.2 support to Chrome.
Does this count as web-facing?

- Work that is predominantly for intranets (HTTP auth, PAC, proxies, etc)

- Optimization work that doesn't expose new APIs, but makes existing
ones more performant.

[Darin Fisher]

If a web developer can detect the change, then it is "web facing".

On Wed, Jun 12, 2013 at 10:22 AM, Chris Bentzel <cben...@chromium.org> wrote:

What counts as an open-web-facing change, particularly for networking?

Is this predominantly at the HTTP layer? I can imagine that any new
headers, or deprecation of headers (such as Accept-Charset) would
count.

Yes

 

Not sure about a few other cases:

  - For example, work is underway to add TLS 1.2 support to Chrome.
Does this count as web-facing?

Yes

 

  - Work that is predominantly for intranets (HTTP auth, PAC, proxies, etc)

Yes

 

  - Optimization work that doesn't expose new APIs, but makes existing
ones more performant.

No

[Darin Fisher]

On Wed, Jun 12, 2013 at 10:27 AM, Darin Fisher <da...@chromium.org> wrote:

If a web developer can detect the change, then it is "web facing".

On Wed, Jun 12, 2013 at 10:22 AM, Chris Bentzel <cben...@chromium.org> wrote:

What counts as an open-web-facing change, particularly for networking?

Is this predominantly at the HTTP layer? I can imagine that any new
headers, or deprecation of headers (such as Accept-Charset) would
count.

Yes

 

Not sure about a few other cases:

  - For example, work is underway to add TLS 1.2 support to Chrome.
Does this count as web-facing?

Yes

 

  - Work that is predominantly for intranets (HTTP auth, PAC, proxies, etc)

Yes

 

  - Optimization work that doesn't expose new APIs, but makes existing
ones more performant.

No

 

explanation: web developer can't tell the difference between such a chrome change and faster network / faster computer, so optimization work doesn't really count.

-darin

[William Chan (陈智昌)]

My two cents, we (networking folks) should be sending PSA emails at the very least here.

On Wed, Jun 12, 2013 at 10:22 AM, Chris Bentzel <cben...@chromium.org> wrote:

What counts as an open-web-facing change, particularly for networking?

Is this predominantly at the HTTP layer? I can imagine that any new
headers, or deprecation of headers (such as Accept-Charset) would
count.

I think stuff like that should be announced. Like if we were to implement https://github.com/igrigorik/http-client-hints or http://datatracker.ietf.org/doc/draft-nottingham-http-browser-hints/.

 

Not sure about a few other cases:

  - For example, work is underway to add TLS 1.2 support to Chrome.
Does this count as web-facing?

Sure. I'd announce this too. This is already a standard though.

 

  - Work that is predominantly for intranets (HTTP auth, PAC, proxies, etc)

Yes if it affects the API.

 

  - Optimization work that doesn't expose new APIs, but makes existing
ones more performant.

No

[Chris Bentzel]

Thanks for clarifications!