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

Issue 441605 link

Starred by 33 users

Issue metadata

Status: Fixed
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Feature

issue 420813

Participants' hotlists:

Sign in to add a comment

Command line option for whitelisting specific origins to ease development and testing of websites using Secure Origin only features

Project Member Reported by, Dec 12 2014

Issue description

We've confirmed with several teams that the Secure Origin requirement* for features like Service Worker hinders development and testing. We assumed that localhost (a perfectly valid secure origin) would be enough for these use cases but we were proven wrong.

An option to temporarily whitelist specific origins that have been setup for development and testing purposes has been asked for.

Add an aptly named command line to whitelist specific origins
  --unsafely-treat-insecure-origin-as secure=""

The command line may accept multiple origins.

Chrome must display a banner warning like it does with --disable-web-security. 

Joel also said he would also like to make sure that it doesn't leave anything persistent around. I assume that this means that registration triggered by these whitelisted origins should not persists.

Adding Review-security label for extra scrutiny, leaving as untriaged until reviewed.

Comment 1 by, Dec 12 2014

 1. got the wrong joel :( Sorry.
 2. ignore the * near the Secure Origin requirement.
 3. hyphen missing in the CLI => --unsafely-treat-insecure-origin-as-secure

Comment 3 by, Dec 12 2014

As an offhand comment about implementation to whomever is doing this, I imagine it will basically consist of adding a check in canAccessFeatureRequiringSecureOrigin() ( to see if the command line exists and, if so, check if the given origin is listed in the flag.
one off bug comment about the command line option's ability to let you specify multiple origins: 
 - allowed: specific origins (e.g. and
 - not allowed: use of wildcard to describe generic origins (e.g. http://*
As an offhand comment: I think getting the persistence story correct is necessary, but going to be INSANELY hard.

Suggestion: Require they specify a --user-data-dir that is not the default user's profile.

Suggestion 2: Date the profile, and require it be recreated after X days. The reason to not force clear it every shutdown is to permit tests that may need to relaunch Chrome several times, while discouraging users from making it the new normal.

Comment 6 by, Dec 12 2014

Suggestion 3: Only allow it in conjunction with --incognito?
jww: That seems to defeat the "make it useful for tests" case. So no, I don't think --incognito is sufficient.

Comment 8 by, Dec 17 2014

Why isn't wildcarding allowed? 

Given the subdomain-per-user model recommended at and that serviceworker dev is one of the motivating factors here, it seems like it may be useful in some cases.

What are the arguments against it?

[I'm also fine with arguments of keeping it simple until there is enough vocal demand for wildcarding, but wanted to understand if there were fundamental issues at play here]

Comment 10 by, Dec 18 2014

Allowing wildcarding would pretty much be taking away the whitelisting nature of the flag. Whitelists discourage absent-minded mistakes, and given how dangerous it is to have this enabled, it's important that developers be explicit about where they want it turned on. With wildcarding, all of a sudden you can bypass the whitelist entirely.
"Hey everybody! Want to use the great new features on our HTTP websites? This one cool command-line to use what Chrome developers don't want you to use!


That is, the goal of having any sort of host-specific whitelist is to avoid the --insecure-web-feature-flag sort of hassle by making it less appealing to set it and forget it, and mitigate the damage (see also comment #5)

A wildcard undermines those goals, or you have to get into trickier and trickier 'security' guarantees ("We only allow *.eTLD+1" "Wait, that prevents *!") etc

In your service-worker-per-user model, and are different security principals (which is the point of that post), and thus shouldn't have conflated access. Similarly for command-line purpose, the 'developer' of the site is _either_ Bob or Alice, but not _both_ (otherwise, the separation wouldn't matter)
Great, thanks for the reasoning.

I was thinking restricting to eTLD+1 but as you point out there are
plenty of edge cases there.
Labels: Needs-Feedback
+jeffy, +jake as our sounding boards

We've heard that the secure origin restriction can be quite stringent when it comes to test or develop something. 

We are considering adding the following command line option:


  1. The command line may accept multiple origins but wildcarding is NOT allowed.
  2. Chrome must display a banner warning like it does with --disable-web-security. 
  3. It's desirable that what happened in this mode does not persist (details still under discussion)

Would this be reasonably good?

Comment 14 by, Jan 15 2015

That sounds reasonable to me as a way of addressing the automated testing use case.

For the "average web dev playing around" use case, I guess it's the best possible option. It would be nice if there was a list of origins that have been whitelisted exposed at chrome://serviceworker-internals (and chrome://inspect/#service-workers).
+lgarron@: This bug is parallel with  issue 401386 .
Blocking: chromium:420813
Labels: Cr-Security-UX-WebDev
Labels: M-44
From feedback we got in SW hackathon in Tokyo it looks this feature would be useful for developers.  Could we aim for M44?
Hi! Based on my work on implementing a proof-of-concept offline functionality for MDN documentation[1], I have voiced my concerns over at GitHub[2] regarding the ability to work with Service Workers in more complex developer environments.

The MDN backend (dubbed "Kuma") is based on Django and the standard developer workflow uses a local instance via a VirtualBox VM (managed by Vagrant), executing the whole stack.[3] In such environments (running dynamic webpages without deploying them on a server with a valid SSL certificate for HTTPs connections) using/developing SW-based sites is troublesome at best. 

So far we have resorted to be using Chrome[4] started with the --ignore-certificate-errors command line flag, which at the moment gets the job done, but is, indeed, super-insecure and would be nice to be able to transition away from this workflow as soon as possible.
The command line flag, offered above is a great start and is, in fact, much in line with our thinking (stated @ GitHub[2]), but unfortunately solves just one half of the problem.

Due to the fact that the command-line flag requires launching the browser instance via a specific parameter, it is effectively unusable on any of the mobile platforms - however, IMHO, mobile testing on production devices might be just as important, if not more than desktop testing.

By making the local machine accessible via local network (i.e. setting up WiFi AP mode on dev machine or similar), one could connect to it from any garden-variety phone/tablet/etc. device but any following SW install would fail due to the the invalid SSL certificate served by the development server. Overcoming this would require some kind of mobile UI to make the same kind of whitelisting available on the (shipping) mobile clients (god forbid, the webview, even, if that is possible), that the above command-line parameter provides.

I have high hopes for Service Workers, so I would be very glad if we could weed out as many of the  unnecessary complications to the development & testing as possible to ease dev. adoption. Any feedback on the above is much welcome. Thank you!

+palmer explicitly, to make his codereviews take even and ever longer.
Reg #19: it'd be nice to provide a way to make this option available on mobile env but I'm not sure if we have a good alternative story (would a rough UI on serviceworker-internals or chrome://inspect/ work?).  For now let us start with a simple command-line one and see if we have a way to expand this on mobile.
Status: Available
Labels: -Pri-2 Pri-1
Reg: #13

 3. It's desirable that what happened in this mode does not persist (details still under discussion)

This part's still a bit unclear.  If this means that we need to clear up everything that's saved/stored during the session (but it shouldn't give an isolate profile like incognito mode) that sounds really really tough.

From #5 by

> Suggestion: Require they specify a --user-data-dir that is not the default user's profile.

Would this be acceptable to start with?  So it'd look like:


  1. The command line may accept multiple origins but wildcarding is NOT allowed
  2. Chrome must display a banner warning like it does with --disable-web-security
  3. Require they also specify --user-data-dir
Re: the suggestion, I believe that the combination of #3 and #2 makes this alternative reasonable enough. Will confirm and suggest a string for the "disable-web-security" like banner to the group.
Status: Assigned
Assigning this to myself.
 Issue 401386  has been merged into this issue.
Project Member

Comment 29 by, Apr 20 2015

The following revision refers to this bug:

r194007 | | 2015-04-20T09:18:28.361590Z

Changed paths:

Simplify protocol name and port comparison in KnwonPorts.cpp

Locking on hashmap initialization may causes problem when constructing
referer. Change it to a simpler approach.

(Original patch
created by Ian Wen (Ianwen@) and added test)

BUG= 373141 , 441605 

Review URL:
Project Member

Comment 31 by, Apr 25 2015

The following revision refers to this bug:

commit 8cbea05bcd64f3a778d92435b6102e82c2cb435b
Author: kinuko <>
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.

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

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

  // Gives the embedder a chance to register additional schemes and origins
  // that need to be considered trustworthy.
  // See
  virtual void AddSecureSchemesAndOrigins(std::set<std::string>* schemes,
                                          std::set<GURL>* origins) {}

BUG= 362214 ,  441605 

Review URL:

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


During the code review we realized that --user-data-dir is chrome/ level concept (but not content/), and if we require --user-data-dir together with this option we need to implement this at chrome/ layer, e.g. we can't support this in content_shell.

jochen@ is asking if we could just ignore ServiceWorker registrations from insecure origins when browser is running without the flag, assuming that accidentally running an insecure SW is the biggest threat we want to avoid.

jww@ and others: what do you think about this?

(I've also sent an email to jww@ and jochen@ to discuss this but feel free to respond on the issue too, we need to settle this asap)
Given the abuse we've seen, I feel like it's a bad idea to allow it to be used in the generic case.

I'm not sure why supporting it for content_shell is necessary/wise, but it seems like a scope creep from what was originally proposed.

Comment 35 by, Apr 30 2015

I'm not tied to --user-data-dir, but I am tied to having Service Worker registration wiped off the map after the browser shuts down (or some reasonable period of time). As rsleevi@ mentioned, the type of abuse we're concerned about is website saying, "try our awesome feature by running Chrome with --some-flag-chrome-doesnt-want-you-to-use every time you launch!"

We see this kind of stuff all the time (in fact, we're dealing with a major site doing exactly that today), and letting SWs persist forever as they normally would is really inviting this type of use. I'd be happy if, in practice, the flag used a new magical user directory somehow, and then other embedders can use it too, but I don't know what that would look like.

Alternatively, rsleevi@ also proposed expiring the user profile after X days, which would encourage users to do this. Another suggestion would be to keep track of the SW registrations and explicitly wipe them out after a few days.

Is there an immediate use case for content_shell? I don't consider this flag a feature, but a developer tool, and as such, other emebedders can implement their own developer tools as appropriate, so I guess, like rsleevi, I don't see what it's important to have this off the bat there.
There is a lot of discussion about expiring Service Workers, etc. Ideally, this command line option would be a turnkey solution for any feature that requires a secure origin.

If we need to support content_shell, can we add an IsNonDefaultUserDataDir() method to ContentClient or something?

However, doesn't the banner warning depend on chrome/ anyway? Thus, it may not make sense to support this in content_shell.
Thanks, the abuse scenario gives us much better understanding about what we want to avoid.

Reg: alternatives, expiring user profile apparently requires chrome layer support. ServiceWorker expiration can be implemented in content layer but we need to implement this expiration logic in each module whenever we find something abusive. I'm also worrying that having date/time dependent logic for security related feature as it's easy to introduce bugs.

Reg: banner warning yes it depends on chrome/ but the warning can be made on content-level switches too so it's not really blocking.

From the discussion I prefer starting with --user-data-dir, that introduces least complexity and we could add some expiration logic later too.  As ddorwin@ suggests we could work around the layering by adding some method in ContentClient() if it's desirable.

jochen@ - does it make sense?

i guess content shell could also just implement that command line option - it's a bit of a code duplication, but not a bad one
Project Member

Comment 39 by, Apr 30 2015

The following revision refers to this bug:

r194750 | | 2015-04-30T16:46:10.425121Z

Changed paths:

Initializes SecurityPolicy static locals during blink initialization

These static locals could be touched before we initialize threading
(which is necessary to call AtomicallyInitializedStaticReference)
in chrome build, so simply using AtomicallyInitializedStaticReference
doesn't work well. On the other hand in non-chromium build we need
to make sure they're initialized before or during the blink initialization.

This patch does:
- changes AtomicallyInitializedStaticReference back to DEFINE_STATIC_LOCAL
- adds explicit SecurityPolicy::init() method and call it in the blink
so that static locals are properly initialized regardless of whether
it's in chrome build or not.

(Note: without this patch chrome starts to crash once we land this patch: and give the whitelisting options)

BUG= 441605 
TEST=green bots

Review URL:
Project Member

Comment 40 by, May 1 2015

The following revision refers to this bug:

commit aaff1f6f8942f714a85a097228dd1e0fb13a36b8
Author: kinuko <>
Date: Fri May 01 04:04:13 2015

Support whitelisting to handle insecure origins as trustworthy origins

The whitelist is given and initialized via
--unsafety-treat-insecure-origin-as-secure command-line flag. This needs to be specified with --user-data-dir
to take effect.

Specifying this flag shows a security banner:
"You are using unsupported command-line flag: ....
Stability and security will suffer."

Depends on blink-side patch:

BUG= 441605 
TEST=manual (to see SW on http works with command-line flag & the security banner is shown)

Review URL:

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


Status: Fixed
Labels: -Needs-Feedback Release-notes
Does this issue address the fact that `[mysubdomain].localhost:3000` is treated as insecure (even in Chrome Canary), making it impossible to develop/debug?
Yes, it fixes that. You need to run an instance with the two flags mentioned in the commmit for it to be a trusted origin for that instance.
How would I enable those flags, and what's the second flag?
mmenke, cbentzel: Regarding comment #43, should we change net::IsLocalhost to return true for *.localhost and/or *.localdomain? Currently:

 976 bool IsLocalhost(const std::string& host) {
 977   if (host == "localhost" || host == "localhost.localdomain" ||
 978       host == "localhost6" || host == "localhost6.localdomain6" ||
 979       IsLocalhostTLD(host))
 980     return true;
 982   IPAddressNumber ip_number;
 983   if (ParseIPLiteralToNumber(host, &ip_number)) {
 984     size_t size = ip_number.size();
 985     switch (size) {
 986       case kIPv4AddressSize: {
 987         IPAddressNumber localhost_prefix;
 988         localhost_prefix.push_back(127);
 989         for (int i = 0; i < 3; ++i) {
 990           localhost_prefix.push_back(0);
 991         }
 992         return IPNumberMatchesPrefix(ip_number, localhost_prefix, 8);
 993       }
 995       case kIPv6AddressSize: {
 996         struct in6_addr sin6_addr;
 997         memcpy(&sin6_addr, &ip_number[0], kIPv6AddressSize);
 998         return !!IN6_IS_ADDR_LOOPBACK(&sin6_addr);
 999       }
1001       default:
1002         NOTREACHED();
1003     }
1004   }
1006   return false;
1007 }

Broadening the definition of localhost, if safe and correct, could be very helpful for developers.
Exactly what I'm trying to do, and yes this would help a ton! Actually it says that * localhost * is supported, here: but that seems to be off.
Palmer:  Doesn't the call to "IsLocalhostTLD" in line 979 of the code you pasted already do that for "*.localhost" (But not "*.localdomain")?  .localhost is reserved per RFC2606, but it doesn't look like localdomain is.
That tuple notation is how I write origins: (scheme, host, port). So (*, localhost, *) means "any scheme, the exact hostname localhost, and any port." In 46 I propose to change it to

    (*, *.localhost, *)


    (*, *.localdomain, *)

If the net/ people agree it's a good idea, we'll fix net::IsLocalhost and the documentation on that web page.
#48: Your eyes and brain work much better than mine. I am trying to take it all in stride.

I'm going to put some tests for *.localhost in content/common/ in a moment and see if maybe we're already good.

If .localdomain is not already reserved (I thought it was? Oh well), then we should not use it, and just stick with *.localhost. Which is hopefully enough for developers to work with.
If it's reserved, I'm certainly fine with adding.

I'm also fine with adding different ports, if we need to, but note that IsLocalhost takes a "host", not a HostPortPair.  If we're passing in string with port numbers to that method, think it's actually a bug in the caller.
Don't change that code :)

I reviewed it, it contains all of the reserved bits and nothing more ;)

.localdomain is definitely not reserved :)

estark@ added support for *.localhost and all is right (it would have been dangerous to change that function alone without changing the DNS resolver; if you dig up her CL, you can find the dangerous side-effects that could have happened)


both pass, so I'm not sure why iradchenko is not seeing success in Canary. Are you sure your Canary is up to date?
Yes, but I also have a port, so mysub.localhost:3000/
I added 2 more test cases with non-standard ports, and they pass too.

iradchenko: Can you tell us more about what, specifically, you are trying to do? (What JavaScript API you are trying to call?) It might be that the API you are trying to call is not doing its security check with IsOriginSecure, but instead with some other ad hoc check. That would be a bug we should fix.
Also I'm using hash urls on the client, see the project at, which locally is maldenma.localhost:3000 
On, I get:

ServiceWorker Registration Error:  DOMException: Only secure origins are allowed. {message: "Only secure origins are allowed.", name: "NotSupportedError", code: 9, INDEX_SIZE_ERR: 1, DOMSTRING_SIZE_ERR: 2…}(anonymous function) @ map.js:15524

On, I get:


Still, Service Workers should work on http://mysub.localhost:3000. SW friends, any thoughts?
I used this example, pretty much word-for-word:
Project Member

Comment 59 by, May 15 2015

The following revision refers to this bug:

commit f9094b370aabf724f5ae8187bdd35e15d6091db2
Author: palmer <>
Date: Fri May 15 18:38:51 2015

Add more test cases for IsOriginSecure.

BUG= 441605 

Review URL:

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


Should this be 
Rather than
#60: !! indeed.  Let me make a followup-patch and try to see if we can merge.
Labels: Merge-Request-44
Labels: ReleaseBlock-Beta
Requesting a merge for the typo fix (, this merge should be safe I assume.
Status: Assigned
(Reopening this in case it may not be considered for merge if it's marked fixed)
Neither works for me:

/Applications/Google\ Chrome\\ Chrome\ Canary --unsafety-treat-insecure-origin-as-secure="http://maldenma.localhost:3000"

/Applications/Google\ Chrome\\ Chrome\ Canary --unsafely-treat-insecure-origin-as-secure="http://maldenma.localhost:3000"
#66: did you try also giving --user-data-dir flag together?  The flag needs to be given together to take effect.  E.g.

/Applications/Google\ Chrome\\ Chrome\ Canary --user-data-dir=/tmp/foo --unsafety-treat-insecure-origin-as-secure=
Labels: -Merge-Request-44 Merge-Requested
Labels: Merge-Request-44
Labels: -Merge-Requested -Merge-Request-44 Merge-Approved-44
Sorry about the label confusion.

Might want to let your CL spend some time in a canary before merging.  But when you are very confident:

Merge approved for M44 branch 2403.
#67 thanks, that worked just fine.
Project Member

Comment 72 by, May 20 2015

Labels: -Merge-Approved-44 merge-merged-2403
The following revision refers to this bug:

commit bff801a9453d809e5bef371c03f25f9264307929
Author: Kinuko Yasuda <>
Date: Wed May 20 09:14:52 2015

Merge: Fix typo in --unsafely-treat-insecure-origin-as-secure

'unsafety' must be 'unsafely', apparently.

BUG= 441605 

Review URL:

Cr-Commit-Position: refs/heads/master@{#330404}
(cherry picked from commit 722bc522935f02c4c481e10d926e3321a509bab8)

Review URL:

Cr-Commit-Position: refs/branch-heads/2403@{#29}
Cr-Branched-From: f54b8097a9c45ed4ad308133d49f05325d6c5070-refs/heads/master@{#330231}


Status: Fixed
Project Member

Comment 74 by, May 22 2015

The following revision refers to this bug:

commit bff801a9453d809e5bef371c03f25f9264307929
Author: Kinuko Yasuda <>
Date: Wed May 20 09:14:52 2015

Components: -Security>UX>WebDev
Labels: Hotlist-Security-UX-WebDev
Labels: -merge-merged-2403 -review-security Merge-Merged-2403 Review-Security
 --unsafely-treat-insecure-origin-as-secure chrome shows unsupported command line flag stability and security will suffer in Version 53.0.2785.101 m
5.5 KB View Download

Sign in to add a comment