Who keeps an eye on clipboard access?

> yeah I'm old enough to be familiar with these things - is there some reason that you seem to think I'm in my early twenties?

No, i don't think that. Why you'd think that? If it was due to me writing about the ILOVEYOU virus, i wrote it because from your reply i got the impression that you thought the "Love Bug" virus (mentioned in the article) would be something different than the ILOVEYOU virus. I don't think age has anything to do with that though.

> first of all, most capability based security assumes applications have the permissions natural for them to achieve their task [...] It would have all the normal common permissions required to be an email client.

Yes, i agree with that and understand it, but...

> second of all, the access for the address book was requested by an attachment that was opened. [...] To reiterate, it is not the email client that needs to ask every time it wants access to the address book, it is any executable opened from it. [...] you have still not explained why opening an attachment would need those particular permissions.

...the issue wasn't that the ILOVEYOU virus was an attachment, it was just a VBS script that was executable like any other executable could be - it could have been an EXE file instead and it'd be able to do the same things as the VBS script.

To make it clear, an attachment would not need those particular permissions, but in the case of the ILOVEYOU virus it wasn't its status as an attachment that was the problem.

The main issue, as far as Outlook Express was concerned, was that Outlook Express didn't provide any means to help users avoid these issues (which BTW is not the same as protecting them from the issues - one case empowers the users, the other treats them as powerless). And of course Windows made the issue worse with hiding filename extensions.

