Don't touch my clipboard
alexanderell.is
alexanderell.is
“ghci> putStrLn (pretty 10 value)”
Excerpt From: Bryan O’Sullivan, John Goerzen, and Donald Bruce Stewart. “Real World Haskell.” Apple Books.
ghci> putStrLn (pretty 10 value)
There's a big warning before it lets you execute the command.
Now, almost 20 years ago only RedHat did it. And it felt wrong to me :-/
[1]: https://en.wikipedia.org/wiki/Rm_%28Unix%29#Protection_of_th...
On FreeBSD you can do
sudo dd if=/dev/random of=/dev/mem
No lasting effects are there? Besides a crash, afterwards I shouldn't have any memory issues, right?
Obviously no warranty on bare metal/systems that are actually used for anything.
The command's intention is so obvious I wonder why there is no warning from the os, the shell program or the terminal for such, easily blacklist-able commands. Or is there?
Wow, that's good to know!
https://apple.stackexchange.com/questions/141321/how-to-rest...
More specifically, I used a bunch of these links until I could get a shell, then manually-fixed the rest.
https://askubuntu.com/questions/308939/how-to-reset-default-...
https://askubuntu.com/questions/508359/restore-default-syste...
Apple Books is so close to being a nice reading interface, but there are so many stupid little bugs. Highlighting is another horrid little bug that can easily wipe out a full chapter’s worth of highlights with one tap...
I can only guess no one on the team actual uses the feature.
As a language learner I use Rikaikun for Japanese on my desktop browser. While I'd really like it if I could also run a similar extension in my mobile browser I'd be okay of Apple's dictionary actually worked with a fuzzy search and multiple terms... but no....
It sounds ridiculous, but in my experience, there are 1000 things that lawyers will identify as possible sources for legal trolling and this looks like that. Apple has a zillion dollars in the bank and they are sued daily. All it takes is for a judge who may nor not be knowledgable or a sufficiently grey area ... and you have a major problem.
So it could be risk mitigation: they are including the attribution in the copy so as to not be perceived as partisan to some kind of IP dissolution paradigm.
On the other hand, this could just be one of those wayward culty Apple kinds of things they think is 'good UI' when it's not.
Though I can see that a reasonable legal opinion might not support my more cynical view, when the risk dynamics are high, a different kind of logic creeps in.
I worked for a software platform that refused to provide usable snippets of code anywhere in the documentation for fear of liability.
We also 'perpetually sued' an organization that was infringing on our brand, even though they were really helpful to us (a user-managed fan-site which used our name in theirs) and otherwise had a positive relationship with them. Our 'perpetual legal action' was merely cover give the appearance that our brand was being defended, without which action, we could feasibly lose rights to it. So, literally suing people, while dragging out and 'nudge-nudge-winking them' to not worry about it, literally inviting the people we were suing to events, dinners etc..
I don't think most people understand the risk dynamic in many large organizations with respect to these issues, the calculation seems bizarre even to most regular product types, it really takes a legal view to understand this. And also the personal fears and biases of the executives.
Was that really easier than just licensing your trademark with a strong contract that preserved your rights while letting the website use your name for one specific purpose? Make the licensing costs $1 per decade or something if it is a question of money.
Misusing the legal system in this way seems like it could backfire if the third party did something you genuinely wanted to stop and they could prove your ongoing action was a sham.
My point is not about branding or lawyers, it's about risk.
Said company gave up a huge amount of money to patent trolls, and their lawyers were empowered to mitigate risk, with the backing of the CEO, their rationality being: "We make a huge amount of over here, why on earth would we allow that to be risked by speculative activity over there?" which is not entirely irrational, it just depends on implementation.
Everything is so gray, it's so hard to tell. Consider that we have no idea how open-source software licensing will work out because it hasn't been really pushed through the court system, and how limiting that ambiguity is for the entire industry.
Why should they be ASCII, and what’s wrong with Unicode?
So unicode quotes and ASCII quotes are not exactly the same in this scenario.
The second is that there's a significant difference between "won't run due to syntax errors" and spitting a pasted line back at you since it thinks it's just a string. In a less robust environment the first option might actually crash your environment, or leave you with subtle errors. Like in a shell, it might treat things like escape sequences and things will look off unless you reset them.
Personally, I don't see any reason to hate typographically correct quote marks when used correctly, which (obviously) doesn't include code samples.
Seems such an obvious interface to innovate, but it seems to run into terminal wizards sense of purity.
The vast majority of programming languages are defined in terms of ASCII and only ASCII. I don't care for this, personally.
I've given some thought to how to do quoting right in a programming language, and implemented «guillemets» as an experiment. But it's challenging, you need to decide what to do with all of “”‟„"″ and there aren't obvious pairings, like „this is a sentence” and “this is a sentence” and »this is a sentence» and «this is a sentence» and »this is a sentence«, it ends up feeling like rather a lot of effort for what you get in return.
Oh, one of those characters I typed isn't a quotation mark, did you catch which one? Hacker news won't even let me type two of them!
The tradeoff is not worth it for programming languages the same way as learning all the scripts of the world is not worth it for one human being, just to accomplish tasks that don't need all these symbols in the first place.
Already fully designed and implemented in Raku: https://docs.raku.org/language/unicode_entry#Smart_quotes
Test online: https://tio.run/##K0gtyjH7//9Rw7ySjMxiBSBKVChOzStJzUtOfdQw9/...
Sure: these are all quibbles, and a language wouldn't die from all these minor cuts. But they're definitely downsides, not upsides. So: where is that upside? Why would you ever support something like this? "It looks a little nicer" sounds like a pretty weak argument compared to "it's inconsistent, hard to machine process, and may cause a few bugs"...
I want «guillemet strings» because they use a matched pair, so you can «quote a string «within a string» without escaping» and I think that's a nice property.
I'm not really interested in supporting all the forms in which they're used in European languages, though, that would be a real hassle. Just the one that looks like the other matched pairs we use in programming.
“smart quotes” have ‟at least two styles” and really „three styles”, and the first two are really easy to confuse with "normal double-quotes". I don't want my users to have to deal with "why doesn't this compile”?, and if I allowed it to compile, now you have to escape all the quote characters inside any string, which is messy.
Raku, as a sibling points out, has bitten down on this bullet, and I respect that. I keep meaning to give it a spin, I'm fond of Parsing Expression Grammars and have good feelings about Perl from the early days.
.say for q[‟”].uninames
# DOUBLE HIGH-REVERSED-9 QUOTATION MARK
# RIGHT DOUBLE QUOTATION MARK
“double "quotes"”
Also note that you can use a variety of characters for quoting if you use `q`, `qq` or `Q` etc.
q<<<<1 < 2>>>> eq '1 < 2' eq q^1 < 2^ eq q%1 < 2% eq q｢1 < 2｣
In Raku string literals are actually a [parameterized domain specific language](https://docs.raku.org/language/quoting). (The domain of creating strings.)
my $buffer = Blob.new(115,116,114,105,110,103); # 'string'.encode()
Q # start with raw quoting
:scalar # enable embedding the value of scalars
:backslash # enable backslashing characters
[This is a $buffer.decode()\n]
'single' eq q [single] eq Q :single [single] eq Q :q [single]
‘single’ eq ‚single’
"double" eq qq [double] eq Q :double [double] eq Q :qq [double]
“double” eq „double”
｢raw｣ eq Q [raw]
< words > eqv qw [ words ] eqv q :words [ words ]
<< quote words >> eqv qqww [ quote words ] eqv Q :double :quotewords [ quote words ]
« quote words »
:double is actually short for :scalar :array :hash :function :closure :backslash
:words splits on whitespace :quotewords splits on whitespace but respects quoted sections
q :words [ a "b c" ] eqv ( 'a', '"b', 'c"' )
q :quotewords [ a "b c" ] eqv ( 'a', 'b c' )
qq [with newline\n]
qq :!backslash [without newline\n]
qq :!array [user@example.com()]
After all, users of non-ascii languages (which is nearly everyone) already know how to deal with it without ambiguity. Its only ambiguous if you don't use encodings, and that should never happen anyway.
If you are going to get rid of it anyways, why bother with it in the first place? Also, you then have the ambiguity/problem whether some symbols are mapped to the same ones or not.
> already know how to deal with it without ambiguity
I wish. Just dealing with ü vs ue vs \"u and ascii, win something, utf8 and utf16 is still annoying in practice. Or latex choking on accents, non-breaking whitespace or similar fun stuff.
Oh, you used foo and föö as variable names, too bad those are the same now by normalization.
> It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate.
Tone down the condescension and insults, please.
Also, they're difficult to type - my keyboard has a " key but not a “ or ” character. I had to copy and paste those from the unicode website since I don't have a suitable input method set up.
Or [Shift]+[Option] [B04] and [Shift]+[Option] [B05] if there's no explicit [Group2] shift.
Open and close single quotation marks use the same keys.
"terminal wizards" have done quite the opposite of rejecting this.
Unicode quotes probably aren't, so it's extra annoying to remove them, and they're not even the same character for start and end so you have to do it twice.
The time spent for removal is then vastly higher than with ASCII quotes, which in the context of unwanted characters may well qualify as "horrid" imo.
(The Unicode quotes also mostly come in matching pairs, so, for good or for ill, they'd in principle be nestable.)
Then there is a less-often used style of quoting, similar to the French style, but: «this» is the French quote, whereas »this« is the German version. Yes, the open and close quotes are swapped.
I applaud the idea, but just want to point out that there are dragons lurking in the shadows.
sed -i '/<open quote>|<close quote>/d'
/"<CR>xnx
Of course, the fact that the text is modified in any way is user-hostile. I don't mind re-typing a code example (since I'm trying to learn it), but I like to copy-paste sometimes (e.g. data literals).
I paid for a DRM-free ebook that's meant to be copy-pasted. We have a universal paradigm for how plaintext copy works. Apple charges a premium for good design. Ebook readers are generally supposed to get out of your way and let you focus on content. There is no reason for Apple Books to have this behavior.
Back then, I was writing papers and it was kind of handy.
As you can see in that answer, I found a better method to assign the keyboard shortcut. Assigning the shortcut within App Shortcuts instead of Services lets you use the normal ⌘C shortcut in Books while not affecting copying in other apps.
Excerpt From: Bryan O’Sullivan,It really does seem like software at Apple is being designed by people who just aren't familiar with the platform.
https://devblogs.microsoft.com/oldnewthing/20140721-00/?p=45...
I recommend the solution in https://apple.stackexchange.com/a/382603/21473 (which is an improved variant of stassats’s solution in https://news.ycombinator.com/item?id=22355322). The method is to use Automator to set up a Quick Action that copies the text while bypassing the clipboard-modifying behavior of Books. Then you configure a keyboard shortcut of ⌘C for the Quick Action, only in the Books app, so you don’t have to change the way you copy.
Is there any way to configure my user agent (Firefox) not to do this? A hack is ok.
You can't do it through a user agent, though
I've only ever seen that setting fix sites that try to prevent you from copying.
But I wouldn’t be surprised if stuff like this is the exception rather than the rule. I feel like most news sites and blogs are improved with JavaScript disabled.
Do you actually need clipboard events, or just dom.event.contextmenu.enabled for that?
The entire ask (stopping the copyright, and allow clipboard integration) be achieved by allowing pages to augment the clipboard data, which can already be done, but not replace it. Pages would still need to be able to hook paste.
So many lost rants ... ;o)
Any time you're not interacting with HTML text is a time it could be useful.
I already mentioned this in another comment, but everyone should enable bracket paste mode in their shell to defend against this.
echo "hello"
echo "lol" ; sudo sl -rf /
Pray for no escape, bang, or control sequences.
(Alternatively: "r! cat <paste> <ctrl>-D" will read into a vim session.)
Examine the output, trim the unwanted / dangerous bits, and run (or save to a file/script).
Since I run what are ... generously ... considered "bash one-liners" all the time, that key sequence is locked into my muscle memory. It's a convenient way to invoke an editor immediately and run code from it.
Alternatively, call a utility that can read the clipboard directly. For Xorg:
:r! xsel -b
:r! wl-pasteI do this frequently on Android via Termux, ssh'ing to remote hosts.
It ... ultimately doesn't scale. The black-hat namespaces are too large, and treating as TOFU eventually proves untenable.
Advanced features -- anything beyond rendering basic HTML, and I'd be quite prepared to argue for a very limited subset of that -- should be expressly prohibited unless enabled.
The trick is to make enabling reasonably painless and consequence-free (e.g., enable into a sandbox). There are still the problems of users gratuitously enabling anything and everything (especially when prompted through website notifications, pop-ups, phishing and vishing social engineering attacks, etc.), as well as the problem of largely invisible second and higher-order effects.
But the key is to cut down on the effectiveness of such methods, to impose costs on websites for employing them, and to make black-hat attacks through these too expensive by reducing the herd susceptibility to the attacks (the unbocking would have to occur on a one-at-a-time case-by-case basis, e.g., it's expensive and has limited scalability).
I don't think we'll actually see this for another 5-10 years (my usual sane-suggestion take-up lead time, it seems), but It Would Certainly Be Nice To See.
I had experimented with NoScript long ago, but found it a bit more cumbersome at that point because (then, before the uBlock days) I couldn’t really judge which scripts were necessary and which weren’t. I’m going to try it again.
One big plus with disabling JS is that all those ad blocker blockers and other annoying popups just don’t even appear, and that adds to a better experience.
I have JS blocked on some domains because of popups/other annoyances which make getting to the content a hassle. In those cases it's the exact opposite.
For mobile devices, easiest way is to use two different browsers (one with JS disabled).
A per tab setting that remembers the JS enabled state would be very useful, with the default being JS disabled.
Perhaps in a rich text editor I want to copy as plain text; or perhaps I want to make a Markdown editor that you can select+copy the Markdown but then paste HTML. Just brainstorming.
I think it is needed for some complex web app to handle copying non-text content. Such as images in wysiwyg editor, Google Sheets/Slides...
I'd be 110% fine with that trade and nothing of value to me would be lost.
Is it possible in Firefox? Anyone know?
The browser is no longer just a document viewer... That ship has sailed, and overall it is a good thing.
We can mitigate the risk of clipboard hijacking without burning down the house. By the way, I would guess that this is a minor risk in the grand scheme of things, as it seems that the worst risks are for technical individuals people copying programmatic commands (e.g. software engineers). For others, it is a real yet minor annoyance.
Perhaps there could be an opt-in setting for allowing a site to modify the default content that is copied from a selection?
X11/Xorg has the primary and secondary selections.
MacOS has ... whatever it's got.
A key problem with this is that the feature is covert, latent, poorly discoverable, and causes unexpected behaviours. Even presumably advanced users (myself, you, other HN readers) are poorly aware of this. Imagine trying to explain to your nontechnical Aunt Tilly or Uncle Kamlesh about these "different clipboards which treat what you've copied differently and access through this funky interface"?
The Javascript interface isn't aware of these distinctions, though I'm not sure I want it to. Web apps like this that abuse one plain text clipboard will abuse multiple richly typed clipboards, too.
No, it really isn't. Web apps and documents using the same underlying technologies doesn't mean they have to be accessed through a single frontend that provides the worst of both worlds.
I don't think that is remotely the case.
Text is highlighted on the page based on the code order, not as it appears on-screen (at least in Firefox and Chrome). If you throw elements off-screen with some CSS, you can create a big disparity between what the user thinks they are selecting and what they get when they copy/paste.
e.g: https://jsfiddle.net/Lbc5gsjm/
Not quite as neat as you can't put it dynamically around exactly what you select, but my favourite example of where you could get pretty malicious with it is a “plain text” link that injects a suffix to the hostname when you copy it.
It’s awkward how easily one can break a basic functionality like select & copy.
Combine a few of those techniques with a fancy-looking text box that you are supposed to "click to copy" to get a command, and it becomes pretty easy to even write css-only "exploits" to put stuff in the clipboard!
What is infuriating is CSS that prevents text selection in the first place. That insult to usability should have never been adopted by browsers.
As a web developer, it's kind of funny seeing people exclaim "this feature should not exist" after seeing a few abuses of it, even though they probably benefit from it every day without realizing it. Overriding copying is needed for wysiwyg editors and selection blocking is needed for many kinds of drag&drop interfaces and also editors.
Instead of complaining that useful features exist because they can be misused, maybe complain about the misuse itself - maybe even to the people actually misusing them. Shoot them an email and they might actually do something about it. Most of these misuses hurt accessibility (screen readers, etc.), so if nothing else, they'll see it as a way to reach more customers.
It's useful for things like rich-text editors (e.g. google docs), where the text is never on screen as text that you are able to copy in the first place.
I don't know whether that's planned to stick around or whether it was added when the clipboard event support was still experimental and will be removed at some point. But I suspect the former, for precisely the reasons in this thread.
Note that disabling these events will likely break "smart" copy/paste in things like Google Sheets, which is one reason it's not disabled by default....
document.addEventListener('copy',
function(e){ e.stopImmediatePropagation() }
);> Ironically, a little reverse searching reveals that this code was copied verbatim without attribution from this StackOverflow post (see “Manipulating the selection” from the top answer). Maybe copy/paste isn’t so bad?
The segment I copied was just long enough that it overflowed my chat window so I had no idea the insertion was even there and I sent it as-is.
The recipient called me about two minutes later and said "hey, I think you've been hacked - you just sent me a CBD oil advertisement."
So yeah, I'd love to see user agents address this. If I push a copy button (like github's clone repo button) then fine, I'm at the mercy of their javascript. But if I copy via ctrl-C or a right click menu, it should not not let the page interfere.
This highlights the tension between the document-web and the app-web. What if the page is an image editor, word processor, spreadsheet? These app-web pages need custom logic for copy and paste. Unfortunately, bad actors (like what you found) ensure browsers cannot implement this stuff properly, because every feature is now a way to shove a new ad in.
This is a huge factor in debates about things like the merits of CSS-in-JS, or the tradeoffs in "JAMstack" architecture. Pick any polarizing facet of web development and odds are you'll find this tension at the heart of the opposing perspectives.
So these features are here to stay.
^ not gonna happen for most platforms, as it’s walled gardens all the way down, but hopefully some day it will become obvious that adcrap tech stack is a wrong foundation to make computers and their economy.
Use Firefox, go to reader mode, copy/pasta whatever you want without worries
https://moz.com/ugc/copymagicpaste-a-script-and-easytousegui...
Anecdotally speaking, I’ve seen it a lot less these days; mostly, I see it when copy-pasting from my Kindle app. I’ve rarely ever seen it for a site this general-purpose (and trivial) though
You know what would prevent a negative user experience? Not adding things to my clipboard that I don't want. (Thankfully, that site didn't seem to.)
If telling people not to do this was going to be enough to solve the problem, we wouldn’t still be talking about it. The browser vendors really need to shut it off once and for all.
The thing that annoyed me recently is that if I cut & paste a single character in Google Mail, it'll "helpfully" surround it with spaces when pasted. Other applications like Firefox or MS Word don't have this behaviour.
I just tested it, and the GMail behaviour is wonderfully inconsistent:
Copying from GMail to to plain text (e.g.: a text editor) will result in a single character.
Copying from plain text into GMail will result in no superfluous spaces.
Copying from GMail to GMail or to any "rich text" editor will add the extra spaces.
So basically I'm copying plain-text, but GMail is abusing rich-text formatting to add "magic" behaviour someone at Google assumed is beneficial, but is just confusing and arbitrary.
PS: Similarly, GMail's spell checker now "fights" with the Firefox spellchecker and the result is that neither wins and obvious typos aren't resolved unless I turn checking off and back on a couple of times.
I'm wondering if some of these issues could be resolved with some solid industry standards.
Let me save you some time in the future. You did not identify the OS and language/script you have trouble with, so my answer has to be kinda generic.
First have a look whether your OS keyboard settings or a third party provides an en_US-101 compatible logical layout that adds more accented characters (typically accessed with right Alt¹) or extra modifier keys² (in addition to acute, grave, tilde), then install it and memorise the characters you need. Oftentimes, this is easy because it's mnemonic, e.g.
AltGr+l → ł
AltGr+d → ð
AltGr+o → ø
dead_tilde N → Ñ
dead_double_acute o → ő
dead_circumflex dead_hook O → Ổ
compose U G → Ğ
compose " y → ÿ
compose a e → æ
compose t , → ț
compose v z → ž
compose I . → İ
compose u o → ů
compose c | → ¢
compose . . → …
(FWIW I use the compose key! Just not those particular characters, my set is incidentally consistent :-))
The modifiers' proper names are "ring above" and "breve".
Have you encountered any unintended consequences from disabling this?
Eg if you select text in Slack that has emojis or formatting, it tries to put plain-text into the clipboard that would produce said emojis and formatting when pasted back into Slack. This is great, and every chat app does does formatted stuff should do this.
I'd hate it if browser vendors would attempt to block this and as a result, break that kind of functionality too.
Is it great that Slack also has its own autocorrect and doesn’t know about the system autocorrect?
How would you let text input with emojis and formatting and code blocks be "handled by the system"? I agree that on most platforms, emojis are a solved problem (although the UX could be better), but the rest isn't.
Sure, like all chat apps, what Slack does is a workaround around system limitations. But the limitations are there, and they need the "copy" event to make their hack work end to end.
But this won't allow you to have a consistent emoji across platforms, neither do server-specific emoji. Besides, I found typing :emojiname: is much easier than finding emoji in emoji keyboard.
I should be able to decide if I want to allow apps to mess with my clipboard, and the default should be "no".
A stock Apple application "Books" does something similar as well. When copying text -- using keyboard shortcut or the context menu rendered as soon as you lift your mouse (another tragedy) -- your clipboard will look something like the following (2 lines):
“<what you actually wanted to copy>”
Excerpt From: <Author>. “<Title>.” Apple Books.
That gets written to your clipboard; quotes and everything.
Using org mode now, and there's probably a way to do it with emacs lisp, but... I'll never get around to it.
This mostly gets used for scenarios where you're pasting into notepad vs into word - the latter will get rich text if it requests it, while the former is just going to request plain text and get it. When copying text or images or HTML out of typical apps, the clipboard actually ends up having 6 or more different formats in it that all represent the same source content.
The 'generate on demand' means that it's theoretically possible to sync clipboard operations over the network transparently for stuff like Synergy, which is pretty cool - no need to copy that big bitmap over unless software on the other machine actually asks for it. I had some custom clipboard sync software I wrote that did this automatically (with a progress indicator for big data like desktop screenshots) in a couple thousand lines of C# and it was pretty satisfying to use.
If I had to guess I'd assume either X11 invented it, or a research lab prototype had it and X11 copied that then was copied by every modern OS
No user ever has ever wanted that.
So what lawyers, where, ever demanded it, and why? Short snippets fall under fair use anyways... and even if it didn't such a message doesn't prevent anything (you just delete it after pasting)... and it you were oblivious to how copyrights worked before, this isn't going to teach you.
So it's UX annoyance but why? Not only does it not provide an obvious legal benefit to any party, I don't even see how it's legally covering anyone's ass? Like, I know how under trademark law companies have to warn people against using their trademark generically or else they can lose it -- so as dumb as it is to get an e-mail from Adobe asking you not to use "Photoshop" as a verb in your press release, I get it. But copyright... doesn't work like that.
So how/why did this become a thing? I just don't understand the legal rationale here.
I am skeptical that this is a copyright issue that raised an attorney's attention. It's far more likely IMO that this was a contractual obligation imposed by the publisher.
I have no insider knowledge as to whether this is actually true, but it's quite probable that in exchange for allowing Apple Books to republish their content, the publisher required Apple to append this attribution when copying content into the clipboard. In theory, preserving such an attribution might cause more copies to be sold.
Also, contrary to your assertion, not every short snippet qualifies for a Fair Use defense; there's a four-factor test that courts apply, and the length is just one of those factors. But again, I think this less to do with copyright and more to do with a business arrangement.
I don't either, with the added bonus of a complete lack of legal training but this clipboard thing has been a part of commercial e-reader apps for so long, if your (very plausible-sounding) theory is right, it's been boilerplate in such contracts for many years.
1. Make sure many people who shared content from your site would link back to the source
2. Track shares where the full link to the page wasn't copied
3. Trick scrapers/careless plagiarists into linking back to the original source, using their own carelessness to get an extra backlink or two (and tell Google your site was the original).
All of these obviously only worked on people that didn't check what they were copying, but hey, those were some of the reasons behind it.
Does this mean that any currently running app (or maybe not even currently running, perhaps there's an event system) can see my clipboard?
My feeling about this is unprintable.
I started planning a clipboard app that doesn't allow this but I'm busy and I'd prefer this wasn't something I need to fix in the first place.
To my mind, the whole point is to provide a way to move information within and between applications.
Similarly for private files: MacOS already alerts you when something tries to read from “~/Desktop” for the first time, why not allow users to extend that to “~/.ssh” and “~/.gpg” too?
The clipboard should act at an only at user direction to copy content from one application or context to another.
The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content.
Applications, other than when clearly and unambiguously directed by the user be able to access or read clipboard contents.
I'd suggest additionally that it should be possible to examine and edit within the clipboard context itself what was copied.
This creates a few obvious issues, one of which is that commandline and programmatic tools for interacting with the clipboard ... won't function as transparently as they do now. A fact which would affect me directly as I make heavy use of these (xclip in Linux, pbcopy / pbpaste in MacOS, termux-clipboard-set and termux-clipboard-get in Termux/Android). I think I'd be reasonably comfortable with a confirmation dialog appearing in such cases, or having those applications specifically exempted (convenient, though some risk).
The problem of programmatic interfaces to the clipboard is another matter, and those are ... probably a complex issue.
Note that when working entirely within the shell, the issue largely disappears as the inter-process commmunications method is largely pipelines, files, or the shell environment (variables) themselves. With some exceptions, such as gpm(8) (a cut-and-paste utility and mouse server for virtual consols, in Linux).
Though there's also behaviour of the X11/Xorg or Wayland clipboards.
This might feel intuitively right, but it severly limits the usefulness of the clipboard.
It then becomes a basic plain text clipboard
Try opening an rich text editor (e.g. https://quilljs.com/playground/) and selecting two words of which one is bold. Hit Ctrl+C. What is now on the clipboard? What happens when you paste? You have your formatting preserved. The editor has intercepted the copy command and stored data only it knows how to create and parse. The same would happen in a diagram editor (a selected shape would perhaps be stored as some json representation), or an image editor.
The problem is that the clipboard as an established concept already means "area where programs write their custom formatted data and where any app can read the same data upon paste".
Restricting it might be a good idea in some cases, but it's the user expectation so it's what apps (including browsers) need to do as the default. This unfortunately means that abusing it as in the article will be possible. There is no way for the browser to know whether the changed content was formatting tags (good) or trashing the selection by adding a copyright (bad).
That preserves the functionality, respects the "copy visibly-selected content" directive, and makes clear just what is being saved to the clipboard, making sneak attacks more difficult.
Argument that the clipboard behaves in a way that is demonstrably prone to malicious attack is simply argument from tradition. Yes, that's how things have been done. We're discovering that how things have been done leads to strongly negative consequences.
The displayed/selected content might be
Foo Bar
but the content I want on the clipboard could be
Foo <i>Bar</i>
but I never want to see the markup, only the formatted text. I don’t want to make a two step function where I need to reveal a textual description of the content and select that. The markup might be a base64 encoded piece of binary gibberish in the case of a visual diagram for example.
You cannot both have transparent copy capability and copy hidden content without revealing it.
Copying visual content would be subject to different requirements and limitations. But for text: what you see is what you get. If you're copying glyphs alone, those are what are copied. If you want formatting, you'll need to have the source application reveal that.
Here, data shown would probably be some info about the data rather than the data itself. It could be a 2mb base64 bitmap...
However, perhaps a better alternative would be to offer both "copy text" and "copy" where the former just copies selected glyphs as plaintext while copy fires the js event allowing the transform.
The important thing to remember is that webpages in 2020 must work like users expect desktop applications to work, and interact with desktop applications (e.g. copy rich content from webpage to desktop must be a default enabled feature or the user will consider the browser broken). For this reason, I don't think it's a viable solution to disable the js event by default (i.e. to hook Ctrl+C to the "copy text" function).
Because we're no longer operating in a world in which apps or processes are trusted or trustable. Maybe the ones you write, maybe if you're really lucky the ones that come with your fully-vetted Linux distro.
But not npm installs, not proprietary binaries, not website logic, and most especially not the crap that's distributed on mobile app stores.
Your OS, you've got to trust. Which means that the logic's in the clipboard.
And how can the clipboard know that the application is attempting to change contents such that the clipboard won't receive what it is that you see?
That's a key reason I see this as something that 1) has to be in the clipboard logic and 2) has to exclude applications entirely from the copy process. The clipboard should be acting on, say, the graphics render layer directly, outside the application's scope.
In general the application is the only thing that knows what is selected (e.g objects in a cad program) and the OS has no idea of how to serialize these into the clipboard.
Even a text editor has to tell the OS what is selected and the OS can only trust the app to tell the truth.
The only way to “verify it” is to show the copied content to the user (e.g in a notification after the copy). Obviously for anything but plaintext this verification doesn’t help (I can’t tell serialized cad objects from something else - it’s just gibberish). I can however verify that it’s not a script that will erase all my files when pasted into a shell (btw executing on paste is s a horrible behavior by a shell. Pasted data must be treated as untrusted and verified before acted on. Immediate shell execution breaks that).
There are some concepts -- and I very barely grasp this -- such as Display Postscript, not in present use AFAIU, which might offer such capabilities within the windowing system.
That is, with DPS the display itself would have awareness of both the underlying text and the formatting directives.
Whether that's even remotely similar to existing graphical systems, I've no idea.
Perhaps the clipboard contents are somehow tagged with their source so the destination can do something intelligent with its contents? This would potentially provide another way to lock down the clipboard: fishy photo filter can get access to an image on the clipboard (or maybe only images from certain sources), but not text.
How are you going to distinguish between user and programmatically-initated actions? Adding something like a “Secure Copy Key”, akin to control-alt-delete in Windows might work, but it’ll need kernel-level support.
Determining whether the clipboard contents faithfully represent the “visibly-selected” content is also very hard, possibly AI-hard. Suppose I copy an image while zoomed? What size should the clipboard contents be: the original size it’s apparent size?
One mitigation, if you’re worried about this now, might be to run certain programs as another user. I don’t think the clipboard is shared then.
That is a deep and fundamental problem within any mediate technology. It's not trivial.
The simple answer is "look for indications from standard user inputs". But those inputs (keyboard, mouse, touchscreen) are themselves sufficiently complex that they can be mimicked, intercepted, or spoofed. There is the problem of distinguishing legitimate from counterfeit confirmation dialogues (already a persistent attack vector for desktop and mobile device users). There is the problem of rogue devices communicating over USB or Bluetooth connections (an argument for a principle of minimum necessary capability for interface ports -- serial and PS/2 connectors have their justifications), though that usually entails other devices being silently added to a system. Though a USB device spoofing an additional keyboard or mouse is also a demonstrated attack.
All of which starts drifting focus away from the key point: what is an unambiguous expression of user intent, and how would you go about ensuring that this is determinable?
The determination of contents question gets to a somewhat different matter: what kind of data are being copied?
I'll admit that I was thinking of the case of text, though there is also image, and conceivably audio and video data.
For text, zoom is irrelevant as that's a display artefact and (at least as I envision it) the goal is to copy the text as displayed, independent of typographical formatting, rather than "glyphs of some size and presentation".
Multi-user clipboard access is dependent on the graphical environment. For X11/Xorg, applications regardless of effective userID, have access to the clipboard.
(X11 also had some early attempts at securing the clipboard, with varying degrees of success. Issues such as grabbing keyboard input, potentially silently, were also an early concern.)
Please do not give Apple ideas for a "App would like to access your clipboard" dialog.
On this key combination (default cmd+V), copy the data stored in this clipboard to the currently active app's own paste buffer, which will then handle inserting the data
vs
All apps can read and write to the clipboard at all times
World readable and writable files that often carry sensitive information sounds like a stupid idea to me.
echo "this is on the clipboard" | cat -
Note: As this was informative I hereby declare this a non-useless use of cat.
Dashes https://en.wikipedia.org/wiki/Dash
Diacritics https://en.wikipedia.org/wiki/Diacritic
Precomposed Latin characters https://en.wikipedia.org/wiki/List_of_precomposed_Latin_char...
Currency symbols https://en.wikipedia.org/wiki/Currency_symbol
Japanese typographic symbols https://en.wikipedia.org/wiki/List_of_Japanese_typographic_s...
etc.
So this: "em--dash" becomes this: "em—dash" while this: "en -- dash" becomes this: "en – dash"
⌥- = en dash
⇧⌥- = em dash
⇧ = shift
⌥ = option
- = hyphenWe have ¼, ½, and ¾, but not en (–) and em (—) dashes; and I get that (') and (") are leftovers from typewriters and ASCII, but wouldn't it be nice to have proper 6-9 (‘…’) and 66-99 (“…”) quotation marks?
Then again, you often see Europeans online misusing acute (´) and grave ( `) accents as apostrophes (writing don´t or don`t, instead of don't or don’t). So perhaps the availability of more similar looking keys would just lead to even more misuse?
[1]: https://upload.wikimedia.org/wikipedia/commons/2/22/KB_US-In...
Even I exercised more caution when I was 12 and learning HTML, arbitrarily applying copyright to things I didn't own.
You should enable bracketed paste mode in your shell. IMO it’s much better UX than a confirmation dialog.
https://i.stack.imgur.com/855az.png
Selecting "prompt" will result in this:
https://i.stack.imgur.com/jvDUh.png
I set it to Prompt for trusted sites, and Disabled for all others.
In this case, what I'd like as a user option is to be able to say "Don't copy via app-specific code", i.e. "don't run the js event to let the page populate the clipboard, instead inspect the selection and if there is a text selection then copy that as plaintext, else copy nothing".
An alternative "prompt when the app tries to subscribe to the copy event" could also work. If I select a shape in an online diagram editor and the app says "can I please put my app-specific markup on the clipboard" then I say yes, because I understand there is now way copy paste works otherwise. And on a page when I have text selected, I can say no, and I get the default plaintext copy.
Some apps have this as 2 different functions for a formatted copy/paste vs. raw text copy paste. If browsers had a "copy text" context menu item that copied the raw selection without invoking the js 'copy' event, that would work too.
Now, there are so many advertisers that use Tynt and related services to muck with copy/paste that it wouldn't surprise me if the major browsers are incentivized to leave this alone and let users suffer.
Clipboard access isn't guaranteed to be a dark pattern, though. It's an API that the browser supports.
I dislike clipboard access 99% of the time, but it's actually useful in a few UIs (like copying keys in AWS). Should it really be up to the browser to determine that an API is always a dark pattern?
Honestly, most of the worst dark patterns of the web are enabled by regular <div>, <button>, and <img> elements -- which is to say, they're not something the browser can unilaterally decide are "evil".
There are file management apps, graphic design apps (figma), etc., that use both the clipboard and the <c-c> / <c-p> binds to work. Neither blocking the bind of <c-c> events, nor of the clipboard are going to happen.
We all have different needs and different pains. Sure, around here, we care about user experience, privacy, performance and optimizations, but let's not forget that we're in a bubble. The regular less-powered users are just as important as us, and their needs may outweight ours.
I wish there was truly open browser that was not crap, there isn't. I wish better privacy controls were available out-of-the box. I wish there could be a feature matrix backed by a default profile so that I can only give access to the clipboard / other APIs manually, but with a prompt on access attempt. I wish so much.
If I don't like my job runner, or my window manager, or even my password manager, I can go ahead and try with at least moderate success to make my own. Browsers are made by large groups of competent (most of them) polyglots, that work countless hours, willing to drill through the shit that has accumulated over the years into what we call the web. I don't have what's required to make my own browser.
Using the web with free Javascript privileges is an utterly appalling experience. I can't stand it for more than 5 seconds.
My work has switched to iPhones, and I really miss NoScript when using Safari
I haven't found a way to do this in any of the Firefox versions available for Android.
My block list is mostly well known news sites.
It's not about copyright. As a website owner, you can disable this behavior, but by default, it was enabled. The main purpose of this functionality was to track shares(for example if you copy text and send it to your friend in skype). As i remember it was one of the most popular & important features in the whole toolkit.
In a nutshell, it's about 200 lines of battle-tested javascript-code that worked perfectly fine in almost any browser(dunno about now it was around 3 years ago).
Personally, i hate this behavior.
Sure, highly technical folk are capable of working around this all -- but the vast majority of people do not have a browser that is _working for them_:
- You have little to no control over what content you are seeing. Instead, it is chosen for you.
- A large number of videos (not even including movies and shows) are geographically blocked. You cannot access them.
- Developers are actively trying to prevent: Saving images[1][2][3], selecting text[4][5], browsing on a mobile phone[6][7], and a whole slew of other normal user actions I don't care to cite: preventing users from going back, manipulating their browser history, asking for notification and geolocation permissions, displaying full-screen modals that block content access, scroll-jacking, click-jacking, and more.
But don't worry! It's not all doom and gloom, websites like Reddit, Instagram, Facebook, banks, and more are heavily pushing their users away from the web to mobile applications where you have ZERO choice.
And we're going to maintain this backwards-compatible stack of completely volatile pieces of anti-patterns until that migration to "apps" is complete, and you can no longer distinguish between the app on your phone monitoring everything you do or the site running 5 different layers of VMs and doing the same -- albeit a bit slower.
[1] https://security.stackexchange.com/questions/122922/discoura...
[2] https://stackoverflow.com/questions/21110130/protect-image-d...
[3] https://stackoverflow.com/questions/35897974/how-to-prevent-...
[4] https://stackoverflow.com/questions/16805684/javascript-disa...
[5] https://stackoverflow.com/questions/8365272/disable-copying-...
[6] https://stackoverflow.com/questions/10177456/how-to-disable-...
[7] https://stackoverflow.com/questions/22618724/how-to-disable-...
There's an easy solution. Stop. Don't run JS by default.
Not sure how to approach it. JS whitelist is a stopgap solution, but not a particularly convenient one, and it doesn't always work.
- Just throw it and the baby away, problem solved
It seems to me that we should be directing our efforts towards better browser/OS design and/or more ethical business practices than in largely futile campaigns to make people give up functionality. I'm reminded of some local activists who campaign tirelessly with posters and graffiti to have people stop driving so as to reduce fossil fuel consumption; even though I agree with them and don't drive myself, just telling people to stop is not very helpful without addressing the question of how to solve the problems that people use vehicles for in the first place.
It's all so silly and doesn't increase site visits in any meaningful way.
Sidenote: I'm glad javascript in browsers is a lot more standard so you don't have to get stupidly hacky.
Ctrl+Alt+R
For an example of what I think wad good UX: In Windows, it used to be that pasting into a text editor would give you the original text while pasting into OneNote would magically give you the text with a link back to the source below.
I used to love that and for what I know it still works, I just don't use Windows and OneNote that much anymore.
Excerpt From: Bryan O’Sullivan,I occasionally find it convenient to select hostnames out of a URL in the address bar and paste them into a terminal. Chrome "helpfully" prepends noise to the text you actually copied ("scheme://"), which makes this a PITA.