Add rappor logging for Device Orientation on security origins different from the main frame

Add rappor logging for Device Orientation on security origins different from the main frame

To address privacy/security concerns regaring exposing sensor
related information on cross origin sub frames it has been
suggested to restict usage of the api to frames with same
origin as the main frame (crbug.com/523320, crbug.com/598674).

As a first step towards applying this restriction this patch adds
some rappor logging to assess the current usage of Device Orientation
on cross origin frames. This is to ensure we don't break pages and
to analyze existing cross-origin use cases of the API.

BUG=598674
Review-Url: https://codereview.chromium.org/2698723002
Cr-Commit-Position: refs/heads/master@{#454373}
Committed: https://chromium.googlesource.com/chromium/src/+/21a19aa03091e1b0b0be9ab87e97d86d15527b94

[timvolodine, 2017-02-15 19:38:51]

timvolodine@chromium.org changed reviewers:
+ rbyers@chromium.org

[timvolodine, 2017-02-17 19:47:02]

Rick, what do you think? I've discussed this briefly some time ago with ojan@
and it was suggested this would be the way forward.

[Rick Byers, 2017-02-17 22:21:28]

LGTM, thanks - this will be interesting!

We don't already have a UseCounter for this, do we?  We'll also want to be able
to answer the more typical "what fractions of page visits does this occur for"
question.

Are you also talking about doing an opt-out?  Eg. a feature-policy the
containing page can set to explicitly enable sensor access in an iframe?  I
think we're starting to standardize on that pattern (eg. <iframe
allow=paymentrequest>).

https://codereview.chromium.org/2698723002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp
(right):

https://codereview.chromium.org/2698723002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp:84:
return true;
Looks like this logic is the same as in
Deprecation::countDeprecationCrossOriginIframe - good.  Ultimately (eg. if/when
we move to generating a deprecation warning for this) we may want to share a bit
more code, but not worth worrying about here.

[timvolodine, 2017-02-28 15:48:15]

https://codereview.chromium.org/2698723002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp
(right):

https://codereview.chromium.org/2698723002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp:84:
return true;
On 2017/02/17 22:21:28, Rick Byers wrote:
> Looks like this logic is the same as in
> Deprecation::countDeprecationCrossOriginIframe - good.  Ultimately (eg.
if/when
> we move to generating a deprecation warning for this) we may want to share a
bit
> more code, but not worth worrying about here.

Yes, acknowledged.

[timvolodine, 2017-02-28 15:49:59]

Thanks for the review! sorry for the delay.

On 2017/02/17 22:21:28, Rick Byers wrote:
> LGTM, thanks - this will be interesting!
> 
> We don't already have a UseCounter for this, do we?  We'll also want to be
able
> to answer the more typical "what fractions of page visits does this occur for"
> question.

Don't think we have a UseCounter for this.. good point about the fractions I'll
look into it as a follow-up. As a first step it will be exiting (indeed!) to see
what kind of actual usage we get here.

> 
> Are you also talking about doing an opt-out?  Eg. a feature-policy the
> containing page can set to explicitly enable sensor access in an iframe?  I
> think we're starting to standardize on that pattern (eg. <iframe
> allow=paymentrequest>).

I think the actual idea is to have some kind of opt-in, e.g. as you mentioned
using <iframe allow=deviceorientation> or so..

> 
>
https://codereview.chromium.org/2698723002/diff/1/third_party/WebKit/Source/c...
> File
third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp
> (right):
> 
>
https://codereview.chromium.org/2698723002/diff/1/third_party/WebKit/Source/c...
> third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp:84:
> return true;
> Looks like this logic is the same as in
> Deprecation::countDeprecationCrossOriginIframe - good.  Ultimately (eg.
if/when
> we move to generating a deprecation warning for this) we may want to share a
bit
> more code, but not worth worrying about here.

[timvolodine, 2017-02-28 15:50:29]

timvolodine@chromium.org changed reviewers:
+ isherman@chromium.org

[timvolodine, 2017-02-28 15:50:30]

+isherman@: for rapport.xml

[timvolodine, 2017-02-28 15:50:56]

On 2017/02/28 15:50:30, timvolodine wrote:
> +isherman@: for rapport.xml

ehh rappor.xml )

[timvolodine, 2017-02-28 19:03:47]

The CQ bit was checked by timvolodine@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 19:04:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[timvolodine, 2017-02-28 19:04:32]

FYI actually also added same thing for DeviceMotion

[commit-bot: I haz the power, 2017-02-28 20:51:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-28 20:51:46]

Dry run: This issue passed the CQ dry run.

[Ilya Sherman, 2017-03-01 00:45:50]

rappor.xml lgtm

[timvolodine, 2017-03-02 19:28:50]

The CQ bit was checked by timvolodine@chromium.org

[timvolodine, 2017-03-02 19:28:51]

The patchset sent to the CQ was uploaded after l-g-t-m from rbyers@chromium.org
Link to the patchset: https://codereview.chromium.org/2698723002/#ps20001
(title: "add DEviceMotion")

[commit-bot: I haz the power, 2017-03-02 19:29:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-02 21:03:59]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1488482930799280,
"parent_rev": "8aabdcad0847a4f400063e4a143df883bc6c2d62", "commit_rev":
"21a19aa03091e1b0b0be9ab87e97d86d15527b94"}

[commit-bot: I haz the power, 2017-03-02 21:04:34]

Description was changed from

==========
Add rappor logging for Device Orientation on security origins different from the
main frame

To address privacy/security concerns regaring exposing sensor
related information on cross origin sub frames it has been
suggested to restict usage of the api to frames with same
origin as the main frame (crbug.com/523320, crbug.com/598674).

As a first step towards applying this restriction this patch adds
some rappor logging to assess the current usage of Device Orientation
on cross origin frames. This is to ensure we don't break pages and
to analyze existing cross-origin use cases of the API.

BUG=598674
==========

to

==========
Add rappor logging for Device Orientation on security origins different from the
main frame

To address privacy/security concerns regaring exposing sensor
related information on cross origin sub frames it has been
suggested to restict usage of the api to frames with same
origin as the main frame (crbug.com/523320, crbug.com/598674).

As a first step towards applying this restriction this patch adds
some rappor logging to assess the current usage of Device Orientation
on cross origin frames. This is to ensure we don't break pages and
to analyze existing cross-origin use cases of the API.

BUG=598674

Review-Url: https://codereview.chromium.org/2698723002
Cr-Commit-Position: refs/heads/master@{#454373}
Committed:
https://chromium.googlesource.com/chromium/src/+/21a19aa03091e1b0b0be9ab87e97...
==========

[commit-bot: I haz the power, 2017-03-02 21:04:36]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/21a19aa03091e1b0b0be9ab87e97...