goog Prefixed Features

[PhistucK]

A recent commit (August 7th, 2014) in WebRTC added a goog prefixed constraint to webkitGetUserMedia -

​​

Log message

(Auto)update libjingle 72847605-> 72850595

Affected files

     expand all   collapse all

	Modify	/trunk/talk/app/webrtc/mediaconstraintsinterface.cc	diff
	... 95 95 "googSuspendBelowMinBitrate"; 96 96 const char MediaConstraintsInterface::kImprovedWifiBwe[] = 97 97 "googImprovedWifiBwe"; 98 + const char MediaConstraintsInterface::kNumUnsignalledRecvStreams[] = 99 + "googNumUnsignalledRecvStreams"; 98 100 const char MediaConstraintsInterface::kScreencastMinBitrate[] = 99 101 "googScreencastMinBitrate"; 100 102 // TODO(ronghuawu): Remove once cpu overuse detection is stable. ...

Prefixing features is harmful to the web platform, making websites incompatible with other browsers, breaking assumptions, causing monopolization and hurting competition. People rely on prefixed features instead of treating them as non production, experimental features that (not only could) will change, break and disappear soon. I listed some details in the last section of this post.

Blink (of Chrome) and Gecko (of Firefox) have announced long ago they will not be adding prefixed features anymore.

Instead, experimental features are disabled by default and can usually be turned on by using a command line flag (about:flags in Chrome) or by setting a certain preference (about:config in Firefox).

In this example, you can use the Experimental Web Platform Features flag in Chrome in order to expose any experimental functionality (a prefix is not needed then, because it is meaningless if it is not exposed to the web by default anyway).

This lets any Chrome user that is looking to experiment with the functionality that you want to introduce, experiment with it by simply flipping a flag, which is really not a big deal.

If you need help with plumbing the flag into WebRTC, I can try diving into the code and come up with a clean way of exposing such concepts ("kEnableExperimentations" or so).

I (and the entire web) would appreciate it, if you could move all of the prefixed features and constraints in WebRTC (meaning, prefixed getStats statistics and prefixed media and peer connection constraints, or any other prefixed feature that is currently exposed by default to the web) behind the Experimental Web Platform Features flag, that can be easily turned on from about:flags.

Note - I am mostly referring to goog prefixed features here. Unless I am mistaken, webkit prefixed WebRTC features (like webkitGetUserMedia, webkitRTCPeerConnection and webkitMediaStream and others with which I might not be familiar) are features that should be deprecated and unprefixed, as soon as possible, rather than be moved behind a flag.

Here are a few reasons, explanations and arguments, some of them are recent and some are not -

- http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/ (I am not sure Firefox actually implemented -webkit- prefixed feature eventually, though).

- http://www.paulirish.com/2012/vendor-prefixes-are-not-developer-friendly/

- http://www.chromium.org/blink#vendor-prefixes

- http://css.dzone.com/articles/are-vendor-prefixes-harmful

- Microsoft just recently announced that Internet Explorer 11 on Window Phone 8.1 Update 1 added support for -webkit- prefixed CSS because websites were incompatible with Internet Explorer, because they only relied on vendor prefixes, because they simply worked with the default browsers.

- Opera did the same with Presto (their rendering engine, prior to switching to WebKit and then Blink), in order to be compatible with the vendor prefix encumbered web.

Thank you very much (everyone here) for all of your work. You are doing amazing things to the web.

☆PhistucK

[Adam Barth]

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.

Adam

[Ryan Sleevi]

Was there a public discussion to follow along on? Or is this now it?

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

[Adam Barth]

On Fri Aug 08 2014 at 9:18:16 AM Ryan Sleevi <rsl...@chromium.org> wrote:

Was there a public discussion to follow along on?

We discussed the issue in a VC.  There have been various email threads on various lists, but none of them converged on a workable solution. 

Or is this now it?

I'm happy to re-open this topic if you'd like to discuss it further.

Adam

[Domenic Denicola]

On Friday, August 8, 2014 12:14:15 PM UTC-4, Adam Barth wrote:

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.

Does this mean we believe that running behind a flag will not gather enough data?

What about shipping only to dev/canary channels?

Mainly, I am curious why this feature is special compared to other experimental features on the web platform.

Or, will we be using the 50%-prefixed technique for other nonstandard features as well?

[Ryan Sleevi]

On Aug 8, 2014 9:27 AM, "Adam Barth" <aba...@chromium.org> wrote:
>
> On Fri Aug 08 2014 at 9:18:16 AM Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>> Was there a public discussion to follow along on?
>
> We discussed the issue in a VC.  There have been various email threads on various lists, but none of them converged on a workable solution. 
>>
>> Or is this now it?
>
> I'm happy to re-open this topic if you'd like to discuss it further.
>
> Adam

After I sent this, I was afraid that last sentence would be seen as more combative than desired.

No, I merely was hoping to follow the decision making a bit more than your summary, to understand the process, as well as understand the impact (however small) to the Blink process.

[Adam Barth]

[-discuss-webrtc, which is bouncing for me]

On Fri Aug 08 2014 at 9:32:27 AM Domenic Denicola <dom...@domenicdenicola.com> wrote:

On Friday, August 8, 2014 12:14:15 PM UTC-4, Adam Barth wrote:

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.

Does this mean we believe that running behind a flag will not gather enough data?

That's correct.  The idea is that Hangouts wants to gather data from the normal population of users in the field.  Users who enable flags aren't representative of the normal population.

 

What about shipping only to dev/canary channels?

There are two issues with that approach:

1) The folks who manage Chrome releases want to ship the same bits to all the release channels because otherwise data from dev/canary isn't valid for evaluating how well a given release will work in beta and stable.

2) The population of users in dev/canary isn't representative of the normal population.

Mainly, I am curious why this feature is special compared to other experimental features on the web platform.

The difference is that it's difficult to evaluate network protocols in a lab, and WebRTC is largely about the networking between the two endpoints.  For example, when we were developing SPDY, we also used live-traffic experiments, and we're using live-traffic experiments currently for QUIC.

