Closed Bug 878917 Opened 7 years ago Closed 2 years ago

Clearing private data doesn't delete sync data on the server

Categories

(Firefox for Metro Graveyard :: Sync, defect)

x86_64
Windows 8.1
defect
Not set

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: jimm, Unassigned)

References

Details

(Whiteboard: [defect] p=0)

From what I remember, we left this issue open the last time we discussed it. We should make a final decision on how clear private data is going to work.

According to bug 877556, we currently blow away your sync connection when you clear, which is one of the solutions we discussed. The alternative would be to mark all data for deletion and leave sync running.

I guess this should probably be a Story if we decide to change existing behavior.
Flags: needinfo?(asa)
Whiteboard: [on hold]
Whiteboard: [on hold] → [triaged-on hold]
This is a broader issue than Metro, to be fair -- Bug 578694, Bug 735532, etc.

You might want to scope this bug down to "if I clear private data in one Windows browser, it doesn't clear it in the other", which you might be able to solve without touching too much of Sync.
Blocks: metrov1defect&change
No longer blocks: metrov1triage
Blocks: metrov1planning
No longer blocks: metrov1defect&change
What does desktop do? We should probably behave the same way. (And this becomes moot if we share profile.)
Flags: needinfo?(asa)
This depends on exactly what you mean by clearing private data.

If you mean "wipe this profile", then it's fair to not sync it -- you're blowing away the sync account, too.

If you mean "clear my history, form history, and passwords", then what desktop currently does was identified -- by Asa! -- as being incorrect in Bug 578694 Comment 16.

Sync *only* fails to sync those wipes because of implementation constraints/omissions. If we have one profile in the cloud, then deletions in one place should propagate.

The only other way I see this working is to ask the user what they mean -- "do you want to (a) wipe this data off all of your other devices, (b) wipe this device and replace it with the contents of your Sync account, or (c) wipe this device and disconnect it from your sync account?".
Blocks: metrov2planning
No longer blocks: metrov1planning
No longer blocks: metrov2planning
Whiteboard: [triaged-on hold] → [defect] p=0
Especially as Sync is becoming a feature under the Fx Account banner, I am treating it as an added service that the user has prescribed to.

Therefore 'clearing private data' feels like it should clear the local data, but doesn't touch any sync interaction - partly because we would expect other devices to be hooked up to the Fx Account for syncing and it would likely be unintended behaviour to kill sync in this instance.

But I think it's also fair that we need a better UX / UI to inform the user IF they have sync set up that this will not affect sync behaviour. 

