Can any of the listed side-effects cause any privacy concerns?

Thanks!

Can any of the listed side-effects cause any security concerns?

Thanks!

Do I understand correctly that this works the following:

The file is stored inside the Chrome app storage?
It is not accessible by other apps?
It is not visible to the user?

Yes, the file is stored inside the Chrome app storage and not visible to the user.

The file is also not accessible to other apps, apart from the scenario mentioned at point 2.

Great, I hope the OS  handles this is in a sane way but I don't think this is a big issue. 
Would it be possible to completely prevent this from happening by exporting files with a different name each time?

That is part of what the fix does: https://chromium-review.googlesource.com/c/chromium/src/+/974181.

However, the CL is large and possibly risky to merge.

It's a security and privacy concern in that the file is unnecessarily exposed to a high-capability forensic attacker for longer than necessary. If the patch is difficult to back-merge, it's OK to follow the standard practice of letting it waterfall down into Stable as normal.

The fix I mentioned doesn't completely solve the problem then, as it was mostly aimed at avoiding file collisions if 2 export operations overlap. The fix introduces file cleanup at Chrome startup, which seems to not be sufficient for that kind of attack.

One point that both vabr@ and dullweber@ brought up is whether the current storing of passwords (in the Keychain) would not also be vulnerable to the same kind of attack as a file stored in Chrome’s sandbox? palmer@, is this assumption correct?

If it turns out to be the same, then the only difference, as I understand, is that the keychain is updated when the user deletes their passwords, but the old state persists with the file. However, this would be easy to fix.

The Keychain's forensic defense is a whole complicated thing. I'm not sure I entirely understand it; there are a variety of layers of encryption applied and removed at different times. (See https://www.apple.com/business/docs/iOS_Security_Guide.pdf, starting on page 16).

Whether or not your assumption is correct depends on what storage class the passwords file is in. `NSFileProtectionComplete` would seem to be the best class, I think. I think it would solve the problem as well as can be done. Maybe you're already doing that?

Thank you for your insights! 

Currently the file is written with default protection, which seems to be NSFileProtectionCompleteUntilFirstUserAuthentication. 

To document my next actions here: I will update the way the file is created to have NSFileProtectionComplete and also make sure the files in the passwords/ directory are deleted whenever passwords stored in the Keychain are removed (deleted directly by the user or via sync).

Related:  crbug.com/835687 

Deletion at startup is live in M67 and deletion when items are removed from the keychain has just gone in for M68.

palmer@, should I close this and the related bug as fixed, or should we look for a better long-term solution? 

I think cleaning up the files and using `NSFileProtectionComplete` is probably the best long-term solution. Adding some people who know more about iOS than I do to check that's true. +awhalley,kerrnel

Ping awhalley, kerrnel: Please see comment #15.

I'm not familiar with iOS programming, but awhalley@ might know.

Thanks for the ping.

Yes, using NSFileProtectionComplete would be the best way to go (data not cryptographically accessible unless device is unlocked).  However, that might have some problems if the device is locked during export. I'd recommend looking at NSFileProtectionCompleteUnlessOpen - you can only open the file if the device is unlocked, but you can keep reading from/writing to it unless the file handle is closed, even if the device locks (it also allows you to create files when locked). 

Also, do you know how the keychain items are stored? Should be kSecAttrAccessibleWhenUnlocked (the keychain equivalent of NSFileProtectionComplete) but worth checking :-)

Thank you for the explanation! I checked the keychain items and they are indeed stored with kSecAttrAccessibleWhenUnlocked.

I think the case in which locking the device blocks export is rare due to the relatively small size of the passwords file and because there should be a period of 10s from screen lock to losing access. Even if this happens, we display an error message to the user.

That being said, I think this bug can now be marked as fixed since the original issue, having leftover unprotected files, has been solved.

Thanks everyone!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot