I suspect the policy may be looking for regex syntax. Can you try:

.*\.example\.com$

jayhlee@ - I have tried with with .*\.example\.com$, but unfoirtunately does not work either 

Hi everyone - I am the owner of this case. Thank you for taking a look at this issue. Any suggestions on next steps?

*.example.org will only match subdomains of example.org -- so it will remove the Not Secure UI on http://test.example.org, but not http://example.org. You would need to include both *.example.org and http://example.org in the policy to remove the Not Secure UI on both subdomains of example.org and example.org itself.

So, I think the behavior is WAI, but I'll leave this bug open in case the documentation should be made more clear.

Thank you. The policy failed:
- http://example:5080

But the policy passed
-http://example.org:80 

Is this because port 80 is the default http port? 
Is it expected behavior not to work for any other port numbers, or by using http://test.example:*? 

My client would like to apply this policy with specific ports, and/or, wildcards for ports in the domain name: 
e.g.: http://example.com:5080 
e.g.: http://example.com:*

Is this possible? Is there any other documentation covering my clients requests?
Again - thank you to the community for your time, and effort with this.

estark@, thank you for details!

I have just checked with two different subdomains:
1. http://testing-ground.scraping.pro
2. http://railsapps.github.io

Policy does work in first case (*.scraping.pro):
https://drive.google.com/open?id=1rdY36Mqyw7V7Y7hcZGArtkCKbHx5fmhN

but does not work in second case (with *.github.io) 
https://drive.google.com/open?id=11RNAzUkNb-4K1Ex7r-RdbLIMPIS_D4Am

Could you please advise why there is a difference in behaviour? 


Policy:

{
   "chromePolicies": {
      "OverrideSecurityRestrictionsOnInsecureOrigin": {
         "level": "mandatory",
         "scope": "machine",
         "source": "sourcePlatform",
         "value": [ "*.scraping.pro", "*.github.io" ]
      }
   },

I believe the underlying host wildcard logic may be preventing wildcards on entire TLDs (which if it is including private registries, which github.io is, would explain this behavior). I'll double check and update this bug.

cthomp@, thank you! 
Could you pelase aslo help with question in #7?
Is it possible to add only specific port(s) to the list?

1) Confirming that the valid wildcard check restricts setting it for registrable labels in the domain and includes private registries [1], i.e., because github.io is an eTLD, you can't set *.github.io. But you could set "http://railsapps.github.io" and "*.railsapps.github.io". This is to prevent people from whitelisting across security principals on the web. For example, *.corp.example.org is all controlled by the same entity, while x.github.io and y.github.io are controlled by different entities. This is an extension of the same logic preventing setting "*.com" as a wildcard pattern.

[1] https://cs.chromium.org/chromium/src/chrome/common/secure_origin_whitelist.cc?gsn=IsValidWildcardPattern&l=42

2) Specifying ports in a wildcard pattern is considered invalid by |IsValidWildcardPattern()| [2]. Specifying specific ports in a non-wildcard origin should work (I tested setting "http://portquiz.net:8080" and it worked on Linux).

[2] https://cs.chromium.org/chromium/src/chrome/common/secure_origin_whitelist.cc?gsn=IsValidWildcardPattern&l=29

If it is prohibitive to individually specify cases with non-standard ports, then we could look into scoping and prioritizing adding support for ports in the wildcard cases (specifying ports with wildcard host labels and/or specifying wildcard ports).

cthomp@, thank you!
I will inform the client of the information you provided. Thank you again to all contributors. Greatly appreciated.

Marking this as WontFix since it appears the issue is resolved as-is. Please re-open if there are remaining issues with wildcards in the policy.