Earlier quoted context omitted.
Do people use them though? Both Mac and Windows have pretty much tied app sandboxing to 30% app store fees, which means the proposition is "rewrite your app to use incomplete APIs and then you can put it in our store where we'll take a big cut!" Not very appealing. It only works on mobile because there wasn't an existing industry used to 2% fees and unrestricted APIs. Unsurprisingly Microsoft has abandoned app store…
Can't apps use sandboxing with Apple's notary feature without needing to distro on the app store? and the incentive is the lack of a scary warning?
Who keeps an eye on clipboard access?
131–140 of 147 posts
Re: Who keeps an eye on clipboard access?
#132Earlier quoted context omitted.
> It’s pretty normal for people to talk about Linux as a computing platform. You know this yourself so making the “it’s just a kernel” argument is next level pedantry. In this case the "pedantry" makes sense because... > I’d put money on you having one installed and not even realising it (eg gnome-keyring, which is a dependency for many desktop applications even without having gnome installed) ...i do not have such a…
> ..i do not have such a thing. I use plain Xorg with Window Maker and i have removed anything i deemed unnecessary from my PC. So you don’t use a web browser then? I guess your posts here must appear by magic. > This is about ANYTHING that can go on the clipboard that can be sensitive. Hence why I’ve repeatedly used the term “secrets” and not “passwords”. The password manager example was just an illustration because…
Of course i use a web browser. What i do not have is a generic store like the one you describe - my web browser does not provide an API for other applications in my desktop to access whatever is stored in it.
> Hence why I’ve repeatedly used the term “secrets” and not “passwords”.
And yet you used them explicitly for storing passwords.
> The password manager example was just an illustration because this entire concept seemed weirdly alien to you.
Clearly in your message here:
https://news.ycombinator.com/item?id=30220104
...you only refer to storing credentials (ie. passwords) and here:
https://news.ycombinator.com/item?id=30220390
you explicitly refer to "password stores".
Meanwhile from the very beginning, like in here:
https://news.ycombinator.com/item?id=30220062
i refer to "copying data" and even if it is in the context of passwords, i make explicit in the very first reply i made to you:
https://news.ycombinator.com/item?id=30220227
...that i do not refer to just passwords but anything that can be copied to the clipboard and passwords was just an example.
That you think that "concept seemed weirdly alien" to me can only be seen as an indication that you do not read what i write.
> You mean like your pedantry about Linux being a kernel when you knew full well the context that term was used in?
As i already wrote previously, that part was to make it clear that this isn't something you can depend to be there "on Linux" because not everyone's setup has one - like mine.
> Your ego here is getting in the way
Does it really? From my perspective you entered the discussion with a polemic tone and when i tried to explain my position you doubled down, ignoring what i wrote and even started writing that i do not even know what i have installed on my own computer.
Re: Who keeps an eye on clipboard access?
#133Earlier quoted context omitted.
so, I can't help but note that when I said an email client should not need to request these capabilities and anything that did would be malware, you said an email client definitely needed to request these capabilities and gave as the example the ILOVEYOU virus.
Yes? In a system based on permissions (which is basically what a capability system is) somehow applications need to gain those permissions - so it makes sense that an email client will need to request them. Otherwise how is it going to work if it cannot access the internet, the address book or any other functionality it might need? BTW the ILOVEYOU virus example is what the linked page brought up, not me. They call i…
>In a system based on permissions (which is basically what a capability system is) somehow applications need to gain those permissions - so it makes sense that an email client will need to request them. Otherwise how is it going to work if it cannot access the internet, the address book or any other functionality it might need?
first of all, most capability based security assumes applications have the permissions natural for them to achieve their task, thus an email client would have access to the address book. It would have access to read previous emails received, it would have access to get latest emails and send emails and display the emails. It might have permission to play a beep tone when email arrives. It would have all the normal common permissions required to be an email client.
second of all, the access for the address book was requested by an attachment that was opened. Not the email client. To quote the first link: "In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. " 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.
third of all, you have still not explained why opening an attachment would need those particular permissions. The linked article uses the virus specifically because something opened by an email client should not need those permissions! I mean I guess, since you said 'yes?' to my earlier question as to whether your argument was that those capabilities should be allowed because it was the kind of thing a virus asked for that is really your argument!?! Most people who talk about email security talk about what an awful application outlook is/was because of its bundling of the browser in to render html opening up all sorts of security holes but you seem to think that an email client (here I drop back to talking about the client instead of an attached executable) should be able to post to random websites data from the users address book based on instructions received in an email? I've never actually seen an email client that needed to do that? Why do you think that it needs to do that? I'm going in circles here but - because a famous virus needed to do it? Really?
Fourth of all, your earlier example of someone messing up their system by installing Steam when they shouldn't is probably not the same as giving the Love Bug access it shouldn't have, but even if it were, yes people can do stupid things, your argument seems to be that any system that tries to help people stop before they do the stupid things will be doomed to failure instead of the common belief that some people will be stopped in their stupidity and caused to reconsider.
It seems frankly weird because the only end to your argument that makes any sense would be no security whatsoever, because people will try to do stupid things thinking that the stupid thing they are attempting to do will somehow give them what they want.
Re: Who keeps an eye on clipboard access?
#134Earlier quoted context omitted.
> ..i do not have such a thing. I use plain Xorg with Window Maker and i have removed anything i deemed unnecessary from my PC. So you don’t use a web browser then? I guess your posts here must appear by magic. > This is about ANYTHING that can go on the clipboard that can be sensitive. Hence why I’ve repeatedly used the term “secrets” and not “passwords”. The password manager example was just an illustration because…
> So you don’t use a web browser then? I guess your posts here must appear by magic. Of course i use a web browser. What i do not have is a generic store like the one you describe - my web browser does not provide an API for other applications in my desktop to access whatever is stored in it. > Hence why I’ve repeatedly used the term “secrets” and not “passwords”. And yet you used them explicitly for storing password…
Well that actually depends on the browser and OS. You’ll find some browsers actually use an existing system API for their password store.
But anyway, I wasn’t suggesting the final solution be a password manager. I just exampled that because you seemed oblivious to the benefits a secrets manager would have and password managers share an overlapping domain.
> > Hence why I’ve repeatedly used the term “secrets” and not “passwords”.
> And yet you used them explicitly for storing passwords.
Not just passwords. Any secrets. I’ve repeatedly said secrets and not passwords. Those secrets could be a password but they could also be private keys / certs and even just sensitive config. I’ve literally used secrets managers for these things too. And it is extremely easy to store any kind of secret because at the most basic level they’re just key value stores with a TTL and encrypted storage engine and secure API for 3rd party applications to query. Literally the end solution one would come to if they took your specs and fleshed them out to a secure and robust natural conclusion.
So yeah, you can put in any data you want.
You’d also know this if you spent even just 5 minutes researching this like I’ve repeatedly suggested.
> you explicitly refer to "password stores".
Yes, as an example of utility because you couldn’t grasp the concept and was too lazy to do any research.
Now that you’ve wrapped your head around the basics go look up Hashicorp Vault and you’ll get a sense for how a secrets manager is much more than just a password manager.
Now think about how that solution could be utilised to solve the same problem you’re identifying. And you’ll finally understand why I keep harping on about it.
> i refer to "copying data" and even if it is in the context of passwords, i make explicit in the very first reply i made to you:
Again, secrets stores aren’t just for passwords.
> That you think that "concept seemed weirdly alien" to me can only be seen as an indication that you do not read what i write.
I’ve been listening to you. But frankly communicating with you is like trying to draw blood from a stone because you keep insisting on having an opinion on a domain you clearly know Jack shit about and then refusing to spend even the smallest amount of time looking into any of the technologies being recommended.
The issue here is 100% you, not me. I build and use these technologies for a living and you clearly haven’t the foggiest on this topic.
> As i already wrote previously, that part was to make it clear that this isn't something you can depend to be there "on Linux" because not everyone's setup has one - like mine.
You could also not install support for the hypothetical API you’re imagining too. So your point here is moot.
This is why I was using Windows as the baseline for the conversation. It saves us from these stupid meta hypotheticals about “what if I chose not to install this thing I just moaned about wanted to install”…
> when i tried to explain my position you doubled down
You tried to tell me that 20 years of security technology didn’t exist. So yes, I did double down on the fact that you were wrong because you were and still are.
Also I love the hypocrisy of the statement that I’m “doubling down” and you’re just “explaining your position”. The way I saw it, you posted an idea, I came up with a better solution and you then doubled down that your crappy alternative was better for reasons and then posted a list of misunderstandings.
You’ve also pulled this hypocritical shit a few times too, accusing me of doing the very things youre already doing.
> ignoring what i wrote
I addressed your points literally. If you’d spent even 5 minutes researching this field you’d realise that.
And I’ve lost count of the number of times I’ve asked you to read up on this topic. It’s not an unreasonable request on my part.
> and even started writing that i do not even know what i have installed on my own computer.
Given you don’t even know what this technology is, I find it hard to believe that you’d know if it was installed or not.
Plus as a Linux developer and sysadmin myself, I know full well that it’s impossible to audit every single package that goes into a desktop installation (a minimal headless image is possible but not a multi-purpose desktop installation). And I’m the kind of person who has spent decades compiling frameworks, drivers and desktop software from source so if I can’t memorise every single dependency then there’s no hope for you. The fact you think it is possible honestly says more about where you sit on the Dunning-Kruger scale than it does about me.
Honestly, drop the ego and look this stuff up. It’s pretty cool technology. It wouldn’t suit your needs perfectly in its “off the shelf” state but it is the backend architecture that would best realise your vision. But until you do any research of your own you’ll find that we will just keep going round in circles.
Re: Who keeps an eye on clipboard access?
#135Earlier quoted context omitted.
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
> For example, you wouldn't be able to put a "paste" item in a context menu Maybe the menu item could be a special window/widget type specific for the "paste" action, controlled by the UI server. An app could be restricted in how many of these it could have and what to display in it.
A "Paste" widget is overlaid with a special transparent window which when clicked authorises access to the clipboard while forwarding the click. Abuse of the mechanism is supposed to be controlled by the transparent window setting the mouse pointer to a specific shape when hovering over it: a user would be alerted if he sees that shape where it isn't supposed to be.
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133....>
Re: Who keeps an eye on clipboard access?
#136Earlier quoted context omitted.
> Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without being in focus or sent any input first. Author here, yes, this is indeed the point of the article. Desktop operating systems could/should have implemented such a feature a long time ago, it is clearly a security "blind spot" at the moment.
Not really though. It makes sense for mobile OSes because they have proper isolation of apps, but desktop OSes don't have that. Apps can pretty much do anything. What's the point of copy notification if apps can just read all your emails and steal all your files anyway. Android and iOS both have this feature already. That's the best we can do for now.
We are discussing "paste" notifications. Knowing that an "app" is constantly pasting(fetching) the contents of the clipboard seems suspicious behavior and I as a user would like to be made aware of it.
Re: Who keeps an eye on clipboard access?
#137Earlier quoted context omitted.
> Sure, but that should really be a permission you have to grant explicitly. That could work but still feels dodgy since if you can grant that permission to a clipboard manager, you can also grant it to something like a TikTok client or an Adobe DRM reader or whatever else program you want to use (ie. the reason you are using your computer in the first place) but also might want to snoop for your data. IMO a better s…
Of course if an app asks for some very dangerous permissions somebody will grant them to it even if they don't belong to the app's advertised functionality. Naming and description could help a little: Full access to copy and paste (maybe somebody doesn't know what clipboard means), it allows this app to access everything is selected and copied including passwords, private data, etc. Only keyboards and clipboard manag…
Re: Who keeps an eye on clipboard access?
#138Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
Only a few applications handle triggering of a Paste action by themself. Most just leave the OS/GUI framework/ handle events and only react to a Paste request event. They would not be affected if the OS stops allowing to read the clipboard while a Paste event isn't being processed.
Re: Who keeps an eye on clipboard access?
#139Earlier quoted context omitted.
Clipboard should be a private and secure enclave (encrypted) in the first place. Only the OS should store and retrieve data from it.
The applications still need to retrieve data for the clipboard to be of any use to anyone. E.g. Editor widgets like to have a paste button. Edit > Paste is a fairly common pattern, too. Without having the OS in charge of managing the entire UI, it's difficutlt to make that work
Aside from Clipboard managers (which should be handled like on screen keyboard or other alternative input methods) I don't see a reason to allow pasting (and so reading from the clipboard) from an window that doesn't have the input focus.
Re: Who keeps an eye on clipboard access?
#140Then what watches the clipboard watcher ?