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

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Feature


Sign in to add a comment

Codify the "secure transport/origin" policy

Project Member Reported by palmer@chromium.org, Apr 10 2014

Issue description

https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq?pli=1#TOC-Which-origins-are-secure- says that "secure" origins are:

(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

Implement the GURL member function:

    bool IsOriginSecure() const;

Announce, document, and use the new function in all places where now there are ad hoc tests. (I suspect there are many such places, and that policy is inconsistent!)

Note that currently, a similar function exists in GURL:

232   // If the scheme indicates a secure connection
233   bool SchemeIsSecure() const {
234     return SchemeIs("https") || SchemeIs("wss") ||
235         (SchemeIsFileSystem() && inner_url() && inner_url()->SchemeIsSecure());
236   }

We could rename and reimplement this function, if it would not make call sites explode with wrongness.
 
Showing comments 5 - 104 of 104 Older
Re #1: SchemeIsSecure() is used in a couple of places outside the context of security.
E.g. captive portal detection is triggered if the page takes too long to load and SchemeIsSecure==true. Changing SchemeIsSecure to include file:// or chrome-extension:// might require some investigation.

Comment 6 by palmer@chromium.org, May 24 2014

See also: bool canAccessFeatureRequiringSecureOrigin() const; in Source/platform/weborigin/SecurityOrigin.h
Project Member

Comment 7 by bugdroid1@chromium.org, Jun 10 2014

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

------------------------------------------------------------------
r175916 | eroman@chromium.org | 2014-06-10T20:30:20.339412Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/modules/crypto/SubtleCrypto.cpp?r1=175916&r2=175915&pathrev=175916
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/weborigin/SecurityOrigin.cpp?r1=175916&r2=175915&pathrev=175916
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/weborigin/SecurityOriginTest.cpp?r1=175916&r2=175915&pathrev=175916
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/weborigin/SecurityOrigin.h?r1=175916&r2=175915&pathrev=175916
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/DEPS?r1=175916&r2=175915&pathrev=175916

[webcrypto] Only allow crypto.subtle.* to be used from "secure origins".

The meaning of a secure origin is defined by:
http://www.chromium.org/Home/chromium-security/security-faq#TOC-Which-origins-are-secure-

In essence, "secure origins" are those that load resources either from the local machine or over the network from a cryptographically-authenticated server.

For example these are considered secure origins:
  * chrome-extension://xxx
  * https://xxx
  * wss://xxx
  * file://xxx
  * http://localhost/
  * http://127.0.0.1/

Whereas these are considered insecure:
  * http://foobar
  * ws://foobar

crypto.subtle itself is visible from insecure origins. However all of its methods will fail by returning a rejected Promise for NotSupportedError.

BUG= 373032 ,  245025 ,  362214 

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

Comment 8 by eroman@chromium.org, Jun 10 2014

r175916 introduces SecurityOrigin::canAccessFeatureRequiringSecureOrigin() which can be used on the Blink side of things.

A few observations on the current definition+implementation of secure origin (in particular Secure Origin vs Secure Transport differences):

  - If you create an <iframe src="data:...."> within an https:// page, the SecurityOrigin of the iframe is considered unique and it will not be granted access to WebCrypto. Even though the source of the frame was delivered over secure transport (by contrast sourcing a <script> as a data:URL works).

  - If you create a sandboxed ifram, <iframe sandbox="allow-scripts" src="..."> the iframe is considered a unique origin and cannot access WebCrypto, even though it may have been delivered over a secure transport.

  - Navigating to a page over data:URL (be it typing directly into omnibox, clicking on a link, or a redirect over HTTPS) is considered a unique origin and WebCrypto is not allowed, even though the script source may have been securely delivered.

Comment 9 by jww@chromium.org, Jun 11 2014

It sounds like we need a special bit for sandboxed iframe and data:// protocols specifying "creating origin was secure". Is that a good summary, eroman@?
@jww: Right. I mentioned those cases first and foremost for clarification on what the desired behavior should be. If the current behavior for such iframes is the expected one, then great. If not, we might need to plumb through an extra bit into the SecurityOrigin to differentiate the cases.

Comment 11 by jww@chromium.org, Jun 11 2014

I doubt that's the intended behavior, though I'll let palmer make the definitive statement on it. It seems to me like we ought to be as permissive as possible in defining "secure origin" (as long as it really is secure).
While we certainly want to allow as much truly secure through, it is far, far better to err on the side of more restrictive than less - as once its out there, there is no taking it back.

I agree there are lots of things probably secure that are blocked at present - we are working to go through, define them, and allow them. This is a first step in that direction.
I do think we will need that "creating origin was secure" bit for the blob: and data: URIs (and maybe others).

Comment 14 by f...@chromium.org, Jun 11 2014

Assuming that the source of the data: URI content was from a secure origin itself?
Not *assuming*; tagging whether it was or not.

Comment 16 by jww@chromium.org, Jun 11 2014

Right, I think palmer was saying "creating origin was secure" bit a la comment #9.

Comment 17 by mkwst@chromium.org, Jun 16 2014

Cc: abarth@chromium.org
For related reasons (insecure websockets inside sandboxes), I put up a "secure-bit" CL as a strawman. Adam wasn't thrilled with the idea, but I haven't had a chance to chat with him about it yet. He'll likely be interested in this bug: +abarth.
Thanks.  I'm not sure I understand why we need this extra bit, and I'm hoping Mike can fill me in when we talk tomorrow.

Comment 19 by jww@chromium.org, Jun 16 2014

mkwst, can you post a link to the "secure-bit" CL strawman?

Comment 20 by f...@chromium.org, Jun 29 2014

Should "javascript" be on the list? https://code.google.com/p/chromium/issues/detail?id=253249

To be fair, we don't know where the full string came from so it's possible that it originated over http; but that is true also for anything being eval'ed in the page.

Comment 21 by jww@chromium.org, Jun 30 2014

That's true for https URLs as well. I could be  loading from
https://evil.com. This isn't about a *safe* origin, it's just about whether
Chrome the origin can be reached with confidentiality, integrity, and
authentication. javascript:, data:, etc seem to fit the bill.

Comment 22 by felt@google.com, Jun 30 2014

If you do an HTTP XHR and then eval/javascript: the result, you now have mixed content running. Nothing to do with evil vs good. However I see that HTTP XHR is now being treated as mixed content so that fixes that.

Comment 23 by jww@chromium.org, Jun 30 2014

Ah, got it :-) Yeah, I viewed that as a separate issue (that is the HTTP XHR as mixed content part).
What's the stance on external protocol schemes such as mailto: and notepad:? Currently they are blocked as mixed content ( bug 318788 ).
Yeah, I think we should not treat external protocol schemes as being relevant at all to mixed content — they won't cause content or code to load in the calling origin, after all.
Blocking: chromium:394213
Is there an equivalent of Blink's "is secure origin" in browser yet?

