New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 520765 link

Starred by 37 users

Issue metadata

Status: Assigned
Owner:
OOO until 4th
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Task

Blocked on:
issue 561641
issue 603574

Blocking:
issue 547654



Sign in to add a comment

Deprecation and removal of powerful features on insecure origins

Project Member Reported by jww@chromium.org, Aug 14 2015

Issue description

(See http://www.chromium.org/blink#launch-process for an overview)

Change description:
Deprecation and eventual removal of powerful features on insecure origins.

Changes to API surface:
* Device motion / orientation
* EME
* Fullscreen
* Geolocation
* getUserMedia

Links:
This has been extensively discussed on blink-dev: https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ
There is apparent consensus on some of the APIs, but not all.

Powerful features spec: http://www.w3.org/TR/powerful-features/

Support in other browsers:
Internet Explorer: No word.
Firefox: Has expressed an intent to deprecate and remove these APIs from powerful origins.
Safari: No word.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Aug 21 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8440052c7882f61cfde793f687e72717c85e0d8f

commit 8440052c7882f61cfde793f687e72717c85e0d8f
Author: jww <jww@chromium.org>
Date: Fri Aug 21 01:05:47 2015

Setup for moving getUserMedia to secure origins only

This makes two notable changes:
  * Removes the browser tests that verify that the getUserMedia
    permission is not "sticky" on insecure origins.
  * Moves the addition of the chrome-extension: and
    chrome-extension-resource: schemes to extensions::Dispatcher.

The former is necessary because once getUserMedia is removed from
insecure origins, the browser test will (correctly) fail. Thus this is
part of a two sided patch.

The later is necessary because extension browser tests that use
getUserMedia will start failing once the change is made, because the
tests use ShellContentRendererClient, which doesn't currently treat
chrome-extension: schemes as secure, so getUserMedia will be disallowed
by the renderer. By marking the scheme as secure in
extensions::Dispatcher instead of in
ChromeContentRendererClient::RenderThreadStarted, the schemes will be
marked as secure in ShellContentRendererClient as well, so getUserMedia
will be allowed in the browser tests.

BUG=520765

Review URL: https://codereview.chromium.org/1301653005

Cr-Commit-Position: refs/heads/master@{#344635}

[modify] http://crrev.com/8440052c7882f61cfde793f687e72717c85e0d8f/chrome/browser/media/chrome_media_stream_infobar_browsertest.cc
[modify] http://crrev.com/8440052c7882f61cfde793f687e72717c85e0d8f/chrome/renderer/chrome_content_renderer_client.cc
[modify] http://crrev.com/8440052c7882f61cfde793f687e72717c85e0d8f/extensions/renderer/dispatcher.cc
[modify] http://crrev.com/8440052c7882f61cfde793f687e72717c85e0d8f/extensions/shell/renderer/shell_content_renderer_client.cc

Project Member

Comment 3 by bugdroid1@chromium.org, Aug 21 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=201012

------------------------------------------------------------------
r201012 | jww@chromium.org | 2015-08-21T20:38:02.748133Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html?r1=201012&r2=201011&pathrev=201012
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt?r1=201012&r2=201011&pathrev=201012
   M http://src.chromium.org/viewvc/blink/trunk/Source/modules/mediastream/MediaDevices.cpp?r1=201012&r2=201011&pathrev=201012

Removal of mediaDevices.getUserMedia from insecure origins

A previous commit removed support for webkitGetUserMedia from insecure
origins. This removes support from the still-behind-a-flag, promise
based mediaDevices.getUserMedia from insecure origins as well.

BUG=520765

Review URL: https://codereview.chromium.org/1311473003
-----------------------------------------------------------------
Project Member

Comment 4 by bugdroid1@chromium.org, Aug 25 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f0d3f1086f14baddc8914d3683125c65c4eed82c

commit f0d3f1086f14baddc8914d3683125c65c4eed82c
Author: phoglund <phoglund@chromium.org>
Date: Tue Aug 25 16:42:17 2015

Now pulling WebRTC telemetry pages from https instead of http.

https://codereview.chromium.org/1301653005 changed getUserMedia so it
only works for secure origins, which led gUM to be blocked. This patch
makes us pull our demo pages from https instead of http. Web page
replay seems to respect https, and will play back as https, so this
should solve the problem.

BUG=520765, 523517 
CQ_EXTRA_TRYBOTS=tryserver.chromium.perf:linux_perf_bisect;tryserver.chromium.perf:mac_perf_bisect;tryserver.chromium.perf:win_perf_bisect;tryserver.chromium.perf:android_nexus5_perf_bisect

Review URL: https://codereview.chromium.org/1313873002

Cr-Commit-Position: refs/heads/master@{#345350}

[modify] http://crrev.com/f0d3f1086f14baddc8914d3683125c65c4eed82c/tools/perf/benchmarks/webrtc.py
[modify] http://crrev.com/f0d3f1086f14baddc8914d3683125c65c4eed82c/tools/perf/page_sets/data/webrtc_cases.json
[add] http://crrev.com/f0d3f1086f14baddc8914d3683125c65c4eed82c/tools/perf/page_sets/data/webrtc_cases_013.wpr.sha1
[modify] http://crrev.com/f0d3f1086f14baddc8914d3683125c65c4eed82c/tools/perf/page_sets/webrtc_cases.py

Project Member

Comment 5 by bugdroid1@chromium.org, Aug 26 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/aaaef28db8754ded3543aead60f75fce9867c99a

commit aaaef28db8754ded3543aead60f75fce9867c99a
Author: phoglund <phoglund@chromium.org>
Date: Wed Aug 26 15:52:26 2015

Revert of Now pulling WebRTC telemetry pages from https instead of http. (patchset #2 id:20001 of https://codereview.chromium.org/1313873002/ )

Reason for revert:
Breaks http://build.chromium.org/p/chromium.perf/builders/Linux%20Perf%20%284%29.

Original issue's description:
> Now pulling WebRTC telemetry pages from https instead of http.
>
> https://codereview.chromium.org/1301653005 changed getUserMedia so it
> only works for secure origins, which led gUM to be blocked. This patch
> makes us pull our demo pages from https instead of http. Web page
> replay seems to respect https, and will play back as https, so this
> should solve the problem.
>
> BUG=520765, 523517 
> CQ_EXTRA_TRYBOTS=tryserver.chromium.perf:linux_perf_bisect;tryserver.chromium.perf:mac_perf_bisect;tryserver.chromium.perf:win_perf_bisect;tryserver.chromium.perf:android_nexus5_perf_bisect
>
> Committed: https://crrev.com/f0d3f1086f14baddc8914d3683125c65c4eed82c
> Cr-Commit-Position: refs/heads/master@{#345350}

TBR=sullivan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=520765, 523517 

Review URL: https://codereview.chromium.org/1303193004

Cr-Commit-Position: refs/heads/master@{#345611}

[modify] http://crrev.com/aaaef28db8754ded3543aead60f75fce9867c99a/tools/perf/benchmarks/webrtc.py
[modify] http://crrev.com/aaaef28db8754ded3543aead60f75fce9867c99a/tools/perf/page_sets/data/webrtc_cases.json
[delete] http://crrev.com/00c2c4809065b53e7f6f9f1db7a5757d3ecef85c/tools/perf/page_sets/data/webrtc_cases_013.wpr.sha1
[modify] http://crrev.com/aaaef28db8754ded3543aead60f75fce9867c99a/tools/perf/page_sets/webrtc_cases.py

Comment 6 by raymes@chromium.org, Aug 31 2015

jww: it seems like this would make it impossible for users to add exceptions for http sites. Is that intended? Should this be something we want to support? I've had the impression that palmer@ has been in favour of allowing users to add arbitrary exceptions in the past.

Comment 7 by jww@chromium.org, Aug 31 2015

It does allow users to use --unsafely-treat-insecure-origin-as-secure; is that what you mean?

Comment 8 by jww@chromium.org, Sep 8 2015

Labels: Merge-Request-46
Based on various discussions, it was decided that we should hold off 1 release on this, thus I'd like to put in a merge request to M-46 for a revert of 91e6b240dc0e327ef584e5e6485c9873b0b3a432. Thanks!
Labels: -Merge-Request-46 Merge-Approved-46 Hotlist-Merge-Approved
Approved for M46 (branch: 2490)
Project Member

Comment 10 by bugdroid1@chromium.org, Sep 8 2015

Labels: -Merge-Approved-46 merge-merged-2490
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=201934

------------------------------------------------------------------
r201934 | jww@chromium.org | 2015-09-08T23:19:16.702201Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt?r1=201934&r2=201933&pathrev=201934
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/Source/modules/mediastream/MediaDevices.cpp?r1=201934&r2=201933&pathrev=201934
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html?r1=201934&r2=201933&pathrev=201934

Revert "Removal of mediaDevices.getUserMedia from insecure origins"

This reverts commit 91e6b240dc0e327ef584e5e6485c9873b0b3a432.

Reason for this revert: Decision to delay removal of getUserMedia() from
insecure origins until after M46.

BUG=520765
TBR=mkwst@chromium.org

Review URL: https://codereview.chromium.org/1314953010 .
-----------------------------------------------------------------

Comment 11 by jhis...@gmail.com, Sep 10 2015

Is this really necessary, and is there some kind of alternative?

Forcing the use of https for simple recording is really inconvenient.  For example, I'm using getUserMedia to record short clips for some web exercises.

Can't it just be something like requiring user input to start, or popping up some kind of large notification that they are being recorded?

Forcing a pop-up for permissions every time the page is loaded is already enough of an inconvenience, and not all of us need or have the resources to use https:// for everything.
As this is a breaking change, I think it should be publicized a lot more.

Comment 13 by jww@chromium.org, Sep 10 2015

re #11, yes, it is necessary. Please see the earlier discussions (in particular the link to blink-dev) which talk about why your proposals are insufficient.

re #12, it will be publicized in the near future (although note that per the numbers cited earlier, this is actually not very widely used, so it shouldn't affect that many users).

Comment 14 by jww@chromium.org, Sep 10 2015

Labels: Merge-Request-46
We actually need a second merge as well to complete the revert. Can I get merge approval for a revert of 568020793451c5b6e9a5cd44e08fef4a9c83a77e to M-46? Thanks.
Labels: -Merge-Request-46 Merge-Approved-46
Approved for M46 (branch: 2490)
Project Member

Comment 16 by bugdroid1@chromium.org, Sep 10 2015

Labels: -Merge-Approved-46
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=202062

------------------------------------------------------------------
r202062 | jww@chromium.org | 2015-09-10T17:37:18.015125Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html?r1=202062&r2=202061&pathrev=202062
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/Source/modules/mediastream/NavigatorMediaStream.cpp?r1=202062&r2=202061&pathrev=202062
   A http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/http/tests/security/powerfulFeatureRestrictions/getUserMedia-on-insecure-origin.html?r1=202062&r2=202061&pathrev=202062
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/Source/core/frame/UseCounter.cpp?r1=202062&r2=202061&pathrev=202062
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt?r1=202062&r2=202061&pathrev=202062

Revert "Removal of getUserMedia() on insecure origins"

This reverts commit 568020793451c5b6e9a5cd44e08fef4a9c83a77e.

Reason for this revert: Decision to delay removal of getUserMedia() from
insecure origins until after M46.

BUG=520765
TBR=philipj@opera.com,mkwst@chromium.org

Review URL: https://codereview.chromium.org/1336633002 .
-----------------------------------------------------------------
Project Member

Comment 17 by bugdroid1@chromium.org, Sep 23 2015

Project Member

Comment 18 by bugdroid1@chromium.org, Sep 23 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dac67a137b9c8d3be8d51bb9fe8ab761d8b054a7

commit dac67a137b9c8d3be8d51bb9fe8ab761d8b054a7
Author: jww@chromium.org <jww@chromium.org>
Date: Fri Aug 21 20:38:02 2015

Removal of mediaDevices.getUserMedia from insecure origins

A previous commit removed support for webkitGetUserMedia from insecure
origins. This removes support from the still-behind-a-flag, promise
based mediaDevices.getUserMedia from insecure origins as well.

BUG=520765

Review URL: https://codereview.chromium.org/1311473003

git-svn-id: svn://svn.chromium.org/blink/trunk@201012 bbb929c8-8fbe-4397-9dbb-9b2b20218538

[modify] http://crrev.com/dac67a137b9c8d3be8d51bb9fe8ab761d8b054a7/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] http://crrev.com/dac67a137b9c8d3be8d51bb9fe8ab761d8b054a7/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html
[modify] http://crrev.com/dac67a137b9c8d3be8d51bb9fe8ab761d8b054a7/third_party/WebKit/Source/modules/mediastream/MediaDevices.cpp

Project Member

Comment 20 by bugdroid1@chromium.org, Sep 23 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf2fce2b76dd44c7b93b285c81e35135dc446e56

commit bf2fce2b76dd44c7b93b285c81e35135dc446e56
Author: jww@chromium.org <jww@chromium.org>
Date: Thu Sep 10 17:37:18 2015

Revert "Removal of getUserMedia() on insecure origins"

This reverts commit 568020793451c5b6e9a5cd44e08fef4a9c83a77e.

Reason for this revert: Decision to delay removal of getUserMedia() from
insecure origins until after M46.

BUG=520765
TBR=philipj@opera.com,mkwst@chromium.org

Review URL: https://codereview.chromium.org/1336633002 .

git-svn-id: svn://svn.chromium.org/blink/branches/chromium/2490@202062 bbb929c8-8fbe-4397-9dbb-9b2b20218538

[add] http://crrev.com/bf2fce2b76dd44c7b93b285c81e35135dc446e56/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/getUserMedia-on-insecure-origin.html
[modify] http://crrev.com/bf2fce2b76dd44c7b93b285c81e35135dc446e56/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] http://crrev.com/bf2fce2b76dd44c7b93b285c81e35135dc446e56/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html
[modify] http://crrev.com/bf2fce2b76dd44c7b93b285c81e35135dc446e56/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] http://crrev.com/bf2fce2b76dd44c7b93b285c81e35135dc446e56/third_party/WebKit/Source/modules/mediastream/NavigatorMediaStream.cpp

Project Member

Comment 21 by bugdroid1@chromium.org, Sep 24 2015

Project Member

Comment 22 by bugdroid1@chromium.org, Sep 24 2015

Project Member

Comment 23 by bugdroid1@chromium.org, Sep 24 2015

Project Member

Comment 24 by bugdroid1@chromium.org, Sep 24 2015

Blocking: chromium:547654

Comment 26 by jww@chromium.org, Nov 25 2015

Blockedon: chromium:561641
I have just opened issue 561641 to track geolocation removal specifically.

Comment 27 by gman@chromium.org, Dec 2 2015

This is progressing too fast! Please contribute to letsencrypt or some other solutions before screwing all hobbiest devs over. Some of us don't have $200-$500 per website to spend and the only free solution, letsencrypt, currently only supports apache without tons of work.
gman: I've described at length on the mailing list how you can deploy your particular application. Also, I don't know where you get your numbers; Namecheap, WoSign, StartCom, and SSLMate all have very cheap or free options.
Project Member

Comment 29 by bugdroid1@chromium.org, Dec 11 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/33ef9f5c8df422b0320cbc506d57bdce2999ebc8

commit 33ef9f5c8df422b0320cbc506d57bdce2999ebc8
Author: jww <jww@chromium.org>
Date: Fri Dec 11 07:34:21 2015

Removal of geolocation APIs on insecure origins

This disallows the geolocation APIs getCurrentPosition() and
watchPosition() from being used on insecure origins. Adds a console
warning message that the API call has failed because of this.

BUG=520765,561641

Review URL: https://codereview.chromium.org/1485973002

Cr-Commit-Position: refs/heads/master@{#364642}

[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/android_webview/javatests/src/org/chromium/android_webview/test/GeolocationTest.java
[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/chrome/browser/geolocation/geolocation_permission_context.cc
[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/chrome/browser/geolocation/geolocation_permission_context_unittest.cc
[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html
[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] http://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8/third_party/WebKit/Source/modules/geolocation/Geolocation.cpp

Project Member

Comment 30 by bugdroid1@chromium.org, Dec 11 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ecdcb8846d510107b97b8401b81ec06462420f15

commit ecdcb8846d510107b97b8401b81ec06462420f15
Author: johnme <johnme@chromium.org>
Date: Fri Dec 11 13:26:32 2015

Revert of Removal of geolocation APIs on insecure origins (patchset #6 id:100001 of https://codereview.chromium.org/1485973002/ )

Reason for revert:
Sorry, this broke the following WebView CTS tests:

android.webkit.cts.GeolocationTest#testSimpleGeolocationRequestAcceptAlways
android.webkit.cts.GeolocationTest#testSimpleGeolocationRequestAcceptOnce
android.webkit.cts.GeolocationTest#testSimpleGeolocationRequestReject

See https://build.chromium.org/p/chromium.android/builders/Android%20WebView%20CTS%20L-MR1%20%28dbg%29/builds/4704

It seems that might be intentional, but turning the bot red doesn't seem great. sgurun@ can probably advise on whether WebView has test expectations for CTS, that could be used to disable these tests.

Original issue's description:
> Removal of geolocation APIs on insecure origins
>
> This disallows the geolocation APIs getCurrentPosition() and
> watchPosition() from being used on insecure origins. Adds a console
> warning message that the API call has failed because of this.
>
> BUG=520765,561641
>
> Committed: https://crrev.com/33ef9f5c8df422b0320cbc506d57bdce2999ebc8
> Cr-Commit-Position: refs/heads/master@{#364642}

TBR=mlamouri@chromium.org,philipj@opera.com,thestig@chromium.org,sgurun@chromium.org,torne@chromium.org,jww@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=520765,561641

Review URL: https://codereview.chromium.org/1515103003

Cr-Commit-Position: refs/heads/master@{#364689}

[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/android_webview/javatests/src/org/chromium/android_webview/test/GeolocationTest.java
[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/chrome/browser/geolocation/geolocation_permission_context.cc
[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/chrome/browser/geolocation/geolocation_permission_context_unittest.cc
[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html
[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] http://crrev.com/ecdcb8846d510107b97b8401b81ec06462420f15/third_party/WebKit/Source/modules/geolocation/Geolocation.cpp

Comment 31 by Deleted ...@, Dec 26 2015

This breaks the majority of the webcam input 'Chrome experiments' that are showcased via https://www.chromeexperiments.com/webcam-input

Comment 32 by jww@chromium.org, Dec 29 2015

That's a great point. I'll start an internal Google thread about getting that fixed.
Project Member

Comment 33 by bugdroid1@chromium.org, Jan 19 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1

commit 9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1
Author: jww <jww@chromium.org>
Date: Tue Jan 19 20:58:59 2016

Removal of geolocation APIs on insecure origins

This disallows the geolocation APIs getCurrentPosition() and
watchPosition() from being used on insecure origins. Adds a console
warning message that the API call has failed because of this.

Note that this is a re-land of
https://codereview.chromium.org/1485973002/. See that CL for full
discussion.

BUG=520765, 561641
TBR=thestig@chromium.org,sgurun@chromium.org,philipj@opera.com,mlamouri@chromium.org

Review URL: https://codereview.chromium.org/1530403002

Cr-Commit-Position: refs/heads/master@{#370185}

[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/android_webview/javatests/src/org/chromium/android_webview/test/GeolocationTest.java
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/android_webview/native/aw_settings.cc
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/chrome/browser/geolocation/geolocation_permission_context.cc
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/chrome/browser/geolocation/geolocation_permission_context_unittest.cc
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/content/public/common/common_param_traits_macros.h
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/content/public/common/content_switches.cc
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/content/public/common/web_preferences.cc
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/content/public/common/web_preferences.h
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/content/renderer/render_view_impl.cc
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/Source/core/frame/Settings.in
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/Source/modules/geolocation/Geolocation.cpp
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/Source/web/WebSettingsImpl.cpp
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/Source/web/WebSettingsImpl.h
[modify] http://crrev.com/9d4ca2d9838b5f33bdb3f8fcfb8ef381d449b2a1/third_party/WebKit/public/web/WebSettings.h

Labels: Cr-Blink-Location
Labels: -Cr-Blink-Location
Actually, it looks like the geolocation work is done here, but this issue won't be closed yet.

Comment 36 by jww@chromium.org, Feb 23 2016

Of note, AppCache has recently been added to our removal plans as well. See issue 588931.
If it is not too late, I would like to vote against adding this restriction for 'Device motion / orientation'.

For one, the feature is not mentioned in the W3C document about secure contexts:  https://w3c.github.io/webappsec-secure-contexts/

In the discussion I've read a quote by Joel Weinberger that advocates this restriction:

> Device motion has some pretty serious privacy consequences, and similar to geolocation, passing that in the clear can reveal quite a bit of information. One of my favorites is reading passwords based on accelerometer data: https://sparrow.ece.cmu.edu/group/pub/owusu_ACCessory_hotmobile12.pdf (which a man-in-the-middle can pretty easily take advantage of).

This research is very interesting, but I think that it doesn't impact HTTP vs. HTTPS.

1. For the hack to be accurate there would need to be a site that would constantly send the device motion events over HTTP. I can't think of a site that has a login screen _and_ sends enough device motion events per second that are needed to acquire something that might come close to the password that was typed.
2. Device orientation is put in the same line here. It shouldn't be. Please point me to the article that explains how passwords can be hacked using device orientation values: 0, -90, 90 and 180.

To me it just doesn't make sense to restrict the usage of device orientation and device motion to HTTPS.

Thanks for reading and responding. :)


Project Member

Comment 38 by bugdroid1@chromium.org, Apr 14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f4086735aeb59b937e8216c923f0ea7c58a3602

commit 4f4086735aeb59b937e8216c923f0ea7c58a3602
Author: timvolodine <timvolodine@chromium.org>
Date: Thu Apr 14 13:38:28 2016

[WebView] Disallow geolocation on insecure origins for apps targeting N and higher.

In Chrome geolocation has been disabled on insecure origins
previously in crrev.com/1485973002.

For WebView we are enabling same behavior for apps that are
targeting N and higher versions of Android. This is to allow
for a smooth transition and remain reasonably backwards
compatible with older apps.

BUG=520765

Review URL: https://codereview.chromium.org/1882783002

Cr-Commit-Position: refs/heads/master@{#387299}

[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/java/src/org/chromium/android_webview/AwSettings.java
[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java
[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/javatests/src/org/chromium/android_webview/test/AwTestBase.java
[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/javatests/src/org/chromium/android_webview/test/GeolocationTest.java
[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/native/aw_settings.cc
[modify] https://crrev.com/4f4086735aeb59b937e8216c923f0ea7c58a3602/android_webview/test/shell/src/org/chromium/android_webview/shell/AwShellActivity.java

Project Member

Comment 39 by bugdroid1@chromium.org, Apr 14 2016

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/clank/internal/apps/+/fa84c8eff1298fdce60be5a9d84b60bb5527d321

commit fa84c8eff1298fdce60be5a9d84b60bb5527d321
Author: Tim Volodine <timvolodine@chromium.org>
Date: Thu Apr 14 14:18:51 2016

Cc: timvolod...@chromium.org
Blockedon: 603574
Regarding orientation, I assume this is talking about the deviceorientation event, which provides high-resolution accelerometer data, as opposed to the orientationchange event, which provides 90-degree non-precision.
Is there an ETA for removal of deviceorientation? Or is it still being discussed?

Comment 44 by jww@chromium.org, Jan 9 2017

Still being discussed. The usage on insecure origins is still higher than
we generally consider acceptable for removal, so we're weighing the
costs/benefits.
--Joel
Owner: mkwst@chromium.org
Labels: migrated-launch-owp Type-Task
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge
Labels: Hotlist-EnamelAndFriendsFixIt
While these powerful features are blocked on HTTP sites, they do not seem to be blocked on invalid HTTPS sites (e.g. expired.badssl.com).

Comment 49 by mkwst@chromium.org, Jan 31 2018

> While these powerful features are blocked on HTTP sites, they do not
> seem to be blocked on invalid HTTPS sites (e.g. expired.badssl.com).

Yup. If the user chooses to trust the site by clicking through an interstitial, we treat the site as secure enough to take actions that require user trust. 
Sometimes, you don't have a choice but to go to a site anyway with invalid HTTPS. For the same reason you can't just choose to allow these features on HTTP sites, I think these features shouldn't be allowed on invalid HTTPS sites just because the user chose to go to the site anyway.
Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment