What happened:
- In M53, https://codereview.chromium.org/1973483002 (followed by https://codereview.chromium.org/2150543002) introduced os_crypt in Linux (for Gnome+libsecret and for KDE). Before that there was no encryption on Linux, all was stored unencrypted (or encrypted with a hard-coded password). For this change, Chrome on Gnome stored the encryption key in Gnome Keyring, under one of two possible names. The names differed in "Chrome" vs. "Chromium", but by mistake did not correspond to the branding but to optimisations (optimisations on = Chrome, off = Chromium). In case of optimised non-Chrome build this resulted in a confusing name, but all has worked well.
- In M54, https://codereview.chromium.org/2264163002 attempted to fix the choice of names and base it on branding instead of optimisations. As a result, users of optimised non-Chrome builds effectively lose access to the encrypted part of their profile data from M53 in M54.

Who is affected: Users of optimised non-Chrome builds on Linux (KDE; Libsecret is unaffected), in particular vanilla Chromium. It is unclear if other distributions of Chrome, including projects like Opera, are affected -- this depends on how they patch they changes over Chromium. To avoid disruption, we assume anything but Google Chrome is affected.

What data is affected: Notably not passwords, because password storage has not been switched over to use os_crypt. Passwords have been and still are stored directly in Keyring or KWallet, and are unchanged. Other profile data use os_crypt: a quick look at the code-base yields cookie storage, credit card numbers, and even sync. The affected users in M54 will lose access to that data. (We did not investigate if syncing can save them, but it is reasonable to assume that a significant part of those users don't sync.)

Workaround: Changing the storage name with OS tools (kwalletmanager for KWallet) should fix this, but the user needs to be aware of this and do it as soon as possible.

Possible next steps:
 - "Lossy" option: we can ignore the affected Chromium users, and keep https://codereview.chromium.org/2264163002 in. To minimize the impact, we should at least merge it into M53, so that users who joined in M54 or who did not update for a while are spared.
Risk: almost certainly data loss for the affected users, merging into M53 may not be allowed
Cost: none, no migration code bloating the code base
- "Graceful" option: we can revert https://codereview.chromium.org/2264163002 and re-do that with proper migration in M55.
Risk: very low, assuming that no distribution suddenly toggles their optimisation setting during versions 53-55. Users who run optimised and non-optimised Chromium builds side-by-side will still lose data on the former.
Cost: some low maintenance coming from the additional ~150 lines of migration code.

If we want to proceed with the "graceful" option, then we need to revert https://codereview.chromium.org/2264163002 before the branch point tomorrow.



--Plagiarised from vabr's summary of our discussions
 

What happened:
- In M53, https://codereview.chromium.org/1973483002 introduced os_crypt in Linux (Gnome+libsecret), followed by https://codereview.chromium.org/2150543002 in M54 for KDE. Before that there was no encryption on Linux, all was stored unencrypted (or encrypted with a hard-coded password). After this change, Chrome on Gnome or KDE started storing the encryption key in Gnome Keyring / KWallet, under one of two possible names. The names differed in "Chrome" vs. "Chromium", but by mistake did not correspond to the branding but to optimisations (optimisations on = Chrome, off = Chromium). In case of optimised non-Chrome build this resulted in a confusing name, but all has worked well.
- In M54, https://codereview.chromium.org/2264163002 attempted to fix the choice of names and base it on branding instead of optimisations. As a result, users of optimised non-Chrome builds under KDE effectively lose access to the encrypted part of their profile data from M53 in M54. (Luckily, for Gnome+libsecret the name is not used for lookup, so those are not affected.)

Who is affected: Users of optimised non-Chrome M54 builds on Linux with KDE, in particular vanilla Chromium. It is unclear if other distributions of Chrome, including projects like Opera, are affected -- this depends on how they patch they changes over Chromium. As comment #5 below shows, we failed to find a Chromium distribution affected by this.

What data is affected: Notably not passwords, because password storage has not been switched over to use os_crypt. Passwords have been and still are stored directly in Keyring or KWallet, and are unchanged. Other profile data use os_crypt: a quick look at the code-base yields cookie storage, credit card numbers, and even sync. The affected users in M54 will lose access to that data. (We did not investigate if syncing can save them, but it is reasonable to assume that a significant part of those users don't sync.)

Workaround: OS tools like kwalletmanager for KWallet allow the user to copy out the key as well as to rename entries. If the user is aware of this issue before updating to Chrome 54 containing https://codereview.chromium.org/2264163002, they can try to create a duplicate entry with the name changed from Chrome to Chromium and the same key. Or they can try to move the key from the Chrome entry to the Chromium one after the update.

Possible next steps:
 - "Lossy" option: we can ignore the affected Chromium users, and keep https://codereview.chromium.org/2264163002 in.
Risk: data loss for the affected users who have been using M54 non-Chrome with optimisations
Cost: none, no migration code bloating the code base
- "Graceful" option: we can revert https://codereview.chromium.org/2264163002 and re-do that with proper migration in M55.
Risk: very low, assuming that no distribution suddenly toggles their optimisation setting during versions 54-55. Users who run optimised and non-optimised Chromium builds side-by-side will still lose data on the former.
Cost: some low maintenance coming from the additional ~150 lines of migration code.

Based on the discussion below, thestig@ and vabr@ decided to go with "Lossy", as the risks involved were really low, and the maintenance burden zero.