Service Workers will check the secure origin policy in the renderer using SecurityOrigin::canAccessFeatureRequiringSecureOrigin, but the policy being applied in the browser is much weaker--just that the origin and the Service Worker script URL match (but may not be a secure origin.)

Would security team consider this a ship blocker for Service Worker?
I want to fix this bug very soon, but I don't think Service Worker should block on it. If you have to ship SW with a temporary ad hoc check, I'll fix it as part of this bug. Or, if I finish this bug soon (as I intend to), you won't find yourself having to do an ad hoc check.
Status: Started
Adding a Chromium equivalent to SecurityOrigin::canAccessFeatureRequiringSecureOrigin.
Project Member

Comment 30 by bugdroid1@chromium.org, Jul 31 2014

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

------------------------------------------------------------------
r179341 | palmer@chromium.org | 2014-07-31T19:52:04.135803Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebSecurityOrigin.cpp?r1=179341&r2=179340&pathrev=179341
   M http://src.chromium.org/viewvc/blink/trunk/public/web/WebSecurityOrigin.h?r1=179341&r2=179340&pathrev=179341

Add WebSecurityOrigin::CanAccessFeatureRequiringSecureOrigin.

Exposes |SecurityOrigin::canAccessFeatureRequiringSecureOrigin| to
embedders such as Chromium.

BUG= 362214 

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

Comment 31 by bugdroid1@chromium.org, Aug 8 2014

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

------------------------------------------------------------------
r179843 | dominicc@chromium.org | 2014-08-08T16:39:39.486762Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/public/web/WebSecurityOrigin.h?r1=179843&r2=179842&pathrev=179843

Export WebSecurityOrigin's secure origin check.

Service Worker needs to enforce the
canAccessFeatureRequiringSecureOrigin check in
content/browser. Exporting the symbol so the embedder can link to
it. This is follow-up to r179341.

BUG= 362214 

Review URL: https://codereview.chromium.org/452793002
-----------------------------------------------------------------
Looking at this again. Service Worker would still like to do this check in browser as well as renderer for defense against corrupted renderers. The patch in Comment 31 could be reverted because there's a prohibition against using anything (more) from Blink in browser.

Seems adding something to GURL as OP suggests makes sense. However it begets duplication:

First, Blink has a dynamic set of secure transports (see WebSecurityPolicy::registerURLSchemeAsSecure) that's configured from ChromeContentRendererClient::RenderThreadStarted. That list should be shared.

Second, this would add GURL::OriginIsSecure next to SchemeIsSecure, and unfortunately some callers don't care which one they use (eg a sync server is going to not be http://localhost, right?) but not all.

Third, this would leave GURL::OriginIsSecure (assuming this should be named in a way consistent with SchemeIsSecure?) will be duplicative of logic in SecurityOrigin::canAccessFeatureRequiringSecureOrigin.
Cc: mlamouri@chromium.org
Cc: miguelg@chromium.org
Blocking: chromium:419731
Cc: mkwst@chromium.org
Should this bug be tracking the latest language in the Mixed Content spec? Specifically, specs will probably be referencing https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features. It would be nice for API implementations to be able to call a single function that implements this (both in Blink and again in the browser process, if necessary).

For cases that don't involve documents, specs will reference https://w3c.github.io/webappsec/specs/mixedcontent/#settings-powerful-features.
ddorwin: Yes, I think you are right.
Trying to register a service worker in a packaged app/extension currently fails with 
"The URL protocol of the current origin is not supported: chrome-extension" (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/serviceworkers/ServiceWorkerContainer.cpp&q=ServiceWorkerContainer.cpp&sq=package:chromium&l=127)

Is this intentional?
Re: Service Workers and chrome-extension, I have filed  Issue 439323 .
Blockedon: chromium:447525
Regarding #36, the language has moved to a new document: http://www.w3.org/TR/powerful-features/#is-origin-trustworthy
Question: Now that Blink exports |canAccessFeatureRequiringSecureOrigin|, and content/browser/service_worker/service_worker_dispatcher_host.cc provides a model of how to call into it, is this bug fixed?

And, if so, to whom should I reassign the bug for credit while marking it as Fixed? :) To me it looks like eroman did the main work.
canAccess doesn't match 1:1 the language requested, the comments in #8 apply, as do those in #32.
OK, great. I'm going to work on this in small steps. Incoming...
mkwst, abarth: Can you link to mkwst's "creating origin was secure" bit CL (mentioned in #17)? I think we're going to need it.
Project Member

