Websites can change content inside a selection
bugzilla.mozilla.org
bugzilla.mozilla.org
It's not a Javascript problem. To make it impossible, we'd need to get rid of invisible spans. Text overflow can't be hidden. This means you can't display extra text to screen readers, since that's invisible text. Also, non-system fonts are right out, because they can contain invisible characters, or even be remapped so that the wrong characters display.
The 'solutions' I'm seeing proposed on this issue are hacks. If this is a real problem, the real answer is to just make the clipboard visible when you copy, preferably on an OS level (since literally every format/platform that allows bundling custom fonts is vulnerable to this, including PDFs).
Prefer security solutions that are simple and universally understandable, rather than solutions that rely on adding a bunch of code to plug part of a hole. Doing real-time analysis to figure out whether text is visible doesn't fix the whole problem, and is highly error prone.
I think Mozilla is right to reject this. If you're coming up with hacks about per-domain character recognition that will end up behind some kind of permission prompt that users will click through without reading anyway... that's a sign you haven't thought hard enough about what the problem is. When something is written to the clipboard, just bring up a notification on-screen and show the user what they copied, and give them the option to inspect/edit it in more detail. The best thing is that's an OS-level mitigation, and not another weird, buggy implementation detail that makes it harder to build or inspect a web browser.
- The browser could do a better job of making sure a text selection only includes the expected content (this is not just a security issue - I often find that text copied from websites include unexpected words or whitespace).
- The browser could do a better job showing you what it is putting on your clipboard. For example, they could briefly overlay the text they copy on the selection, in a way that would be virtually unnoticeable when you copied the expected text, but reveals the difference if the content somehow changed.
- The system could do a better job showing users what the clipboard contains. The fact that clipboards are completely invisible in most OSes is kind of weird, and also has privacy implications, for example if you copy something sensitive on a public machine and forget to clear it.
- The system could implement a way to flag clipboard items as “untrusted”, and require apps to implement adequate checks if you paste something that can have security implications.
- When you paste into a terminal, it should probably give you a chance to see what you’re pasting before it tries to execute. After all, this is the place where the actual security problem happens.
> The browser could do a better job of making sure a text selection only includes the expected content (this is not just a security issue - I often find that text copied from websites include unexpected words or whitespace).
I disagree this is necessarily a good goal for the browser to have, or that it's feasible for the browser to identify what the "expected" text is. Even in the area of stripping extra whitespace, sometimes extra whitespace is expected.
It's worth noting that browsers already strip unnecessary whitespace like linebreaks and double spaces by default. The extra whitespace that shows up in text you copy is there because a site deliberately added characters or elements that bypass that behavior (I'm looking at you, Twitter, stop #!&%?@ breaking all your input fields).
So relying on signals from the page itself isn't enough to mitigate this problem, since pages give bad signals. The browser would need to be smart enough to know on its own when whitespace was being inserted because it was important, and when it was being inserted to add an extra linebreak or something.
I am skeptical that it's possible to build a browser that smart without simultaneously turning it into a buggy, unpredictable mess whenever you encounter edge-case content.
My mantra in situations like this is, "don't come up with a solution that is more complicated than the problem you are trying to solve." Most of the solutions I've heard proposed as to how the browser is going to accomplish this sound really complicated, at least to me.
It's kind of impossible in general on an OS level†, since clipboards (a.k.a. your OS's drag-and-drop system—clipboards just being asynchronous DnD-events) are a negotiated multi-format data transfer. Maybe everything you'd copy from a browser window is just HTML, but if you select e.g. an embedded Excel spreadsheet in a Word document and hit "copy", there's nothing comprehensible to the OS on the clipboard; and maybe nothing at all (until a particular drop-target responds to an accept-formats query.)
† Okay, it'd maybe be possible in AmigaOS, or any other similar OS (not that there are many) where all content encoding is inherently an OS job, not an application-layer job, such that the OS can see into every possible container format.
These do not need to contain the same thing, so the OS would need to preview all different formats and the user would have to manually inspect each of them.
No. It just needs to preview the one that would be used by the destination. You could pretty much model this like existing drag & drop APIs, where whether a certain object is acceptable for "dropping" is communicated even before the user releases the mouse.
In any case the OS doesn't need the application to tell it how to render the basic text representation.
This sounds quite cumbersome even for the techie.
The basic text representation isn't enough. Maybe the text representation is correct but the html one embeds some javascript? How are you going to render that?
Your web browser is an untrusted source? You might be confusing the browser for the sites it displays.
Browser vendors are unlikely to fight you trying to make copy & paste a better experience, they just lack ideas or a good solution that works across application/OS boundaries.
In any case the OS wouldn't need the web browser to tell it how to display the text representation.
Metro is a publisher, and so ideally should just serve content. But the web is ad-supported, and ordinary ads are non-economical (maybe?), so Metro is forced into the application space. The browser gives them an inch and they take a mile.
I wish browsers sliced along this line. You get to be an app or a document, not both. Documents give up control but can play in more sandboxes. Apple News does this, AMP is trying it but has other problems.
You can trivially execute this attack with CSS by adding invisible spans that will be copied, but not rendered, and pseudo-elements that will be rendered but won't be copied.
You can also trivially execute this attack by bundling a custom web font that contains invisible characters and swapped glyphs.
I don't know what Apple's writing format is for Apple News, but AMP at least does not block this attack. It's not necessarily even a web thing -- PDFs are vulnerable to this attack, because they allow embedding custom fonts.
Bingo. Thanks for your eloquence.
It's also not Firefox-specific. Same behavior happens in Safari and Chrome.
But yeah, it makes total sense to point this out that hijacking the clipboard is probably not a good idea and this might be a security issue.
Disabling the copying of invisible text will not mitigate all the instances. Disabling the modification via clipboard events won't either. Nor will disabling the ability to see user's selection.
But each of them would cut off a lot of offenders already (defense in depth-like), and each change in this direction would give credibility to the idea that the expected behaviour is to copy what's visible. With all of them implemented, it would become politically much more palatable to plug the last holes and let copy-paste behave 100% as users expect.
The issue is not that the clipboard can be modified. The issue is that users expect a clean copy when they copy from a website.
There are many valid uses for this, and there is not a strong enough argument that this presents a real security issue that would necessitate disabling such a widely-used feature.
As someone with a (healthy?) distrust of the content I copy/paste, and would never run code I copy/pasted without checking it first (one of the examples given in the linked bug report thread), I would still rather my browser only copy the text that I visibly highlighted. It is annoying to edit content out that I have carefully selected.
Absolutely. But how do we solve that problem and still allow proper usage of it? Removing this feature would break the copy ability of nearly every rich-text-like web-based UI in existence, such as Google Sheets.
Personally, this feels more like something for an adblock-like addon.
Why that is a hard question can be understood by reading through the discussions in the OP.
Skipping over the technical implementation issues, I'd rather copying rich-text-like be relegated to a "Copy Rich Content" context menu action, and the default copy command be plain text only.
I very seldom want to copy rich content. I very frequently am copy/pasting content to notepad, selecting it, and then copying it again in order to strip out the rich content I don't want.
But what is achievable immediately is being closer to user's expectations of what will be pasted in general, and a step-by-step approach gives benefits in this regard at every step, without making false promises.
What happens?
Do we not let Google modify what you just copied to inject the actual rich-text version of what you highlighted, as opposed to the presentation-formatted version you're seeing as a user in the editor UI?
What can actually be done if we allow the 'good actors' to continue working as needed?
could you not have a two tiered clipboard that is exposed via javascript for the webpage interactions(to solve the copy and paste issue with rich text inside google docs) but have the main paste system be synced with the system clipboard and that restricts the copy and paste to visible text/non-javascript hijackable(stops the manipulation of the clipboard to inject malicious code for terminals or even the annoying injection of "this snippet was copied from example.com/xyz")
I haven't thought too hard about the downsides to this or how hard it would be to implement but i'd be curious to see any discussion on some kind of approach like this.
What's clear to me is that the situation we have now is suboptimal, that coming up with a better solution will take up some time, and that incrementally fixing the current situaton completely will take enough time to find a better solution in the meantime.
Except I don't think we should ask the user, because everyone will blindly click yes. I think we should disable this by default, and let Google Docs, etc., remind the user via some in-app modal with step-by-step instructions.
If someone actually needs this functionality, let them do the work to unlock it for a given website.
99.99999% of the web has no good reason to be modifying a user's clipboard.
> The metro.co.uk code inserts an off-screen-positioned element with the disclaimer into the selection range, and you could just listen for selectionchange and/or mouse drag and/or keypress events to detect selection changes, and add/remove such an element based on those events.
Well, shit.
Never underestimate newspaper publishers' CMS vendors' ingenuity.
The solution is all of the above, and also don't paste stuff into your terminal from the internet.
Or at least use a shell or terminal that handles pasted newlines gracefully.
Each proposed fix breaks a substantial number of websites, and you're breaking tons of websites for something you know can be trivially bypassed from the get-go.
There's certain times/reasons to break a tons of sites. SameSite being one of them. Mandating Https across resources was another. This group of hacks that don't really fix the core issue, is definitely not one of those times.
If someone can legit fix it, it might be worth some breakage, but the fix has to be far better than the proposals here (and to be honest I don't think it is actually possible to fix, a simple font can undo any amount of work).
Which websites? Do you have specific examples?
If your website functionality is critically dependent on manipulating my clipboard in ways I can neither predict nor expect, then I'd argue your website is broken by design and should be burned to the ground and rebuilt from scratch.
The only legitimate use of this I can think of is a "click here to copy this text to your clipboard" type of button, and I'd hardly count that as a critical feature (hell, more often than not it just gets in the way).
The link contains specific examples. But Microsoft's entire suite of Office 365 online applications is another example.
> critically dependent on manipulating my clipboard
They're manipulating their own content before populating your clipboard request. There's a stark difference. If you turn off the clipboard interception (there's several extensions that do just that) you'll often get garbage out instead (e.g. raw HTML, gibberish, etc).
But don't take my word for this, install one of those extensions and never opt out of any sites. You'll get roughly the experience you're asking for, including the broken ones.
One of the proposed fixes (only copy visible text) would fix this, not cause it to spontaneously happen.
Not that it should be happening in the first place. If your site is abusing HTML to such a degree that the browser can't figure out on its own whether or not some text should be included when copying to the clipboard, and that you therefore feel the need to pull some insane switcheroo to get the "right" data into the clipboard, then that is the exact sort of site that ought to be burned to the ground and redesigned from scratch per my previous comment. That strongly indicates an extraordinarily-broken design.
And yes, Google Docs and Office 365 would be included in that category of "burn it to the ground, salt the earth upon which it stood, and rethink its design in its entirety" if they were really that defectively-designed. Thankfully...
> But don't take my word for this, install one of those extensions and never opt out of any sites.
I already have (or more precisely: I set "dom.event.clipboardevents.enabled" to false in Firefox's about:config page), and just tried copying and pasting in Office 365. Word works without any issue whatsoever (except for a loss of formatting). Excel won't let me copy and paste cells, but if I double-click into a cell, copy the text, double-click into another cell, and paste, I get the same text (with default formatting). Similar deal for PowerPoint; it won't let me copy the text boxes themselves, but I can copy the text inside them and paste that text elsewhere.
If I were to fix O365 in this scenario, I'd probably opt to use JS to detect the CTRL-C and CTRL-V keystrokes and maintain an application-specific internal clipboard specifically for these rich objects (cells in Excel, text boxes in PowerPoint, etc.); they're unlikely to be wanted outside of those applications, so no need to put anything in the real clipboard (besides what the browser thinks should go in it by default, if anything). The only thing that'd still be broken is any kind of text fallback (if one even exists).
The don't allow changes to selection would mean if you mark something on a website and use a button to change it (change to a link for example) you can't do that anymore.
The proposed fix would be either easily circumvented or/and would mean a high risk of breaking working sites.
If you read the bug section the last comment explains why the proposed fixe are a bad idea.
It wouldn't be harder to circumvent if changing the text (including the visibility thereof) between the start and end of the selection caused an automatic deselection. It shouldn't break any sites, either, unless those sites are doing fishy things or are already poorly designed (which - again - would warrant the torches and salt).
That would mean the following would not work:
selecting text-->making it bold(via button)-->making it underlined(via button)-->making it to a link(via button).
There are valid use cases for selections and manipulations.
I think the only way to work against such a thing would be to display the selected text in a tooltip like window, like another user described.
None of those things affect visibility, though, nor do they change the actual content (just the styling/appearance), so the "deselect on visibility or content change" approach wouldn't impact that at all anyway.
Lots of technical solutions which would break the browser/site/web/whatever.
What I haven't seen is;
Why not, on highlighting text to copy, a small window pops up in one of the corners of the browser, and whatever text would be copied to the clipboard, is instead bunged into this window?
A sort of intermediate step as it were.
Then if you're satisfied that the content is what you want, hit some 'really copy to clipboard' button. The window goes away, the text is copied to clipboard.
A built-in text window. Because most people who use browsers aren;t going to go to the bother of copying and pasting into a text editor (Notepad, Kwrite, whatever) to vet the contents before pasting it wherever.
So make the intermediate step mandatory.
But also, I suspect users would find this annoying and treat it as broken.
I don't think users would treat it as annoying - not if there was a terse explanation in the popup box, and there could always be an option to disable it (rather than make it mandatory) for those users too impatient to use it and would rather take the risk of pasting altered content into a CLI window ;)
It's not like adding something like an intermediate stage like that would take an enormous amount of work - and the feedback would be more valuable than thinking "oh they won't like it".
Stubbornness doesn't play any part in my work.
1. Detect the first time a site (domain? URL?) attempts to copy something that's not visible. Algorithm TBD but we can start by warning too frequently.
2. Ask the user if this is a trusted site and deny, allow once, allow always. Users presumably select allow-always for apps like Google sheets.
3. (advanced) detect if enough people over long enough time select allow-always and then allow users to go with the herd. I'm talking 10+mm users not 10k, i.e. hard to cheat.
4. (Advanced) option to see what's in the proposed copy buffer.
(Obviously this all assumes that publishing sites have web security measures in place e.g. no raw HTML...)
2. What are we asking the user? Permission to copy from the website?
3. So we are adding a new 'permission' that users must accept to... copy from the website? And that trustworthiness is based on how many other people click 'allow' on a permissions popup?
4. You mean displaying what you just copied to the user, on copy? So the browser would give you a popup with the content of what you copied every time you copy anything?
I'm failing to see how any of your proposals solve the problems mentioned and discussed in the OP.
(4) To show a dialog showing the actual copied content if the content does not match the rendered visible content of the selection.
(4) is better but it would have to be every single time, because (2) is impossible to define.
It's like spam: a precise closed-form analytical definition is impossible, but spam filters do work.
Browser vendors could hypothetically start adding specific types of exceptions to make certain types of the 'hidden box' trick not work, but that would ultimately mean those website developers simply switch to whatever method works. The problem isn't solved, it's just re-coded.
TLDR: There is NO SOLUTION, because there is NO PROBLEM. The feature works as intended, as written in the spec.
(I say this as a matter of how you express such things, not about this particular case. I agree with you in considering there to be no bug here, but rather that this is a serious feature that shouldn’t be messed with—and pretty fundamentally can’t without unravelling substantial foundations of the web platform.)
I'm in favor of two-tier system where rich applications require permission for enhanced clipboard events but the average site will just copy what is selected without modification.
It's nowhere close to a solved problem, and is much more complex than this. Give a read through the comments in the OP for a taste of why.
Maybe there are deep reasons why it's impossible, but they are not well presented in the OP, unfortunately.
I suspect that for the great majority of practical cases, it is possible.
Where a definite answer is too hard to achieve, it's safe to err on the side of "not visible".
The bad guys aren't going to be using the great majority of practical cases.
The key principle of security is to deny all, allow a closed subset. Same here: allow what is obviously clear and has no hidden parts, and ask a confirmation for all the rest, legitimate or not.
> The right approach if you're worried about these vectors is: never paste things off internet sites you don't trust directly into your terminal.
I'd like to add that disabling JavaScript also seems like a sensible option, unless that prevents the site from rendering, of course.
This post shows that it is possible to put unwanted text in your c&p buffer without using JS: http://thejh.net/misc/website-terminal-copy-paste
That being said, yes, stripping CSS, fonts, and Javascript would fix the issue.
'Exclude on this site,' 'Run on this site only' option for Firefox addons. A site Whitelist / Blacklist menu for all Firefox addons.
It should be accessible from the toolbar, so I can click to restrict / allow the current domain without needing to type (that's for the extension details page).
This will be massive privacy help.
Modern terminals & shells guard against this. Modern *nix terminals emit special "paste bracketing" codes around the pasted text, which the shell can use to turn off handling of newline (such that you just get a multiline input instead of executing text). I don't know about Windows but I would hope Windows terminals have similar capabilities.
Typically though these are done with third-party scripts and just blocking the script is sufficient.
In this case it isn't so uBlock has a rule: https://www.reddit.com/r/uBlockOrigin/comments/7l54xr/metro_...
Expected for cheese-brained marketers who love to slap garbage into my selections. Certainly not expected when I'm trying to discuss an article in slack and comment on excerpts.
People should complain about it. People should complain about clipboard hijacking, hyperlink hijacking and all the other unacceptable breaches of trust that web masters perpetrate. Web developers were given powerful tools and instead of using them responsibly they chose to abuse them. So they shouldn't have access to them anymore.
These issues need to be fixed client side just like ads were. We need to remind these people who owns the machine.
Perhaps a browser extension that maintains a list of offenders and alerts the user that the site injects bad things (including marketing and promotional stuff) into copied text?
Now that those cases are combined into a single technical platform, it's difficult to tease them back apart when it comes to level of trust.
Most chat sites seem to want their own emoji. Gmail replaces emoji with Google's. Discourse claims to do it to make it consistent across devices and they got angry when I asked for an option to disable the conversion and just leave things plain text.
In order for all of these to work they have to let you select your chat messages with their embedded images and then convert that back to utf8 if you copy
How will it break any of those sites?
If you mean that it won't copy-and-paste formatting, which is encoded in a mark-down like syntax, then that's true - but most of the time when I copy something on a website, the formatting there rarely makes it through to another application (like any of the ones you mentioned) anyway, and most of the time when it _does_ survive the journey, I silently curse and try to remember what the "paste without formatting" hotkey is.
text <img src="happy.png"> text
text (@) text
same for vscode/Monaco where the editor adds a clickable color box for css colors.
In any case, I would gladly give up the ability to copy-and-paste an emoji if it meant never again seeing a long line trying to link me to some website just because I had the audacity to copy three words from a news article.
Okay, add an opt-in?
Letting the selection get hijacked on the way to the system clipboard silently is bogus.
Maybe merging the concepts of a hypertext document layout system and an application platform wasn't a good idea.
On the same note, I like to see how the discussions here look like a good distributed brainstorming session instead (ignoring a couple of naysayers).
Aside from shady websites, the other main attack vector would be, e.g., a XSS vulnerability on Stack Overflow. And browser vendors do seem to take XSS very seriously, and there are a number of ways to mitigate those.
Scummy news site injecting social links in to copied text? That to me sounds like a people problem, not a software problem.
But there is a big difference. This is almost the entire point of a browser, a secure way of viewing data from outside our control?
He also whined on his blog that saying "it's what expected abd that's how it works on every browser" is bullshit, Firefox was the 1st browser that e.g. implemented popup blocker, which obviously breaks the "expected" functionality of window.open; or blocking 3rd party cookie also isn't according to the spec of how cookies work.
QUOTE
I try not to make fun of people for admitting they don't know things. Because for each thing "everyone knows by the time they're adults, every day there are, on average, 10,000 people in the US hearing about it for the first time.
Fraction who have heard of it at birth = 0%
Fraction who have heard of it by 30 ~= 100%
US birth rate ~= 4,000,000 year
Number hearing about it for the first time ~= 10,000 day
If I make fun of people, I train them not to tell me when they have those moments. And I miss out on the fun.
Person #1, about to have a messy fun time: "Diet coke and mentos thing"? What's that?
Person #2, in a delightfully pro-knowledge mood: Oh man! come on, we're going to the grocery store.
Person #1: Why?
Person #2: You're one of today's lucky 10,000.
{{Title text: Saying 'what kind of an idiot doesn't know about the Yellowstone supervolcano' is so much more boring than telling someone about the Yellowstone supervolcano for the first time.}}