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 103 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 116624
issue 226931

Sign in to add a comment

Issue 129353: chrome.webRequest.onBeforeRequest doesn't intercept WebSocket requests

Reported by, May 23 2012

Issue description

Chrome Version       : 21.0.1148.0

What steps will reproduce the problem?
1. Create an extension with "webRequest" and "*://*/*" host permissions.
2. Add listener to "chrome.webRequest.onBeforeRequest" in extension's code.
3. Open new tab and perform a WebSocket request to any URL.

What is the expected result?
Listener intercepts request.

What happens instead?
Request is sent without interception.

Please provide any additional information below. Attach a screenshot if
Also, it seems that "ws://" and "wss://" schemes per se are not supported in "permissions" property in application manifest, same as in "urls" property in RequestFilter object. The extension described above intercepts other (non-WebSocket) types of requests as expected.
Showing comments 5 - 104 of 104 Older

Comment 5 by, May 25 2012

Yes, I think it makes sense to do this after the refactoring.

Comment 6 by, Jun 1 2012

Labels: -Pri-2 -Area-Undefined Pri-3 Area-Internals

Comment 7 by, Jun 13 2012

Comment 8 by, Jun 14 2012

+bashi is originally a change to support "URLBlacklist" group policy feature (
I'm not sure that the mechanisms used in both of the policy feature and webRequest are the same one.

Comment 9 by, Jun 14 2012

Looks like the implementation of webRequest APIs is bounded tightly with URLRequest, unlike URLBlacklist. I think it'd be better to support this after refactoring.

Comment 10 by, Jun 14 2012

The usual support for policy based URL blacklists is in ChromeNetworkDelegate::OnBeforeURLRequest, which is shared to be used by the WebRequest API and the policy based URL blacklists.

My point was that once we support the webRequest API for web sockets, we should also have a shared place to do policy based blacklisting and webRequest API based cancelling.

Comment 11 by, Aug 12 2012

Blockedon: -chromium:116624 chromium:116624

Comment 12 by, Mar 10 2013

Project Member
Labels: -Area-Internals -Feature-Extensions -WebKit-WebSockets Cr-Platform-Extensions Cr-Content-WebSockets Cr-Internals

Comment 13 by, Apr 6 2013

Project Member
Labels: Cr-Blink

Comment 14 by, Apr 6 2013

Project Member
Labels: -Cr-Content-WebSockets Cr-Blink-WebSockets

Comment 15 by, Aug 14 2013

Blockedon: chromium:226931

Comment 16 by, Oct 3 2013

Labels: todo-kbx
Status: Unconfirmed
Bulk reset for re-triage.

Comment 17 by, Oct 3 2013

bulk edit for re-triage.

Comment 18 by, Oct 4 2013

Labels: -todo-kbx
Adam and al: can you triage this one? Thanks.

Comment 19 by, Oct 4 2013

Status: Assigned

Comment 20 by, May 13 2014

Adam, do you think that webrequest support for websockets will be a fallout of your work on a new WebSocket stack?

Comment 21 by, May 13 2014

Labels: Cr-Privacy

Comment 22 by, May 13 2014

Do you mean ?
If so, it is not supported from the original old implementation, IIRC.

Comment 23 by, May 13 2014

Ah, sorry. I misunderstood the question at #20. Please ignore my comment at #22.

Comment 24 by, May 13 2014

Yes, exactly. Mike received some external reports that are asking for this. I saw that Adam is the current owner and according to his teams page working on a new Web Sockets stack. So I was wondering whether the problem solves itself automatically. Otherwise, we should see what's necessary to get there.

Comment 25 by, May 13 2014

Right. Old WebSocket stack doesn't use net::URLRequest to issue an opening handshake. OnBeforeRequest() hook of ExtensionWebRequestEventRouter is invoked in the ChromeNetworkDelegate. Events on URLRequest are intercepted by NetworkDelegate but SocketStream events are not.

The new stack uses the URLRequest.

Comment 26 by, May 13 2014

I haven't tested it personally, but in principle it should just work with the new stack.

Comment 27 by, May 13 2014

What happens and should happen on other handlers, e.g. onComplete()?
Maybe the spec is not well defined for WebSocket, I think.

Comment 28 by, May 13 2014

Good point, Takashi. We should draft some spec and discuss it with guys developing the extension.

Comment 29 by, May 14 2014

I am happy to take a look at the spec. Thanks!

Comment 30 by, Jun 20 2014

The old impl with 35.0.1916.153 (Official Build 274914) doesn't work.
The new impl with ToT doesn't work.

Comment 31 by, Mar 16 2015

Owner: ----
Status: Available
I think there are three levels of extension support we could add:

1. Basic interception of WebSocket handshakes, similar to HTTP. We probably should have this, but I don't know how to implement it. Maybe it should be opt-in, so that extensions which up until now haven't seen WebSocket requests don't accidentally start blocking them all?
2. Interception of data frames sent to/from the renderer. This would involve a brand new extension API. I don't know what the use-case would be.
3. The ability to implement WebSocket extensions in Chrome extensions. This would be prohibitively complex.

Comment 32 by, Mar 16 2015

I think option 1 should be fine. That is basically what Firefox does. And would be sufficient for us - Adblock Plus. However, excluding WebSocket requests by default isn't necessary IMO. For example if an extension is blocking all kind kind of requests to, blocking WebSocket requests as well is probably the intended the behavior. And on the other hand if an extension only considers certain request types, it will just ignore WebSocket requests anyway, assuming there will be a new type indicating WebSocket requests.

Comment 33 by, Aug 6 2015


Comment 34 by, Nov 21 2015

I'm also in support of option 1. Like #32, I support opt-out and not opt-in. 

There are badware distributors "exploiting" (using the lack of implementation reflected in this bug) this to distribute potentially dangerous code to clients already.

Comment 35 by, Nov 22 2015

Labels: -Pri-3 Pri-2
Upping priority to P2 due to active exploitation report from #34. It appears that fixing this may be as simple as changing HasWebRequestScheme() in //extensions/browser/api/web_request/ but verification is needed (and there ought to be a test to make sure it keeps working).

Comment 36 by, Nov 27 2015

Labels: Cr-Blink-Network-WebSockets

Comment 37 by, Nov 27 2015

Labels: -Cr-Blink-WebSockets

Comment 38 by, Dec 1 2015

 Issue 488100  has been merged into this issue.

Comment 39 by, Dec 7 2015

Status: Assigned

Comment 40 by, Dec 10 2015

Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.

Comment 41 by, Dec 24 2015

Is there any news here?
This feature would be great for user blockers (such as uMatrix, uBlock).

Comment 42 by, Feb 12 2016

Status: Available

Comment 43 by, Feb 12 2016

Owner: ----

Comment 44 by, Mar 15 2016

Is there any news? Will this be fixed in near future?

Comment 45 by, Mar 16 2016

It's almost 4 years since this bug was open. Do you have plans on implementing/fixing it. This really anticipated feature in terms of network requests debugging.

Comment 46 by, Mar 17 2016

Special chromebug for the distribution of advertising

Comment 47 by, Mar 22 2016 said:
There are badware distributors "exploiting" (using the lack of implementation reflected in this bug) this to distribute potentially dangerous code to clients already. 

Does anyone know an example of this exploit?
Maybe people will notice when real exploit happens in the wild

Comment 48 by, Apr 1 2016

Look at the comment 46 right above yours. There are at least two examples of an advertisements being loaded this way.

Comment 49 by, Apr 1 2016

@48 precisely. 

The failure to implement websocket intercepts means malvertising has an unimpeded path into our browsers. 

I know this bug is tagged privacy, but it's a serious security flaw given how popular it is to breach advertising networks for the purpose of distributing malvertising on large, popular websites.

Comment 50 by, Apr 13 2016


Comment 51 by, Apr 26 2016

Someone reported that there is an advert network (rev defender) that use websocket to deliver advert when other methods are blocked (you can see it at
The discussion is at

Comment 52 by, Apr 27 2016

uBlock Origin has a workaround for this problem: they replace the WebSocket API with dummy code.

Comment 53 by, Apr 27 2016

> they replace the WebSocket API with dummy code

There is no dummy code, it's wrapper code, which purpose is to allow uBO to become aware of WebSocket creation while keeping the functionality of WebSocket when they are not to be filtered.

Comment 54 by, May 3 2016

This issue becomes more important day by day, because advert networks are turning to websocket as a way to evade various ad-blocking softwares.

Comment 55 by, May 3 2016

Whether it is dummy code or wrapper code, they are bad because of chrome's multi-thread multi-process way.
If there is just a slight delay (eg due to a background process doing something), chrome may skip whatever the extension is trying to do or it will be inserted and executed too late meaning the script that use websockets have already been executed.

People have been talking about before-script-execution event and similar to try and solve this issue. Chrome dev team doesn't want to play ball as usual. It must be their motto: "We will not be co-operative at all!".

Comment 56 by, May 23 2016

From comment #35, this looks like a fairly simple fix.
>>> Upping priority to P2 due to active exploitation report from #34. It appears that fixing this may be as simple as changing HasWebRequestScheme() in //extensions/browser/api/web_request/ but verification is needed (and there ought to be a test to make sure it keeps working).

Can anyone from Chrome team verify this assessment?

Comment 57 by, Jun 27 2016

This loophole has already been used by an advert network (revdefender) to deliver advert or anti-adblock scripts.
It won't be long before malware starts using this vulnerability. Only then this issue will be acknowledged as a security problem.
I hope this will be fixed before too many people get hurt.

Comment 58 by, Aug 17 2016

#57:  It's not a security problem for Ad networks to use javascript functions to deliver ads.

Malware that exploits security vulnerabilities in browsers should be addressed at the root, not by breaking core Javascript functionality.

uBlock Origin, Adblock Plus, etc., are breaking core JS functionality and presenting even more security issues by overriding basic JS functions.

It would be prudent for Chrome to implement a fine-grained permission model to allow or disallow extensions from overwriting core JS functionality so users can make informed decisions.

The adblock extensions which overwrite WebSocket() may introduce their own security issues or break other things and the user will almost certainly believe it to be the browser's fault.

Comment 59 by, Aug 17 2016

Adverts are a well documented vector for serving malware. That even has a name "malvertising" . To say that an open source wrapper for the WebSocket function is more of a security risk than these adverts seems crazy to me. (Of course I will be happy when the warppers are no longer required, but I'm not holding my breath there...)

Comment 60 by, Aug 17 2016

#58: While we're at it, how about a fine-grained permission model for what third-party domains the browser can connect to using what technologies, so that these kind of problems can be solved at the root if need be?

And I strongly disagree with your notion that there is only one point at which malware problems need to be solved. Content blockers *already* let the user make an informed decision, and they are an important tool in preventing the spread of malware, *even* if you discard the other reasons for blocking ads (such as not consenting to being manipulated).

Comment 61 by, Aug 17 2016

routeh is working in advertising industry: 

"I am recovering over $1,000,000 / quarter in lost revenue from Adblock for my current employer. I have designed and implemented multiple strategies to combat Adblock."

yep, he's crazy.

Comment 62 by, Aug 17 2016

> and the user will almost certainly believe it to be the browser's fault.

And the best part here: it actually will be "the browser's fault"! 'Cause if someone will manage to break through browser's security using wrapped around WS he will manage to do so without that wrapper at all.

...also, WS is not part of "core Javascript functionality".

Comment 63 by, Aug 18 2016

WebSockets are core functionality.  Overwriting them without informing the user is unsafe.

Once upon a time, Android apps could be installed with a very coarse permission model.  Now, many individual items require user input approval.

It would make sense to adopt this same permission model for Chrome and Extensions, so users can make informed decisions about the extensions they're installing.

What would stop a malicious extension from intercepting WebSockets requests, copying the data and sending it to a logging server?  How would you know?

How can non-technical users understand the risks presented to them from extensions which overwrite Websockets and perform their own logic on top?

Comment 64 by, Aug 18 2016

I see, the advertising industry (the very dark part of this "industry") is very angry: they wont be able anymore to deliver malware using websockets.

What about the malicious ads / popups plenty of pages are trying to deliver to so-called non-technical users ? Are you also worried about them ?

Comment 65 by, Aug 18 2016

> WebSockets are core functionality.
Nope, also you gave a link to WebSocket Protocol, not WebSocket object. JS have a couple of fundamental objects and WS is not one of these.

> What would stop a malicious extension from intercepting WebSockets requests, copying the data and sending it to a logging server?  How would you know?

What would stop malicious extension from stealing your credit card data and show you third-party ads? If extension already have access to the page it can do whatever it want and rewriting WS is just a tiny fraction of that. You can modify the entire page as you wish, so malicious extension can simply add necessary code into the page scripts on the fly. It can log every your keystroke within a page and every single click. Some banks have a special on-screen keyboard with randomized button locations, but malicious extension can detect where you clicked and which number was that. So, separate permission for redefining stuff like WS won't help anyone and only add the confusion.

Comment 66 by, Aug 18 2016

#63: It is very telling that you are conveniently glossing over the problem of ability-to-block-ads, focusing on lobbying for removal of *current means* for doing that instead, despite that not being what this thread is about *at all*.

This is made even more questionable by the fact that you are employed at Mindgeek *specifically* in a role where you are responsible for *preventing ad-blocking*. You are evidently here to try and protect your business, rather than to argue security.

But I'll briefly entertain your question:

> What would stop a malicious extension from intercepting WebSockets requests, copying the data and sending it to a logging server?  How would you know?

Nothing. Just like for any other kind of software. Just like for scripts loaded on the page. I'm all for more granular permission models, but that's not what you're here to argue. You're trying to get the ability to block ads removed.

If you *truly* feel that there needs to be a more granular permission model for extensions, then please create your own issue on the Chromium tracker to argue that, and stop hijacking this one for your own interests.

Comment 67 by, Aug 18 2016

Pornhub and many other adult sites ("Pornhub") are owned by MindGeek[1].

These sites currently deliver 3rd-party ads (including 3rd-party javascript code) through WebSocket connections.

In Chromium-based browsers, WebSocket requests do not go through the webRequest API (the present issue). So they can't be blocked, in practice they are "invisible" to an extension.

A blocker wrapping WebSocket on a Chromium-based browser gain the ability to block WebSocket-based ads served by Pornhub.

uBlock Origin ("uBO") currently does this through its companion extension uBO-WebSocket. uBO-WebSocket still has a relatively small user base.

The next version of Adblock Plus ("ABP") and AdBlock (which uses ABP's filtering engine) will gain the ability to block WebSocket's connections through wrapping.[2]

Adblock Plus + AdBlock together have tens of millions of users.

This is of course what really worries #58 -- only this can explain the nonsensical arguments put forth.


Comment 68 by, Aug 18 2016


> A blocker wrapping WebSocket on a Chromium-based browser gain the ability to block WebSocket-based ads served by Pornhub.

Should really be:

> A blocker wrapping WebSocket on a Chromium-based browser gain the ability to disclose to the user, and to block WebSocket-based connections made by web pages served by Pornhub.

The ability to even just disclose to users these previously invisible connections is a big pro-users forward step.

Comment 69 by, Aug 19 2016

Well, technically they wasn't invisible to the user. If you open page inspector and go to the Network tab they will be there and even marked as "websocket" type.

Comment 70 by, Aug 19 2016

yes, the wording is a bit confusing here.

Actually, in comment #67, he said that:
In Chromium-based browsers, WebSocket requests do not go through the webRequest API (the present issue). So they can't be blocked, in practice they are "invisible" to an extension.

Comment 71 by, Aug 25 2016

Apologies, I would have understood an issue discussing WebSocket to be pertinent.

In any case, I have created an issue to track the idea of granular permission models for Chrome extensions here:

Comment 72 by, Aug 27 2016

For book keeping, Chromium team has merged in to this ticket:

After reading this:

There appears to be a strong motivation on the extension side to ensure they can blacklist / whitelist network calls.  As a for-profit organization, I believe the only reason for this is for them to further profit from "Acceptable" programmes, similar to "Acceptable Ads". 

I can see an offering in the future for "Acceptable WebSockets", "Acceptable WebRTC", etc.

Comment 73 by, Aug 27 2016

#72: Please cut out the nonsense in this thread. The majority of content-blocking extensions are not commercial at all, and have no such programmes.

If you have a problem with AdBlock Plus or their Acceptable Ads programme, then take up the issue with them, and stop polluting this thread.

Comment 74 by, Sep 10 2016

#72 as a non-profit extension developer (Privacy Badger by EFF) I completely support #73 and gorhill's comments on this. Your arguments are inane. There is no security risk that is exacerbated by allowing extensions to block websocket requests beyond the already existant security problems of extensions. 
There are many quite legitimate reasons that adblocking and tracker blocking extensions want to intercept *all* network calls. Especially as long as your industry keeps using super cookies and fingerprinting to track users. I am sure you are well aware of this fact which is why you are here fighting so hard against this API.

Google devs, please pay attention to this issue, it is extremely important for all of us who are writing tracking protection software.

Comment 75 by, Oct 6 2016

Is anyone working on a patch for this?

Comment 76 by, Oct 6 2016

Look at that empty "Owner" field at the top-left corner. Yet, that's it. :(

Comment 77 by, Oct 25 2016

Hi everyone,

I've created a patch for this:
Not sure yet who should review the patch. Asked Dominic (battre@) and Takeshi (tyoshino@) to start with somebody.

Comment 78 by, Oct 28 2016

+nasko and charlie - any security concerns with allowing extensions to intercept web socket requests assuming they have the proper host permissions?

Comment 79 by, Nov 2 2016

Although not directly related to the "industry versus private (single) user" debate per se, this will have repercussions in what other programmers can dictate onto a browser's visitor.

It is a creative use to use/misuse/abuse WebSockets to attempt to bypass adblocking but it still remains an invasion of privacy nonetheless. So I can only agree with comment #73 and #74 and have to wonder about Comment #72 a lot. This is not solely about adblocking per se - it also is about what is deemed "permissible" by the google chromium team for third party content providers to dictate onto visitors and what kind of control the visitor will have over content sent to their browser(s).

Comment 80 by, Nov 3 2016

@72 If a for-profit organisation is what it takes to ensure that ad-networks are doing their due-diligence when it comes to protecting consumers against malicious and invasive ads, then so be it.

The ad networks put themselves in this corner with their greed. If they spent even 1% of their revenue, ensuring that the ads run on their networks were SAFE to run, then we wouldn't be in this situation today.

Additionally, arguing for granular permissions, or against WebSockets in particular is nonsense. NoScript exists. Content-Blockers exist. Firewalls and Anti-malware products exist. This has NOTHING to do with breaking JS functionality, as there are far more integral parts to JS out there that are disabled by extensions as it stands.

Personally, I think ALL parts of the request stack should be configurable via extensions. Extensions themselves ARE the permission set that you speak of already, and I see no reason to go more granular than what we already have for web-requests, etc.

Comment 81 by, Jan 21 2017

@77 provided a patch for review by Chrome team. Can Chrome team please review it? Thank you.

Comment 82 Deleted

Comment 83 by, Feb 17 2017

Project Member
The following revision refers to this bug:

commit a7a2ee3f307090e4f5dd8848ce498c939993b3db
Author: pkalinnikov <>
Date: Fri Feb 17 12:39:54 2017

Introduce WebRequestResourceType.

WebRequestResourceType enumerates all resource/request types that WebRequest
API cares about.

There is a 1-to-1 mapping between WebRequestResourceTypes and their string
names. Helper functions are provided to get string representation for each
type, and vice versa.

Each content::ResourceType maps to a single WebRequestResourceType, while the
latter can correspond to multiple content::ResourceTypes, e.g., the OTHER type.
Note that this CL also makes 3 content::ResourceTypes (SUB_RESOURCE, PREFETCH,
and CSP_REPORT) map to OTHER explicitly (before they were indirectly considered

Some (so far only 1) types are not covered by content::ResourceType. For
example, the WEB_SOCKET type represents a WebSocket request, and corresponds to
URLRequests which have a ws/wss scheme. A helper function is provided to
compute type from a URLRequest in such a way that it takes both scheme and
content::ResourceType (if any) into account.

This CL also adds 'media' and 'websocket' types to WebRequest API.

BUG= 129353 

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


Comment 84 by, Feb 20 2017

FYI (in response to the commit description of a7a2ee3f307090e4f5dd8848ce498c939993b3db): CSP reports have always been mapped to the "ping" webRequest type (since internally CSP reports were flagged as ping by Blink).
CSP reports will be flagged as the (new) "csp_report" type once the patch for  bug 637577  lands.

Comment 85 by, Feb 22 2017

Project Member
The following revision refers to this bug:

commit 0f198df6bc8da6fe51b34f11b50936700b6e9353
Author: pkalinnikov <>
Date: Wed Feb 22 11:11:24 2017

Support WebSocket in WebRequest API.

This CL makes WebRequest API support intercepting the WebSocket handshake
request. Since the handshake is done by means of an HTTP upgrade request, its
flow fits into HTTP-oriented WebRequest model. Additional restriction applies,
that WS request redirects triggered by extensions are ignored.

Note that WebRequest API does *not intercept*:
 - Individual messages sent over an established WebSocket connection.
 - WebSocket closing connection.

The |details| object reported to extensions uses the newly introduced type of
request: 'websocket'.

BUG= 129353 

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


Comment 86 by, Feb 22 2017

Status: Started (was: Available)
Hello everyone,

The fix has landed. I see a lot of interest here, so please try it out. Happy to receive feedback.

Comment 87 by, Mar 3 2017

Labels: M-58
Status: Fixed (was: Started)
Marking as fixed. The feature is available starting from Chrome 58.

Comment 88 Deleted

Comment 89 by, Mar 5 2017

Extra thanks to the team for making this to work for declarativeWebRequest too!!

Confused me a bit at first because redirections didn't work, but I found out this was by design.

Comment 90 by, Mar 6 2017

#88 ( Raymond, did you delete your comment? I was going to respond that the feature is available from 58.0.3021.0. Did you make it work?

Comment 91 by, Mar 6 2017

#90 I thought I just added noise to the thread and that I should wait to know which build for sure contains the fix. So I am on build 58.0.3026.3 (linux), and so far I have not been able to see websocket reported.

Comment 92 by, Mar 6 2017

Alright, never mind, it works fine. I had forgotten one "tiny" detail: to add "ws://*/*" and "wss://*/*" to "permissions" in the manifest.

Thanks for your work.

Comment 93 by, Mar 9 2017

Works for me in the Linux dev channel (58.0.3026.3), using the existing "<all_urls>" permission.

Comment 94 by, Mar 29 2017

It seems that nobody thought about updating validation in Chrome Web Store. An upload fails right now:

  The manifest defines an invalid url: ws://*/*. (PKG_MANIFEST_PARSE_ERROR)
  The manifest has an invalid URL scheme: wss (PKG_MANIFEST_PARSE_ERROR)

Comment 95 by, Mar 30 2017

+rdevlin.cronin@: Devlin, do you know how to address #94?

Comment 96 by, Mar 31 2017


Comment 97 by, Mar 31 2017

+James for comment #94 on CWS

Comment 98 Deleted

Comment 99 by, May 1 2017

+lottie for comment on #94.

Comment 100 by, Jun 12 2017


Am trying to intercept cookies in ResponseHeaders through webRequest.onHeadersReceived.

This works fine for reqular http(s) requests, but for the ws:// request containing the "Connection: Upgrade" and "Upgrade: WebSocket" headers, it doesn't seem to work: the webRequest.onHeadersReceived is never called, but a Set-Cookie header in the response is applied to the CookieJar of the page I'm on. 

So I'm unable to intercept cookies set by the server on the response of the WebSocket upgrade request.

Am I maybe doing something wrong, is this by design or a bug?

My host permission is <all_urls> and my filter uses url's with the *:// protocol

Comment 101 by, Jun 13 2017


Hello. A short answer is that onHeadersReceived probably should be called (at least it is so in the tests:

Can you please file a separate bug for this issue? This one is already quite long, and was initially for supporting onBeforeRequest.

Comment 102 by, Jun 13 2017

Nevermind... whentrying to create teh case and coming up with a reproducible scenario, I figured out what i was doing wrong: I used *://* as urls in the filter for my listeners. 

Turns out *:// only maps on http and https, not on any other schema, including ws(s).

Adding the proper url's with ws(s):// schema's to the list of urls in my filter solved the problem

Comment 103 by, Aug 30 2017

`*://` permission do not work for ws/wss also

Comment 104 by, Aug 30 2017

#103, this is documented behavior: * matches only http and https, 
Showing comments 5 - 104 of 104 Older

Sign in to add a comment