UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. Create an extension that asks for externally_connectable permission on `https://*`

What is the expected behavior?
The extension is connectable from any `https` website.

What went wrong?
The extension is not connectable from any `https` website.

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

TL;DR: restricting externall_connectable to third level domain wildcards effectively (though indirectly) decreases chrome security.

There are a class of extensions that need to interact with arbitrary websites, but only if the website in question is cooperative.  A great example of this are security related extensions that simplify 2FA via browser extensions.  Such extensions serve no purpose when interacting with a page that doesn't integrate with the extension, but any page can integrate with the extension and the list of all pages that integrate is dynamic and not available at install time.

At the moment, for such an extension to do its job it needs to inject a content script which effectively gives the extension full control over all websites the user browses, not just the ones that integrate with the extension.  This situation is less than ideal because now instead of having to trust the website they are viewing with the data provided to the website, the user must trust the extension with all information they enter into any chrome tab.

This is a *massive* security escalation but it is required because `https://*` isn't available to the `externally_connectable` permission.  The security impact of a compromised extension that requires content_scripts to `https://*` is effectively a complete browser compromise.  The security impact of a compromised extension that requires externally_connectable to `https://*` however is restricted to the data that is sent by any webpage to the extension.

By restricting externally_connectable to third level domain wildcards and below, the permissions API has effectively lowered security instead of raising it because it leaves only the worse of two options to extensions that need to interact with a dynamic set of webpages and further trains users away from being cautious of extensions that ask for wildcard content_scripts.

Here is an example of an extension that would benefit from such permissions (to the point where a back-door hack was added just for this extension): https://bugs.chromium.org/p/chromium/issues/detail?id=417062  Non-Google developed chrome extensions that need this are ones that add support for external hardware to chrome (e.g., external security hardware) or interact with desktop apps/drivers.