Activity
While looking over closed bugs I stumbled over https://bugzilla.mozilla.org/show_bug.cgi?id=1440022, which might be relevant here.
Replying to gk:
While looking over closed bugs I stumbled over https://bugzilla.mozilla.org/show_bug.cgi?id=1440022, which might be relevant here. The
"global broadcast"/real time updates API, should not be enabled as long asdom.push.enabled=false. This is becausePushServiceis only initialized in one place: https://searchfox.org/mozilla-esr68/rev/4fc15df791ad4d3ceaf1a958af2bfc1252433ca8/dom/push/PushComponents.jsm#22. And https://searchfox.org/mozilla-esr68/rev/4fc15df791ad4d3ceaf1a958af2bfc1252433ca8/dom/push/PushBroadcastService.jsm usesPushServicebut it does not initialize it, just adds some listeners which will never be used.dom.push.enabledis false in esr68 desktop, but not on mobile AFAIK. We do havepref("dom.push.serverURL", "");which should do the trick, but we might want to have alsopref("dom.push.enabled", false)just in case.To give an idea about what these remote-settings requests look like. Periodically, or responding to some events (e.g. creating a
RemoteSettings(...)client for a new collection), there will be a GET request tohttps://firefox.settings.services.mozilla.com/v1/buckets/monitor/collections/changes/records, used to obtain a list of available "collections" and metadata about them (https://searchfox.org/mozilla-esr68/rev/4fc15df791ad4d3ceaf1a958af2bfc1252433ca8/services/settings/Utils.jsm#57). Each entry looks like:id: 8da7db1e-dffb-18c9-2efe-0e9d7459a0f4 last_modified: 1571184016986 bucket: main collection: normandy-recipes host: firefox.settings.services.mozilla.comFor each collection (distinct
RemoteSettings("...")call), depending on the correspondinglast_modifiedvalue returned in the previous request another request might be performed to retrieve the records of that collection (possibly only the ones that changed since some timestamp). For example, foronecrlcollectionhttps://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/onecrl?_expected=1568310941289would be fetched (with possibly different parameters).One concern is that the different parameters (etag, timestamps...) might be leaking enough info about the user state that it allows linking together requests done over time as belonging to the same user. In principle, the request parameters depend on the values returned in previous responses, and these seem not to change very often. I did not do a deep analysis, but I feel like we would not lose too much by doing the same requests without parameters (as if there was no previous state in the browser). I don't see the responses being so big, nor the requests done so often. But this would probably require a bit more time to make sure the changes are not breaking the
RemoteSettingsfunctionality. Perhaps on a different ticket?For now, I think we can disable the
RemoteSettings("...")calls that we do not need, if only for sparing some unnecessary requests. The currently activeRemoteSettingsinstances are:-
toolkit/components/search/SearchService.jsm(hijack-blocklists)- I think we don't want this one, it allows mozilla to blacklist search extensions.
-
browser/components/preferences/browserLanguages.js(language-dictionaries):- I think we need this one if we allow changing language via
about:preferences.
- I think we need this one if we allow changing language via
-
netwerk/url-classifier/UrlClassifierSkipListService.jsm(url-classifier-skip-urls):- We don't need this one until we enable enhanced tracking protection (content blocking).
-
services/common/blocklist-clients.js(onecrl, pins):- OneCRl and certificate pinning blocklist? I think we want to have these.
Note that the previously mentioned
RemoteSettingsinstances intoolkit/mozapps/extensions/Blocklist.jsmare actually currently disabled because ofextensions.blocklist.useXML = true, see https://trac.torproject.org/projects/tor/ticket/16931#comment:8.So here is a patch disabling
hijack-blocklistsandurl-classifier-skip-urls: https://github.com/acatarineu/tor-browser/commit/31740. If it's ok to disable the latter, we could update #30939 (moved), as we will need to reenable if we decide to enable Firefox Enhanced Tracking Protection.Trac:
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R added
Status: new to needs_review-
Replying to acat:
Thanks for the detailed analysis, really appreciated!
To give an idea about what these remote-settings requests look like. Periodically, or responding to some events (e.g. creating a
RemoteSettings(...)client for a new collection), there will be a GET request tohttps://firefox.settings.services.mozilla.com/v1/buckets/monitor/collections/changes/records, used to obtain a list of available "collections" and metadata about them (https://searchfox.org/mozilla-esr68/rev/4fc15df791ad4d3ceaf1a958af2bfc1252433ca8/services/settings/Utils.jsm#57). Each entry looks like:{{{ id: 8da7db1e-dffb-18c9-2efe-0e9d7459a0f4 last_modified: 1571184016986 bucket: main collection: normandy-recipes host: firefox.settings.services.mozilla.com }}}
For each collection (distinct
RemoteSettings("...")call), depending on the correspondinglast_modifiedvalue returned in the previous request another request might be performed to retrieve the records of that collection (possibly only the ones that changed since some timestamp). For example, foronecrlcollectionhttps://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/onecrl?_expected=1568310941289would be fetched (with possibly different parameters).One concern is that the different parameters (etag, timestamps...) might be leaking enough info about the user state that it allows linking together requests done over time as belonging to the same user. In principle, the request parameters depend on the values returned in previous responses, and these seem not to change very often. I did not do a deep analysis, but I feel like we would not lose too much by doing the same requests without parameters (as if there was no previous state in the browser). I don't see the responses being so big, nor the requests done so often. But this would probably require a bit more time to make sure the changes are not breaking the
RemoteSettingsfunctionality. Perhaps on a different ticket?Sounds good, please file one.
For now, I think we can disable the
RemoteSettings("...")calls that we do not need, if only for sparing some unnecessary requests. The currently activeRemoteSettingsinstances are:-
toolkit/components/search/SearchService.jsm(hijack-blocklists)- I think we don't want this one, it allows mozilla to blacklist search extensions.
-
browser/components/preferences/browserLanguages.js(language-dictionaries):- I think we need this one if we allow changing language via
about:preferences.
- I think we need this one if we allow changing language via
-
netwerk/url-classifier/UrlClassifierSkipListService.jsm(url-classifier-skip-urls):- We don't need this one until we enable enhanced tracking protection (content blocking).
-
services/common/blocklist-clients.js(onecrl, pins):- OneCRl and certificate pinning blocklist? I think we want to have these.
Note that the previously mentioned
RemoteSettingsinstances intoolkit/mozapps/extensions/Blocklist.jsmare actually currently disabled because ofextensions.blocklist.useXML = true, see https://trac.torproject.org/projects/tor/ticket/16931#comment:8.So here is a patch disabling
hijack-blocklistsandurl-classifier-skip-urls: https://github.com/acatarineu/tor-browser/commit/31740. If it's ok to disable the latter, we could update #30939 (moved), as we will need to reenable if we decide to enable Firefox Enhanced Tracking Protection.Looks good, thanks! I cherry-picked the commit to
tor-browser-68.1.0esr-9.0-3(commit e1e1f70187dc106628e8e8c58ecbe23976b31131). Making a note on #30939 (moved) would be good. Maybe we don't want to use that protocol when working on ETP but we should have it on our radar that we disabled it.Trac:
Resolution: N/A to fixed
Status: needs_review to closed-