Or, will we be using the 50%-prefixed technique for other nonstandard features as well?

We've also used this technique in the past to experiment with exposing the GL renderer string for WebGL so that we could evaluate how having that information affected the user experience for the WebGL version of Maps.

I think it's an appropriate technique to use in the context of an experiment that aims to gather data from a large population of users.  For most features, using a runtime flag is likely a better approach because they can be evaluated individually by developers.

Adam

[Domenic Denicola]

From: Adam Barth <aba...@chromium.org>

> I think it's an appropriate technique to use in the context of an experiment that aims to gather data from a large population of users.  For most features, using a runtime flag is likely a better approach because they can be evaluated individually by developer

Thanks Adam; this makes sense. It might be helpful to update the documentation at http://www.chromium.org/blink/developer-faq#TOC-Will-we-see-a--chrome--vendor-prefix-now- and thereabouts to reflect this update to our thinking and capture the subtleties you've explained in this thread.

[Jochen Eisinger]

Note that webrtc shipped prefixed features before, and we were looking for a way to avoid having websites rely on them after they already shipped.

Yes, in this case, a new property was added, but mainly for consistency reasons.

I think using a random trial is a suitable tool for trying out not yet standardized features, but it doesn't fundamentally change our stance on prefixed features.

Best
Jochen

[Ben Kelly]

Would it not be preferable to:

1) Use non-prefixed features
2) Put them behind a pref defaulted off
3) Make your experiment flip the pref on for some small subset of users?

This would also allow users to opt out of the experiment if they wished.

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

[PhistucK]

As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.

For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.

A better example is screen sharing. Screen sharing is a 'plugin free' Hangouts feature that uses the "chromeMediaSource": "screen" constraint in webkitGetUserMedia.

Other websites cannot use this (chrome prefixed, oh...) constraint, not even in HTTPS. Only Hangouts can.

I do not recall more examples at the moment, but I think there were more, even for short periods of time.

If Google wants to experiment with stuff, you can limit the constraints (or any other feature) to Google properties. While I am not in favor of this kind of favoritism, I prefer it over this - prefixed properties are harmful to the web as a whole, while favoritism is simply 'cheating'.

By the way, 50% is a pretty high percentage. WebGL used to be available to less than 50% of the users for a long time (not due to experiments), due to driver issues, or insufficient implementations on certain operating systems, but websites still experimented with WebGL and used WebGL, even if not all of the users could experience them.

At least it was know. But this can be even worse - a developer uses the prefixed constraint because it works for them and for some of their users that tested their website (luck, I guess) and have no idea the feature is not available for all (no one publicized this decision until now). It is true that these constraints were never publicized as well, but as you know - if something exists in a browser, there will be developers that use it.

☆PhistucK

[William Chan (陈智昌)]

On Fri, Aug 8, 2014 at 1:57 PM, PhistucK <phis...@gmail.com> wrote:

As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.

For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.

We've never whitelisted origins for SPDY. SPDY has always negotiated via NPN/ALPN, using a published spec (that eventually got adopted by the IETF for HTTP/2).

[Adam Barth]

On Fri Aug 08 2014 at 1:58:19 PM PhistucK <phis...@gmail.com> wrote:

As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.

For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.

A better example is screen sharing. Screen sharing is a 'plugin free' Hangouts feature that uses the "chromeMediaSource": "screen" constraint in webkitGetUserMedia.

Other websites cannot use this (chrome prefixed, oh...) constraint, not even in HTTPS. Only Hangouts can.

I do not recall more examples at the moment, but I think there were more, even for short periods of time.

If Google wants to experiment with stuff, you can limit the constraints (or any other feature) to Google properties. While I am not in favor of this kind of favoritism, I prefer it over this - prefixed properties are harmful to the web as a whole, while favoritism is simply 'cheating'.

We discussed that as a possibility, but in the past we've had difficulty removing features that are exposed only to Google web sites for much the same reason that we have difficulty removing vendor-prefixed features more generally in the web.

The idea behind exposing these non-standard features less than 50% of the time is that it lets retain the option of removing the feature entirely, even if the web site that uses the feature is uncooperative.

By the way, 50% is a pretty high percentage. WebGL used to be available to less than 50% of the users for a long time (not due to experiments), due to driver issues, or insufficient implementations on certain operating systems, but websites still experimented with WebGL and used WebGL, even if not all of the users could experience them.

50% is just an upper limit.  Ideally we'd use as small a percentage as we can while still being able to get statistically significant data from the experiment.

 

At least it was know. But this can be even worse - a developer uses the prefixed constraint because it works for them and for some of their users that tested their website (luck, I guess) and have no idea the feature is not available for all (no one publicized this decision until now). It is true that these constraints were never publicized as well, but as you know - if something exists in a browser, there will be developers that use it.

Yes, that's a risk.  The good news is that either the developer's site works without the feature or the developer will quickly get many bug reports from the majority of users who lack the feature.

Another way we could mitigate that risk is to log a message to the developer console whenever you use one of these experimental APIs.

Adam

[PhistucK]

When was this up-to-50% policy applied? Or will it be applied going forward? And for what features - all of the goog prefixed ones (constraints and statistics)?

Your past experience with Google websites makes me sad. :(

What about an up-to-50%-for-Google-properties policy? Looks like the best of both of the worlds.

Logging a message to the console sounds like the least we should do.

☆PhistucK

[PhistucK]

Oh, then I misremembered - sorry!

What about QUIC, though? Is it currently limited to Google properties?

☆PhistucK

[William Chan (陈智昌)]

On Fri, Aug 8, 2014 at 2:26 PM, PhistucK <phis...@gmail.com> wrote:

Oh, then I misremembered - sorry!

What about QUIC, though? Is it currently limited to Google properties?

I did not mention QUIC because I'm not authoritative on it, unlike SPDY & HTTP/2. That said, I do believe we don't whitelist origins for QUIC either. And indeed, I think people have been running their own experimental QUIC server deployments (possibly using our test server). At least, I believe I've read emails to that effect on our public mailing list [1]. If you find any whitelisting of origins for QUIC, let me know and I will dig up more Cones of Shame and pay Mountain View a visit.

[1] - https://groups.google.com/a/chromium.org/d/msg/proto-quic/itjF2NSkKLU/gzj9dAofBW8J

[Adam Barth]

On Fri Aug 08 2014 at 2:26:03 PM PhistucK <phis...@gmail.com> wrote:

When was this up-to-50% policy applied?

Justin and I discussed it a could week ago, after the last email thread in which you were involved.

 

Or will it be applied going forward?

My hope is that we'll use this approach for new non-standard features in WebRTC.

 

And for what features - all of the goog prefixed ones (constraints and statistics)?

Justin and I didn't discuss them.  My plan was to raise that issue after getting some experience with using this approach in a new feature.

Your past experience with Google websites makes me sad. :(

Me too.  :(

 

What about an up-to-50%-for-Google-properties policy? Looks like the best of both of the worlds.

IMHO, Chrome shouldn't treat Google web sites different from other web sites.  Please be aware that's just my perspective and not everyone on the team agrees with me.

Adam

[PhistucK]

Regarding the last point - I agree with you - but it is the lesser evil for the entire web.

I appreciate your effort and the fact that you discussed it further with Justin after my overly aggressive approach. Sorry about that.

I am glad it yielded at least some result.

☆PhistucK

[Chris Bentzel]

+rch for the QUIC specific questions earlier in the thread.

"That said, I do believe we don't whitelist origins for QUIC either"

[Ryan Hamilton]

QUIC is open to the public. We do not have any restrictions to .google.com origins or anything like that. If you build the quic_server target from the chromium source tree, and configure it correctly, you too can have Chrome speaking QUIC to your very own server :>

[PhistucK]

Great to know and sorry for the false accusation! ;)

☆PhistucK

[Justin Uberti]

Adam summarized the overall situation well. Regarding the exact APIs, there are two significantly different cases here, so let me explain them individually:

1) Experimental algorithms or internal mechanisms

Examples: googNumUnsignalledRecvStreams, googOpusFec, googIPv6

These have no impact on anything user-visible; they are various optimizations and other improvements that ought to improve the quality of experience for WebRTC applications. We test these mechanisms in controlled experiments across large populations to get statistically valid indications on whether these things help or hurt WebRTC QoS; we also allow non-Google applications to toggle these to do experiments on their own populations. Eventually, once the data has been analyzed and the bugs fixed, we will turn the feature on for everyone, which has already happened for many of these parameters (e.g. googImprovedWifiBwe)

There is little risk of applications becoming dependent on these features (as optimizations, we could safely turn them off at ay time) but we are evaluating how we could prevent these things from being misused or misunderstood. 

One option, as Adam described, is to enable these features to a subset of the Chrome population; we are looking into the logistics surrounding this. Another approach could be to replace the googXXXX params with an explicit list of experiment GUIDs, passed in via some .experiments parameter. This would help make it clear (perhaps with a console message as well) that these are for experimentation only.

2) Features that we think are useful, but have not yet been standardized 

Examples: googAutoGainControl, googNoiseSuppression, goog stats

While we had been waiting until the WG had the cycles to standards-track all of these, Adam made a strong case that prefixing these is the wrong thing to do, because applications almost certainly will become dependent on these API (i.e. the standard argument against prefixing). We need to figure out the exact timing, but I think we will start replacing googFoo with its foo equivalent shortly.

[PhistucK]

Thank you for taking the time to explain.

1. I understand that constraints can always be specified as mandatory and optional. Are these constraints accepted as mandatory constraints? If so, perhaps you can change the policy to only accept them as optional constraints, this way you ensure that no code and no assumption breaks (only the experience, somewhat, but this is inevitable).

Like I mentioned before, a console log would be a good step forward.

2. Good to know. Will you update (this thread, or somewhere else) once you figure out the plan?

Generally, these silent additions and changes of public APIs have a sneaky sense to them, even if you do not intend that to be the case at all. Will you be willing to announce these kinds of additions, deprecations and removals in blink-dev (use blink-dev...@chromium.org)?
I would rather see intent threads, of course, but given the decision that was made (and the fact that they do not involve Blink changes), a public service announcement would suffice.

☆PhistucK

[brua...@gmail.com]

Le vendredi 8 août 2014 23:16:38 UTC+2, Adam Barth a écrit :

On Fri Aug 08 2014 at 1:58:19 PM PhistucK <phis...@gmail.com> wrote:

As far as I know, Hangouts (and other Google properties) have various exceptions in Chrome.

For example, in the past, if I remember correctly, only Google properties were allowed to use SPDY (and now QUIC? or were all sites always allowed?) at first.

A better example is screen sharing. Screen sharing is a 'plugin free' Hangouts feature that uses the "chromeMediaSource": "screen" constraint in webkitGetUserMedia.

Other websites cannot use this (chrome prefixed, oh...) constraint, not even in HTTPS. Only Hangouts can.

I do not recall more examples at the moment, but I think there were more, even for short periods of time.

If Google wants to experiment with stuff, you can limit the constraints (or any other feature) to Google properties. While I am not in favor of this kind of favoritism, I prefer it over this - prefixed properties are harmful to the web as a whole, while favoritism is simply 'cheating'.

+1. I'm not fan of website-specific code paths in browsers, but it feels justified in this case, not to give more privileges to Google property, but rather to limit the scope of the prefix pollution.
 

We discussed that as a possibility, but in the past we've had difficulty removing features that are exposed only to Google web sites for much the same reason that we have difficulty removing vendor-prefixed features more generally in the web.

The reason is the same, but the scale is different. In one case, Google code bases are a bit polluted (but Google has good engineers who can isolate the portion of the code that depends on the experimental feature). If you expose something to the web, the entire web is polluted, possibly forever.