Comment 46 by bugdroid1@chromium.org, Apr 3 2015

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

------------------------------------------------------------------
r193143 | palmer@chromium.org | 2015-04-03T22:08:05.790562Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebSecurityPolicy.cpp?r1=193143&r2=193142&pathrev=193143
   M http://src.chromium.org/viewvc/blink/trunk/public/web/WebSecurityPolicy.h?r1=193143&r2=193142&pathrev=193143
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/weborigin/SchemeRegistry.h?r1=193143&r2=193142&pathrev=193143

Export shouldTreatURLSchemeAsSecure.

BUG= 362214 
TBR=brettw,abarth

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

Comment 49 by bugdroid1@chromium.org, Apr 17 2015

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

commit 298d7eb01ab6f9c1f8781a31c2fddc13f9e4e4e2
Author: palmer <palmer@chromium.org>
Date: Fri Apr 17 21:09:23 2015

Use IsOriginSecure when checking Web MIDI SYSEX capability.

Rather than the previous ad hoc check. IsOriginSecure is the standard way.

BUG= 362214 , 470170 

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

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

[modify] http://crrev.com/298d7eb01ab6f9c1f8781a31c2fddc13f9e4e4e2/chrome/browser/content_settings/permission_context_base.cc

Blocking: chromium:442590
Project Member

Comment 52 by bugdroid1@chromium.org, Apr 22 2015

Project Member

Comment 53 by bugdroid1@chromium.org, Apr 25 2015

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

commit 8cbea05bcd64f3a778d92435b6102e82c2cb435b
Author: kinuko <kinuko@chromium.org>
Date: Sat Apr 25 13:35:43 2015

Move IsOriginSecure() into //content and use it in ServiceWorker

IsOriginSecure() implements web platform feature [1] and it'd be
more natural to provide this at content-layer.
Also ServiceWorker actually wants to call this in content layer
for browser-side security check.

https://www.w3.org/TR/powerful-features/#is-origin-trustworthy.

This CL moves IsOriginSecure() from
chrome/common/origin_util.{h,cc} to
content/{public/,}/common/origin_util.{h,cc}

and adds a following method to ContentClient so that ChromeContentClient
can add chrome-level schemes (and whitelisted origins, this is to be
implemented in  crbug.com/441605 ).

  // Gives the embedder a chance to register additional schemes and origins
  // that need to be considered trustworthy.
  // See https://www.w3.org/TR/powerful-features/#is-origin-trustworthy.
  virtual void AddSecureSchemesAndOrigins(std::set<std::string>* schemes,
                                          std::set<GURL>* origins) {}

BUG= 362214 ,  441605 
TEST=content_unittests:URLSchemesTest.IsOriginSecure

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

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

