Profile move detection module
eoger at mozilla.com
Mon Mar 5 21:53:58 UTC 2018
While working on Sync support for per-channel profiles in bug 1419505, we identified a number of actions Sync should take when a profile is cloned.
We’ve also seen issues reported by users where, after some discussion, we finally discovered that the user manually made a copy of their profile which resulted in the reported problem (e.g., bug 1234181)
We’ve also since established that Sync isn’t alone here. Components such as FxA, Telemetry, the Push service, and others we might have forgotten, become buggy in ways that could be mitigated if the code was aware of the profile copy. However, if we implement a solution just for Sync, we know that users are still going to have related issues in these other components.
We would like to propose a general solution which can be leveraged by all impacted code. This solution would centralize how a profile move is detected but allow each of the impacted modules to take whatever action is necessary. A key advantage of this is that it would be useful both for per-channel profiles and for the cases when a user explicitly makes a copy of their profile.
Note however that we’d probably want a way to disable this for users who keep their profile on a USB stick or other scenarios where the user regularly “moves” (rather than “copies”) their profile.
So the first question: does this sound like something we should pursue?
If so, we would also like to propose the following straw-man implementation:
There would be a new module/service that is responsible for detecting the move.
Other code which wants to leverage this capability would register some preference names with this new module/service.
The new module/service would detect the change by comparing a hash of multiple metrics at each launch of the browser: the full path of the profile folder, the computer hostname, logged in username etc. We are open to ideas on ways to enhance that “fingerprint”. It would persist this fingerprint somewhere.
If a move is detected, that module would toggle these pre-registered preferences. The external modules would then be responsible for checking the pref, taking whatever action they feel is necessary, and reset the pref.
There’s some devil in the detail here, but using preferences seems better than observers as we would like to make this check as soon as practical, while acknowledging that for performance reasons the impacted modules may not be loaded at the time the move is detected. However, we are open to any solution.
I'd like to hear your thoughts about this.
More information about the firefox-dev