Google will eventually do rewrites of its software. Even if you don't, well, that's your problem, not the web's problem.
Exposing something to the web just so you can make tests on Google Hangout feels a bit odd.

 

The idea behind exposing these non-standard features less than 50% of the time is that it lets retain the option of removing the feature entirely, even if the web site that uses the feature is uncooperative.

Cool, so then if Google websites "have difficulty removing vendor-prefix" (aka are "uncooperative"), you have a leverage, so the argument above used as answer to "use only in Google properties" is void, right?

 

Another way we could mitigate that risk is to log a message to the developer console whenever you use one of these experimental APIs.

Lol. It's not a mitigation measure, it's an communication one. We've done this in the past. Thinking the prefix was enough an indication that people shouldn't use in production. Didn't work. A console warning won't make a difference. Communicating has non-zero value, but this value isn't about mitigating the risk.

The only thing that matters when it comes to prefix pollution is whether you're exposing something to the web or not. It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)

David

[Yoav Weiss]

Maybe instead of activating the feature on a percentage of users or activating it only for Google properties (which doesn't feel right), we could declare a time-limited experimentation with non-standard features for data gathering purposes?

For example, such features would be turned on by default in a certain Chromium milestone version, but turned off immediately after that?

That way, I doubt we'd see significant adoption of these experimental features by authors, since it won't be worth the trouble for just 6 weeks.

If we're expecting to see more features of that nature, maybe they can be announced using "Intent to Experiment" threads here on blink-dev?

[brua...@gmail.com]

Le samedi 9 août 2014 14:11:32 UTC+2, Yoav Weiss a écrit :

Maybe instead of activating the feature on a percentage of users or activating it only for Google properties (which doesn't feel right), we could declare a time-limited experimentation with non-standard features for data gathering purposes?

For example, such features would be turned on by default in a certain Chromium milestone version, but turned off immediately after that?

That way, I doubt we'd see significant adoption of these experimental features by authors, since it won't be worth the trouble for just 6 weeks.

"We need just one more week to get more data"

We've seen in the past that commitments to a future decisions aren't necessary held. I'm skeptical about this path.

David

[brua...@gmail.com]

Le vendredi 8 août 2014 18:14:15 UTC+2, Adam Barth a écrit :

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

It was exactly the same thinking for when one browser had an experimental feature and the other didn't "People won't write non-standard code since it's not interoperable. We'll be able to remove the feature later". What happened is that the websites were encouraging users to download a different browsers (not pointing fingers, it happened with pretty much all combinaisons of source and target browsers).
This time, the website just has to display a message like "your version of Chrome has a bug preventing it from running this awesome demo. Please re-install Chrome."
And "my friend can run the demo while I cannot and we're both on Chrome, that should work the same, right?" would be a powerful motivator for people to re-install Chrome.

Exposing something experimental on the web is playing with fire.

I'm sympathetic with the intention of real-world testing on a large population, that's why I'm fine with exposing the experimental things on Google properties. It's a noble goal to want other web devs to test out the feature, however, as soon as you release something on the web, you cannot control what will happen.
One possible middle-ground between "google only properties" and "the entire web" would be to have web devs declare interest and the Chrome team to whitelist their domains (akin to what happens with the HSTS prelaod list [1][2]). Among other things, that would "guarantee" that the Chrome team has a point of contact with the websites running experiments, which would give you a clear way to inform people that an experimentation is coming to an end (which you don't have if you ship something on the web).
Other middlegrounds are possible. I would love to see them explored.

David

[1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
[2] https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

[Adam Barth]

What matters ultimately is how these decisions affect users.  In my view, the biggest problem with vendor prefixes is that they make web sites behave different in different browsers, which makes it harder to users to switch browsers, which results in a worse experience for users.  For example, look at all the crazy things IE is doing now in order to get web sites to work properly in IE on Windows Phone.

 

It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)

Personally, I find it frustrating to develop for a platform that grants special privileges to some developers.  For example, Chrome on Windows originally used WinInet as its network stack, but we couldn't implement HTTPS certificate handling properly because Internet Explorer used a private API to WinInet in order to implement its HTTPS certificate handling.

I don't think the web platform should grant special privileges to some developers.  As I've written earlier in this thread, that's a matter of opinion and not everyone agrees with me.  It sounds like you're in the camp of folks who disagree.

On Sat Aug 09 2014 at 5:11:30 AM Yoav Weiss <yo...@yoav.ws> wrote:

Maybe instead of activating the feature on a percentage of users or activating it only for Google properties (which doesn't feel right), we could declare a time-limited experimentation with non-standard features for data gathering purposes?

For example, such features would be turned on by default in a certain Chromium milestone version, but turned off immediately after that?

We've certainly talked about that.  The problem with that approach is that you get into a game of chicken with developers that adopt the time-limited feature.  When the clock runs out, the discussion goes something like this:

"It's time to stop using feature X.  If you continue to use it, your web site will break in Chrome N."

"If you remove feature X in Chrome N, our web site will break."

Neither party wants the web site to break, and you get embroiled in an argument that's ultimately a test of resolve.

That said, we're trying something like this at the moment on two fronts: NPAPI and showModalDialog.  For NPAPI, we've announced a date after which Chrome will no longer support NPAPI.  For showModalDialog, we've given enterprise users the option to re-enable the feature for a limited period of time.

I understand that those situations are a bit different from what you're suggesting, but hopefully we'll learn something from how those date-based feature removals go.

That way, I doubt we'd see significant adoption of these experimental features by authors, since it won't be worth the trouble for just 6 weeks.

If we're expecting to see more features of that nature, maybe they can be announced using "Intent to Experiment" threads here on blink-dev?

I would like to see something like that, although chromium-dev might be a better forum for work that's going on outside Blink.

On Sat Aug 09 2014 at 7:59:43 AM <brua...@gmail.com> wrote:

Le vendredi 8 août 2014 18:14:15 UTC+2, Adam Barth a écrit :

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

It was exactly the same thinking for when one browser had an experimental feature and the other didn't "People won't write non-standard code since it's not interoperable. We'll be able to remove the feature later". What happened is that the websites were encouraging users to download a different browsers (not pointing fingers, it happened with pretty much all combinaisons of source and target browsers).

This time, the website just has to display a message like "your version of Chrome has a bug preventing it from running this awesome demo. Please re-install Chrome."

To be clear, the dice get re-rolled whenever you launch Chrome.

 

And "my friend can run the demo while I cannot and we're both on Chrome, that should work the same, right?" would be a powerful motivator for people to re-install Chrome.

You can re-launch Chrome to get a new roll of the dice.  That seems like a numerical problem.  Perhaps 1% would be a better size?  Then a user would have to re-launch Chrome a hundred times to game the system.

 

Exposing something experimental on the web is playing with fire.

Definitely.  That's why I take this topic seriously and why we're trying a few different approaches to see what works in practice.  The alternative is to try to design network protocols without real-world data, which will result in protocols that don't work in the real world.

I'm sympathetic with the intention of real-world testing on a large population, that's why I'm fine with exposing the experimental things on Google properties. It's a noble goal to want other web devs to test out the feature, however, as soon as you release something on the web, you cannot control what will happen.

As I wrote above, we disagree about the harm that's caused by having browsers treat one web site differently than other web sites.

 

One possible middle-ground between "google only properties" and "the entire web" would be to have web devs declare interest and the Chrome team to whitelist their domains (akin to what happens with the HSTS prelaod list [1][2]). Among other things, that would "guarantee" that the Chrome team has a point of contact with the websites running experiments, which would give you a clear way to inform people that an experimentation is coming to an end (which you don't have if you ship something on the web).
Other middlegrounds are possible. I would love to see them explored.

A similar idea that we've talked about is having API keys for experimental features.  For example, if you wanted to use the experimental parts of the web animation API, you could somehow get an API key that would be scoped to a particular set of URLs and a particular time period.

That idea is probably worth trying, but my concern is the same as with the other time-limited approaches.  When it comes time to expire the API key for a popular web site, we're back to the same game of chicken.

What's appealing to me about the <50% experiment is that we retain the option to remove the non-standard feature even if the web site doesn't cooperate with us.  Maybe you're right that 50% is too large a number and we'll need to use a smaller number like 1%.  My inclination is to try it, see how it works, learn, and iterate.

Adam

[brua...@gmail.com]

Le samedi 9 août 2014 17:11:46 UTC+2, Adam Barth a écrit :

On Sat Aug 09 2014 at 2:34:27 AM <brua...@gmail.com> wrote:

It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)

Personally, I find it frustrating to develop for a platform that grants special privileges to some developers.  For example, Chrome on Windows originally used WinInet as its network stack, but we couldn't implement HTTPS certificate handling properly because Internet Explorer used a private API to WinInet in order to implement its HTTPS certificate handling.

I don't think the web platform should grant special privileges to some developers.  As I've written earlier in this thread, that's a matter of opinion and not everyone agrees with me.  It sounds like you're in the camp of folks who disagree.

I don't want the web platform to grant special privileges to some developers, but for an experimental feature that is meant to be removed eventually, it seems like a reasonable trade-off.
What is the harm if you're sure you'll remove it eventually? I'd obviously be outraged if you any browser was considering adding a permanent feature only to some developers.

I imagine the feature will be unconditionally available in Canary builds, so the reason you want to expose the feature to the web is to gather real-world data on websites with lots of users who will use the feature (not just devs who want to play around with the feature, because they'd just use Canary).
In the end, that's a very small population you're targetting, it feels inadequate to expose the feature to a wide audience when you know the intended audience is very small (and when you know there is potential harm).

On Sat Aug 09 2014 at 7:59:43 AM <brua...@gmail.com> wrote:

Le vendredi 8 août 2014 18:14:15 UTC+2, Adam Barth a écrit :

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

It was exactly the same thinking for when one browser had an experimental feature and the other didn't "People won't write non-standard code since it's not interoperable. We'll be able to remove the feature later". What happened is that the websites were encouraging users to download a different browsers (not pointing fingers, it happened with pretty much all combinaisons of source and target browsers).
This time, the website just has to display a message like "your version of Chrome has a bug preventing it from running this awesome demo. Please re-install Chrome."

To be clear, the dice get re-rolled whenever you launch Chrome.

oh.. thanks for the clarification, it isn't what I had understood.
 

 

And "my friend can run the demo while I cannot and we're both on Chrome, that should work the same, right?" would be a powerful motivator for people to re-install Chrome.

You can re-launch Chrome to get a new roll of the dice.  That seems like a numerical problem.  Perhaps 1% would be a better size?  Then a user would have to re-launch Chrome a hundred times to game the system.

Nit: I'm not sure the maths are right here. I think we're in a draw with replacement situation, so probabilities are to be computed with geometric series.
The user wants the feature at least once among a few restarts and each restart gives the feature with 1% probability, then 69 restarts gives them 50% probability of having the feature (anytime between the first and 68th restarts).
10 restarts give almost 10% probability of having the feature sometime between the first and 9th restart.

If you get above 6,7% of having the feature, then, 10 restarts leave to having >50% chance of having the feature in one of these restarts.
Anyway, 1% is probably fine.

Code I used for the numbers :
https://gist.github.com/DavidBruant/4fd1384487c867b04d21
Formula courtesy of Wikipedia http://en.wikipedia.org/wiki/Geometric_series#Formula

This is of course all assuming that repeated restarts are an annoyance. It probably takes less than a day to write a script that restarts Chrome until some condition is reached (and less than an hour to find an open source version of it) and a website with a great service will happily distribute it to its users ("because there is a bug in Chrome" or whether excuse they'll use to convince people to run the script).
If the "restart to get experimental feature" becomes common practice, this script will quickly exist.

Exposing something experimental on the web is playing with fire.

Definitely.  That's why I take this topic seriously and why we're trying a few different approaches to see what works in practice.  The alternative is to try to design network protocols without real-world data, which will result in protocols that don't work in the real world.

That's one alternative. Another is temporarily (!) make the feature accessible only to some websites (which you rule out implicitely here).
 

 

One possible middle-ground between "google only properties" and "the entire web" would be to have web devs declare interest and the Chrome team to whitelist their domains (akin to what happens with the HSTS prelaod list [1][2]). Among other things, that would "guarantee" that the Chrome team has a point of contact with the websites running experiments, which would give you a clear way to inform people that an experimentation is coming to an end (which you don't have if you ship something on the web).
Other middlegrounds are possible. I would love to see them explored.

A similar idea that we've talked about is having API keys for experimental features.  For example, if you wanted to use the experimental parts of the web animation API, you could somehow get an API key that would be scoped to a particular set of URLs and a particular time period.

That idea is probably worth trying, but my concern is the same as with the other time-limited approaches.  When it comes time to expire the API key for a popular web site, we're back to the same game of chicken.

There are probably ways to work around that. Now that you control the population who has access you can decide to disable the feature, say, one week out of two. Of course inform the website owners that you're doing so. This way, their website breaks one week out of two, so they cannot rely solely on the feature. Either they have to have a fallback (so won't be bothered by a permanent disappearance of the feature) or users will know that the website doesn't always work and won't rely on it.
There are probably other better ideas to explore, but as said above, the exposure of this feature on the web is temporary and is targetting a very small population (a website really needs a big population of users if they want to experiment with something that is there for 1% of users with statistical significance), so you have a good reason to restrict it.

David

[j...@google.com]

On Saturday, August 9, 2014 9:30:55 AM UTC-7, brua...@gmail.com wrote:

Le samedi 9 août 2014 17:11:46 UTC+2, Adam Barth a écrit :

On Sat Aug 09 2014 at 2:34:27 AM <brua...@gmail.com> wrote:

It's honorable of Google to want to experiment at scale (in number of users), but it doesn't mean it has to be at scale (number of websites with access to the feature)

Personally, I find it frustrating to develop for a platform that grants special privileges to some developers.  For example, Chrome on Windows originally used WinInet as its network stack, but we couldn't implement HTTPS certificate handling properly because Internet Explorer used a private API to WinInet in order to implement its HTTPS certificate handling.

I don't think the web platform should grant special privileges to some developers.  As I've written earlier in this thread, that's a matter of opinion and not everyone agrees with me.  It sounds like you're in the camp of folks who disagree.

I don't want the web platform to grant special privileges to some developers, but for an experimental feature that is meant to be removed eventually, it seems like a reasonable trade-off.
What is the harm if you're sure you'll remove it eventually? I'd obviously be outraged if you any browser was considering adding a permanent feature only to some developers.

I imagine the feature will be unconditionally available in Canary builds, so the reason you want to expose the feature to the web is to gather real-world data on websites with lots of users who will use the feature (not just devs who want to play around with the feature, because they'd just use Canary).
In the end, that's a very small population you're targetting, it feels inadequate to expose the feature to a wide audience when you know the intended audience is very small (and when you know there is potential harm).

Just to throw my two cents in, it seems like fundamentally, what we're trying to achieve is a whitelist for Google properties. While I'm not really in favor of doing this, if we are going to, it seems more honest with ourselves and everyone if we use a whitelist in Chrome that define what origins can use the special implementation/features that define what sites can use the unprefixed version of the feature.

In any case, if we do go ahead with prefixes in cases like this, we ought to have a chromium.org doc to clearly define the conditions under which we allow them so they don't bleed into other use cases, as Domenic suggested earlier.

--Joel 

[j...@chromium.org]

Just to throw my two cents in, it seems like fundamentally, what we're trying to achieve is a whitelist for Google properties. While I'm not really in favor of doing this, if we are going to, it seems more honest with ourselves and everyone if we use a whitelist in Chrome that define what origins can use the special implementation/features that define what sites can use the unprefixed version of the feature.

In any case, if we do go ahead with prefixes in cases like this, we ought to have a chromium.org doc to clearly define the conditions under which we allow them so they don't bleed into other use cases.

--Joel

On Saturday, August 9, 2014 9:30:55 AM UTC-7, brua...@gmail.com wrote:

[Aaron Boodman]

FWIW, I think the percent-limited experiment approach is great. I proposed it awhile back (https://plus.google.com/u/0/b/109132032588648589691/109132032588648589691/posts/84byPDaVLYa), but others on blink-dev weren't that happy about it back then. I'm glad to see it come back 'round :).

I think it works best for cases where the experimental feature provides some genuine value to either the developer or user, but it's still possible to implement the application reasonably well using the fallback.

- a

On Fri, Aug 8, 2014 at 9:14 AM, Adam Barth <aba...@chromium.org> wrote:

Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.

Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.

Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.

Adam

On Fri Aug 08 2014 at 3:50:42 AM PhistucK <phis...@gmail.com> wrote:

A recent commit (August 7th, 2014) in WebRTC added a goog prefixed constraint to webkitGetUserMedia -

​​

Log message

(Auto)update libjingle 72847605-> 72850595

Affected files

     expand all   collapse all

	Modify	/trunk/talk/app/webrtc/mediaconstraintsinterface.cc	diff
	... 95 95 "googSuspendBelowMinBitrate"; 96 96 const char MediaConstraintsInterface::kImprovedWifiBwe[] = 97 97 "googImprovedWifiBwe"; 98 + const char MediaConstraintsInterface::kNumUnsignalledRecvStreams[] = 99 + "googNumUnsignalledRecvStreams"; 98 100 const char MediaConstraintsInterface::kScreencastMinBitrate[] = 99 101 "googScreencastMinBitrate"; 100 102 // TODO(ronghuawu): Remove once cpu overuse detection is stable. ...

Prefixing features is harmful to the web platform, making websites incompatible with other browsers, breaking assumptions, causing monopolization and hurting competition. People rely on prefixed features instead of treating them as non production, experimental features that (not only could) will change, break and disappear soon. I listed some details in the last section of this post.

Blink (of Chrome) and Gecko (of Firefox) have announced long ago they will not be adding prefixed features anymore.

Instead, experimental features are disabled by default and can usually be turned on by using a command line flag (about:flags in Chrome) or by setting a certain preference (about:config in Firefox).

In this example, you can use the Experimental Web Platform Features flag in Chrome in order to expose any experimental functionality (a prefix is not needed then, because it is meaningless if it is not exposed to the web by default anyway).

This lets any Chrome user that is looking to experiment with the functionality that you want to introduce, experiment with it by simply flipping a flag, which is really not a big deal.

If you need help with plumbing the flag into WebRTC, I can try diving into the code and come up with a clean way of exposing such concepts ("kEnableExperimentations" or so).

I (and the entire web) would appreciate it, if you could move all of the prefixed features and constraints in WebRTC (meaning, prefixed getStats statistics and prefixed media and peer connection constraints, or any other prefixed feature that is currently exposed by default to the web) behind the Experimental Web Platform Features flag, that can be easily turned on from about:flags.

Note - I am mostly referring to goog prefixed features here. Unless I am mistaken, webkit prefixed WebRTC features (like webkitGetUserMedia, webkitRTCPeerConnection and webkitMediaStream and others with which I might not be familiar) are features that should be deprecated and unprefixed, as soon as possible, rather than be moved behind a flag.

Here are a few reasons, explanations and arguments, some of them are recent and some are not -

- http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/ (I am not sure Firefox actually implemented -webkit- prefixed feature eventually, though).

- http://www.paulirish.com/2012/vendor-prefixes-are-not-developer-friendly/

- http://www.chromium.org/blink#vendor-prefixes

- http://css.dzone.com/articles/are-vendor-prefixes-harmful

- Microsoft just recently announced that Internet Explorer 11 on Window Phone 8.1 Update 1 added support for -webkit- prefixed CSS because websites were incompatible with Internet Explorer, because they only relied on vendor prefixes, because they simply worked with the default browsers.

- Opera did the same with Presto (their rendering engine, prior to switching to WebKit and then Blink), in order to be compatible with the vendor prefix encumbered web.

Thank you very much (everyone here) for all of your work. You are doing amazing things to the web.

☆PhistucK

[Ryan Sleevi]

Perhaps, but doesn't it also benefit those who are first to gather data using the prefix - and penalize late comers?

That is, using WebRTC as an example, it seems the prefix is to allow WebRTC-using sites to change/adapt their infrastructure. If we believed it was for the benefit of Chrome users directly, we could just expose the data gathering as part of Chrome UMA, without ever exposing to the web.

So sites that know about the prefix - which, presumably, includes Google sites (and, had PhistucK not mentioned it, may have been JUST Google sites), that can quickly adopt the prefix and gather data, have a greater chance to shape and influence the decisions.

How do we decide when we can remove the prefix? When we've decided we have collected enough data? Considering its the site operators collecting the data, this is the same as saying "When Google services decide they no longer need the data" - since if we kept it around (even at 50%) for other services, then we really are doing exactly what is wrong with prefixes - making them a defacto part of the platform.

So the prefixes deployed only benefit those that fastidiously follow Chrome development, can influence and convince Chrome devs to add a prefix, and convince Chrome devs to avoid removing a prefix until "sufficient" data is collected. That seems to be, effectively, Google only, so why not be transparent and spell that out in code?

Either way, if this is the route we go, a huge +1 to a clear and transparent policy.

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

[Aaron Boodman]

On Sat, Aug 9, 2014 at 10:49 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

Perhaps, but doesn't it also benefit those who are first to gather data using the prefix - and penalize late comers?

It benefits developers who are aware of the experiment and take advantage of it. It might also benefit them if they provide feedback to vendors which results in changes to the API before it is finalized. It also (hopefully) benefits the users who are in the experiment group, because they get some new/better feature.

That is, using WebRTC as an example, it seems the prefix is to allow WebRTC-using sites to change/adapt their infrastructure. If we believed it was for the benefit of Chrome users directly, we could just expose the data gathering as part of Chrome UMA, without ever exposing to the web.

I don't know enough about this particular API to say whether there is some other way to do it besides adding DOM APIs to the platform.

So sites that know about the prefix - which, presumably, includes Google sites (and, had PhistucK not mentioned it, may have been JUST Google sites), that can quickly adopt the prefix and gather data, have a greater chance to shape and influence the decisions.

I would be in favor of us telling people widely when we were doing this so that lots of developers could take advantage of it and we'd get lots of feedback.

How do we decide when we can remove the prefix? When we've decided we have collected enough data? Considering its the site operators collecting the data, this is the same as saying "When Google services decide they no longer need the data" - since if we kept it around (even at 50%) for other services, then we really are doing exactly what is wrong with prefixes - making them a defacto part of the platform.

This is where I disagree. Vendor-prefixed properties become a defacto part of the platform when they are present in a large enough percent of users' browsers that it starts becoming economically worthwhile for developers to optimize for that case and to ignore the case where the property doesn't exist.

As long as the chance of the property existing is relatively small, then developers must continue to invest in the case where the property is missing, and the property can be removed at any time without breaking sites.

So the prefixes deployed only benefit those that fastidiously follow Chrome development, can influence and convince Chrome devs to add a prefix, and convince Chrome devs to avoid removing a prefix until "sufficient" data is collected. That seems to be, effectively, Google only, so why not be transparent and spell that out in code?

I hadn't been thinking about the idea as a way to add Google-privileged APIs -- I was thinking of it as a better way for the Blink team to get early feedback on features which are genuinely on a standards track.

[Ryan Sleevi]

On Aug 9, 2014 11:35 AM, "Aaron Boodman" <a...@chromium.org> wrote:
>
> On Sat, Aug 9, 2014 at 10:49 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>> Perhaps, but doesn't it also benefit those who are first to gather data using the prefix - and penalize late comers?
>
> It benefits developers who are aware of the experiment and take advantage of it. It might also benefit them if they provide feedback to vendors which results in changes to the API before it is finalized. It also (hopefully) benefits the users who are in the experiment group, because they get some new/better feature.
>>
>> That is, using WebRTC as an example, it seems the prefix is to allow WebRTC-using sites to change/adapt their infrastructure. If we believed it was for the benefit of Chrome users directly, we could just expose the data gathering as part of Chrome UMA, without ever exposing to the web.
>
> I don't know enough about this particular API to say whether there is some other way to do it besides adding DOM APIs to the platform.
>>
>> So sites that know about the prefix - which, presumably, includes Google sites (and, had PhistucK not mentioned it, may have been JUST Google sites), that can quickly adopt the prefix and gather data, have a greater chance to shape and influence the decisions.
>
> I would be in favor of us telling people widely when we were doing this so that lots of developers could take advantage of it and we'd get lots of feedback.

+1, and why I think we should codify policy.

>>
>> How do we decide when we can remove the prefix? When we've decided we have collected enough data? Considering its the site operators collecting the data, this is the same as saying "When Google services decide they no longer need the data" - since if we kept it around (even at 50%) for other services, then we really are doing exactly what is wrong with prefixes - making them a defacto part of the platform.
>
> This is where I disagree. Vendor-prefixed properties become a defacto part of the platform when they are present in a large enough percent of users' browsers that it starts becoming economically worthwhile for developers to optimize for that case and to ignore the case where the property doesn't exist.
>
> As long as the chance of the property existing is relatively small, then developers must continue to invest in the case where the property is missing, and the property can be removed at any time without breaking sites.

Except when it let's you optimize your server infrastructure ahead of those that aren't gathering the data, and indepdent of how it influences the client side.

Much of the data being gathered here can certainly help influence the standards process for WebRTC, of which Google is involved with in every aspect. But I think there is a real danger of using Chrome to act as a client-side metrics gathering for server side properties, which was true for webGL prefixes, and is true here, both to degrees.

While it helps standards - running code and real world experience - we do need to be careful here. And it doesn't seem like we've been doing well, especially around transparency (AFAICT)

>>
>> So the prefixes deployed only benefit those that fastidiously follow Chrome development, can influence and convince Chrome devs to add a prefix, and convince Chrome devs to avoid removing a prefix until "sufficient" data is collected. That seems to be, effectively, Google only, so why not be transparent and spell that out in code?
>
> I hadn't been thinking about the idea as a way to add Google-privileged APIs -- I was thinking of it as a better way for the Blink team to get early feedback on features which are genuinely on a standards track.
>>
>> Either way, if this is the route we go, a huge +1 to a clear and transparent policy.
>>
>> On Aug 9, 2014 10:37 AM, "Aaron Boodman" <a...@chromium.org> wrote:
>>>
>>> FWIW, I think the percent-limited experiment approach is great. I proposed it awhile back (https://plus.google.com/u/0/b/109132032588648589691/109132032588648589691/posts/84byPDaVLYa), but others on blink-dev weren't that happy about it back then. I'm glad to see it come back 'round :).
>>>
>>> I think it works best for cases where the experimental feature provides some genuine value to either the developer or user, but it's still possible to implement the application reasonably well using the fallback.
>>>
>>> - a
>>>
>>>
>>> On Fri, Aug 8, 2014 at 9:14 AM, Adam Barth <aba...@chromium.org> wrote:
>>>>
>>>> Juberti and I discussed this topic, and the approach we agreed upon was to continue to use vendor-prefixed properties but only expose new vendor-prefixed properties in <=50% of installs.
>>>>
>>>> Exposing non-standard properties lets us run experiments to improve WebRTC and limiting the exposure to <=50% of installs prevents web sites from assuming the properties exist.  Specifically, the web sites still need to work for the 50% of users who don't have the non-standard features, which will give us the ability to remove these features when the experiment is over.
>>>>
>>>> Hopefully that approach strikes a good balance between gathering data to improve WebRTC and avoiding web sites becoming dependent on non-standard features.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Fri Aug 08 2014 at 3:50:42 AM PhistucK <phis...@gmail.com> wrote:
>>>>>
>>>>> A recent commit (August 7th, 2014) in WebRTC added a goog prefixed constraint to webkitGetUserMedia -
>>>>> ​​
>>>>> Log message
>>>>>
>>>>> (Auto)update libjingle 72847605-> 72850595
>>>>>
>>>>> Affected files
>>>>>      expand all   collapse all

[Tab Atkins Jr.]

On Sat, Aug 9, 2014 at 10:10 AM, <j...@chromium.org> wrote:
> Just to throw my two cents in, it seems like fundamentally, what we're
> trying to achieve is a whitelist for Google properties. While I'm not really
> in favor of doing this, if we are going to, it seems more honest with
> ourselves and everyone if we use a whitelist in Chrome that define what
> origins can use the special implementation/features that define what sites
> can use the unprefixed version of the feature.
>
> In any case, if we do go ahead with prefixes in cases like this, we ought to
> have a chromium.org doc to clearly define the conditions under which we
> allow them so they don't bleed into other use cases.

Agree. Like Aaron Boodman, I was an proponent of using randomized
activation of features as a replacement for prefixes.

Note, though - as far as I can tell, randomization does *not* mean you
can proceed without prefixes! In fact, it requires prefixes; the
randomization part just forces authors to not *depend* on those
prefixes existing.

If you do randomization + no prefix, then you just get developers with
a code path for "no feature" and one for "experimental version of
feature", and the latter will be triggered (and possibly break) when
the updated version of the the feature ships for real.

We should have a proper discussion of this, and definitely write up a
doc for it.

~TJ