As an example, nowadays Thunderbird provides pretty much the same features that Outlook Express had, including displaying of HTML content and even allowing access to the address book (instead of using some API you can use SQLite3 - but that is available in pretty much every language out there and the data is still just plain text). However you can switch off the HTML display or use a simplified one, have images not be downloaded by default to protect from remote attacks and tracking and it displays prominent warnings whenever it detects you are trying to launch an executable (this isn't ideal since, as i wrote in a previous message, many users will ignore the message, but it is still better than -say- Gmail disallowing executables completely).

> I mean I guess, since you said 'yes?'

And again to be clear, i wrote "yes" to that the email client would need those permissions (since that is what you wrote). The email client needs to be able to access the internet to function.

But the attachment is not part of the email client, it is just a file that in the case of the ILOVEYOU virus, it happened to be an executable. In a permission or capability-based system that executable would need its own set of permissions that are independent of the email client.

Which goes back to what i wrote initially: those permissions will need to somehow be acquired and the most logical way - and what, e.g., mobile phones do nowadays, since that is the most widely available form of permissions-based OSes - is to ask the user.

But as the link i gave shows, most users do not pay attention to these requests - especially if they happen frequently - and just accept whatever is presented to them because what they have in mind isn't the requests and permissions to give, but performing the task the application would be for. The Linus Tech Tips video was a recent example of this of a user blindly accepting through every request and conformation presented him in the pursuit of the goal to do the task he had in mind - he wasn't interested in whatever the system was asking, he was interested in installing Steam.

> It seems frankly weird because the only end to your argument that makes any sense would be no security whatsoever

No, that is a defeatist attitude, my argument was really that the UX of the capability system that was proposed in the linked page about capability systems was a usability nightmare because it flies in the face of how users actually behave when faced with them. They do not solve the issues, at best they just make developers feel like they're doing something good, at worst they work as a way for developers to pass the blame from themselves to the users for ignoring the warnings. Either way the user is not "saved".

There must be a better way that doesn't also remove any functionality from the system, but i don't really know what that would be. I'm certain though that a system that bombards users with confirmation dialogs aren't it since we have a ton of evidence that these do not work.

> In both your original reply to me and the follow up what you wrote about was storing passwords in a secret store to avoid copying them from somewhere else as that would have them go through via "a clear text protocol". This was a complete > misunderstanding of what i wrote about.

You keep saying “passwords” then saying you’re not taking about “passwords” and then saying I misunderstood you because I mentioned passwords yet I never actually mentioned passwords. Go back and read my original reply:

https://news.ycombinator.com/item?id=30220104

Is it possible that you’re conflating “secrets” with “passwords”? Because they’re not the same. The latter is a subgroup of the former

> I am not oblivious to what benefits secrets managers would have, they are only tangentially (if at all) relevant to what i discussed about.

I know that’s not what you discussed. My point was what you discussed is a crappy solution that has already been superseded with secrets stores to solve this over arching problem space. Thus your solution should incorporate secrets stores instead of reinventing them but badly.

> you made some initial assumption about what i know

With the greatest of respect we’ve had the following issues:

1. You’ve conflated “secrets” and “passwords”. Secrets is a term in infosec that refers to more than just passwords. It’s the standard term for discussing sensitive content in this context. Which is why I’ve repeatedly used that term. And you’ve misunderstood it’s meaning completely and even made accusations that I’ve not understood that you’re describing more than just passwords because you’ve misunderstood the term “secrets”.

2. You didn’t realise that secrets stores have a TTL. That alone literally solves 80% of the problem you’ve got and does so right out of the box.

3. You conflated password managers and secret stores (ok, that one is partly my fault too because I used password managers as an example to loosely describe how a secrets store might work. But the fact I had to make that explanation is telling).

4. You forgot that browsers often use system APIs for password storage. I’m giving you the benefit of the doubt that you did know this originally (given your comment about kwallet) but you cannot deny that you did post earlier that you wanted an external API (with regards to browsers), forgetting that many do actually already do this.

5. You also claim that you know every single library that is installed on you desktop. This is at best a huge exaggeration. But realistically it’s either completely delusional or an out right lie.

I could go on. But suffice to say you’ve not exactly redeemed yourself as an authority on this topic despite being confident that everyone else is wrong.

> What i wrote about was on improving the security for clipboard-like workflows specifically, to avoid the issues the clipboard has right now without breaking any existing applications

I got that. The point you keep missing is that adding a new API breaks clipboard-like workflows anyway. So if you’re already breaking that then why not build your new API on top of a secrets store, give that data a short TTL and leverage already proven technology. The entire process can be streamlined from a user perspective so it even looks like a clipboard. Except it is secure.

> All that stuff should be obvious and i do not see why i'd have to spell them out when

What you’ve posted is obvious. The issue is you don’t understand how secrets managers work so defaulting to the position that they are clearly not suited.

Anyway, I can’t see this argument being resolved. You’re not going to research the topic and I’m not going to concede that you’re not just reinventing the wheel but badly. So maybe we just give up here?

> You keep saying “passwords” then saying you’re not taking about “passwords” and then saying I misunderstood you because I mentioned passwords yet I never actually mentioned passwords.

You also keep using the word "password" while claiming you are not using the word "password" like you did right now.

And of course what i just wrote, just like what you just wrote, is not an argument at all since this isn't about the existence of the word "password" in the text that was typed, but of what you are claiming.

From the very beginning i only used passwords as an example of something that can be placed in the secret clipboard. In the first reply to you i already made that clear - which is also something i pointed out in another reply later.

> Is it possible that you’re conflating “secrets” with “passwords”? Because they’re not the same. The latter is a subgroup of the former

Please read what i write, i do not conflate the two and this should have been obvious from the first reply i made to you where i write that the source for the data to be placed in the secure clipboard can come from a secrets manager.

> My point was what you discussed is a crappy solution that has already been superseded with secrets stores to solve this over arching problem space. Thus your solution should incorporate secrets stores instead of reinventing them but badly.

And this is why you do not understand what i wrote. Secret stores do not solve the same problems that the secret clipboard i described does.

> 1. You’ve conflated “secrets” and “passwords”.

As i already wrote, i did not, you just made that assumption. Even if i had no idea what they'd be it'd be a very stupid mistake to make since the name is practically self-describing in context.

> You didn’t realise that secrets stores have a TTL. That alone literally solves 80% of the problem you’ve got and does so right out of the box.

This has nothing to do with what i describe, aside perhaps from using it as a way for a secrets manager to implement the secure clipboard API - like i already mentioned several replies ago in https://news.ycombinator.com/item?id=30220474

> You conflated password managers and secret stores

I did not, i only brought up password managers as an example which i quickly made clear that they were only just one source for the data to be placed in the secure clipboard in the first reply i made to you.

> But the fact I had to make that explanation is telling

It is only telling that you do not bother to read and understand what the others are writing.

> You forgot that browsers often use system APIs for password storage.

...no? I never forgot anything like that, this is again an assumption you made. The only time i referred to a browser was for my browser and i already wrote that i only did to that, not to any potential browser that could exist. I have used other browsers in the past, like Safari, that does use system APIs for password storage (or at least that is what i assumed Safari was doing, i never really digged down on that).

> benefit of the doubt

Instead of trying to doubt me, you may actually want to try and understand what i am writing.

> but you cannot deny that you did post earlier that you wanted an external API (with regards to browsers)

What i describe is a different API because the functionality i describe is not the same as what a secrets store would provide. This is what i am trying to explain from the beginning.

> 5. You also claim that you know every single library that is installed on you desktop.

I never claimed such a thing, this is yet another assumption you make.

The only thing i claimed was that my setup does not have a secrets manager that other applications can use, like you originally described "Linux" having. Which is why i wrote what you took as pedantry, that Linux isn't just a single setup and setups without a secrets manager do exist - and brought up mine.

While i do not know every single library that is on my system, i do have a decent idea on what is in it there since i try to pay attention to what i install.

So unless you consider having libsqlite3 and libgcrypt available as shared objects passes as a secrets store API that applications can use (they can always pester me for a password/something every time they need to access the data), i am certain i do not have one.

> suffice to say you’ve not exactly redeemed yourself as an authority on this topic

I never claimed to be an authority on this topic either. In fact if you were to ask me, i'd be the first one to say i do not really know much about security (and it isn't really a topic i am interested), which is why i mainly focused on the functionality from a UX perspective and how people would use it rather than how the underlying system would be implemented.

