#31740: Review RemoteSettings usages in esr68 -------------------------------------+------------------------------------- Reporter: acat | Owner: tbb-team Type: defect | Status: new Priority: Medium | Milestone: Component: Applications/Tor | Version: Browser | Keywords: ff68-esr Severity: Normal | TorBrowserTeam201909 Actual Points: | Parent ID: Points: | Reviewer: Sponsor: | -------------------------------------+------------------------------------- `RemoteSettings` (https://firefox-source- docs.mozilla.org/main/68.0/services/common/services/RemoteSettings.html) is now used for several features as a way to synchronize some local state (collections, sets of records) with some remote state that Mozilla controls. I did not review the protocol, but the way I understand it is that there are periodical polls to the server with an etag header (last_timestamp, returned by the server in a previous poll) which return the list of changes since that timestamp. I think this etag may be quite close to a user identifier, so Mozilla's servers could probably link together all the RemoteSettings request can get is the sequence of all 'RemoteSettings polls' for a user. Not sure how much you can guess about the user with that, though.
In any case, opening this to decide/review which ones of the usages of RemoteSettings we need or not. The `RemoteSettings` one is probably a subset of the requests happening in background, but I guess it's a start. I'm listing files where `RemoteSettings` are used. My understanding is that just calling `RemoteSettings('acollectionname')` will start the syncing mechanism, meaning that there will be requests polling in background 'from time to time'. * `browser/components/newtab/{lib/ASRouter.jsm, lib/FaviconFeed.jsm, lib/PersonalityProvider.jsm, lib/SiteClassifier.jsm}` * These should not be run if we disable Activity Stream (#31575). * `toolkit/components/normandy/lib/RecipeRunner.jsm` * I think this will not be run, since the `RemoteSettings` is created lazily when `gRemoteSettingsClient` is accessed, and that should not happen since we have `datareporting.healthreport.uploadEnabled = false`. * `toolkit/components/search/SearchService.jsm` * Used to update the "ignore list settings" which can be used to remotely "ignore" search engines? I think we can remove this one. * `browser/components/preferences/browserLanguages.js` * There is a dump for this one in `services/settings/dumps/main /language-dictionaries.json`. It seems to be a mapping of locale to dictionary ids. We probably have to keep this one if we want to allow changing UI language in `about:preferences`, via Mozilla's language packs. * `netwerk/url-classifier/UrlClassifierSkipListService.jsm` * If I understand it correctly, this is used for content blocking, to be able to skip some steps ("features") for specific urls. I guess to be able to fix antitracking breakage remotely? We should not need this one if we don't plan to make it possible to enable content blocking/mozilla's antitracking. * `security/manager/ssl/RemoteSecuritySettings.jsm` * Intermediate certificate preloading. There is #30682 to decide what to do with this. Finally some blocklists, I think some of them we already have in esr60, but not all? Not completely sure, but I would say it's better to keep these? * `services/common/blocklist-clients.js` * onecrl (already in esr60). * pinning blocklist (related to HPKP? not sure if it's in esr60). * `toolkit/mozapps/extensions/Blocklist.jsm` (these were already in esr60) * extensions blocklist * plugins blocklist * gfx blocklist -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31740> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs