How exactly would you block this behavior without getting rid of a substantial portion of web functionality, even around simple document styling?<p>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.<p>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).<p>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.<p>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.
This has been a "bug" for a long time with exactly the same behavior that is described here. Copy&paste from a news article or a blog and have something like "read more at <URL>" inserted.<p>It's also not Firefox-specific. Same behavior happens in Safari and Chrome.<p>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.
I find the reasons not to mitigate this in any way short-sighted.<p>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.<p>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.
Okay, I've read all the responses so far at time of writing.<p>Lots of technical solutions which would break the browser/site/web/whatever.<p>What I haven't seen is;<p>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?<p>A sort of intermediate step as it were.<p>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.<p>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.<p>So make the intermediate step mandatory.
A slightly more nuanced proposal:<p>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.<p>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.<p>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.<p>4. (Advanced) option to see what's in the proposed copy buffer.<p>(Obviously this all assumes that publishing sites have web security measures in place e.g. no raw HTML...)
One of the people active in the thread concludes that:<p>> 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.<p>I'd like to add that disabling JavaScript also seems like a sensible option, unless that prevents the site from rendering, of course.
Off topic: I've been wanting a:<p>'Exclude on this site,' 'Run on this site only' option for Firefox addons. A site Whitelist / Blacklist menu for all Firefox addons.<p>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).<p>This will be massive privacy help.
As someone who spent quite a while understanding the differences between innerText and textContent between different browsers and browser versions, I completely empathize with the POV that it's not just as simple as not letting someone copy what isn't "visible." It's really hard to define visibility of text in a simple straightforward way.
> <i>Note that this is a horrible security issue. The newlines cause the text to be immediately executed if I pasted it into a command line window.</i><p>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.
There are some extensions that help, e.g. <a href="https://github.com/aaronraimist/DontFuckWithPaste" rel="nofollow">https://github.com/aaronraimist/DontFuckWithPaste</a>. It just allows you to paste, IIRC, not copy, but if someone was really annoyed I guess they could make one for copying. And NoScript had some clickjacking protection, but it hasn't been ported to the WebExtension yet.<p>Typically though these are done with third-party scripts and just blocking the script is sufficient.<p>In this case it isn't so uBlock has a rule:
<a href="https://www.reddit.com/r/uBlockOrigin/comments/7l54xr/metro_copyjacking_filter/" rel="nofollow">https://www.reddit.com/r/uBlockOrigin/comments/7l54xr/metro_...</a>
Hasn't this been the expected behavior since the dawn of the web 2.0? Next he is going to complain that websites can have a hyperlink that says example.com but points to badexample.com! And worse yet, they can use js to hide their tracks! (ie, google search click redirects)
If there really are technical reasons not to change this behavior, then shaming sites that employ it to do bad things seems like a next-best solution.<p>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?
This is one of those cases where useful features for web applications (ie. custom copy & paste logic) enables dark UI patterns for the web in general. Neigh impossible to solve without breaking existing apps.
The challenge around issues like this, is that the informal separation between "trusted" and "untrusted" software used to be formalized (by coincidence) as a <i>technical</i> distinction: software you installed to your computer could do whatever it wanted, but you put more thought into whether or not to use it in the first place than you do when you click a link.<p>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.
changing this behavior will break many sites. slack, discourse, Gmail chat/Hangouts , Facebook messenger, and I'm guessing discord etc.<p>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.<p>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
1) Remember the selection when the selection is made, if content changes ignore until a re-selection is made or un-select when it changes.
2) for hidden content, when selected display a permission box
2.1) permission box states, "hidden content was selected but Chrome removed it, to allow hidden content to be selected for this website click allow " [Allow] [Ignore]
obviously it needs finessing but it seems possible?
I think a sensible ”solution” might be for OS vendors (usually not that different from browser vendors) to continuously monitor the clipboard just like anti-virus software is monitoring the file system for viruses. And block access (or condition it with hard warning modal) on pasting flagged text. Possibly allow pasting to same site without check.
I am glad to see this raised as a bug, even if the fix would be a huge breaking change. It highlights one of many ways that growth of complexity and API surface of the browser has become a serious security issue.<p>Maybe merging the concepts of a hypertext document layout system and an application platform wasn't a good idea.
I'd just like to point out that I find the reflex of "I don't like the comments here, so I lock the bug report down" rather misfortunate.<p>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).
I'd disable javascript on the offending website (not web apps, but blogs, news sites, or the likes) for anything JS related that causes annoyances, like popups or unsolicited modals or alerts.
The people most likely to be actually harmed by this are developers, right (i.e. pasting in to a terminal)? And shouldn’t we of all people understand that there isn’t much practical difference between opening a shady website, and running a shady executable binary? And if pasting straight into your terminal then there literally is no difference whatsoever.<p>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.<p>Scummy news site injecting social links in to copied text? That to me sounds like a people problem, not a software problem.
Attacking shell seems to be an exploit that could maybe affect 1 out 50 people. Attack the url bar with "javascript:" and you can have XSS attack on any site.