[Intent to implement] Access to gnome-keyring/kwallet becomes a setting

[Christos Froussios]

Contacts

cfrou...@chromium.org, va...@chromium.org

Summary

We propose to introduce a setting on whether Chrome should expect access to Gnome-Keyring and KWallet. The user must either grant access consistently or disable it. This should improve stability and decrease unwanted prompts.

Tracking bug

http://crbug.com/709096

Details

https://docs.google.com/document/d/1oNkL2PBig5AAEBScPu1ajRiei_vz7PTP4op7vyXAa10/edit#

Some sections of the document are still open to discussion.

[Václav Brožek]

The current issues with the Keyring/KWallet are a headache and Christos' proposal linked above seems to me like a reasonable approach to fix that.

Let me emphasise that early technical input is useful here, because:

• The proposal contains changes to Chrome's start-up code.
• Keyring/KWallet are used by OSCrypt, which in turns is used in a number of Chrome's components.
  

Additionally, the proposal will introduce new UI and highlight (existing) risk of data loss. Those parts will be designed and reviewed according to standard launch processes, but the engineering questions would be best settled here before the implementation starts.

Cheers,
Vaclav

[Brett Wilson]

If it 's easy to implement, this seems nice. And on the plus side, I doubt UI review cares about desktop Linux much which will make the job easier.

I'm slightly worried about edge cases in switching causing a big headache. Hopefully we can minimize that since the benefit here doesn't justify *too* much effort.

We should be sure to test that switching doesn't confuse sync and then also delete the "lost" data from the server. If sync works, hopefully it just recreate everything after the switch.

Brett

On Tue, Jun 6, 2017 at 6:00 AM, Václav Brožek <va...@chromium.org> wrote:

The current issues with the Keyring/KWallet are a headache and Christos' proposal linked above seems to me like a reasonable approach to fix that.

Let me emphasise that early technical input is useful here, because:

• The proposal contains changes to Chrome's start-up code.
• Keyring/KWallet are used by OSCrypt, which in turns is used in a number of Chrome's components.
  

Additionally, the proposal will introduce new UI and highlight (existing) risk of data loss. Those parts will be designed and reviewed according to standard launch processes, but the engineering questions would be best settled here before the implementation starts.

Cheers,
Vaclav

On Thu, 18 May 2017 at 17:42 Christos Froussios <cfrou...@chromium.org> wrote:

Contacts

cfrou...@chromium.org, vabr@chromium.org

Summary

We propose to introduce a setting on whether Chrome should expect access to Gnome-Keyring and KWallet. The user must either grant access consistently or disable it. This should improve stability and decrease unwanted prompts.

Tracking bug

http://crbug.com/709096

Details

https://docs.google.com/document/d/1oNkL2PBig5AAEBScPu1ajRiei_vz7PTP4op7vyXAa10/edit#

Some sections of the document are still open to discussion.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAN8iHei3KMC-n_zf5ch2AXTU34aWihjBkGHfKgSbx2d-%2BoDXHA%40mail.gmail.com.

[Michael Giuffrida]

On Tuesday, June 6, 2017 at 8:53:42 AM UTC-7, Brett Wilson wrote:

If it 's easy to implement, this seems nice. And on the plus side, I doubt UI review cares about desktop Linux much which will make the job easier.

Let's go ahead and not assume that it works like that.

 

I'm slightly worried about edge cases in switching causing a big headache. Hopefully we can minimize that since the benefit here doesn't justify *too* much effort.

We should be sure to test that switching doesn't confuse sync and then also delete the "lost" data from the server. If sync works, hopefully it just recreate everything after the switch.

It's important that the settings UI, or the bubble or whatever you decide to use for this, clearly explains the consequences of setting or switching this setting. The behavior here sounds unintuitive, so we'll want to think about how to display it: https://docs.google.com/document/d/1oNkL2PBig5AAEBScPu1ajRiei_vz7PTP4op7vyXAa10/edit#heading=h.vhav3yz0ze1v

[Christos]

On Tuesday, June 6, 2017 at 5:53:42 PM UTC+2, Brett Wilson wrote:

If it 's easy to implement, this seems nice. And on the plus side, I doubt UI review cares about desktop Linux much which will make the job easier.

I'm slightly worried about edge cases in switching causing a big headache. Hopefully we can minimize that since the benefit here doesn't justify *too* much effort.

We should be sure to test that switching doesn't confuse sync and then also delete the "lost" data from the server. If sync works, hopefully it just recreate everything after the switch.

Good point. I've added this to the Testing Plan section. 

Ultimately, treating an unsuccessful decryption as a deletion is a bug that each component needs to test for itself, but this is a good opportunity to check that such a bug doesn't exist today.

[Christos]

Given the discussion so far, I've updated the document and marked the preferred approaches. I hope to begin prototyping soon.

@Michael: Do you want to be involved in the discussions to decide the details of UI?

[Adam Rice]

I was concerned about more cases that would need to be tested, but my understanding of the design doc is that the "no keyring" case already effectively exists as a fallback. Correct?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e1bae15b-b8e8-4123-8ea2-c6bba7526d79%40chromium.org.

[Christos Froussios]

It's not clear to me what the "no keyring" case refers to when it comes to testing.

Chrome already also works without keyring/kwallet, just with reduced security.

[Christos Froussios]

After an attempt to prototype it, I discovered that OSCrypt cannot simply use user preferences. The reason is that preferences are initialised during profile creation, while encryption needs to be already initialised during profile creation.

I added a section to the documentation describing the options we considered.

https://docs.google.com/document/d/1oNkL2PBig5AAEBScPu1ajRiei_vz7PTP4op7vyXAa10/edit#heading=h.b2x32umc2se1

Our preferred approach is to save the preference outside of profiles, in the user data directory.

PTAL

On Thursday, May 18, 2017 at 5:43:25 PM UTC+2, Christos Froussios wrote:

Contacts

cfrou...@chromium.org, vabr@chromium.org

[Christian Dullweber]

ProfileAttributeStorage might be useful, it already stores some settings that can be accessed even before a profile is loaded. 

https://cs.chromium.org/chromium/src/chrome/browser/profiles/profile_attributes_storage.h?type=cs&q=profile+attribute+storage&l=60

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82269fae-9915-4439-9225-37686bface85%40chromium.org.