Can i preview attached photos inside 1Password?
Comments
-
@DBrown At the end of a previous discussion on this subject both you and @svondutch seemed positive about the idea of an option to allow the "slightly insecure" mode. Has that positivity changed now?
0 -
I haven't heard of any activity or plans, in this area.
0 -
Richard,
I understand that and had thought of that myself. Also, a reason why I said that the temp directory should be wiped upon lock or other interval. This way if the process crashes, etc, it will be wiped at least the next time 1Password runs.
But, on the flip side. You are less secure today with the current implementation. A user will click on an attachment and it will then prompt to download to wherever the user want to save it. They hen can open it and view it. Then what? What are the odds a user would ever go back and try and wipe it. Or try and wipe it in a secure manner? At least if it auto downloaded to a temp directory and was wiped periodically then you have a shot it would be deleted. Sort of like the clipboard being wiped. I understand attachments rings an additional level of issues, since a 3rd party process would have the attachment open and thus, the file can't be deleted until that process/program is closed. But, you have a better shot it will happen and require less user intervention in this manner. I would imagine you also could open many of these attachment types using the browser (like chrome), where you may gain more control of what you can monitor and control. Even if its using/supporting 1 browser type to do it initially.
0 -
@imt, a lot of thought went in to the current design (prompting you to choose a location for the file, so you know where to find it if you want to delete it). We still believe that's safer than saving it anywhere that's not transparent and leaving until later a possible automatic cleanup.
A change to that design will require a safe and dependable alternative and the resources to implement it.
0 -
If you don't want to put unencrypted data to a hard disk, how 'bout writing it to a RAM disk owned by 1Password? Maybe that's too much complexity.
0 -
Hmm, interesting. I was looking for built in RAM disk support but never thought to look at third party software.
@DBrown, you could provide an option for this with a way to specify the save location. This would kill two birds with one stone. The folder used would be user specified and so they would know that files are being saved there. Also, users could configure it point at a RAM disk and have the files disappear when the system is shutdown.
0 -
The folder used would be user specified and so they would know that files are being saved there.
This sounds a lot like the current approach.
users could configure it point at a RAM disk and have the files disappear when the system is shutdown.
I'm guessing this is way too complicated for the average 1Password user.
0 -
This sounds a lot like the current approach.
Except I want to specify it once, not every single time you want to view an attachment.
I'm guessing this is way too complicated for the average 1Password user.
Hence making it an option.
0 -
Hi @RichardPayne,
We'll look into the possibility of doing a hidden regedit option for folks who need a specific directory.
0 -
Why make it a hidden option? Wouldn't it be perfectly reasonable to show it on the preferences general tab, with the default already filled in?
0 -
Hi @bkh,
We already have too many settings as we speak, we do not plan to add more unless it is absolutely needed. Right now, until we have a great clean-up process in place to handle this along with the quick viewers support, we're going to stick with the prompt as is.
A hidden option for a few advanced users might help as a temporary measure until we get this set up.
0 -
"We already have too many settings as we speak, we do not plan to add more unless it is absolutely needed."
Are you referring to the user experience or the difficulty of maintaining feature-rich software? If the former, then I'd like to offer a few thoughts for consideration.
It helps the user experience for the software to make decisions without user involvement if (a) the software knows better than the user, or (b) the choice is gratuitous (it doesn't really matter, so giving the user another knob to turn isn't really helping the user). I note that neither of these applies to the current issue (where to write an unencrypted copy of secured data).
Sometimes there is a decision to be made, and it would actually help some users get better functionality by making that decision, but we don't want to burden most users with this. Rather than just hard-wiring the answer in the code (or in "data constants" automatically configured at install time or boot time), we can set the default, and make a configuration option available but not "in your face" so most users never even notice the option. I would argue that a hidden option configured via Regedit is a bit too deeply hidden. I think the typical approach is reasonable: the principal options are defaulted reasonably and are accessible through something like Edit > Options or Edit > Preferences, which many users can reasonably ignore. There may be an Edit > Options > Advanced section so that a user who does need to configure a basic option is protected from the requirement to wade through pages of settings (I think Adobe Reader gets this wrong but Firefox does a reasonable job.) And for options that are more delicate or fragile, there can be a deeper level of configuration, like the Mozilla about:config. The advantage of an about:config editor over Regedit is the OS-independence, of course.
So back to "We already have too many settings...." It's an unavoidable fact that 1Password has many knobs that actually do need to be configured. The only question for each knob is whether 1Password is the right one to make the decision. And I put it to you that "where to write a decrypted version of a secure data item" is a strikingly clear instance of a decision that 1Password can't possibly make correctly, because writing the cleartext to an unsecured location is inherently bogus. The best the user can do is to mitigate by specifying a RAMdisk or an encrypted filesystem. So let them.
0 -
Hi @bkh,
Are you referring to the user experience or the difficulty of maintaining feature-rich software?
Both, actually. If we make users second-guess how they use 1Password, we've failed in our mission to keep our application simple to use. We're not in the market to offer a overly-complicated program, even if it could please all of the market.
If we can cover two-three feature sets with one approach to it, that's better in the long term, and that's what we're looking for. An example would be when the user double-clicks on the attachment for the first time, they can quick-view it, open it in their app (from a temp directory) or save it to their preferred location. From the same prompt, they can set it as the default to avoid getting the prompts again. They would be able to change this later in the preferences.
That is what we want to investigate and figure out the best approach to these features. We don't want to rush into adding so many settings to something we can reduce with a better approach. We already have a few settings where it can introduce unforeseen changes to how 1Password behaves, like the system tray icon and/or universal unlock.
Like I mentioned before, this isn't a permanent option to offer a hidden regedit option. That's just an idea for something we can do now for folks who knows what they're doing and if they know how to set up RAMdisk or encrypted file system, they certainly knows how to use regedit. In the long run, as we work on 1Password, we'll change this into something more user-friendly.
Right now, it's just that it's not a simple change that can be done in a day. It's going to take some time for us to code all of the proper changes and to ensure it doesn't introduce security risks to the app.
0 -
"We're not in the market to offer a overly-complicated program, even if it could please all of the market."
I'm fully on board with that line of thought. But you've already opened an enormous can of worms by enabling users to use 1Password as secure storage for their large chunks of type-bound data (via the 1Password attachment) because now you've incurred a user expectation that they can get their data back out for secure, convenient use. And since each attachment has a type (jpeg, pdf, etc.) it invites too much feature creep to provide your own collection of viewers, so now you're into creating a reasonably secure and convenient way to send an attachment to an appropriate external viewer for its type, on each OS/platform. I appreciate the size of that project, and the difficulty of getting a good design.
"We already have a few settings where it can introduce unforeseen changes to how 1Password behaves, like the system tray icon and/or universal unlock."
Unfortunately, I think the right user experience there requires forcibly keeping the app, browser plugin, and helper's notion of lock status in sync, through some combination of messaging to sync the state and watchdogs to start the app or helper if missing. Unlocking in the plugin probably should always unlock the app: at present if I unlock 1Password via the plugin and then open the app to do something not available in the plugin, I probably need to unlock again. I recognize that there are more pressing issues to solve....
0 -
Hi @bkh,
But you've already opened an enormous can of worms by enabling users to use 1Password as secure storage for their large chunks of type-bound data (via the 1Password attachment) because now you've incurred a user expectation that they can get their data back out for secure, convenient use.
Oh, if you only know the whole story. :P We definitely could've approach this better a long time ago if we knew everything we know now, heck, this is true for all parts of 1Password.
The good thing is that we can improve from this. That's why developing software is fun for many people in the business.
at present if I unlock 1Password via the plugin and then open the app to do something not available in the plugin, I probably need to unlock again. I recognize that there are more pressing issues to solve....
If you already have Universal unlock turned on, then you would only have to do this once per the 1Password program's process. We simply can't sync the lock status from the extension/helper to the program process when it is not running. So, if you open the main program but then unlock via the extension, it should then sync it and the program would unlock at the same time.
That also means if you reboot the PC or exit the program via the File Menu > Exit or pressing ALT-F4, the process is terminated and you have to repeat the cycle.
0 -
@ClickCardo, if I understand your comment, I believe you should simply disable the Universal Unlock option on the Browsers tab of 1Password preferences.
0 -
@ClickCardo could I ask why? I'm genuinely struggling to understand your use case.
0
