Re: nspasteboard.org, tagging password in the pasteboard
13 views
Skip to first unread message
Thomas Tempelmann
Nov 14, 2013, 4:22:09 AM11/14/13
to AgileBits Support, nspast...@googlegroups.com
Kyle,
> As for the pasteboard question. We tried using the suggested identifiers and found several applications were not handling it properly (pretty much the exact opposite of what they should've been doing) so we implemented our own. We may change it back in the future, but at this time I don't have any further information about that.
That makes little sense. My (our) primary proposal was that you provide
an identifier to signal when data contains a password. The secondary
suggestion was to use the identifier named
"org.nspasteboard.ConcealedType". If the latter caused trouble, then you
could as well have used your own identifier. Which is exactly what you did.
But instead of adding this identifier to ALL data you place into the
pasteboard, you should have added it only when you put a secret text in
there, such as a password, or anything else 1pw or its user wants
"highly protected". Or you could always add the identifier as you do
now, but use its value to say whether it's concealed or not. Instead,
you add the same value into this identifier that is already present in
the text flavor of the pasteboard. Which feels kind of redundant.
I guess 1pw mini also uses this identifier to clear the pasteboard after
90s, right? So, it checks if there's still the same value in the
pasteboard and clears it only then.
But this clearing is also only necessary (and desired) when the data is
"secret", such as a password. Therefore, I don't think you'll break
anything if you only added this new type to the pasteboard for secret
data but not for user names and other non-critical copies from 1pw.
So, yes, please reconsider this for the next minor update.
I also welcome you to discuss any concerns with us, i.e.
nspast...@googlegroups.com, where there's a few more tool developers
with clipboard related tools at hand.
> We felt we'd rather be on the cautionary side and not have applications record any data copied from 1Password. Most users have sensitive data in it and better to err on the side of caution than have users expect one thing but see another when it comes to security.
Fair point. Better this than nothing.
Though, I think the extra caution here is not necessary. If you really
believe that a user's login name is sensitive, then you should conceal
it the same way you conceal passwords. But you don't.
Furthermore, this is not about background programs stealing passwords
from the clipboard (they can do that without or without the extra
identifier), this is about letting the user (permanently) record or
otherwise work with the data in the clipboard. It is important that
other tools that look into the clipboard know when they must not store
the data without further protection. That's what the new type was meant
for. Now, however, these tools have to conceal even a user name, which
is not a good service to the user, I hope you agree.
Thomas
> As for the pasteboard question. We tried using the suggested identifiers and found several applications were not handling it properly (pretty much the exact opposite of what they should've been doing) so we implemented our own. We may change it back in the future, but at this time I don't have any further information about that.
That makes little sense. My (our) primary proposal was that you provide
an identifier to signal when data contains a password. The secondary
suggestion was to use the identifier named
"org.nspasteboard.ConcealedType". If the latter caused trouble, then you
could as well have used your own identifier. Which is exactly what you did.
But instead of adding this identifier to ALL data you place into the
pasteboard, you should have added it only when you put a secret text in
there, such as a password, or anything else 1pw or its user wants
"highly protected". Or you could always add the identifier as you do
now, but use its value to say whether it's concealed or not. Instead,
you add the same value into this identifier that is already present in
the text flavor of the pasteboard. Which feels kind of redundant.
I guess 1pw mini also uses this identifier to clear the pasteboard after
90s, right? So, it checks if there's still the same value in the
pasteboard and clears it only then.
But this clearing is also only necessary (and desired) when the data is
"secret", such as a password. Therefore, I don't think you'll break
anything if you only added this new type to the pasteboard for secret
data but not for user names and other non-critical copies from 1pw.
So, yes, please reconsider this for the next minor update.
I also welcome you to discuss any concerns with us, i.e.
nspast...@googlegroups.com, where there's a few more tool developers
with clipboard related tools at hand.
> We felt we'd rather be on the cautionary side and not have applications record any data copied from 1Password. Most users have sensitive data in it and better to err on the side of caution than have users expect one thing but see another when it comes to security.
Fair point. Better this than nothing.
Though, I think the extra caution here is not necessary. If you really
believe that a user's login name is sensitive, then you should conceal
it the same way you conceal passwords. But you don't.
Furthermore, this is not about background programs stealing passwords
from the clipboard (they can do that without or without the extra
identifier), this is about letting the user (permanently) record or
otherwise work with the data in the clipboard. It is important that
other tools that look into the clipboard know when they must not store
the data without further protection. That's what the new type was meant
for. Now, however, these tools have to conceal even a user name, which
is not a good service to the user, I hope you agree.
Thomas
Roustem Karimov
Nov 14, 2013, 6:13:28 PM11/14/13
to Thomas Tempelmann, AgileBits Support, nspast...@googlegroups.com
Hi Thomas,
You are right, we do not conceal item titles and usernames in 1Password interface. I am not sure how you would use the app if we did :)
I agree that attributes like item title or URL are less important they should probably be not marked as ‘Concealed’.
At the same time, for years we got feedback from the users that they would prefer that all information stored in 1Password is fully encrypted and we finally started doing this in version 4. I think the majority of the users expect that everything they store in 1Password is sensitive.
We are adding org.nspasteboard.ConcealedType in the next build. At the moment it will be applied to any value that is copied from 1Password or 1Password mini (browser extension).
Best regards, Roustem
Founder of AgileBits
You are right, we do not conceal item titles and usernames in 1Password interface. I am not sure how you would use the app if we did :)
I agree that attributes like item title or URL are less important they should probably be not marked as ‘Concealed’.
At the same time, for years we got feedback from the users that they would prefer that all information stored in 1Password is fully encrypted and we finally started doing this in version 4. I think the majority of the users expect that everything they store in 1Password is sensitive.
We are adding org.nspasteboard.ConcealedType in the next build. At the moment it will be applied to any value that is copied from 1Password or 1Password mini (browser extension).
Best regards, Roustem
Founder of AgileBits
Peter N Lewis
Nov 14, 2013, 10:10:14 PM11/14/13
to nspast...@googlegroups.com, AgileBits Support
On 15 Nov 2013, at 7:13 , Roustem Karimov <rou...@agilebits.com> wrote:
> We are adding org.nspasteboard.ConcealedType in the next build. At the moment it will be applied to any value that is copied from 1Password or 1Password mini (browser extension).
Please please please do not do that!
> We are adding org.nspasteboard.ConcealedType in the next build. At the moment it will be applied to any value that is copied from 1Password or 1Password mini (browser extension).
That will render the org.nspasteboard.ConcealedType useless and I will be forced to remove support for it from Keyboard Maestro.
If you mark plainly visible items like usernames that users expect to be able to see with ConcealedType, that renders ConcealedType meaningless. Not only is this problematic for supporting 1Password, it will actively render the type useless.
If you want to mark everything that 1Password copies, then stick with your own flavor as you currently do.
In fact, why not use your own flavour for everything that you copy, and the ConcealedType for only passwords (or anything else you obscure). That would be the correct way of using the type.
Marking everything as concealed will be horrendous and defeat the whole point.
Peter.
--
Keyboard Maestro 6.3 now out - enhanced Typed String trigger, fixed volume control actions, and more.
Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<http://www.stairways.com/> <http://download.keyboardmaestro.com/>
Brian Bucknam
Nov 15, 2013, 6:06:43 PM11/15/13
to nspast...@googlegroups.com, AgileBits Support
On Thursday, November 14, 2013 7:10:14 PM UTC-8, Peter N Lewis wrote:
On 15 Nov 2013, at 7:13 , Roustem Karimov <rou...@agilebits.com> wrote:
> We are adding org.nspasteboard.ConcealedType in the next build. At the moment it will be applied to any value that is copied from 1Password or 1Password mini (browser extension).
Please please please do not do that!
[…]
If you mark plainly visible items like usernames that users expect to be able to see with ConcealedType, that renders ConcealedType meaningless. Not only is this problematic for supporting 1Password, it will actively render the type useless.
+1 I can't see much point of applying ConcealedType to a name or URL, and doing so seems like it would encourage developers to ignore the marker, or treat it less seriously.
Cheers,
Brian
Reply all
Reply to author
Forward
0 new messages