The default bug view has changed. See this FAQ.
Last Comment Bug 1309926 - Allow uBlock Origin to be a WebExtension
: Allow uBlock Origin to be a WebExtension
Status: NEW
triaged[awe:uBlock0@raymondhill.net]
:
Product: Toolkit
Classification: Components
Component: WebExtensions: Compatibility (show other bugs)
: unspecified
: Unspecified Unspecified
P2 normal with 14 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andy McKay [:andym]
Mentors:
: webext-port-adblock-pro (view as bug list)
Depends on: 1190687 1299411 1310026 1312802 1313510
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-13 09:37 PDT by Andy McKay [:andym]
Modified: 2017-03-06 12:41 PST (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Andy McKay [:andym] 2016-10-13 09:37:43 PDT
This is a general tracking bug to allow uBlock Origin to be a WebExtension.
Comment 1 User image R. Hill 2016-10-14 18:00:58 PDT
Ok, I created a WebExtensions uBO by wholly importing the Chromium code, and adjusting where necessary to find out what issues I face from converting uBO as a webext.

Things I had to adjust in the code to be able to launch without errors in Nightly:

- Add code to test for the existence of chrome.privacy, and abort its use if it does not exist. uBO currently needs to be able to set the following privacy-related settings (with FF's corresponding about:config entries listed):

  - Disable pre-fetching
    - about:config / network.prefetch-next
    - about:config / network.http.speculative-parallel-limit
    - about:config / network.dns.disablePrefetch
  - Disable hyperlink auditing
    - about:config / browser.send_pings
  - Prevent WebRTC from leaking local IP addresses
    - about:config / media.peerconnection.ice.default_address_only (if it exists)
    - about:config / media.peerconnection

- Comment out the call to chrome.webNavigation.onCreatedNavigationTarget.addListener (reportedly now fixed as seen above)

- Add code to conditionally use chrome.storage.managed and chrome.storage.sync, which are not yet available for Firefox.

This allowed uBO-webext to be able to load successfully in Nightly.

My first test was to launch a Google search, using "buy car" (which invariable returns a page with ads). However an error was reported at the console, and I have no idea how to fix this one.

uBO uses chrome.runtime.onConnect.addListener to manage communications between content scripts, background page (and its Dashboard/logger pages when opened). Once uBO receives an event that a connection occurred, it registers a message listener for the port passed as an argument. Now the problem occurs when that message listener is called, it misses the second argument, and this breaks uBO.

As per Chrome API documentation, the second parameter to a port.onMessage listener is the port that received the message[1]:

> This event is fired when postMessage is called by the other end of the port.
> The first parameter is the message, the second parameter is the port that
> received the message.

So this is currently a showstopper on my side to convert uBO to webext.

1. https://developer.chrome.com/extensions/runtime#type-Port
Comment 2 User image R. Hill 2016-10-14 18:07:22 PDT
I forgot to mention that the port issue above is an issue which prevents the content script code from doing its job.

However it does appear that uBO's webRequest code works fine with a couple of very quick tests. So uBO can block content at network level, but is broken for everything which requires message sending through ports:

- Content scripts => uBO's main process
- Popup panel => uBO's main process
- Dashboard => uBO's main process
- Logger => uBO's main process
Comment 3 User image R. Hill 2016-10-16 05:53:23 PDT
> the second parameter to a port.onMessage listener is the port that received the message

I am guessing this would be the place where the second argument, portObj, is missing:

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/ExtensionUtils.jsm#1225

Once this is fixed, I am quite optimistic we would have a well working 1st version of webext-based uBO.
Comment 4 User image R. Hill 2016-10-18 12:42:34 PDT
Depends on: 1311128
Comment 5 User image R. Hill 2016-10-29 10:14:29 PDT
I confirm the port issue is fixed with today's Nightly. From now on, I will release a Firefox's WebExtension version of uBO for those who would want to check it out: https://github.com/gorhill/uBlock/releases  -- see uBlock.webext.zip.

Currently, the webext version of uBO is to plainly use the Chromium version of uBO, with only a trivial patch to the manifest.json file and the removal of the chromium-specific polyfill code (needed for older versions of chromium)[1]. So as I had expected, simply using the chromium code essentially worked as is, expect for the other issues reported here.

[1] https://github.com/gorhill/uBlock/tree/master/platform/webext
Comment 6 User image Bob Silverberg [:bsilverberg - on PTO until 03/27] 2017-02-15 13:01:24 PST
(In reply to R. Hill from comment #1)
> Ok, I created a WebExtensions uBO by wholly importing the Chromium code, and
> adjusting where necessary to find out what issues I face from converting uBO
> as a webext.
> 
> Things I had to adjust in the code to be able to launch without errors in
> Nightly:
> 
> - Add code to test for the existence of chrome.privacy, and abort its use if
> it does not exist. uBO currently needs to be able to set the following
> privacy-related settings (with FF's corresponding about:config entries
> listed):
> 
>   - Disable pre-fetching
>     - about:config / network.prefetch-next
>     - about:config / network.http.speculative-parallel-limit
>     - about:config / network.dns.disablePrefetch
>   - Disable hyperlink auditing
>     - about:config / browser.send_pings
>   - Prevent WebRTC from leaking local IP addresses
>     - about:config / media.peerconnection.ice.default_address_only (if it
> exists)
>     - about:config / media.peerconnection

Can you relate these WebRTC prefs back to Chrome's options? Chrome allows one to specify one of the following values for IPHandlingPolicy [1]:
- "default"
- "default_public_and_private_interfaces"
- "default_public_interface_only"
- "disable_non_proxied_udp"

If we implement Chrome's privacy.network.webRTCIPHandlingPolicy, to which of those values would you be setting the IPHandlingPolicy? I want to make sure that our mappings match what you need.

[1] https://developer.chrome.com/extensions/privacy#type-IPHandlingPolicy
Comment 7 User image R. Hill 2017-02-15 13:47:43 PST
> If we implement Chrome's privacy.network.webRTCIPHandlingPolicy, to which of those values would you be setting the IPHandlingPolicy?

uBO uses "disable_non_proxied_udp" if the current setting is "disable_non_proxied_udp", otherwise it will use "default_public_interface_only". In other words, uBO won't select a setting which results in lower privacy, only use a setting value which results in same or higher privacy level.

The Chromium code can be seen here:
https://github.com/gorhill/uBlock/blob/a0c172c13e689c9df2a7f57ada1e115fa4d3db25/platform/chromium/vapi-background.js#L165
Comment 8 User image R. Hill 2017-02-15 13:49:56 PST
Off-topic: Is there an easy way to quote text without having the quoted text end up as a single line with an horizontal scrollbar? I usually find manually but I forgot (again) above.
Comment 9 User image Bob Silverberg [:bsilverberg - on PTO until 03/27] 2017-02-17 09:57:59 PST
(In reply to R. Hill from comment #7)
> > If we implement Chrome's privacy.network.webRTCIPHandlingPolicy, to which of those values would you be setting the IPHandlingPolicy?
> 
> uBO uses "disable_non_proxied_udp" if the current setting is
> "disable_non_proxied_udp", otherwise it will use
> "default_public_interface_only". In other words, uBO won't select a setting
> which results in lower privacy, only use a setting value which results in
> same or higher privacy level.
> 

Okay, so we will be implementing all four of Chrome's possible values for webRTCIPHandlingPolicy, which should handle your use cases for both "disable_non_proxied_udp" and "default_public_interface_only". You also listed "about:config / media.peerconnection" in your initial comment, but I'm not sure to what that refers. There is no pref simply called "media.peerconnection" although there is "media.peerconnection.enabled". Is that what you meant, and if so when would you need to set that?

As I understand it, that is used to enable/disable the ability to create RTCPeerConnection objects. Is that what you need? If so, do you think it would make sense to make that correspond to a new possible value for webRTCIPHandlingPolicy, or how else do you imagine having access to it via the privacy API?
Comment 10 User image Bob Silverberg [:bsilverberg - on PTO until 03/27] 2017-02-17 10:30:29 PST
I have yet another question for you, R. Hill: In trying to determine exactly which Firefox prefs should be flipped to correspond with each of these values for webRTCIPHandlingPolicy, there has been some confusion about the "disable_non_proxied_udp" setting. You seem to have a good handle on which prefs you need in Firefox, so I wonder if you have an opinion. Here's a quote from someone who works on WebRTC regarding Chrome's disable_non_proxied_udp value:

"The documentation for that is not very good; it could be interpreted to mean media.peerconnection.ice.relay_only, or it could be interpreted to mean media.peerconnection.ice.proxy_only. It depends on whether they're using the word "proxied" correctly. If they actually mean "proxied", then it should be equivalent to proxy_only, and if they actually mean "relayed" it should be equivalent to relay_only. (There are two different mechanisms that could be limited here; there's the standard web proxy stuff, and on top of that there is the TURN media relay stuff, which are kinda similar in that they relay packets back and forth)"

Do you have an opinion about which in fact is meant by Chrome's disable_non_proxied_udp value?
Comment 11 User image R. Hill 2017-02-17 10:34:06 PST
> There is no pref simply called "media.peerconnection" although there 
> is "media.peerconnection.enabled". Is that what you meant, and if so 
> when would you need to set that?

Yes, I really meant "media.peerconnection.enabled".

uBO has a checkbox feature called "Prevent WebRTC from leaking local IP addresses".

In older versions of Firefox, there was no setting to specifically prevent the leakage of local IP addresses, so uBO was wholly disabling WebRTC through "media.peerconnection.enabled".

Once "media.peerconnection.ice.default_address_only" became available[1], uBO started to use this setting.

uBO's latest stable release, v1.10.6, uses "media.peerconnection.ice.no_host" (which is a new setting in Firefox 51)[2].

***

[1] Since version 42 according to my notes: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address#firefox

[2] https://github.com/gorhill/uBlock/issues/2337
Comment 12 User image R. Hill 2017-02-17 11:06:30 PST
> Do you have an opinion about which in fact is meant by Chrome's
> disable_non_proxied_udp value?

I believe this may help?
https://bugs.chromium.org/p/webrtc/issues/detail?id=4784#c5

> Disabling this preference prevents non-proxied UDP to be used 
> as it leads to IP leak when using WebRTC. Currently, this is 
> effectively disabling all UDP traffic until UDP supporting proxy 
> is available in chrome.

This issue was originally reported for Chromium:
"When using a proxy, WebRTC leaks unproxied IP address even with multiple routes disabled"
https://bugs.chromium.org/p/chromium/issues/detail?id=497040

Reading through all this, I do wonder if uBO should instead use this setting, I would have to set up a test environment for this -- and so far nobody has reported an issue about this.
Comment 13 User image Bob Silverberg [:bsilverberg - on PTO until 03/27] 2017-02-22 06:37:56 PST
The initial implementation of the privacy API has landed on Nightly (although probably won't be available in a build until tomorrow). It implements the following, which was requested earlier in this bug:

privacy.network.networkPredictionEnabled, which interacts with the following prefs:
    "network.predictor.enabled",
    "network.prefetch-next",
    "network.http.speculative-parallel-limit",
    "network.dns.disablePrefetch"

privacy.network.webRTCIPHandlingPolicy, which interacts with the following prefs:
    "media.peerconnection.ice.default_address_only",
    "media.peerconnection.ice.no_host",
    "media.peerconnection.ice.proxy_only"

privacy.websites.hyperlinkAuditingEnabled, which interacts with the following prefs:
    "browser.send_pings"

I believe that addresses uBO's requirements with respect to the privacy API. Please let me know if that is not the case.
Comment 14 User image R. Hill 2017-03-02 09:48:54 PST
As far as I can tell, it's all working fine with the webext version of uBlock Origin.

Un-checking the option "Disable hyperlink auditing" does nothing really since hyperlink auditing is disabled by default with Firefox 51 (which is really the right thing to do). Still useful for uBO users in case the default setting changes in the future.
Comment 15 User image Tomislav Jovanovic :zombie 2017-03-05 11:27:01 PST
*** Bug 1282893 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.