[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #31740 [Applications/Tor Browser]: Review RemoteSettings usages in esr68
#31740: Review RemoteSettings usages in esr68
-------------------------------------------------+-------------------------
Reporter: acat | Owner: tbb-
| team
Type: defect | Status:
| needs_review
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: ff68-esr, tbb-9.0-must-alpha, | Actual Points:
TorBrowserTeam201910R |
Parent ID: | Points: 0.5
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by acat):
* keywords: ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201910 =>
ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201910R
* status: new => needs_review
Comment:
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 to
`https://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 corresponding `last_modified` value 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, for `onecrl` collection
`https://firefox.settings.services.mozilla.com/v1/buckets/security-
state/collections/onecrl?_expected=1568310941289` would 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 `RemoteSettings` functionality. 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
active `RemoteSettings` instances 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`.
* `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 `RemoteSettings` instances in
`toolkit/mozapps/extensions/Blocklist.jsm` are actually currently disabled
because of `extensions.blocklist.useXML = true`, see
https://trac.torproject.org/projects/tor/ticket/16931#comment:8.
So here is a patch disabling `hijack-blocklists` and `url-classifier-skip-
urls`: https://github.com/acatarineu/tor-browser/commit/31740. If it's ok
to disable the latter, we could update #30939, as we will need to reenable
if we decide to enable Firefox Enhanced Tracking Protection.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31740#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs