There are several problems related to gnome-keyring/kwallet (a.k.a. the backend) prompts, such as issue 690435, issue 658348
Common themes are
* To handle the case where a user inconsistently grants access to the backends, components depending (directly or indirectly) on the backend must have increased code complexity. Some components don't expect this and can malfunction.
* The user gets interrupted by a prompt, which is produced non-deterministically by the inner workings of Chrome.
* Chrome malfunctions, because the user is not reacting to the prompt for unlocking the backend.
* Occasionally people mention their unhappiness with facing prompts at all.
We want to offer a promise of stability to the components interacting with backends. We can achieve that by eagerly getting access to the backend on start and block everything until we do (for backends that unlock automatically no blocking will occur). For the users who don't have or want to use a backend, we must offer a way to opt out.
There are several problems related to gnome-keyring/kwallet (a.k.a. the backend) prompts, such as issue 690435, issue 658348
Common themes are
* To handle the case where a user inconsistently grants access to the backends, components depending (directly or indirectly) on the backend must have fallbacks and awareness that carries between runs. This increases code complexity. Components that don't expect this and can malfunction.
* The user gets interrupted by a prompt, which is produced non-deterministically by the inner workings of Chrome.
* Chrome malfunctions, because the user is not reacting to the prompt for unlocking the backend, leading one or more components to block on (de)encryption.
* Occasionally people mention their unhappiness with facing prompts at all.
* Encryption of local data is redundant when the environment is already trusted and protected, e.g. by encrypting the entire drive.
The above is a family of issues, a subset of which can be solved by reworking how and what we expect from the backends. Primarily, we want to offer a promise of stability to the components interacting with backends.
We can achieve that by introducing a user setting on whether Chrome should use the backends. When enabled, access will be non-optional. Users who aren't interested in the value of encryption, either at all or enough to grant access consistently, will now be able to opt out.
Comment 1 by cfroussios@chromium.org
, May 18 2017