Multiple sync datatypes handle the disable-sync event by deleting data and/or metadata from disk.
As per data is concerned: datatypes like user consents are on a per-gaia-id basis and shouldn't be kept around when sync is disabled (or at least when the user signs out).
As per sync metadata is concerned, it has been historically decided that it's most sensible privacy-wise to wipe it out, and reconstruct again when sync is reenabled.
In the current implementation, we handle the [meta]data wipeout when the user disables sync (or signs out). If it crashes during that process, we don't have the ability to detect that on the next run (and hence consents would be attributed to the next user enabling sync).
A more robust implementation could involve extending our proto ModelTypeState (part of metadata) with a field that represents the owner's identity. If we find a mismatch when sync is starting, all metadata (and in some cases like user consents) should be thrown away.
Comment 1 by bugdroid1@chromium.org
, Mar 12 2018