Update deprecation messages for powerful features on insecure origins

Update deprecation messages for powerful features on insecure origins

This makes two particular changes to the deprecation messages for
powerful features on insecure origins:
  * Rewords the messages to be clearer and more accurate
  * Removes deprecation messages for device motion and orientation until
  we get a better understanding of what's causing their high usage.

TBR=mvanouwerkerk@chromium.org,timvolodine@chromium.org,mlamouri@chromium.org
BUG=481604
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=195007

[jww, 2015-05-05 21:28:13]

jww@chromium.org changed reviewers:
+ mlamouri@chromium.org, mvanouwerkerk@chromium.org, philipj@opera.com,
timvolodine@chromium.org

[philipj_slow, 2015-05-06 07:45:30]

lgtm

[timvolodine, 2015-05-06 11:03:13]

On 2015/05/06 07:45:30, philipj_UTC2 wrote:
> lgtm

I think the high usage numbers are incorrect, but they should be correct after
the fix in https://codereview.chromium.org/1000173002/. Looks like the fix
didn't make it to M42 though, but it should be in M43

[philipj_slow, 2015-05-06 12:04:13]

Another thing to consider is measuring at some other place. AFAICT, the use
counter is now triggered when the event listener is added, even if the event
never fires. The very most conservative counter would be for access to the
attributes on the DeviceMotionEvent and DeviceOrientationEvent interfaces.

[jww, 2015-05-06 21:53:13]

On 2015/05/06 12:04:13, philipj_UTC2 wrote:
> Another thing to consider is measuring at some other place. AFAICT, the use
> counter is now triggered when the event listener is added, even if the event
> never fires. The very most conservative counter would be for access to the
> attributes on the DeviceMotionEvent and DeviceOrientationEvent interfaces.

timvolodine: Thanks for the pointer to that CL! We'll reevaluate those numbers
and the deprecation once those new numbers roll in.

philipj: The current measurement seems to me to be the most conservative. That
is, a developer can only be using the feature if they register an event handler,
but they still might not be using it depending on if the event actually fires.
At the very least, this measurement is an upper bound on the number of page
loads interested in device motion and orientation.

Given that this CL is just a wording change for the features, I'm going to TBR
the feature owners. and commit. Thanks!

[jww, 2015-05-06 21:54:14]

jww@chromium.org changed reviewers:
- mlamouri@chromium.org, mvanouwerkerk@chromium.org, timvolodine@chromium.org

[jww, 2015-05-06 21:54:27]

The CQ bit was checked by jww@chromium.org

