My hunch is these things are more boneheaded than nefarious. Probably looking for URLs to share or something silly like that and just implemented poorly. Obviously not good for the PR, but say sorry and fix the bug. Luckily this shouldn't happen much longer once iOS 14 is properly released.
Though some apps I trust more with how they use the clipboard data or only restrict it to certain types, eg: image data for a photo viewer, urls for a browser, tracking code for a delivery app
A few years ago, linkedin purposefully changed their notification emails to have less information so you're forced to log in and read the notification on their platform. Linkedin is also widely known for when they scraped users contacts and then spammed them.
Call it incompetence if you want, but there's a certain flavor of evil incompetence here.
There might be a thin guise of "security" (i.e. email isn't a secure place to send your top-secret inbound message) but I'm inclined to suspect the main motivation is to drive people back to the platform and drive up their stickiness metrics.
It is not just Facebook and LinkedIn. I've seen this from random small sites.
Some other silly shit that come to mind - having the unsubscribe link after half/full page of white space, once you click on unsubscribe "give us 24 to 48 hours to remove your email" etc. Really? they need 24 hours to delete (or change a flag) in the database?
Sometimes it’s some freaky ETL script that runs daily to put your address in a marketing message integration system. Not that it’s a great excuse, just usually more than a single flag update.
For Facebook, the worst part is that it shows more in the gmail message preview than it shows when you click through to the message. There is no security explanation for that; it's clearly deliberate manipulation.
What I love is Reid Hoffman then going on about that move like he invented the fucking wheel. Like congrats, you stole some e-mail addresses and spammed them...you are now a genius growth expert? Joker.
His book is also staggering insight into how little ability he has an executive and investor (some of the stuff is intern-level mistakes, like maybe juniors who are in their first week and got the job because of daddy...but even then...rare).
I have no dog in this fight, but I was at LinkedIn at the time, on teams that worked closely to this. I can assure you that these changes were not made to force log in. It was a recommendation from the security team.
I know it's Hacker News and it's easy to criticize LinkedIn for shady growth practices and get praise for it. They often deserve it, but assigning malicious/growth intent for every change they make is misguided.
I'm not an expert, but i understand that redirecting to the app store is an explicit decision on part of the developer (and in Fact it only happens randomly), and a very anti-user one.
The security excuse is used as a way to increase conversion.
Guess I'm never copying and pasting anything sensitive on my phone ever again. Still don't understand why clipboard-sniffing isn't behind a permissions flag.
The screen capture is from an iPad Pro. It's not clear how it was getting the Macbook clipboard; via AirDrop maybe? Really that just makes it even more concerning.
But you can turn it off by turning off "Handoff", which luckily I already had. Nowhere is it mentioned in the settings UI that this extends to your clipboard.
Handoff really is awesome though. You start browsing a website on your phone, unlock your Mac and boom you can switch to the big screen. Copy a phone number from a website on your Mac, pull out your phone and paste it into the phone app. Once you’re used to it, it seems so obvious
That's great when my threat model is "there's a firm boundary between my devices and everything third-party". Now that that's been punctured, it's a nightmare.
I’m not sure why they didn’t add a permissions flag for it either to be honest. Most apps are going to stop doing it because of the notifications, and presumably those that continue will make some effort to explain it somewhere so people don’t panic and uninstall their app when they’re told about it. Seems like a permissions flag with the usual app’s explanation of why would work well.
Well, once upon a time you trusted the code running on your device.
In Chrome on Android, the flag you want is under Settings | Site Settings | Clipboard | Ask before allowing sites to read text and images from the clipboard, and I think it's on by default.
iOS very early-on took on a model of not trusting the software you install on it, and for good reason. Android and the web followed soon afterward. This is the expectation today. Doubly so given Apple's chest-beating about privacy. This clipboard scandal is unacceptable.
It only declared and didn't let you individually toggle permissions until version 6.0. You just had to take-or-leave the app as-is. I don't know whether or not it declared them from the very beginning.
It did have them from the beginning, and the set of supported permissions was quite substantial compared to what iOS offered. But you're right, iOS was first to have the ability to grant/revoke individual permissions at runtime
I remember giant take-it-or-leave-it permission warnings for apps back on 2.1 when I had my Nexus One. Updates that changed permissions would just give you the whole list again with no hint as to what had changed, it was awesome in its user-hostility.
I think i saw that some of the new betas of ios pop an alert whenever software sniffs your pasteboard.. maybe i'm wrong. Seems like I saw somethng during the tiktok stuff earlier this week.
Which is the whole point behind giving a notification about it. Clipboard use is so core and fundamental, literally every app with any kind of entry box would need to ask ahead or you'd hit that so randomly all the time nobody would pay any attention to the warning.
The current feature being added allows this to happen, for awareness to be raised.
To be honest, I'm surprised we haven't heard of more snoopy apps already, but, I guess that will come when the feature's out of beta.
Apps wouldn't have to ask ahead for a text entry box.... you just have to only grant paste read access when a user explicitly chooses to paste by hitting a button.
> Clipboard use is so core and fundamental, literally every app with any kind of entry box would need to ask ahead or you'd hit that so randomly all the time nobody would pay any attention to the warning.
That's, one way to implement it...
Alternatively, and how I'm pretty sure it already works, is that on paste the clipboard could insert content directly into the control, never involving the app in the process.
Apps with completely custom inputs would need to see the contents, but that's both rare and usually a bad idea in the first place.
Funny how you are promoting Chrome and Android when I've known for a fact that Google Maps has done this since forever because when you open the app immediately if and only if it's an address it suggests whatever is on your clipboard as a destination. This means 1) there's code running somewhere grabbing the clipboard and deciding if it's an address (might ping home) 2) it has to copy the clipboard all the time to do that.
Not a fan of any of the big tech companies, but Apple needs to be applauded for this feature. Can't wait to see how many such behavior is exposed by iOS 14
They didn't say it was. They're saying they're looking forward to the next major release which alerts the user when this happens. That's why all these stories are coming out right after the release of the beta.
I would save my claps for people who are really working to improve the world, not for corporations who sometimes accidentally do the right thing while pursuing profit.
> Still don't understand why clipboard-sniffing isn't behind a permissions flag.
Screw permissions flags. Clipboard-sniffing is never justified. Moving data out of the clipboard should only ever happen by direct user request via the OS interaction layer.
Launchbar and Dash on the mac both have great clipboard features. I use it many times a day. For example, a snippet to drop a markdown formatted link with the title from the first clipboard stack entry and the URL from the second clipboard stack entry.
I would tend to agree, but a handful of people have a handful of reasons why they like it, and so removing it completely isn't as much of a no-brainer as adding a permission dialog is.
Sure, but the reasons are always so...contrived and frivolous...and none of them require accessing the clipboard automatically without the user invoking a system command. And the consequence of these poorly considered objections is what we have now.
It's like people have either been gaslit into thinking that there's no sane alternative to the current nightmare or are so shortsighted that they don't understand the horrors lurking around every corner that wouldn't be there if they stopped to consider the consequences of [checks notes] "google maps doesn't require you to to paste the address in before it starts to route" and "dash can drop a markdown formatted link". Because saving you one click is surely _so_ important that it's worth giving up everything for.
And what, exactly, constitutes "direct user request" that both 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings) and 2) is not trivially spoofable by the enterprising developer?
I understand the outrage over apps abusing their access to the clipboard but what I don't understand is the people acting as though the OSes they use on the daily don't have the exact same "flaw".
> what, exactly, constitutes "direct user request" that both...
> 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings)
A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS. Want something perpetually backgrounded that exists exclusively to steal your secrets? Make _that_ a special permission if you must. Or just don't allow it.
> * 2) is not trivially spoofable by the enterprising developer?*
Ignoring the _minor_ contradiction of mixing "trivially" and "enterprising", rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that.
Could someone root your system and blahblahblah? Sure. But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
> A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS.
Wonderful! Now how does this brilliant little solution account for applications that don't centre their operations on the keyboard?
How does this work for clicking on a UI element to paste?
How does this work for using non-tactile forms of input - say, a voice command?
How does this work for any method of interaction that's not "press a combination of keys"?
How does this interact with the very real and undebatable need to allow programs to simulate keyboard events?
What happens to operating systems that have the implementation of a system clipboard as out of scope (like a little-known operating system called Linux)? How does, say, the X window server then manage to implement a clipboard on top of it?
> rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that.
I am very curious indeed: what, exactly, do you think happens when (for example) a C program calls `getchar()`?
> But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications? The whole point of a buffer for temporarily storing and transferring data between applications is for said applications to actually access it. You are doing the equivalent of saving your "secret" in plaintext in your home folder and then complaining about the OS if/when a program peeks through your generally accessible home folder and finds it.
Although I understand your point on the shared buffer, I don't see how else I can share information between two arbitrary apps not explicitly designed for it. Perhaps I should be able to use settings to require an os confirmation dialog, at least for info not copied into the clipboard by the same app, much as users can use noscript. As for Linux, if they don't want to deal with the clipboard, then users need to understand (and should have already) that a buffet style open source ecosystem does come with some risks and rewards that make it a different security paradigm from a centralized os with a lot of basic tools/apps made by the os provider.
Do you have some idea of a better, more secure way to share information between two apps the user alone has decided should be in communication?
Between two or more known apps, a solution already exists - don't put in the system-wide shared buffer, put it in a buffer whose access is restricted to apps that you know. For example, on iOS you've been able to create team-local (only accessible from apps with the same team ID) and app-local (created with a unique identifier so only your app knows & can interact with it) clipboards since...a very long time, definitely pre-iOS 8 because that's when I encountered the API the first time.
To some extent, a solution does exist for arbitrary (iOS and Android) apps, which lets you explicitly pick what application you want to receive some data - the sharesheet. It's criminally underused in my opinion.
> How does this work for clicking on a UI element to paste?
The same way as designating keybindings. Registration with the OS. I don't care if you have to do it by defining hotspot outlines for bespoke-from-raw-pixels interface elements.
> How does this work for using non-tactile forms of input - say, a voice command?
Voice interface is mediated by the OS. Register your desired custom paste command.
> the very real and undebatable need to allow programs to simulate keyboard events?
False. I'm happy to debate it. But before we do, I have to ask you to try to not be stuck in the "how things are done now" mindset.
> What happens to operating systems that have the implementation of a system clipboard as out of scope"
Then they have decided to punt on user safety. Be angry at them and demand better. Also, you're derailing.
> what, exactly, do you think happens when (for example) a C program calls `getchar()`?
What do YOU think happens? You think that your program talks directly to your keyboard buttons? And why do you think that this question is relevant?
> If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications?
Frankly, I think this is a bullshit user-hostile copout. Treating the clipboard as "general shared buffer between applications" is exactly what caused this madness. The clipboard is an extension of the user, like writing something down on paper so they can then reading it back later, and should be treated as such with sanctity.
Try approaching from the perspective that all of your "what if"s have a safe non-almost-100%-of-the-time-user-hostile solution. Because the freewheeling "steal my secrets" API is almost 100% of the time extremely user hostile and computers are meant for people to use.
I'm not going to create an account with the WSJ just to read that article, but from the opening paragraph I don't see how it support your claim. It appears to be talking about something AT&T did?
When I saw this video of a lot more apps doing it, I did wonder if it actually might be a commonly used third-party library causing this. It's certainly possible.
Make clipboard behave like a channel[+], like GNOME native apps do, additionally require a standard paste command to paste, then this clipboard attack will be impossible to conduct.
[+]:A sample pipe might be a good analogy for this behaviour. You cut or copy the input, send through the sample pipe, and the receiving end unpacks, receiving itself makes the sample disappear for further use. Multiple samples could be sent through the pipe, though the pipe should behave in a LIFO, no sample adding allowed after removal starts, manner if this is desired.
It would all be a lot simpler if browsers and other operating systems just implemented an API call for obtainAllMyPrivateInformation(). That's clearly what developers like LinkedIn (and TicToc, etc.) are looking for.
LinkedIn has had so many privacy disasters over the years, and it's kinda crazy how we kinda tend to forget most of that eventually. I definitely wouldn't trust them with much of your data.
One of my hobbies is looking at url strings with GET key/value pairs. Programmers must forget that they're visible to users. LinkedIn has a search workflow that shows "origin=TYPEAHEAD_ESCAPE_HATCH" which I've always found humorous.
> Programmers must forget that they're visible to users.
GET parameters aren't usually visible to users; with the deemphasis of the URL bar, you'd have to have an incredibly short URL for that to even be a possbility. Right now I'm looking at
That's one visible parameter. There's PLENTY OF SPACE for firefox to show the rest of the URL, but it won't; instead, a bunch of icons are unhelpfully crammed into the same horizontal layout.
In the larger sense, where users can see the parameters if they intentionally look for them, despite the fact that they are normally invisible, POST parameters are just as visible.
> That's one visible parameter. There's PLENTY OF SPACE for firefox to show the rest of the URL, but it won't; instead, a bunch of icons are unhelpfully crammed into the same horizontal layout.
Right click on the "crammed" icon area, pick "customize", and then you can drag and drop the icons crammed into the space into another bar (or out of the UI entirely if they are icons for things you never use), which should then recover much of the lost space.
Yeah I noticed that too. If you go to the profile page of someone who has the LinkedIn pro version and hover over the gold "in" symbol next to their name, it links to a URL containing
Haha I worked on that flow. It's the escape hatch because we didn't find what you were looking for in the typeahead, so we have to let you escape to the full SERP results page.
Every day I read about another outrage being committed by another garbage app that I do not have and would never install on my phone. Why do people need a LinkedIn app? Even if you think that you need LinkedIn, can’t you access your please-spam-me account through your browser? Isn’t it obvious that every closed-source mystery program that you install increases your attack surface? You wouldn't click on an email attachment from a stranger in Russia, so why install an executable from a company that you already know is unethical?
Think it's just the app? Hope you don't have your clipboard events enabled in your browser
Edit for those interested:
tl;dr: "asynchronous clipboard API" [0]
Overtly, it's used by shit news sites like WSJ, nytimes, and bloomberg to inject their shit into your clipboard when you copy-paste. A common thing I've noticed is selecting text, copying the text, and then pasting somewhere and seeing a link to the original article instead.
I'm not sure if they're still doing it; there has been several people complaining about this over time [1] [2] [3] [4] [5] [6]. I found this awesome article on the Security StackExchange from 2013 [8].
Also it's not just javascript. You might be forgiven to think that using a command-line interface would spare you. Unfortunately you'd be wrong; mosh, tmux, vi, emacs all support your terminal emulator's clipboard events. [7] [8]
Right. Firefox and Safari (iOS and desktop) haven't implemented the Clipboard.read functionality yet either, only Chrome has and it's only available on use action such as a click or keydown (and not available on touch or scroll events).
But they can copy to your clipboard for you, a lot of services use "Click to copy" features. But reading is much harder.
iOS before 14.0 appears to have allowed apps to read clipboard contents without making that clear to users. Now that you get a notification whenever an app reads the clipboard, it has become fairly clear a lot of apps are reading clipboards constantly. For what… we all wonder.
Thanks for the details. I agree that it’s obnoxious for sites to interfere with copy. But they still can’t read from the clipboard, which is the topic here. And your [8] seems to be about the user deciding to paste unsafe content — totally different issue, isn’t it?
It is at least supposed to be hidden behind a permission. What's the default for that permission though? I sure hope Google^H^H^H^H^H^HMicrosoft^H^H^H^H^H^H^H^H^Hsome evildoer doesn't find a way to override your permission setting. A reset of configuration data after an automatic update might do the trick...
> And your [8] seems to be about the user deciding to paste unsafe content — totally different issue, isn’t it?
Perhaps you are right. I won't claim to fully understand how tty programs work. However:
* `emacs` documentation describes an ability to interact with the user's system clipboard [1].
* `tmux` integrates with the user's system clipboard [2].
* `mosh` apparently caches the user's system clipboard [3].
* `vim` has special registers to represent the user's system clipboard [4] [5].
If the system is using dbus (nearly every Linux based OS), it's pretty easy to do. Here's a python script using GTK to do so [6]. A high level overview of the clipboard is described in the freedesktop specification [7].
I think it's really unfortunate that desktop and CLI software is so insecure.
Of course there are APIs for accessing the clipboard. I probably use Vim’s clipboard registers 300 times a day. None of this has anything to do with closed source programs reading the clipboard without permission. Speculating that somehow an app might “override your permission setting” is not really informative. There might be any number of exploits.
> None of this has anything to do with closed source programs reading the clipboard without permission.
This has everything to do with closed source programs reading the clipboard without permission since there are no permissions involved in desktop operating systems.
Oh, OK. But all of your examples are open source programs. And there is a reason I only run open source programs on the desktop (except maybe for a driver or two, I guess, possibly). I'm not afraid that Vim is scraping my clipboard and selling the contents to an advertising firm. Because it’s not.
Perhaps not relevant to LinkedIn specifically, but in general people install these apps because they eventually get fed up with the purposefully crippled mobile website badgering them about it. Ever tried to use Yelp or Reddit's mobile websites? Impossible.
Actually, no, I never have. But if I wanted to wallow in these sewers for some reason, and the mobile sites were unusable, I would use my laptop, or just manage to find some way to survive without them. Installing their apps is out of the question.
If you don't mind seeing the desktop interface, prepend "old" to the domain on any reddit page (i.e. change the domain to old.reddit.com) to bring up the legacy interface. Loads quick and works fine on mobile if you don't mind zooming.
That said, it's ridiculous that this is necessary.
Why does a website or app even need access to the clipboard? I would maybe naively think that the OS could send the characters on the clipboard as if they were typed quickly, end of story.
Every time I paste something in iOS Mail it will inevitably get pasted as "rich" text where I have to put extra effort to clear that formatting (paste it into a plaintext-only input field, then copy from there).
Agreed, but that still doesn't mean that and app should ever have the query the contents of the clipboard. The OS could send a message to the app with the contents of the clipboard when the user presses CTRL-V.
Again, how exactly do you propose that "get a message when CTRL-V is clicked" would work with:
- raw keyboard modes (in which an application gets input straight off the keyboard because it wants to do its own keyboard processing)
- graphical context menus (user clicks on a paste button within the app, or even uses a voice or other control - how does the application communicate to the OS "my user wants to paste"? Or does your back-of-the-napkin fix require users to only use devices with keyboards and only use the keyboard?)
Amongst other technical considerations. It's almost as if pretty much every major OS/windowing system has ways of programmatically accessing the shared clipboard for a reason.
Every digital application that can be used for surveillance and control will be used for surveillance and control, irrespective of its originating intention.
Coined in the early 1980s, in The Age of the Smart Machine.
LinkedIn is a subsidiary of Microsoft. I know the title of this post is an excerpt from a tweet, not a headline, but I think it's generally appropriate to call out the parent company in cases like this. For instance: "Microsoft's LinkedIn app is copying the contents of my clipboard on every keystroke."
Very not cool. I am a medium LinkedIn user, but now it is going to be limited strictly to a PC browser, where I have some control. I just uninstalled it from my cell. I got caught in the siren song of convenience.
I hear you, but I do get some value from LinkedIn ( few prospects, interviews and so on ). In my little corner of the world, it has become defacto online resume. I stand by my initial reaction. I am not sure I am ready to drop it altogether.
But the thing is you need to get to the airport and there's no other way without missing your plane and forfeiting money paid for your ticket. Now what?
That's where we are with the market power of the big players. Google, facebook, apple, linkedin etc. Use the competition to linkedin in this space? You lose. The end.
The way we have always dealt with market power abuse in the past is via a combination of breaking up dominant players and regulation. The longer this wild abuse of market power goes on the more likely that this will be done in a bad way with pitchforks rather than a sensible, measured, outcome driven way carefully weighing the competing intrests to get what is best for the wider population in the medium and long term.
Also the fact this is legal at all is another case of everyone in law making, courts and enforcement having their brains fall out of their ears as soon as the words "using computers" are uttered. Do the exact same thing in any business where a computer is not used to do that thing and you are going to jail. It's break and enter. But "using a computer" so it's fine with the laws all no longer applicable.
I uninstalled it from my phone years ago when I started getting cold calls, and was told directly they got my information from linkedin (where I never put in my phone number)
I've actually been reassured by how many of my more thoughtful friends have appeared on Signal (and other less well-known but more trustworthy tools) recently. Sure, lots of people are just using something like Zoom or one of the Facebook-owned privacy invaders, but I get the feeling that with so many more people relying on these tools for both personal and professional reasons because of the virus situation, awareness of the issues is at least in moving-the-needle territory now. It's not much, but it's still progress in the right direction.
379 comments
[ 2.9 ms ] story [ 310 ms ] threadGive it a few weeks and people will start posting articles about how it happens on PC / Mac platforms too.
Though some apps I trust more with how they use the clipboard data or only restrict it to certain types, eg: image data for a photo viewer, urls for a browser, tracking code for a delivery app
Call it incompetence if you want, but there's a certain flavor of evil incompetence here.
There might be a thin guise of "security" (i.e. email isn't a secure place to send your top-secret inbound message) but I'm inclined to suspect the main motivation is to drive people back to the platform and drive up their stickiness metrics.
It's user-hostile.
Some other silly shit that come to mind - having the unsubscribe link after half/full page of white space, once you click on unsubscribe "give us 24 to 48 hours to remove your email" etc. Really? they need 24 hours to delete (or change a flag) in the database?
I'm sure in A/B tests it increased engagement...
His book is also staggering insight into how little ability he has an executive and investor (some of the stuff is intern-level mistakes, like maybe juniors who are in their first week and got the job because of daddy...but even then...rare).
I know it's Hacker News and it's easy to criticize LinkedIn for shady growth practices and get praise for it. They often deserve it, but assigning malicious/growth intent for every change they make is misguided.
Fixed by switching to firefox and blocking redirects.
The security excuse is used as a way to increase conversion.
Edit: Apparently it's Just A Thing: https://support.apple.com/guide/mac-help/copy-and-paste-betw...
But you can turn it off by turning off "Handoff", which luckily I already had. Nowhere is it mentioned in the settings UI that this extends to your clipboard.
In Chrome on Android, the flag you want is under Settings | Site Settings | Clipboard | Ask before allowing sites to read text and images from the clipboard, and I think it's on by default.
What do you expect when the CEO holds an MBA?
The current feature being added allows this to happen, for awareness to be raised.
To be honest, I'm surprised we haven't heard of more snoopy apps already, but, I guess that will come when the feature's out of beta.
That's, one way to implement it...
Alternatively, and how I'm pretty sure it already works, is that on paste the clipboard could insert content directly into the control, never involving the app in the process.
Apps with completely custom inputs would need to see the contents, but that's both rare and usually a bad idea in the first place.
[1] "How popular apps can read your phone's clipboard without permission": https://www.mysk.blog/2020/03/10/popular-iphone-and-ipad-app...
[2] "Popular iPhone and iPad Apps Snooping on the Pasteboard": https://www.telegraph.co.uk/technology/2020/03/30/popular-ap...
They didn't say it was. They're saying they're looking forward to the next major release which alerts the user when this happens. That's why all these stories are coming out right after the release of the beta.
Screw permissions flags. Clipboard-sniffing is never justified. Moving data out of the clipboard should only ever happen by direct user request via the OS interaction layer.
It's like people have either been gaslit into thinking that there's no sane alternative to the current nightmare or are so shortsighted that they don't understand the horrors lurking around every corner that wouldn't be there if they stopped to consider the consequences of [checks notes] "google maps doesn't require you to to paste the address in before it starts to route" and "dash can drop a markdown formatted link". Because saving you one click is surely _so_ important that it's worth giving up everything for.
I understand the outrage over apps abusing their access to the clipboard but what I don't understand is the people acting as though the OSes they use on the daily don't have the exact same "flaw".
> 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings)
A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS. Want something perpetually backgrounded that exists exclusively to steal your secrets? Make _that_ a special permission if you must. Or just don't allow it.
> * 2) is not trivially spoofable by the enterprising developer?*
Ignoring the _minor_ contradiction of mixing "trivially" and "enterprising", rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that.
Could someone root your system and blahblahblah? Sure. But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
Wonderful! Now how does this brilliant little solution account for applications that don't centre their operations on the keyboard?
How does this work for clicking on a UI element to paste?
How does this work for using non-tactile forms of input - say, a voice command?
How does this work for any method of interaction that's not "press a combination of keys"?
How does this interact with the very real and undebatable need to allow programs to simulate keyboard events?
What happens to operating systems that have the implementation of a system clipboard as out of scope (like a little-known operating system called Linux)? How does, say, the X window server then manage to implement a clipboard on top of it?
> rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that.
I am very curious indeed: what, exactly, do you think happens when (for example) a C program calls `getchar()`?
> But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications? The whole point of a buffer for temporarily storing and transferring data between applications is for said applications to actually access it. You are doing the equivalent of saving your "secret" in plaintext in your home folder and then complaining about the OS if/when a program peeks through your generally accessible home folder and finds it.
Do you have some idea of a better, more secure way to share information between two apps the user alone has decided should be in communication?
To some extent, a solution does exist for arbitrary (iOS and Android) apps, which lets you explicitly pick what application you want to receive some data - the sharesheet. It's criminally underused in my opinion.
The same way as designating keybindings. Registration with the OS. I don't care if you have to do it by defining hotspot outlines for bespoke-from-raw-pixels interface elements.
> How does this work for using non-tactile forms of input - say, a voice command?
Voice interface is mediated by the OS. Register your desired custom paste command.
> the very real and undebatable need to allow programs to simulate keyboard events?
False. I'm happy to debate it. But before we do, I have to ask you to try to not be stuck in the "how things are done now" mindset.
> What happens to operating systems that have the implementation of a system clipboard as out of scope"
Then they have decided to punt on user safety. Be angry at them and demand better. Also, you're derailing.
> what, exactly, do you think happens when (for example) a C program calls `getchar()`?
What do YOU think happens? You think that your program talks directly to your keyboard buttons? And why do you think that this question is relevant?
> If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications?
Frankly, I think this is a bullshit user-hostile copout. Treating the clipboard as "general shared buffer between applications" is exactly what caused this madness. The clipboard is an extension of the user, like writing something down on paper so they can then reading it back later, and should be treated as such with sanctity.
Try approaching from the perspective that all of your "what if"s have a safe non-almost-100%-of-the-time-user-hostile solution. Because the freewheeling "steal my secrets" API is almost 100% of the time extremely user hostile and computers are meant for people to use.
If you're a random internet weirdo who uses a public interface in an unexpected way, you face decades in prison. [1]
[1] https://www.wsj.com/articles/SB10001424052748704312104575299...
I'm uninstalling this app from my phone now. This isn't acceptable!
https://news.ycombinator.com/item?id=23634138
https://news.ycombinator.com/item?id=23691190
https://www.youtube.com/watch?v=pRSWdtoUAjo
[+]:A sample pipe might be a good analogy for this behaviour. You cut or copy the input, send through the sample pipe, and the receiving end unpacks, receiving itself makes the sample disappear for further use. Multiple samples could be sent through the pipe, though the pipe should behave in a LIFO, no sample adding allowed after removal starts, manner if this is desired.
Seriously, has anyone complaining about this actually paid any attention to how clipboards work on their OSes before this?
GNOME has a Wayland implementation too, and what I said only applies to GNOME native apps.
I am thus very curious indeed about how a "GNOME native" app differs in this context.
0. https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html
It would all be a lot simpler if browsers and other operating systems just implemented an API call for obtainAllMyPrivateInformation(). That's clearly what developers like LinkedIn (and TicToc, etc.) are looking for.
GET parameters aren't usually visible to users; with the deemphasis of the URL bar, you'd have to have an incredibly short URL for that to even be a possbility. Right now I'm looking at
That's one visible parameter. There's PLENTY OF SPACE for firefox to show the rest of the URL, but it won't; instead, a bunch of icons are unhelpfully crammed into the same horizontal layout.In the larger sense, where users can see the parameters if they intentionally look for them, despite the fact that they are normally invisible, POST parameters are just as visible.
Right click on the "crammed" icon area, pick "customize", and then you can drag and drop the icons crammed into the space into another bar (or out of the UI entirely if they are icons for things you never use), which should then recover much of the lost space.
Edit for those interested:
tl;dr: "asynchronous clipboard API" [0]
Overtly, it's used by shit news sites like WSJ, nytimes, and bloomberg to inject their shit into your clipboard when you copy-paste. A common thing I've noticed is selecting text, copying the text, and then pasting somewhere and seeing a link to the original article instead.
I'm not sure if they're still doing it; there has been several people complaining about this over time [1] [2] [3] [4] [5] [6]. I found this awesome article on the Security StackExchange from 2013 [8].
Also it's not just javascript. You might be forgiven to think that using a command-line interface would spare you. Unfortunately you'd be wrong; mosh, tmux, vi, emacs all support your terminal emulator's clipboard events. [7] [8]
[0]: https://www.w3.org/TR/clipboard-apis/
[1]: 4 months ago: https://news.ycombinator.com/item?id=22352674
[2]: 4 months ago: https://news.ycombinator.com/item?id=22446940
[3]: 8 months ago: https://news.ycombinator.com/item?id=21377598
[4]: March 2019: https://news.ycombinator.com/item?id=19384895
[5]: December 2017: https://news.ycombinator.com/item?id=16034854
[6]: September 2015: https://news.ycombinator.com/item?id=10301881
[7]: Three months ago: https://news.ycombinator.com/item?id=22815757
[8]: https://security.stackexchange.com/q/39118/47800
But they can copy to your clipboard for you, a lot of services use "Click to copy" features. But reading is much harder.
iOS before 14.0 appears to have allowed apps to read clipboard contents without making that clear to users. Now that you get a notification whenever an app reads the clipboard, it has become fairly clear a lot of apps are reading clipboards constantly. For what… we all wonder.
I'm not saying this is true, rather asking if I got the wrong impression.
Incorrect; the API is here [0].
[0]: https://www.w3.org/TR/clipboard-apis/#dom-clipboard-read
It is at least supposed to be hidden behind a permission. What's the default for that permission though? I sure hope Google^H^H^H^H^H^HMicrosoft^H^H^H^H^H^H^H^H^Hsome evildoer doesn't find a way to override your permission setting. A reset of configuration data after an automatic update might do the trick...
> And your [8] seems to be about the user deciding to paste unsafe content — totally different issue, isn’t it?
Perhaps you are right. I won't claim to fully understand how tty programs work. However:
* `emacs` documentation describes an ability to interact with the user's system clipboard [1].
* `tmux` integrates with the user's system clipboard [2].
* `mosh` apparently caches the user's system clipboard [3].
* `vim` has special registers to represent the user's system clipboard [4] [5].
If the system is using dbus (nearly every Linux based OS), it's pretty easy to do. Here's a python script using GTK to do so [6]. A high level overview of the clipboard is described in the freedesktop specification [7].
I think it's really unfortunate that desktop and CLI software is so insecure.
[1]: https://www.gnu.org/software/emacs/manual/html_node/emacs/Cl...
[2]: https://superuser.com/a/1336764
[3]: https://superuser.com/a/1336764
[4]: https://vi.stackexchange.com/a/96
[5]: https://vim.fandom.com/wiki/Accessing_the_system_clipboard
[6]: https://stackoverflow.com/a/21337063/1111557
[7]: https://specifications.freedesktop.org/clipboards-spec/clipb...
This has everything to do with closed source programs reading the clipboard without permission since there are no permissions involved in desktop operating systems.
https://news.ycombinator.com/item?id=23716931
right?
The other day I tried to view a subreddit in Safari. It was literally impossible, it was claimed to be only available in the app.
That said, it's ridiculous that this is necessary.
https://i.reddit.com/
An app doesn't need access to the clipboard unless I'm actively pasting to it while it's in focus.
Every time I paste something in iOS Mail it will inevitably get pasted as "rich" text where I have to put extra effort to clear that formatting (paste it into a plaintext-only input field, then copy from there).
The discussion around this is so strange and weirdly nontechnical to me.
Currently: application queries clipboard state and gets back some structured data. (quick googling confirmed this).
Proposed: application gets a message when CTRL-V is clicked along with the same data that currently gets returned when clipboard is queried.
- raw keyboard modes (in which an application gets input straight off the keyboard because it wants to do its own keyboard processing)
- graphical context menus (user clicks on a paste button within the app, or even uses a voice or other control - how does the application communicate to the OS "my user wants to paste"? Or does your back-of-the-napkin fix require users to only use devices with keyboards and only use the keyboard?)
Amongst other technical considerations. It's almost as if pretty much every major OS/windowing system has ways of programmatically accessing the shared clipboard for a reason.
Apple's Universal Clipboard may share your clipboard across devices.
if you agree with that premise, then it's no surprise that every possible source of data that can be collected upon, will be collected upon.
Every digital application that can be used for surveillance and control will be used for surveillance and control, irrespective of its originating intention.
Coined in the early 1980s, in The Age of the Smart Machine.
https://en.wikipedia.org/wiki/Shoshana_Zuboff
I wonder if they are using some tracking software and that is doing this. My guess is every tracking software does it.
-- Richard Stallman, probably
-- Richard Stallman, probably
Now how many other apps do this.
That's where we are with the market power of the big players. Google, facebook, apple, linkedin etc. Use the competition to linkedin in this space? You lose. The end.
The way we have always dealt with market power abuse in the past is via a combination of breaking up dominant players and regulation. The longer this wild abuse of market power goes on the more likely that this will be done in a bad way with pitchforks rather than a sensible, measured, outcome driven way carefully weighing the competing intrests to get what is best for the wider population in the medium and long term.
Also the fact this is legal at all is another case of everyone in law making, courts and enforcement having their brains fall out of their ears as soon as the words "using computers" are uttered. Do the exact same thing in any business where a computer is not used to do that thing and you are going to jail. It's break and enter. But "using a computer" so it's fine with the laws all no longer applicable.
We have allowed empires to be built on scummy business practices that are fundamentally user hostile. We are under no obligation to maintain them.
This shit is on literally every platform, it's inescapable, and at this point necessary to participate in society.
That kind of stuff is not beyond them.