（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=41415866

为了改善软件应用程序（例如操作系统、浏览器和各种类型的应用程序（例如本机或 Web 应用程序））的用户体验，应该在使用剪贴板读写任务期间增强对纯文本的支持。在处理纯文本时，此功能还应优先考虑易用性。虽然简单的文本似乎更受欢迎，但并不是每个人都同意这个观点。事实上，这可能只是少数人的观点。此外，引用纯文本会忽略这些数据通常包含的附加元素，例如格式和非文本信息。大量用户重视这种丰富的内容，并且会发现纯文本版本令人困惑。因此，多部分剪贴板系统提供了一种平衡的方法。尽管可以进行改进，但其主要目标仍然是确保与大多数用户的首选格式（纯文本）兼容，同时满足需要丰富数据格式的用户的偏好。将默认设置保留为纯文本有利于那些主要查找无格式文本的用户，同时又不会影响需要更丰富内容的用户的需求。

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.

Join me, and we can form an army. We need to solve this, and "learnings". I think it's possible this becomes the Butlerian Jihad but without spice.

"Literally" has been abused so much that they have officially made an informal definition of it to mean "figuratively."

Which means "literally" is now its own antonym. Pretty wild

The main issue with powerful tools is that they get used against you by threat actors.

Our society sets limits based on the most selfish. Our computers get limitations based on the most effective threat.

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'

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

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.

Hmmm. My work machine had them on, but I suppose that could have been set by policy. I will check my Aya Neo later (only personal Win11 device).

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)

Particularly good combination of scope (including differences across systems and browsers) and depth (including both gotchas and workarounds).

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

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.

  - 0. https://apps.apple.com/us/app/pasteboard-viewer/id1499215709
  - 1. https://apps.apple.com/us/app/actions/id1586435171

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.

Yea, first time I hit their site from this machine. And the alert showed on my mobile phone - "allow aluminium?"

One of these days I'm gonna log in with the debugger active.

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.

I'm logging in on a laptop and getting notifications on my mobile that contains my laptop hostname.

I don't have any banking app installed on either device.

It's confounding.

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.

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/

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.

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

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.

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.

（评论） (comments)

（评论）
(comments)