[commit-bot: I haz the power, 2015-05-06 21:55:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1125573003/40001

[philipj_slow, 2015-05-06 22:08:48]

On 2015/05/06 21:53:13, jww wrote:
> On 2015/05/06 12:04:13, philipj_UTC2 wrote:
> > Another thing to consider is measuring at some other place. AFAICT, the use
> > counter is now triggered when the event listener is added, even if the event
> > never fires. The very most conservative counter would be for access to the
> > attributes on the DeviceMotionEvent and DeviceOrientationEvent interfaces.
> 
> philipj: The current measurement seems to me to be the most conservative. That
> is, a developer can only be using the feature if they register an event
handler,
> but they still might not be using it depending on if the event actually fires.
> At the very least, this measurement is an upper bound on the number of page
> loads interested in device motion and orientation.

I think we meant the opposite things by conservative in this context, but in any
event measuring actual access to the values read from the underlying hardware
would necessary give lower numbers than the current counters. (And it seems
fairly likely that on desktop some sites register for the events but they never
fire.)

[philipj_slow, 2015-05-06 22:09:37]

(This still LGTM of course, just throwing out ideas if the refined counters
still disappoint with high usage.)

[commit-bot: I haz the power, 2015-05-06 23:34:33]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=195007

[jww, 2015-05-08 23:33:41]

On 2015/05/06 22:08:48, philipj_UTC2 wrote:
> On 2015/05/06 21:53:13, jww wrote:
> > On 2015/05/06 12:04:13, philipj_UTC2 wrote:
> > > Another thing to consider is measuring at some other place. AFAICT, the
use
> > > counter is now triggered when the event listener is added, even if the
event
> > > never fires. The very most conservative counter would be for access to the
> > > attributes on the DeviceMotionEvent and DeviceOrientationEvent interfaces.
> > 
> > philipj: The current measurement seems to me to be the most conservative.
That
> > is, a developer can only be using the feature if they register an event
> handler,
> > but they still might not be using it depending on if the event actually
fires.
> > At the very least, this measurement is an upper bound on the number of page
> > loads interested in device motion and orientation.
> 
> I think we meant the opposite things by conservative in this context, but in
any
> event measuring actual access to the values read from the underlying hardware
> would necessary give lower numbers than the current counters. (And it seems
> fairly likely that on desktop some sites register for the events but they
never
> fire.)

Got it. I think we're in violent agreement ;-)

[jww, 2015-06-01 23:27:48]

On 2015/05/08 23:33:41, jww wrote:
> On 2015/05/06 22:08:48, philipj_UTC2 wrote:
> > On 2015/05/06 21:53:13, jww wrote:
> > > On 2015/05/06 12:04:13, philipj_UTC2 wrote:
> > > > Another thing to consider is measuring at some other place. AFAICT, the
> use
> > > > counter is now triggered when the event listener is added, even if the
> event
> > > > never fires. The very most conservative counter would be for access to
the
> > > > attributes on the DeviceMotionEvent and DeviceOrientationEvent
interfaces.
> > > 
> > > philipj: The current measurement seems to me to be the most conservative.
> That
> > > is, a developer can only be using the feature if they register an event
> > handler,
> > > but they still might not be using it depending on if the event actually
> fires.
> > > At the very least, this measurement is an upper bound on the number of
page
> > > loads interested in device motion and orientation.
> > 
> > I think we meant the opposite things by conservative in this context, but in
> any
> > event measuring actual access to the values read from the underlying
hardware
> > would necessary give lower numbers than the current counters. (And it seems
> > fairly likely that on desktop some sites register for the events but they
> never
> > fire.)
> 
> Got it. I think we're in violent agreement ;-)

It looks like the fix to the device motion metrics is starting to roll in, and
DeviceMotionInsecureOrigin is hovering around 4.5%
(https://www.chromestatus.com/metrics/feature/popularity#DeviceMotionInsecureO...).
philipj@, do you think that's still too high for deprecation messages?

[philipj_slow, 2015-06-02 07:38:51]

On 2015/06/01 23:27:48, jww wrote:
> It looks like the fix to the device motion metrics is starting to roll in, and
> DeviceMotionInsecureOrigin is hovering around 4.5%
>
(https://www.chromestatus.com/metrics/feature/popularity#DeviceMotionInsecureO...).
> philipj@, do you think that's still too high for deprecation messages?

It looks like it's still falling, but for the sake of argument let's say it
stabilizes at 1% on Android. (I can't get this data, but you can internally at
Google.) 1% is definitely higher than most deprecations, and deprecation
messages generally don't seem to influencing usage. What is the threshold where
you think it would be reasonable to actually disable device motion events on
insecure origins? This would have to be some trade off between the severity of
the security risk and what kind of breakage would result. It might be best to
have that discussion on blink-dev.

[jww, 2015-06-04 00:59:23]

Yes, that was sort of my assumption as well. I'll revisit this later if the
numbers drop further and/or we come up with a good way to discourage use
before then.

On Tue, Jun 2, 2015 at 12:38 AM <philipj@opera.com> wrote:

> On 2015/06/01 23:27:48, jww wrote:
> > It looks like the fix to the device motion metrics is starting to roll
> > in, and
> > DeviceMotionInsecureOrigin is hovering around 4.5%
>
> (
>
https://www.chromestatus.com/metrics/feature/popularity#DeviceMotionInsecureO...
> ).
> > philipj@, do you think that's still too high for deprecation messages?
>
> It looks like it's still falling, but for the sake of argument let's say it
> stabilizes at 1% on Android. (I can't get this data, but you can internally
> at
> Google.) 1% is definitely higher than most deprecations, and deprecation
> messages generally don't seem to influencing usage. What is the threshold
> where
> you think it would be reasonable to actually disable device motion events
> on
> insecure origins? This would have to be some trade off between the severity
> of
> the security risk and what kind of breakage would result. It might be best
> to
> have that discussion on blink-dev.
>
> https://codereview.chromium.org/1125573003/
>

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