Where the design community meets.
If I were building 1Password, one goal would definitely be that nobody could sit down at (or steal) another user's computer and easily get the user's data from the filesystem. Maybe that goes beyond the basic value prop, but when you're selling a security product, it should be built with security in mind from the bottom up. And no, suggesting that it's the user's fault for not password-protecting their filesystem is doesn't cut it when your product is for people who can't remember passwords.
As for the dropbox issue, it needs to be extremely clear to the user what's happening here, and they need to be given instructions to confirm that they are not making this data publicly accessible. An important population of the customer base are folks who have trouble remembering not only passwords, but details in general, and may not be fully computer literate. Plus, 1Password is heavily relying on a third party here, which should scare the pants off them.
Plus, ,last night my girlfriend was trying to use the unpaid version of 1Password to sync her data from her phone to a new laptop. To use icloud, the recommended (and presumably more secure) sync method, she would have had to pay $30, so she was forced to use the dropbox method instead.
The initial post was alarmist and not totally accurate, but there's definitely some work 1Password needs to do here to do right by the user.
I checked the contents.js file again. It's only the URL is in plaintext, not even your username. I can imagine, the URL is used as some kind of index table. I think this is a good balance without the security trade-off. Your browser history and bookmarks hold all these information too.
As the official help states:
The more that is encrypted, the less a would-be thief can access, but it is also necessary to leave enough open to allow applications to freely access certain items without needing to decrypt every single entry each time. The Mac OS X keychain nicely balances security and convenience, so the Agile Keychain follows suit.
And in this post:
If your 1Password data are captured, the encrypted information is secured from any attack which professional cryptographers and security experts can imagine. However, some information among your 1Password data is not encrypted. The unencrypted information is includes the web locations (URLs) and the Titles you give to items. The unencrypted information available is similar to the information available from web browser bookmarks. Although we may not be comfortable with that information being compromised it is not a significant security risk for most people.
As for the Dropbox issue, I think it is very clear that a Dropbox user won't make their files public by default. That's why Dropbox provides a "public" folder. And when you share files from anywhere else, you need to manually choose "Share public link", then it returns the public URL with random string inside, which make it difficult to be guessed or brute force. So only you and the recipients that you send the link to, know the path to that file. With this gatekeeper, I don't think it's a problem even for a non-tech user with some accidentally wrong files operations. Even, in the worse case, the whole 1password keychain folder is in public, then it is like making your browser bookmark/history public, which is not nice, but still secure for all the usernames/passwords.
By the way, using iCloud is more or less the same because the files are still in the file system, under the user's library folder somewhere.
Using a securely designed 3rd party file sync is absolutely fine. In my opinions, it is a better approach than AgileBits builds their own cloud sync method because it's not their focus.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.