[libertymcateer]

> Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data.

I hear you, but this is not the case with Safari. It offers secure local storage. It's the securesettings API. It uses the OS level encryption, and, based on the current state of play, this does not appear to be compromised.

> as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database.

Is this also the case for Safari? I have not read anything to this effect.

[GauntletWizard]

I'll admit that the OSX Keychain has advantages - Offering OS-managed secure storage, with the possibility of the OS authenticating requests for credentials with the user is pretty cool. But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api.

[libertymcateer]

> But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api.

That is a very fair point, which I will take into consideration.

[mschuster91]

> It uses the OS level encryption

So all the NSA/CIA needs is a XNU kernel exploit which they need anyway for iPhone root exploits. Then, intercept the securesettings API or just do a raw memory dump of the browser process.

And the NSA has another card they can play, and that way easier on Apple than on the fragmented Windows ecosystem: all the tiny chips on your motherboard (EC, or any chip on the PCI bus which has DMA) can read and parse the RAM. Given that there is a highly limited number of different Mac EC chips and even then Apple likely uses the same firmware across them, it's easier for CIA/NSA to develop an exploit for these and don't care about kernel at all.