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.
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
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
