Your post is correct, but I do think it's an issue worth highlighting.
I remember when I first learnt about the ability to view your 1Passworld vault even without the app installed. I wondered how they were able to do something so useful, so I looked into the files and saw that my usernames and websites were in plain text, which was pretty surprising. I don't think it's unfair to assume that all of your data is hidden behind your master password, not just the actual passwords. Even if you don't use any syncing options like Dropbox, they're still being stored on your local machine in plain text. Fair enough, someone isn't able to view your passwords, but they can see the "metadata" — enough to know what websites you have accounts for. Again, I would assume that most people would assume that none of this is visible without entering the master password.
As to him using the Dropbox referral link, I'm torn. I'd have more of an issue with it if he was using a referral to buy 1Password after pointing out its flaws.
Though I don't have that expectation, it's fair point that users have expectation that everything is hidden behind the master password.
But I think this is a potential privacy issue rather than a security issue. And it happens only when your computer (or your Dropbox account) is exposed, which the theft can actually can much much more than the login history, and makes this leak too little to care, comparing to your important files, ssh keys, logged in email session in browser etc.
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.
Agreed. There's no way to have this stuff exposed unless you're logged into your Dropbox account. It's not like 1Password has made all your stuff available publicly, unless you've made this a folder/file a public link in Dropbox. Which is really user error more than 1Password's fault. The original article is very much a boy who cried wolf story.