> The point you keep missing is that adding a new API breaks clipboard-like workflows anyway.

It doesn't, the existing clipboard API would still be there. From the very first comment i brought that up, i mentioned that the secret clipboard would exist alongside the existing one as to not break anything that currently works.

It is even right after the bit you quoted in your first reply to me.

Here: "IMO a better solution that wouldn't break existing clipboard usage is to have a second "secure" clipboard that you can lock as tight as you want. Then password managers would copy data to that and text editors and browsers can have a "Copy Sensitive Data" (or something better worded) in addition to "Copy" that will place data there.

In fact...

> why not build your new API on top of a secrets store, give that data a short TTL and leverage already proven technology.

...I even mentioned in another reply that what you describe could implement the API i describe.

> The entire process can be streamlined from a user perspective so it even looks like a clipboard.

Yes, like i already wrote in my original message: making something that, for lack of a better word, is essentially a "secure" separate clipboard, something that looks and behaves like a clipboard. The never specified how it would be implemented, only how it'd behave. I only wrote "lock as tight as you want with explicit permissions for reading it, notifications for writing to it and whatever else you want". I left the implementation up in the air.

Would it be implemented by a secrets store or some other service that communicates with a secrets store and sets up some low TTL or outright destroys the data after it has been pasted? Doesn't matter, it wasn't what i was describing, that would be some implementation detail.

Which is why i kept on and on and on and on repeating over and over that what i describe is not about secrets stores and is irrelevant, aside from perhaps having one implement it.

> The issue is you don’t understand how secrets managers work so defaulting to the position that they are clearly not suited.

I understand what they are used for and what they are used for is not for the functionality that i describe (there might be one that does have something similar that i do not know about but as i do not know it, i only refer to the concept in general), otherwise i wouldn't bring up the idea in the first place.

> Anyway, I can’t see this argument being resolved. You’re not going to research the topic and I’m not going to concede that you’re not just reinventing the wheel but badly. So maybe we just give up here?

If you are so hellbent in avoiding to understand what i write, sure, it doesn't sound like there is a reason to continue.