Large files and 1Password
Is there a reason why 1Password doesn't deal with / handle large files very well. Last I checked, there was a 20MB limit on the system. Is there a reason for that? Will we ever be able to encrypt larger files within 1Password? I find myself wanting to attach larger backups directly to items in 1Password, as opposed to manually tracking them in a mirrored TrueCrypt database.
Comments
-
As far as I know this limitation is directly related to syncing. Without a limit, we saw many novice users adding huge files and syncing would either take forever or break. For large files you need to work with regularly, we recommend Knox since you don't have to re-atttach a file if you make a change. The "live" version lives in the vault.
0 -
Ah, well I wouldn't mind seeing a feature do release the restriction (for those of us with paid Dropboxes like myself) and perhaps an async attach stage, where attaching doesn't lock the UI (like it does in Windows)
So maybe a Power user mode for attaching would be nice :p
0 -
I'll certainly mention it to the developers. Thanks for letting us know you'd be interested in this. :)
0 -
Great thanks so much!
0 -
Any time! If you need anything else, you know where to find me. :D
0 -
Hello @Urda,
The synching concern isn't so much about Dropbox storage limits, but with what people may have to pay as these sync to their cell phones. At the moment there is no way for 1Password on mobile to check an attachment size prior to fetching it. So until that is sorted out, we have to put an arbitrary cap on attachment size.
There is actually a theoretical limit on how much data should be encrypted under one key. For AES, that limit is in the millions of terabytes, so I think we won't have to worry about that for a while. When we do reach that, we can either switch to a cipher with a larger block size or use multiple keys for different chunks of the data, which is how disk encryption systems work today. 1Password also uses multiple keys, but for different reasons. Each attachment is encrypted with its own key.
Coming back slightly closer to Earth, there is a hard limit of about 4.2 Gigabytes for attachments in the 1Password 4 data format, but to be honest, I don't think we've tested with anything like that. Encryption and decryption would take a very long time. Our choice of encryption modes was not geared toward huge files.
But, of course, of course the limit that we impose, and which you encountered, is far lower than that; and that, as noted, is largely motivated by not synching huge data with mobile.
0 -
At the moment there is no way for 1Password on mobile to check an attachment size prior to fetching it. So until that is sorted out, we have to put an arbitrary cap on attachment size.
Ah I could see how this would be a problem, since it would lead to longer sync times / unresponsiveness in the application. With your detailed writeup I better understand why the system works as it is.
I will just continue to use my current TrueCrypt + 1Password setup, perhaps down the road I'll see 1Password handling larger files in a much easier fashion. Thanks for taking the time developing this project, I don't know what I would do without it!
0 -
I love imaginative uses of 1Password, but sometimes it is better to use tools that are specifically designed for the tasks that you are facing.
0 -
I love imaginative uses of 1Password, but sometimes it is better to use tools that are specifically designed for the tasks that you are facing.
Sounds like a great topic sentence for a FAQ or Knowledge Base article:
DON’T DO THAT!! Things You Should Not Use 1Password For (And What Tools You Might Consider Using Instead)
I’m actually not sure whether to take that thought seriously or not.
@jpgoldberg’s observation is easier to state than it is to put into practice. How is a user to know the intentions of the tool designer? I ran into this very problem when I started using 1Password’s (no longer available) File > Export Selected > Encrypted Web Page function to share passwords and other sensitive information. I thought it was a good security practice. Turns out that it wasn’t, and that this encrypted export feature was not intended to be used for secure sharing. But how could I have recognized this without being told in advance?! On the other hand, how can AgileBits anticipate the myriad ways that its customers will use, and perhaps inadvertently misuse, the product?
The answer, I think, is that you can’t anticipate everything, but you can learn as you go along, and it might actually be useful to aggregate that accumulated learning in a FAQ or a Knowledge Base article.
0 -
How is a user to know the intentions of the tool designer?
Well spotted, @benfdc! I failed to appropriately consider the users' point of view here. My mistake.
0 -
Jeff—No criticism intended. I just wanted to clarify the difficulty.
0 -
No worries, @benfdc. I didn't take it as criticism, but as a very useful and well-warrented corrective.
0
