<div dir="ltr"><div>I think something like this is important, so thank you for bringing it up.</div><div><br></div><div>I agree that we should detect moves and copies of profiles. (I personally think this kind of module is also a good candidate for centralizing downgrade detection, but that's a separate proposal!)</div><div><br></div><div>On IRC markh proposed a simpler strawman: pull rather than push. The centralized service would indeed track a fingerprint for the current profile, making it available for consumers in Rust, C++, and JS.</div><div><br></div><div>Storage services wouldn't register prefs: they would check the fingerprint when convenient, and take appropriate action. Individual storage modules would be responsible for storing their own fingerprint (e.g., Places would likely store it in places.sqlite) and checking on init.</div><div><br></div><div>This avoids figuring out init of consumers/missing prefs observers; it avoids issues when the user futzes with prefs.js; and it handles corruption of individual files more carefully (because the fingerprint is stored alongside the data).</div><div><br></div><div>It's worth doing two things, I think:</div><div><br></div><div>- Writing this up for a <a href="https://mozilla.github.io/firefox-browser-architecture/text/0006-architecture-review-process.html">brief design review</a>.</div><div>- Figuring out what kind of UX might be necessary here. (Do we need to prompt the user? Synchronously? Do we need a setting to turn it off? What's the interaction with Refresh Firefox?)</div><div><br></div><div>And you and I should talk, perhaps with Mossop, about downgrades: as I alluded to above, I'm thinking about this problem, and one of the solutions might be automatic profile copies.</div><div><br></div><div>Thanks for kicking this off!</div><div><br></div><div>-R<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 1:53 PM, Edouard Oger <span dir="ltr"><<a href="mailto:eoger@mozilla.com" target="_blank">eoger@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
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.<br>
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)<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
So the first question: does this sound like something we should pursue?<br>
<br>
If so, we would also like to propose the following straw-man implementation:<br>
There would be a new module/service that is responsible for detecting the move.<br>
Other code which wants to leverage this capability would register some preference names with this new module/service.<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
I'd like to hear your thoughts about this.<br>
<br>
Thanks,<br>
Edouard<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
</blockquote></div><br></div>