We discussed supporting use-cases where some engines want to be enabled or disabled per device. 2 easy to describe use-cases: * Someone uses Firefox at work and doesn't want that instance to Sync the saved passwords for work to their personal device. * People don't want to "pollute" their mobile history with their desktop history Richard had some thoughts on this, but I don't think they ever made it to a bug - so here it is.

We talked about this a lot for the original FxA changeover. Lots of product-level opinion at that time was that it would be too complicated, and I got _a lot_ of pushback, so it never happened. Since then I've had conversations with (I think) every product person currently involved with Sync, as well as several UX people (and of course we engineers), and everyone's position can be summed up as "well, duh, of course per-device choices make sense!" (Perhaps in the future I should just wait two years and let time argue my case for me…?) The changeover now will be a little more complicated than it would have been then, but hey. That'll be my next comment…

Things to think about: * We need to pay attention to the transition period where some devices support per-device datatype elections and others don't. * Existence of a collection in meta/global means it has a syncID, which is how we detect resets. We can't get rid of this entirely. * When signing in to an existing account, which checkboxes do we show checked for the user, and what do we do when they change those? If I opt in to history sync on a new device, but no other device is syncing history, what should we do? We added the 'declined' array for this kind of purpose: next time you switch to each other device, it can ask you if you want to start syncing history. (declined isn't perfect, but we can explore this.) * In this world, a device opting into or out of syncing a collection must decide whether to enable or disable it in meta/global and delete data from the server. These choices have two effects: 1. Writing meta/global will turn on or off syncing for other devices, particularly those who don't support per-device datatypes. 2. Leaving data on the server, or removing it, can be good or bad. This is a hard decision: if we're the last person out of the building, perhaps we want to turn off the lights (i.e., delete data from the server). Or perhaps the user is about to turn on history sync somewhere else, and if we issue a delete we're going to lose their data. If we always leave data on the server, then when we're the *first* device to opt in, we face the possibility that we'll merge in a bunch of really stale stuff -- e.g., bookmarks on the server that you haven't had on any device for six months, and you thought were long gone. We don't have a good UI for resolving this kind of thing. Looking at these options it seems clear that we're moving towards a world where (a) meta/global has every collection enabled, and (b) we ask the user more questions about what they're trying to do. Probably me and Ryan and some other folks should sit down in front of a (virtual) whiteboard and draw a flowchart so we can identify exactly which questions we need to ask and when.

I suppose bug 1220929 (Combine various history related panels) will likely impact the solution for this problem. Please include me in the virtual whiteboarding/brainstorming.

+1

(In reply to mpopova from comment #3) > I suppose bug 1220929 (Combine various history related panels)… Bug 1220928. (We need CRCs for bug numbers!) I don't think this'll have too much impact on how we show data locally. It would have an effect on how we message enablement affordances -- it's no longer enough to turn on a datatype _here_, you also have to do it _there_ -- but we don't currently do that: we just offer Sync as a whole, and then leave you to figure things out for yourself. I'd love to see that improve, though.

I haven't heard this come up from any product person, but decided to take a stab at it. Thoughts are welcome. I am not satisfied with our current Sync page, so the radical change this forces might be a good one. However, I have been testing Sync with users for probably two years and check social media regularly and have never heard this kind of request come up. Also, it only offers value to users who are syncing 3 or more devices, so it would be hard to argue that we should prioritize this highly (unless you think the feature is attractive enough to make 2 device users 3 device users).

> it only offers value to users who are syncing 3 or more devices This would also offer more value if sync were a proper backup, with The Cloud functioning as the third device.

Negatives/complications: * Without more infra support -- e.g., each device writing a "here's what I'm syncing" record to the server -- it's not possible to tell what other devices are syncing. * Remotely turning on things to sync is arguably a negative of our current model, given that it enables trivial remote data theft of stuff you chose not to sync if someone has access to your sync account. Is it better to only be able to opt in to syncing things right there on the particular device? * What happens for custom data types? There's a long tail of add-ons. Presumably we can just ignore these? * If we add a data type, what do you see on an earlier device? There's a simpler (in some respects) version of this, which is that we do something very similar to what we do now, but the checkboxes only affect the device you're on. We can build that on top of current Sync pretty easily. The downsides of doing so: * You can end up with stale data sitting on the server that no client is syncing. * You can't see what other devices are syncing; there's no central source of truth. * When you start syncing something, other devices need to prompt you to turn it on or off.

(In reply to Ryan Feeley [:rfeeley] from comment #6) > I am not satisfied with our current Sync page, so the radical change this > forces might be a good one. However, I have been testing Sync with users for > probably two years and check social media regularly and have never heard > this kind of request come up. I've certainly seen bug/feature requests allowing this feature - comment 0 was a reflection of real justifications from users who want this feature. > Also, it only offers value to users who are syncing 3 or more devices, so it > would be hard to argue that we should prioritize this highly (unless you > think the feature is attractive enough to make 2 device users 3 device > users). It seems possible that this feature could push people from being, eg, a 4 device user with 2 accounts to a 4 device user with a single account. Also, see bug 1182397 comment 3 where there's a case being put forward that the current behaviour could lead to users accidentally deleting data - I think that's a bit if a stretch, but there is a grain of truth to it... Beyond that though, I've nothing to add to rfkelly's and rnewman's responses above.

(In reply to Richard Newman [:rnewman] from comment #8) -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< > * You can end up with stale data sitting on the server that no client is > syncing. Is this likely to result in more data-threatening collisions? When users turn Sync back on? > * You can't see what other devices are syncing; there's no central source of > truth. Understood. That might be okay. > * When you start syncing something, other devices need to prompt you to turn > it on or off. They would need to? I am not sure Chrome or iCloud do that for other devices. Wouldn't we also need to offer a way for users to erase certain datatypes from the server?

(In reply to Ryan Feeley [:rfeeley] from comment #10) > > * You can end up with stale data sitting on the server that no client is > > syncing. > > Is this likely to result in more data-threatening collisions? When users > turn Sync back on? Yeah, and bad experiences. Think of it this way: * You set up Sync. It syncs all of your data to the cloud. * You uncheck Bookmarks on both of your devices. * Six months later, you sign in to Sync on a new device. It now automatically has a stale snapshot of your bookmarks from six months ago. That might be desirable -- perhaps you only want a backup! But probably we need to give you control over cleaning up. > > * When you start syncing something, other devices need to prompt you to turn > > it on or off. > > They would need to? I am not sure Chrome or iCloud do that for other devices. That depends what gets built. If we stick with only the current meta/global and no other changes, about the best we can do is detect when any client has opted in to a particular datatype for the first time. At that point the detecting device can either (a) turn on that datatype automatically, or (b) offer to turn it on. I argue that the former is surprising in a world of per-device choices: you'd turn on bookmarks for the first time, and all of your devices would sync them! Even if you later unchecked bookmarks on every device, you couldn't undo that merge, and you'd be upset. If we build more stuff, we can expose a little more functionality, like offering to remotely opt in your other devices when you check the box on one of them. > Wouldn't we also need to offer a way for users to erase certain datatypes > from the server? In the existing meta/global world, we cannot detect when you've unchecked a datatype on every device, which is the point we'd like to use to clean up. I suspect the behavior we want is: * When you start syncing a particular datatype for the first time, we add an entry to meta/global, and also add our GUID to a new list on the server. * When a client sees meta/global grow, it offers (once) to turn on syncing for that type. * When a client unchecks a box, it removes itself from the scratchpad. If it's the last one out the door, it offers to turn the lights out. * When a client record is TTLed away, another client must be responsible for cleaning up the scratchpad -- we aren't aware of when a client has just disappeared for a few weeks versus when it's gone for good. That gives us two or three new prompts: * I see you turned on bookmark sync on Richard's iPhone. Do you want to sync bookmarks with this device? * You're no longer syncing bookmarks with any of your devices. Do you want to remove this data from the server? * "Richard's iPhone" hasn't synced in a while. Do you want Sync to forget about it?

* It feels a bit complicated * I feel it serves a limited audience * It would take a good deal of work to implement properly I'm more in favor of per-device datatype selection, but where the controls are on each device.

We seem unlikely to get to this in this quarter.