I would propose that UX revisits the 'clear private data' screen - and also revisits how Android and Desktop manages this - to make the sync interaction more clear to the user (without us managing any sync functionality - users will have control over their sync profile within their Fx Account if they wish to change sync settings)
(In reply to Karen Rudnitski [:kar] from comment #4)
> Especially as Sync is becoming a feature under the Fx Account banner, I am
> treating it as an added service that the user has prescribed to.
> 
> Therefore 'clearing private data' feels like it should clear the local data,
> but doesn't touch any sync interaction - partly because we would expect
> other devices to be hooked up to the Fx Account for syncing and it would
> likely be unintended behaviour to kill sync in this instance.

The reason why I pushed so hard on Bug 578694 is because what you're thinking of as ideal is impossible with the current Sync. There is no such thing as "local data" unless you're using Private Browsing.

Say you start browsing to nsachristmasgifts.com on your device. Doesn't matter which device. As you're browsing, we're silently streaming history items, form fields, etc. into a shared pool on the Sync server. They're indistinguishable from your old history, and your history from other devices.

"Oh", you exclaim. "I didn't want to save this private data!". (And some users won't think in advance to use Private Browsing.)

So you clear private data.

If we don't wipe the deleted data from the server, you're now in a state where:

1. This device doesn't have that private history, but your work computer does. Oops.
2. At a later date, an automated process or an apparently unrelated act by you ("Reset Sync") can cause that history to be synced *back down to this device*, where it will silently reappear in your history from Christmas 2013.

Barn door, meet escaped horse.

So the user *thinks* that their private data has been cleared, but in fact it hasn't -- you just hid it, temporarily, on this device, because the local databases are a cache of the cloud.

If we do wipe the deleted data from the server, then all of your devices agree, and that data is really gone.

That was the conclusion of Bug 578694: this is a cloud system, so that's where your canonical data lives.

Now, this is consistent, but it's *also* a UX problem.

If you're wiping just this session's history, retrospectively removing that history from the server is probably exactly what you want (albeit with Sync's coarseness -- if you visited Reddit in this session, goodbye Top Site!). If you're deleting everything in order to let a friend use it for a while, wiping your other devices is probably *not* what you want.

That might well be the outcome of UX work -- Clear Private Data should really be much more educational, asking what the user wants to do. Start guest mode, educate about Private Browsing mode, ask whether they want to blow away all of their sync data or disconnect sync and delete the local cache (with caveats).

(By the way: it's tempting to think that we can grab the IDs of the items that are about to be cleared somehow separately from the rest of the IDs in the system, and just delete those. This falls down when you realize that those IDs are the ones that Sync would delete already. That's exactly what Sync does.)

My tentative suggestion, given the constraints of the existing Sync system:

1. Clear everything => "Hey, do you want to Reset Sync, or detach this device from your Sync account?"
2. Clear recent => delete it here and everywhere.
3. Clearing anything that's not synced => fine.
I appreciate the explanation. Sync is just one of these beasts. 

With Firefox Account (FxA) being the 'holder' of the Sync service, we have to think of it in those terms: I have 1 or more devices that I can sign into my own FxA and in these instances, data is shared via Sync across these devices.

Now as a user, my initial expectation when I 'clear private data' is that I have cleared the info from that device (like if I'm going to pass my mobile onto someone else / give it away or was embarrassed by some sites I was visiting or what not).  It is unlikely I am thinking about the Sync implications - my mindshare is undoubtedly at a 'device' level in the majority of instances.

So I think we *must* make this a UX / education flow as well as add another step here. Now I am not a proponent of disabling sync as an option - but give the choice to either delete :
A) session data from 'my FxA that enables sync' so that it doesn't get synced across (and back again)
B) all of my data from 'my FxA that enables sync'

Of course, it needs to be smart enough to only show up if I have a FxA.

I'll move this across to the Sync MVP project page as well so it also gets discussed in that forum (so we can also (hopefully) come to a conclusion on what the expected behaviour is for MVP.
(In reply to Karen Rudnitski [:kar] from comment #6)

> So I think we *must* make this a UX / education flow as well as add another
> step here. Now I am not a proponent of disabling sync as an option - but
> give the choice to either delete :
> A) session data from 'my FxA that enables sync' so that it doesn't get
> synced across (and back again)

By this, do you mean "data added in this session"?

Honestly, Clear Private Data + Sync is a broken concept. If we rephrased it as "delete recent history from this device", then it makes more sense, but also shines a bright light on Sync's broken data model -- we know neither your recent history *changes*, nor which changes happened on which device.

It's worth making clear: there is no way to distinguish data by client, context, or session.

The desktop client could be extended to temporarily (and at some expense) track data that was modified since the start of the session, but the action it can take afterwards is much more destructive than "undo all of the data I synced" -- it's "delete anything I touched", not "restore everything I touched".

Even so, there's no good way to reach out to the other clients that have already pulled down this data and integrated it into their own data stores -- no provenance info -- and if your session lasted more than five minutes, that'll be exactly what happened.

Neither Sync nor our browser data stores were designed to address this (in any way!), and so the options available within the current codebase and protocol are exceedingly limited, and also not very easy to explain to users.
How does desktop deal with this? In options we provide the "clear all history" dialog which from my experience seems to work as advertised even with sync connected.
(In reply to Jim Mathies [:jimm] from comment #8)
> How does desktop deal with this? In options we provide the "clear all
> history" dialog which from my experience seems to work as advertised even
> with sync connected.

It pretty much doesn't deal with this. See Comment 1 and Comment 5, which both describe desktop's behavior, and (to a point) Android's, too. The constraints are in our data model and syncing protocol, not really in client logic.
Blocks: 957180
OS: Windows 8 Metro → Windows 8.1
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.