[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/chrome/browser/content_settings/permission_context_base.cc
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/chrome/chrome_common.gypi
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/chrome/chrome_tests_unit.gypi
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/chrome/common/chrome_content_client.cc
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/chrome/common/chrome_content_client.h
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/chrome/common/chrome_switches.h
[delete] http://crrev.com/ca801973e5abfe45b9ce05c418dee51c4196404b/chrome/common/origin_util.cc
[delete] http://crrev.com/ca801973e5abfe45b9ce05c418dee51c4196404b/chrome/common/origin_util.h
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/browser/service_worker/service_worker_dispatcher_host.cc
[add] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/common/origin_util.cc
[rename] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/common/origin_util_unittest.cc
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/content_common.gypi
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/content_tests.gypi
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/public/common/content_client.cc
[modify] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/public/common/content_client.h
[add] http://crrev.com/8cbea05bcd64f3a778d92435b6102e82c2cb435b/content/public/common/origin_util.h

Note to self: look at places that use SchemeIs(url::kHttpsScheme) or SchemeIs(url::kHttpsScheme) to see if any of them should us SchemeIsCryptographic() or maybe IsOriginSecure().

(Many call sites check if something is either HTTP or HTTPS, which we shouldn't change.)
Blockedon: chromium:486087
#57: Thanks, I separated that out into a distinct bug: https://code.google.com/p/chromium/issues/detail?id=486087
Project Member

Comment 60 by bugdroid1@chromium.org, May 11 2015

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

commit fe50e76fa445ff8e6fc3d18bb4b8d3a6b1408730
Author: lgarron <lgarron@chromium.org>
Date: Mon May 11 23:14:28 2015

Switch Fizzy //components to use SchemeIsCryptographic() instead of SchemeIsSecure().

We recently introduced SchemeIsCryptographic() and IsOriginSecure(),
which are meant to replace SchemeIsSecure().

IsOriginSecure() roughly means "do we trust this content not to be
tampered with before it reaches the user?" [1] This is a higher-level
definition that corresponds to the new "privileged contexts" spec. [2]

SchemeIsCryptographic() [3] is close to the old definition of
SchemeIsSecure(), and literally just checks if the scheme is a
cryptographic scheme (HTTPS or WSS as of right now). The difference is
that SchemeIsCryptographic() will not consider filesystem URLs secure.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/origin_util.h&sq=package:chromium&type=cs&l=19&rcl=143099866
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and https://w3c.github.io/webappsec/specs/powerfulfeatures/
[3] https://code.google.com/p/chromium/codesearch#chromium/src/url/gurl.h&sq=package:chromium&type=cs&l=250&rcl=1430998666

BUG= 362214 

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

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

[modify] http://crrev.com/fe50e76fa445ff8e6fc3d18bb4b8d3a6b1408730/components/autofill/content/browser/wallet/wallet_service_url_unittest.cc
[modify] http://crrev.com/fe50e76fa445ff8e6fc3d18bb4b8d3a6b1408730/components/content_settings/core/browser/host_content_settings_map.cc

Project Member

Comment 61 by bugdroid1@chromium.org, May 12 2015

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

commit 92725553228681b9b7a8fd9a9e9f324d32c12018
Author: lgarron <lgarron@chromium.org>
Date: Tue May 12 02:03:15 2015

Switch remaining functions from SchemeIsSecure() to
SchemeIsCryptographic().

We recently introduced SchemeIsCryptographic() and IsOriginSecure(),
which are meant to replace SchemeIsSecure().

IsOriginSecure() roughly means "do we trust this content not to be
tampered with before it reaches the user?" [1] This is a higher-level
definition that corresponds to the new "privileged contexts" spec. [2]

SchemeIsCryptographic() [3] is close to the old definition of
SchemeIsSecure(), and literally just checks if the scheme is a
cryptographic scheme (HTTPS or WSS as of right now). The difference is
that SchemeIsCryptographic() will not consider filesystem URLs secure.

IsOriginSecure() should be correct for most Fizz code.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/origin_util.h&sq=package:chromium&type=cs&l=19&rcl=143099866
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and https://w3c.github.io/webappsec/specs/powerfulfeatures/
[3] https://code.google.com/p/chromium/codesearch#chromium/src/url/gurl.h&sq=package:chromium&type=cs&l=250&rcl=1430998666

BUG= 362214 

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

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

[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/content/browser/ssl/ssl_policy.cc
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/extensions/browser/updater/extension_downloader.cc
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/google_apis/gaia/gaia_auth_util.cc
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/ios/web/net/request_tracker_impl.mm
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/ios/web/net/request_tracker_impl_unittest.mm
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/remoting/host/third_party_auth_config.cc
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/sync/internal_api/sync_manager_impl.cc
[modify] http://crrev.com/92725553228681b9b7a8fd9a9e9f324d32c12018/third_party/libaddressinput/chromium/chrome_metadata_source.cc

Project Member

Comment 62 by bugdroid1@chromium.org, May 12 2015

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

commit 7b70d593c20676a7b2656684416a1be1f50a167a
Author: lgarron <lgarron@chromium.org>
Date: Tue May 12 02:05:04 2015

Switch //chrome functions to use SchemeIsCryptographic() instead of SchemeIsSecure().

palmer@ recently introduced SchemeIsCryptographic() and
IsOriginSecure(), which are meant to replace SchemeIsSecure().

IsOriginSecure() roughly means "do we trust this content not to be
tampered with before it reaches the user?" [1] This is a higher-level
definition that corresponds to the new "privileged contexts" spec. [2]

SchemeIsCryptographic() [3] is close to the old definition of
SchemeIsSecure(), and literally just checks if the scheme is a
cryptographic scheme (HTTPS or WSS as of right now). The difference is
that SchemeIsCryptographic() will not consider filesystem URLs secure.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/origin_util.h&sq=package:chromium&type=cs&l=19&rcl=143099866
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and https://w3c.github.io/webappsec/specs/powerfulfeatures/
[3]  https://code.google.com/p/chromium/codesearch#chromium/src/url/gurl.h&sq=package:chromium&type=cs&l=250&rcl=1430998666

BUG= 362214 

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

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

[modify] http://crrev.com/7b70d593c20676a7b2656684416a1be1f50a167a/chrome/browser/extensions/updater/extension_updater_unittest.cc
[modify] http://crrev.com/7b70d593c20676a7b2656684416a1be1f50a167a/chrome/browser/search/search.cc
[modify] http://crrev.com/7b70d593c20676a7b2656684416a1be1f50a167a/chrome/browser/signin/signin_header_helper.cc
[modify] http://crrev.com/7b70d593c20676a7b2656684416a1be1f50a167a/chrome/browser/ui/toolbar/toolbar_model_unittest.cc
[modify] http://crrev.com/7b70d593c20676a7b2656684416a1be1f50a167a/chrome/renderer/chrome_content_renderer_client.cc

Project Member

Comment 63 by bugdroid1@chromium.org, May 12 2015

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

commit c3efc57462238dc0a5de6e7857f6af6e4459ce6f
Author: lgarron <lgarron@chromium.org>
Date: Tue May 12 03:49:36 2015

Switch //chrome/browser code to use IsOriginSecure() instead of SchemeIsSecure().

We recently introduced SchemeIsCryptographic() and IsOriginSecure(),
which are meant to replace SchemeIsSecure().

IsOriginSecure() roughly means "do we trust this content not to be
tampered with before it reaches the user?" [1] This is a higher-level
definition that corresponds to the new "privileged contexts" spec. [2]

SchemeIsCryptographic() [3] is close to the old definition of
SchemeIsSecure(), and literally just checks if the scheme is a
cryptographic scheme (HTTPS or WSS as of right now). The difference is
that SchemeIsCryptographic() will not consider filesystem URLs secure.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/origin_util.h&sq=package:chromium&type=cs&l=19&rcl=143099866
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and https://w3c.github.io/webappsec/specs/powerfulfeatures/
[3] https://code.google.com/p/chromium/codesearch#chromium/src/url/gurl.h&sq=package:chromium&type=cs&l=250&rcl=1430998666

BUG= 362214 

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

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

[modify] http://crrev.com/c3efc57462238dc0a5de6e7857f6af6e4459ce6f/chrome/browser/banners/app_banner_manager.cc
[modify] http://crrev.com/c3efc57462238dc0a5de6e7857f6af6e4459ce6f/chrome/browser/content_settings/permission_context_uma_util.cc
[modify] http://crrev.com/c3efc57462238dc0a5de6e7857f6af6e4459ce6f/chrome/browser/extensions/api/desktop_capture/desktop_capture_api.cc
[modify] http://crrev.com/c3efc57462238dc0a5de6e7857f6af6e4459ce6f/chrome/browser/ui/content_settings/content_setting_bubble_model.cc
[modify] http://crrev.com/c3efc57462238dc0a5de6e7857f6af6e4459ce6f/chrome/browser/ui/website_settings/permission_menu_model.cc

Project Member

Comment 64 by bugdroid1@chromium.org, May 12 2015

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

commit a2da0cfdd55a53963a5298f301b896bdb909750e
Author: lgarron <lgarron@chromium.org>
Date: Tue May 12 20:52:00 2015

Switch //components to use SchemeIsCryptographic() instead of SchemeIsSecure().

We recently introduced SchemeIsCryptographic() and IsOriginSecure(),
which are meant to replace SchemeIsSecure().

IsOriginSecure() roughly means "do we trust this content not to be
tampered with before it reaches the user?" [1] This is a higher-level
definition that corresponds to the new "privileged contexts" spec. [2]

SchemeIsCryptographic() [3] is close to the old definition of
SchemeIsSecure(), and literally just checks if the scheme is a
cryptographic scheme (HTTPS or WSS as of right now). The difference is
that SchemeIsCryptographic() will not consider filesystem URLs secure.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/origin_util.h&sq=package:chromium&type=cs&l=19&rcl=143099866
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and https://w3c.github.io/webappsec/specs/powerfulfeatures/
[3] https://code.google.com/p/chromium/codesearch#chromium/src/url/gurl.h&sq=package:chromium&type=cs&l=250&rcl=1430998666

BUG= 362214 

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

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

[modify] http://crrev.com/a2da0cfdd55a53963a5298f301b896bdb909750e/components/data_reduction_proxy/core/browser/data_reduction_proxy_bypass_protocol.cc
[modify] http://crrev.com/a2da0cfdd55a53963a5298f301b896bdb909750e/components/data_reduction_proxy/core/browser/data_reduction_proxy_bypass_stats_unittest.cc
[modify] http://crrev.com/a2da0cfdd55a53963a5298f301b896bdb909750e/components/data_reduction_proxy/core/browser/data_reduction_proxy_metrics_unittest.cc
[modify] http://crrev.com/a2da0cfdd55a53963a5298f301b896bdb909750e/components/error_page/renderer/net_error_helper_core.cc

Project Member

Comment 65 by bugdroid1@chromium.org, May 14 2015

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

commit a774b92283e458a9bc77ba0ce49777b74cde493a
Author: lgarron <lgarron@chromium.org>
Date: Thu May 14 22:56:37 2015

Switch //net functions to use SchemeIsCryptographic() instead of SchemeIsSecure().

SchemeIsCryptographic more appropriately reflects
the intent (that a cryptographically secure
transport was used - e.g. https:// and wss:// schemes),
whereas SchemeIsSecure also considers situations where
the scheme is locally trusted (e.g. filesystem URLs)

BUG= 362214 

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

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

[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/base/sdch_dictionary.cc
[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/base/sdch_manager.cc
[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/cookies/canonical_cookie.cc
[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/http/http_auth_controller.cc
[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/http/http_network_transaction.cc
[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/http/http_stream_parser.cc
[modify] http://crrev.com/a774b92283e458a9bc77ba0ce49777b74cde493a/net/quic/quic_http_stream.cc

Project Member

Comment 66 by bugdroid1@chromium.org, May 15 2015

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

commit cce355c1f7bca05df3da34b279c67ebba1b20660
Author: lgarron <lgarron@chromium.org>
Date: Fri May 15 07:32:30 2015

Switch private WebRTC desktop capture API to use IsOriginSecure() instead of SchemeIsSecure().

This mirrors the change in chrome/browser/extensions/api/desktop_capture/desktop_capture_api.cc in https://codereview.chromium.org/1131993005/

BUG= 362214 

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

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

[modify] http://crrev.com/cce355c1f7bca05df3da34b279c67ebba1b20660/chrome/browser/extensions/api/webrtc_desktop_capture_private/webrtc_desktop_capture_private_api.cc

Comment 67 by Deleted ...@, Jun 5 2015

Prior to Chrome 44 beta, I am able to registering a service-worker in an https iframe that is in a http web-page.

In Chrome Version 44.0.2403.30 beta (64-bit), this approach no longer registers a service-worker.

There are still many websites that do not have https support. Allowing a service-worker to be registered via a https iframe is a useful feature.

Is there anything that can done to allow service-workers via a https iframe and still address security concerns. For example, allowing https urls that are listed a meta tag/manifest file (similar to the manifest file that is used by chrome push notifications) 
Project Member

Comment 68 by bugdroid1@chromium.org, Aug 7 2015

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

commit 2249c80e8c4b50793a8261c4f9eb3f879ddf4aff
Author: lgarron <lgarron@chromium.org>
Date: Fri Aug 07 22:18:35 2015

Switch media stream permissions to use IsOriginSecure() instead of
SchemeIsSecure().

In particular, note that this means that media permissions are persisted on http://localhost.

The change also updates the old media stream permission tests (which
were no longer testing anything meaningful).

BUG= 295723 ,  362214 ,  509844 

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

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

[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/chrome_media_stream_infobar_browsertest.cc
[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/desktop_capture_access_handler.cc
[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/media_stream_device_permissions.cc
[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/media_stream_devices_controller.cc
[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/media_stream_infobar_delegate.cc
[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/webrtc_browsertest_base.cc
[modify] http://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff/chrome/browser/media/webrtc_browsertest_base.h

Project Member

Comment 69 by bugdroid1@chromium.org, Aug 9 2015

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

commit 05d9f8f40cf146a4f45f469b5e5a43cad7f397ee
Author: magjed <magjed@chromium.org>
Date: Sun Aug 09 15:19:58 2015

Revert of Switch media stream permissions to use IsOriginSecure() instead of SchemeIsSecure(). (patchset #11 id:220001 of https://codereview.chromium.org/1132203002/ )

Reason for revert:
This CL broke WebRtcWebcamBrowserTest.TestAcquiringAndReacquiringWebcam on all platforms, failing on the introduced assert 'EXPECT_TRUE(permissionRequestObserver.request_shown());’ at webrtc_browsertest_base.cc:149.

Link to bots:
https://build.chromium.org/p/chromium.webrtc/builders/Win7%20Tester
https://build.chromium.org/p/chromium.webrtc/builders/Linux%20Tester
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester

Stdio output:
[ RUN      ] WebRtcWebcamBrowserTests/WebRtcWebcamBrowserTest.TestAcquiringAndReacquiringWebcam/0
[7391:1799:0807/160702:WARNING:vt_video_decode_accelerator.cc(194)] Failed to initialize VideoToolbox framework. Hardware accelerated video decoding will be disabled.
[7388:1799:0807/160703:INFO:CONSOLE(71)] "This appears to be Chrome", source: http://127.0.0.1:50232/webrtc/adapter.js (71)
[7388:71959:0807/160703:WARNING:embedded_test_server.cc(258)] Request not handled. Returning 404: /favicon.ico
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning has-video-input-device to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Requesting doGetUserMedia: constraints: {"video":{"mandatory":{"minWidth":640,"maxWidth":640,"minHeight":480,"maxHeight":480}}}", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning request-callback-granted to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning ok-got-stream to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning ok-started to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning video-not-playing to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning video-playing to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160703:INFO:CONSOLE(13)] "Returning ok-640x480 to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning ok-stopped to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Requesting doGetUserMedia: constraints: {"video":{"mandatory":{"minWidth":640,"maxWidth":640,"minHeight":360,"maxHeight":360}}}", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning request-callback-granted to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
../../chrome/browser/media/webrtc_browsertest_base.cc:149: Failure
Value of: permissionRequestObserver.request_shown()
  Actual: false
Expected: true
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning ok-got-stream to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning ok-started to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning video-not-playing to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning video-playing to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning ok-640x360 to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[7388:1799:0807/160704:INFO:CONSOLE(13)] "Returning ok-stopped to test.", source: http://127.0.0.1:50232/webrtc/test_functions.js (13)
[  FAILED  ] WebRtcWebcamBrowserTests/WebRtcWebcamBrowserTest.TestAcquiringAndReacquiringWebcam/0, where GetParam() = "force-qtkit" (2127 ms)

Original issue's description:
> Switch media stream permissions to use IsOriginSecure() instead of
> SchemeIsSecure().
>
> In particular, note that this means that media permissions are persisted on http://localhost.
>
> The change also updates the old media stream permission tests (which
> were no longer testing anything meaningful).
>
> BUG= 295723 ,  362214 ,  509844 
>
> Committed: https://crrev.com/2249c80e8c4b50793a8261c4f9eb3f879ddf4aff
> Cr-Commit-Position: refs/heads/master@{#342458}

TBR=felt@chromium.org,raymes@chromium.org,tommi@chromium.org,lgarron@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 295723 ,  362214 ,  509844 

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

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

[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/chrome_media_stream_infobar_browsertest.cc
[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/desktop_capture_access_handler.cc
[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/media_stream_device_permissions.cc
[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/media_stream_devices_controller.cc
[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/media_stream_infobar_delegate.cc
[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/webrtc_browsertest_base.cc
[modify] http://crrev.com/05d9f8f40cf146a4f45f469b5e5a43cad7f397ee/chrome/browser/media/webrtc_browsertest_base.h

Project Member

Comment 70 by bugdroid1@chromium.org, Aug 13 2015

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

commit 64d923cbb60f7ac1d7d21e63224b8120bd323f1c
Author: lgarron <lgarron@chromium.org>
Date: Thu Aug 13 21:28:22 2015

Switch media stream permissions to use IsOriginSecure() instead of SchemeIsSecure().

In particular, note that this means that media permissions are persisted on
http://localhost .

The change also updates the old media stream permission tests (which
were no longer testing anything meaningful).

(This is a reland of https://codereview.chromium.org/1276373004/ with a fixed
test, after it was reverted in https://codereview.chromium.org/1276373004/ )

BUG= 295723 ,  362214 ,  509844 

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

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

[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/chrome_media_stream_infobar_browsertest.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/chrome_webrtc_webcam_browsertest.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/desktop_capture_access_handler.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/media_stream_device_permissions.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/media_stream_devices_controller.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/media_stream_infobar_delegate.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/webrtc_browsertest_base.cc
[modify] http://crrev.com/64d923cbb60f7ac1d7d21e63224b8120bd323f1c/chrome/browser/media/webrtc_browsertest_base.h

Project Member

Comment 71 by bugdroid1@chromium.org, Aug 14 2015

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

commit fc65f35f28fe5625306f40e80259fced9675a57e
Author: lgarron <lgarron@chromium.org>
Date: Fri Aug 14 23:36:49 2015

Switch DataReductionProxyResourceThrottle::MaybeCreate() from SchemeIsSecure() to SchemeIsCryptographic().

BUG= 362214 

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

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

[modify] http://crrev.com/fc65f35f28fe5625306f40e80259fced9675a57e/chrome/browser/renderer_host/data_reduction_proxy_resource_throttle_android.cc

Project Member

Comment 72 by bugdroid1@chromium.org, Aug 17 2015

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/72ff43b03ec683d946659c8ad23521ea9f483f72

commit 72ff43b03ec683d946659c8ad23521ea9f483f72
Author: lgarron <lgarron@google.com>
Date: Mon Aug 17 22:39:26 2015

Project Member

Comment 73 by bugdroid1@chromium.org, Aug 18 2015

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

commit ee4c0b0c531417177164e91d3a987ab2946c6792
Author: lgarron <lgarron@chromium.org>
Date: Tue Aug 18 05:10:04 2015

Switch Sdch3.AdvertisedWithSecureScheme histogram to use target_url.SchemeIsCryptographic().

SchemeIsSecure() is deprecated. Replacing it with SchemeIsCryptographic() in this case is safe because the check was effectively only checking for HTTP vs. HTTPS. (The UMA histogram values are even called "HTTP" and HTTPS"):

- Sdch3.AdvertisedWithSecureScheme is recorded in SdchManager::GetDictionarySet(),
- which is only called from URLRequestHttpJob::AddExtraHeaders(),
- which is only used for HTTP and HTTPS requests.

BUG= 362214 

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

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

[modify] http://crrev.com/ee4c0b0c531417177164e91d3a987ab2946c6792/net/base/sdch_manager.cc

Project Member

Comment 74 by bugdroid1@chromium.org, Aug 18 2015

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

commit 4f486f6f6a1e5a90e33beb9af6d0d253e775b437
Author: lgarron <lgarron@chromium.org>
Date: Tue Aug 18 21:57:35 2015

Remove GURL::SchemeIsSecure().

BUG= 362214 

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

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

[modify] http://crrev.com/4f486f6f6a1e5a90e33beb9af6d0d253e775b437/url/gurl.h

Is there anything left to do on this bug?
Not that I know of.
Status: Fixed

Comment 78 Deleted

Comment 79 by Deleted ...@, Sep 28 2015

Hey i am using iframe[is on https, parent isn't] to fetch location of user, why is that not working

I am trying to get code for document->isPrivilegedContext() but unable to find that in any open repository.


Comment 80 by tom.m...@gmail.com, Nov 20 2015

How do the powers that be suggest that we develop with gUM when not on localhost? We use docker to containerize our development environment however this means it has an IP address other than 127.0.0.1 - I tried to point project.localhost to our docker machine and came across this issue...
I also ran into the same issue as #80 when trying to add Service Worker to one of my websites requiring the use of subdomains.

The website is running at subdomain.project.localhost (also tested subdomain.localhost), but I'm getting "Only secure origins are allowed (see: https://goo.gl/Y0ZkNV)", even though the linked document says that *.localhost should be considered secure. It would be great if *.localhost could be added as secure origin.

Mentioning --unsafely-treat-insecure-origin-as-secure in the document linked in the error would also be great for everyone coming across this who can't change the domain.
As we can see in ./content/common/origin_util_unittest.cc, pumpkin.localhost should be considered  secure origin:

 22   EXPECT_TRUE(IsOriginSecure(GURL("http://localhost/fun.html")));
 23   EXPECT_TRUE(IsOriginSecure(GURL("http://pumpkin.localhost/fun.html")));
 24   EXPECT_TRUE(
 25       IsOriginSecure(GURL("http://crumpet.pumpkin.localhost/fun.html")));
 26   EXPECT_TRUE(IsOriginSecure(GURL("http://pumpkin.localhost:8080/fun.html")));
 27   EXPECT_TRUE(
 28       IsOriginSecure(GURL("http://crumpet.pumpkin.localhost:3000/fun.html")));
 29   EXPECT_FALSE(IsOriginSecure(GURL("http://localhost.com/fun.html")));
 30   EXPECT_TRUE(IsOriginSecure(GURL("https://localhost.com/fun.html")));

Thus, I suspect that getUserMedia and Service Workers are using a check in Blink that is not in sync with this definition. Indeed; see third_party/WebKit/Source/platform/weborigin/SecurityOrigin.h:

155     bool canAccessDatabase() const { return !isUnique(); }
156     bool canAccessLocalStorage() const { return !isUnique(); }
157     bool canAccessSharedWorkers() const { return !isUnique(); }
158     bool canAccessServiceWorkers() const { return !isUnique(); }
159     bool canAccessCookies() const { return !isUnique(); }
160     bool canAccessPasswordManager() const { return !isUnique(); }
161     bool canAccessFileSystem() const { return !isUnique(); }
162     bool canAccessCacheStorage() const { return !isUnique(); }

mkwst: What should be happening here? This doesn't seem right.
i'm using an iframe who is in https to record audio, the parent isn't, is not  working, this should work?

---

this method only works when i active the option chrome://flags/#enable-site-per-process.
Cc: nasko@chromium.org creis@chromium.org
nasko, creis: Does #84 match your expectations? That seems weird.
if you want to test here a link HTTP with iframe in HTTPS
http://nearbytes.com/plugin/js-fl/

and here both in HTTPS
https://www.totmob.com/nearbytes/plugin/js-fl/

Comment 87 by Deleted ...@, Dec 17 2015

The safe list should be expanded to common local networks such as 192.168.0.*, 192.168.1.*, 10.0.0.*, and perhaps locally resolved names such as http://mylocaltestingcomputer/

Comment 88 by creis@chromium.org, Dec 17 2015

Cc: est...@chromium.org
Comment 85: Thanks for the heads up.  estark@ is fixing mixed content for --site-per-process mode in  issue 486936 , which might explain that behavior difference.  (Emily, will we need any separate changes for media policy for secure origins in OOPIFs?)
Yes, I actually ran across this recently and thought I filed a bug for it but must have forgotten because I can't find it now. Document::isSecureContext() will need to be fixed to work with OOPIFs (specifically this line which doesn't work if the parent is remote: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.cpp&sq=package:chromium&l=5739&rcl=1450442745). I think it should be a simple fix though. I'll file a bug.
As per comment 81, this bug isn't fixed as *.localhost is not considered a secure origin.

I can replicate the scenario described: "Only secure origins are allowed (see: https://goo.gl/Y0ZkNV)"

*.localhost is listed as a secure origin in the document below, and would be useful for development/testing:

https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
Re: #90: Please note that that document is a proposal, not the final truth. The document also links to the current W3C draft specification (https://www.w3.org/TR/powerful-features/). Again, that's a draft, not a finished specification. 

Finally, unfortunately we have found that some platforms will ask the network to resolve *.localhost names. That makes no sense to me, personally, but it's the reality. It means that we cannot say for certain that http://foo.localhost uses secure transport.

Comment 92 by zltn...@gmail.com, May 6 2016

Please add http://*.localhost to the secure transport list. I don't exacly understand why this was left out from the list.

Comment 94 by orepo...@gmail.com, May 25 2016

Disabling web-security:

open -a Google\ Chrome --args --disable-web-security

 still fails on secure origin (using web crypto). 
Shouldn't it override the same way that --unsafely-treat-insecure-origin-as-secure  does?
I've been trying for days to get --unsafely-treat-insecure-origin-as-secure to work.
The application is a Cordova/Crosswalk app on android, Crosswalk version 17 / Chromium version 47. I checked the source and version history and the flag is present in the source. I keep getting the 'Uncaught (in promise) DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV).' error no matter how I specify the hostname.

Here is an example of the crosswalk/chromium invokation:

    xwalk --disable-pull-to-refresh-effect --unsafely-treat-insecure-origin-as-secure=http://angie,http://angie.fritz.box,http://angie:3000,http://angie.fritz.box:3000 --user-data-dir=Defoult

I tried all these different origin specifications by now in case there was some hidden policy I didn't understand but none of them work. --user-data-dir is working, I can see a new directory being created when I change the parameter and I tried deleting it and reloading, to no avail.

Does anyone have an idea on why the flag isn't being applied or on how to debug this? 
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Comment 97 Deleted

Comment 98 Deleted

Comment 99 Deleted

Comment 100 by ejo...@gmail.com, Jun 3 2017

Hi,

At the moment, "Web Cryptography API" is under the "secure transport/origin" policy. It is very irrational, because main point of cryptography is to secure data on insecure environments. It is like a policy which allows to install antivirus only on secure computers where your system is protected from viruses already.

For example: I would like to use "Web Cryptography API" to pass data securely to the server:
http://www.jocys.com/Common/JsClasses/Examples/System.Web.Mobile.htm

Unfortunately, Chrome is the only web browser, which won't allow me to generate RSA Key and secure the data, because HTTP environment is not secure enough. Duh, unsecure HTTP is the reason why I want to use "Web Cryptography API" in the first place:

http://www.jocys.com/Common/JsClasses/Examples/System.Security.Cryptography.RSA.htm

Please remove "Web Cryptography API" from "secure transport/origin" policy.

Sincerely,
Evaldas Jocys

RE comment #100:

Chrome is following the Web Crypto specification, which restricts the use of crypto.subtle to SecureContext [1] [2].

There was a lot of discussion about this on the working group, so your concern is not a new one [3] [4].

The trouble with the model described in comment #100, is if the script was not delivered securely, then an attacker could handily bypass whatever security was layered on via Web Crypto simply by changing the code executed by the page.

You can voice any additional concerns with the WG via their bug tracker (https://github.com/w3c/webcrypto/issues)

[1] https://www.w3.org/TR/WebCryptoAPI/#crypto-interface
[2] https://lists.w3.org/Archives/Public/public-webcrypto/2016Aug/0047.html
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972
[4] https://github.com/w3c/webcrypto/issues/28

Comment 102 by ejo...@gmail.com, Jun 6 2017

I see, I am too late. Decision to disable new security features for 25% of Internet pages, which are served via HTTP, reminded Microsoft's mistake to disable access to security updates to non-genuine versions of Windows, which lead to large networks of infected computers and it started to cause issues for genuine users. I use Chrome as my default browser, but kudos to Microsoft and Mozilla devs for learning from their mistakes and by not disabling tools which will make the weakest part of the Internet stronger.
Both Mozilla and Microsoft have indicated they are committed to restricting WebCrypto to Secure Origins, and see it as active bugs that they have not.
It looks like you can't check for the origin to avoid running into the restriction.

Our 1der1 website builder generates secure pages only. However, if someone frames our websites in an insecure page, there is no way to avoid the "Prefer Secure Origins For Powerful New Features" warning.

You can't check for the window.top.location.protol because access to the top.location is restricted.

Example page:
http://www.plattercafe.co.nz/

You get the restriction if you click the direction arrow button. However, if you use the frame link, there is no restriction.
Showing comments 5 - 104 of 104 Older

Sign in to add a comment