Nice writeup. This explains why I have issues trying paste with/without formatting on Firefox on my Mac in Google Docs. It’s interesting that Google is using a deprecated API to add their own content type format to the clipboard.
If some bigwig has marked an API “depreciated”, but hasn’t provided a viable alternative and the user experience suffers when user agents stop allowing their users to invoke the helpful functionality, the agents who do let their users do what they want are not the issue.
A pluralization once popular in 14th Century Middle English that died out until ressurected in central north American business English.
In 2016 Grammarist was to the point.
"Learnings is a pluralization of an erroneous form of learning as a singular noun. Said singular noun (e.g., a learning) does not exist, at least according to most dictionaries. Colloquially, especially in the medical field, learnings means specific items that were newly discovered or learned."
My takeaway is the most reliable way to send custom app data over clipboard is using data embedded in HTML a la figma. Bonus is that method lets you define failure behavior via html message if receiving app doesn’t support
Wordpress stuffs around with this. Cut-pasting across multiple paragraphs in editor mode can go horribly wrong (copying wordpress words into another web system for cross-pollinating the textual dependencies over "there") -Presumably because the paragraphs are actually different regions under different DIV logic and under different control-effect outcomes?
Another game I find the machine plays on me, is uplifting what I think is ASCII into UTF-8 or iso-latin1 which latterly invokes the clippy-like "I changed those quotes to be more aesthetic thank me later" behaviour which of course, I did NOT want. If I wanted `this' I would not have typed 'this'
Years ago when I was a student, and JavaScript could get a user’s clipboard without their consent, I made a website ‘getpasted’ that automatically pasted and posted your clipboard to a public database.
Needless to say, some people weren’t happy about it. But it was a nice project to create awareness that it was possible to read the clipboard at any time.
Wait until people find out that by default on Windows 11 all of your clipboard data gets sent to a Microsoft server via Clipboard History / Cloud Clipboard.
Is Apple’s version of this any better? Clipboard is synced between phone/computers logged into iCloud although it doesn’t log history (at least visibly)
Excellent read, thank you. Just wanted to note that the author of Pasteboard Manager[0], Sindre Sorhus, is also the maker of Actions[1] shortcut library as well as other cool iPhone and Mac apps. Not sure if he is on HN.
Thanks! I've been trying to limit excessive detail and tangents in my writing (my posts tend to be on the longer side). Great to hear I managed to strike a good balance here.
This was easily the greatest article ever written on the web clipboard interfaces.
I didn't even know about isTrusted until a couple of weeks ago when I was writing some widgets to speed up some tasks by automating a bunch of web controls. I couldn't get my auto-paste to work, discovered that flag and went down a rabbit hole of trying to over-ride a safety mechanism on my own local browser (not easy!).
On the subject of getting "private" data from the browser.
Somehow my Bank webapp was able to 2FA prompt me on sign-in with my hostname (aluminium). How did it get that? And when using their site from mobile it's able to see the text with the 2FA code and auto paste it in! Wow/How? Pixel+Chrome or Linux+Chrome.
At least the 2FA Code probably is a Chrome feature, safari displays 2FA SMS text codes as a autocomplete suggestion and I could imagine that Chrome on Android just autofills it. For the hostname, it’s more difficult. Are you sure you never gave that info to the bank as a username or similar? What Bank is this?
And where exactly does it show your hostname there? And are you sure you never used it as an account name or something like that? I can’t imagine they can access the hostname from JS.
One possible answer: if the phone app is a native app, it could be listening on a HTTP port and sending the phone's network information to the webserver, which then tells the webapp to ping the phone app, and then the phone uses reverse-mDNS to get the hostname.
I'm not sure why they would go to the trouble of getting the web app to talk to the phone app directly, but it is possible.
This article is a perfect illustration of why Webapps will never be as good as native ones. Webapps are always "untrusted" code so they are arbitrarily and artificially restricted from accessing resources on your local machine.
Untrusted by default is a feature. No user would be able to protect themselves, unless perhaps they are a highly trained security expert always on alert, which is not a thing.
This is not the exciting early days of the interwebz where script kiddies run amok and it’s mostly for the geeks anymore, it’s where government-affiliated gangs are launching ransomware attacks on critical infrastructure in order to finance nuclear programs. Accessing arbitrary resources on your local machine is how that happens.
Web apps, given a modern browser, naturally have stricter sandboxing, but native apps are treated as untrusted on any modern OS, too. If I launch anything new, the dialog will have me confirm before it accesses anything other than its isolated app data directory.
I dont run a single native application across five operating systems that requires a popup nag to access the clipboard or that is unable to put any data other than text, html and PNG on the clipboard.
Every mobile OS from Apple would show a popup if an app tried to access clipboard without your explicit pasting. Obviously, if you tapped “paste” then popup would be unnecessary since you would be approving your own action, not app’s action.
It is somewhat crazy that macOS doesn’t do that yet.
But the comment I replied to was talking in general terms. Yes, for some APIs native apps are for now more trusted than Web apps, depending on the OS, but the trend is that they are becoming less and less trusted.
Nope, native applications are not ever going to get the ridiculous level of sandboxing demonstrated by the restrictions on accessing the clipboard in the article. Nor are they ever going to be prevented from accessing the file system as web applications are.
It's sad that there's no support for lossy compressed images. People copypaste images a lot without intention to change them, and each time it's JPEG source the compression is lost but artifacts are preserved, and more artifacts are added upon repeated JPEG compression, which happens immediately with most target web apps. https://xkcd.com/1683/
Software (OS, browser, native apps, web apps, …) should make it easier to use plain text for both read/write clipboard operations. And probably should make it easier to prefer doing that.
I know that’s a lot more words to say a similar thing, but it avoids two problems with how you put it:
1. Not everyone will share your preference. (I’d hazard a guess that it’s a minority preference, albeit one I mostly share.)
2. It’s self-contradictory. The “damn text I copied” is not just an array of characters: it often includes formatting; it frequently interpolates other content that isn’t even text at all.
The latter is largely the basis for the former. You—and I, mostly!—might be after that array of characters. But many many people are after that richer content, and would be utterly baffled by copying something rich only to get that array of characters on the other side. And quite a lot of people would have little recourse to get what they want.
This is why the multipart clipboard solution is a pretty good compromise. It could be better! It could definitely accommodate the preference for plain text. But it can only be better for those of us with that preference, without regressing for the much more common preference, by keeping the common preference as default.
Part of the problem is a poor (or insufficiently DWIM) implementation of rich text copy-paste. If I copy text that has some parts bolded or italicised, that is indeed "the damn text I copied". But the fact that the source website happens to be 12pt blue Verdana should not override the fact that I'm writing an email in 11pt black Arial.
In many cases I do not particularly care whether an email is in 12pt blue Verdana or 11pt black Arial, I absolutely care about there suddenly being a big blue word in the middle of my otherwise-consistent paragraph.
So neither "rich text" nor "plain text" are really correct: often plain text is good enough, but sometimes it's easier to correct the rich text.
It's probably a hard problem to solve generically. Word has a little popup when pasting where you can select how you want that paste to be applied: Just text, text with its original formatting, or formatted text, adjusted to the document styles. So far I've used all three, so I guess there's no answer that fits all use cases.
I just paste through a plain text editor(i.e. paste into a plain text editor, verify and copy the bits I want, then paste it in it's intended destination). I know not ideal, but at least that way I can see and verify everything before pasting it somewhere important. I'm sure there are some hacks one can do with rich formats, that some people might try to take advantage of.
Sometimes I agree, but recently I was trying to copy all the contents from one Quip to another and the system was entirely unable to support pasting the same look&feel I copied. No, I don’t want my headings and links and code and lists and…… to all be given back as plain ASCII. Drove me bonkers.
My problem with rich-text paste is that it transfers unwanted presentational formatting, resulting in mismatched fonts, sizes, and typography. I generally either want plain-text paste or preserving semantic elements (like bold/italic emphasis, links, and bullets).
More generally, when editing a document I want to be able to view both formatted text and "escaped" contents (like "view source"), and when copy-pasting or saving text, I want to be able to convert formatted text into "escaped" text to diff, and also paste text without misinterpreting asterisks and angle brackets as formatting information (until I explicitly copy text as source and paste as formatted).
Copying my comment from above here because you may find it helpful:
I use Obsidian for note taking, and discovered one very useful feature: if you paste formatted text, it removes everything except what can be handled in markdown (approximately, things corresponding to html tags, not to styles/CSS). You can then copy it back out as html and paste it and it will have exactly the right amount of formatting.
I use Obsidian for note taking, and discovered one very useful feature: if you paste formatted text, it removes everything except what can be handled in markdown (approximately, things corresponding to html tags, not to styles/CSS). You can then copy it back out as html and paste it and it will have exactly the right amount of formatting.
Off topic: I often find that copy&paste doesn't work. I clearly hit copy, when I paste nothing happens, or I get the previous copy instead. Not sure why this happens, I see it both on Macs and Ubunutu. As if, after decades of work, we still can't reliably implement a simple operation. It happens both in browsers and other apps.
