Websites can change content inside a selection(bugzilla.mozilla.org)
bugzilla.mozilla.org
Websites can change content inside a selection
https://bugzilla.mozilla.org/show_bug.cgi?id=1591698
30 comments
> just make the clipboard visible when you copy, preferably on an OS level
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.
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.
The source would know how to render it and could provide the OS with some kind representation when asked (basically drawing the contents of the preview window).
The clipboard contains multiple formats. So if you paste a couple of excel cells in another sheet you get what you expect. But if you paste it into notepad you get a text representation.
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.
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.
> 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.
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.
You don't know that until you paste, which might be a while after the copy and you also don't have the source available anymore in case it shows up weird, or you don't remember exactly what it was, or have it to compare to.
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?
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?
The suggestion to have the OS responsible for rendering is precisely to deal with the case of an untrusted source, Asking that source to tell you 'what did you really put on the clipboard?' is not going to get you a better answer.
> The suggestion to have the OS responsible for rendering is precisely to deal with the case of an untrusted source
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.
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.
This highlights the tension between the web as publishing vs an application platform. Publishers do not need programmatic clipboard access, but applications do.
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.
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.
The problem isn't Javascript in this case.
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.
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.
> "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. "
Bingo. Thanks for your eloquence.
Bingo. Thanks for your eloquence.
There’s a lot of steps that are failing to produce this problem:
- 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).
- 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.
I agree with the majority of this. However:
> 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.
> 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.
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.
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.
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.
I find the reasons not to mitigate this in any way short-sighted.
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.
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.
I think your suggestion would actually make things worse, because it would cause more people to have a false sense of security when copying from a web browser, which is exactly the problem in the first place.
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.
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.
I respect and share your goal to educate users about what they should expect from their browser/computer security-wise.
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.
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.
>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.
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.
> Removing this feature would break the copy ability of nearly every rich-text-like web-based UI in existence, such as Google Sheets.
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.
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.
The 10 sites that have a genuine reason to listen to selection events and force you to copy invisible text can ask permission to do so, as suggested in the thread.
That still does not answer the question of "what are we asking permission for?"
Why that is a hard question can be understood by reading through the discussions in the OP.
Why that is a hard question can be understood by reading through the discussions in the OP.
I don't think security is the only factor here. Security is only achieved when 100% of the holes are plugged, which is indeed not achievable outright.
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.
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.
Ok. So you're editing a sheet on google docs, you highlight part of it to copy into another doc. You hit ctrl+c.
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?
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?
[deleted]
Let's handle this like we handle things like location tracking, notifications, etc: ask the user.
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.
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.
I encourage you to read through the OP first on why your suggestion (remove copy-modification entirely) is not reasonable.
Ah:
> 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.
> 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.
My favorite scummy thing done to mess with browsers is to insert a noscript meta refresh redirect just to catch anyone who refuses to run the JavaScript adware embedded in their crappy local news website CMS. It must be standard in some local newspaper CMS and I've only ever seen it used on that sort of site.
Never underestimate newspaper publishers' CMS vendors' ingenuity.
Never underestimate newspaper publishers' CMS vendors' ingenuity.
Idon't know what the "correct" solution for that could be. I can come up with some half-baked ideas, like whitelisting, web-app bifurcation (we have reader mode, why not app mode?), or allowing for some amount of modification if clipboard events are enabled.
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.
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.
> 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?
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.
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.
Isn't this just a rehash of the "people ride their bicycle more dangerously when they're wearing helmets" argument?
The solution is all of the above, and also don't paste stuff into your terminal from the internet.
The solution is all of the above, and also don't paste stuff into your terminal from the internet.
[deleted]
I'd agree with you if the proposed fixes were "freebies." But they're not, far from it.
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).
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).
> 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.
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).
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).
> Which websites? Do you have specific examples?
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.
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.
> 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).
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).
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 only copy visible fix was afaik reject in the bug tracker because you could switch the visibility on and off for a short time (<1s).
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.
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.
> The proposed fix would be either easily circumvented or/and would mean a high risk of breaking working sites.
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).
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).
Sorry for the late reply.
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.
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.
The web app could maintain its own start and end points for the selection (independent of what the browser deems "selected") and apply those operations to the text within that internally-defined range.
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.
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.
Okay, I've read all the responses so far at time of writing.
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.
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.
I would love this. Similarly, I often use the URL bar as a sort of pivot point before pasting some bash command into my shell. It would be nice to have some kind of intermediate scratch pad that is a temporary-unless-touched kind of element, like what happens when you take a screenshot on macOS.
Same! I always wondered if I was the only one. It's a great way to sanitize text, especially when pasting into Powerpoint or Excel. Especially Excel because once you paste something, that formatting does not go away with Ctrl-Z (relevant comic https://i.imgur.com/pwXryVe.png)
Only don't make them dissapear after 3 seconds...
For one thing, clipboard contents aren't necessarily plain text.
But also, I suspect users would find this annoying and treat it as broken.
But also, I suspect users would find this annoying and treat it as broken.
I was thinking to include a sentence on that particular point, but thought it was obvious that non-text copy-to-clipboard (I have copied images straight from the browser to the clipboard quite often for example) would be handled differently, as image data should be distinguishable from text data.
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 ;)
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 ;)
In my experience as a browser developer, you're overly optimistic about what users will put up with.
As a developer with decades of experience in designing GUI's, who always acts on feedback from end users of what I have produced, I think you're overly pessimistic about this suggested feature, and should at least try it, rather than dismissing it offhand without doing so.
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".
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".
Maybe, just maybe, the people who work on Web browsers and have lots of experience shipping UI to that particular audience, are right to trust their intuitions more than yours about which experiments are worth carrying out.
Rather than rely on intuitions, I take the time to try things out on people and keep, alter or discard, depending on reactions.
Stubbornness doesn't play any part in my work.
Stubbornness doesn't play any part in my work.
Or just display the copied text. If it isn’t the thing you want, don’t paste it or paste it into a text editor to edit it.
A slightly more nuanced proposal:
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...)
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...)
You can't start by "warning too frequently". When you warn too frequently, users quickly learn to dismiss your warnings without reading them (and this effect spills over to your other kinds of warnings, and even other applications :-( ).
1. As mentioned in the OP, there are numerous ways to add content to a copy event, and 'not visible' is not a 'real thing' - see discussion in the OP
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.
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.
(2) A permission to copy something not rendered in the selection.
(4) To show a dialog showing the actual copied content if the content does not match the rendered visible content of the selection.
(4) To show a dialog showing the actual copied content if the content does not match the rendered visible content of the selection.
(2) is undefined. What defines "rendered in the selection?" Which clipboard data stream are we even discussing? How far are you going to take the rendered analogy? Is font too small to read, white on white, an invisible font, or similar "rendered?"
(4) is better but it would have to be every single time, because (2) is impossible to define.
(4) is better but it would have to be every single time, because (2) is impossible to define.
(2) is possible to define in practical terms, that is, with a small amount of false positives, and very close to zero amount of false negatives.
It's like spam: a precise closed-form analytical definition is impossible, but spam filters do work.
It's like spam: a precise closed-form analytical definition is impossible, but spam filters do work.
It's absolutely not a reasonable thing to define and target. The bottom line is the feature is a FEATURE and will continue to exist, so trying to police how far websites take it is ultimately a non-starter.
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.
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.
Be careful: just because a feature is working as intended and specified, doesn’t mean that there’s no problem. The spec can be just bad.
(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 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.)
Think about the reasons why e.g. CORS was invented and implemented, despite XHR requests across domains being a perfectly working feature.
Both of your answers assume there is a simple and easy way to identify what is "visible on screen" - which if you read through the OP, you will understand that is not an achievable concept.
The browser literally highlights the selection so that seems like a solved problem.
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.
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.
>The browser literally highlights the selection so that seems like a solved problem.
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.
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.
I did; it sounded mostly hand-wavy.
Maybe there are deep reasons why it's impossible, but they are not well presented in the OP, unfortunately.
Maybe there are deep reasons why it's impossible, but they are not well presented in the OP, unfortunately.
Within a browser, which basically knows where each pixel is rendered?
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".
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".
> I suspect that for the great majority of practical cases, it is possible.
The bad guys aren't going to be using the great majority of practical cases.
The bad guys aren't going to be using the great majority of practical cases.
My idea is that the minority will be false negatives.
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 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.
One of the people active in the thread concludes that:
> 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.
> 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.
Disabling JS doesn't help in this case.
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
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
Leading that page in Firefox reader mode seems harmless enough...
Remembering to click a button that strips the fonts/CSS out every page I read seems a lot harder to me than remembering to always paste into a blank document before my terminal. Reader mode isn't even available for every site.
That being said, yes, stripping CSS, fonts, and Javascript would fix the issue.
That being said, yes, stripping CSS, fonts, and Javascript would fix the issue.
You would also have to disable images, because they could hide text in the alt attribute. (The reader mode doesn't to it for you.)
Off topic: I've been wanting a:
'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.
'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.
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.
> 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.
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.
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.
Hmm I'm concerned that zsh doesn't seem to do this by default.
/bin/zsh (version 5.3) in Terminal.app on macOS 10.14.6 does.
There are some extensions that help, e.g. https://github.com/aaronraimist/DontFuckWithPaste. 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.
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_...
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_...
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)
I think that protecting against this sort of thing would be helpful: identify hyperlink text that looks like a URL and compare it with the actual link. If they differ, pop up a warning.
> Hasn't this been the expected behavior since the dawn of the web 2.0?
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.
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.
No, this is not the expected behavior. When people copy a selection, they intend to paste it somewhere else. They expect to paste exactly what they copied, no more and no less. Whether they trust a website or not should not even be a factor.
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.
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.
A grantable permission would be nice. "This site would like to modify your clipboard"
As mentioned in many other comments, both here and in the link, sites don't need to modify your clipboard to exploit this behavior. They can insert invisible text inside the highlighted area when you select text, before you've even hit Copy, and this hidden text will be copied.
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.
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?
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 technical 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.
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.
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.
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
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
> changing this behavior will break many sites. slack, discourse, Gmail chat/Hangouts , Facebook messenger, and I'm guessing discord etc.
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.
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.
since HN doesn't allow emoji I can't post an example. without this feature what you copy in slack would be
same for vscode/Monaco where the editor adds a clickable color box for css colors.
text <img src="happy.png"> text
text (@) text
same for vscode/Monaco where the editor adds a clickable color box for css colors.
It'd be nice if browsers would copy an image's alt-attribute if you tried to copy some text that included an image; that would solve the problem.
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.
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.
> changing this behavior will break many sites.
Okay, add an opt-in?
Letting the selection get hijacked on the way to the system clipboard silently is bogus.
Okay, add an opt-in?
Letting the selection get hijacked on the way to the system clipboard silently is bogus.
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.
[deleted]
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.
Maybe merging the concepts of a hypertext document layout system and an application platform wasn't a good idea.
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.
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).
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).
Not important though but the reporter says that they used ctrl+v to copy. Is that right or a typo ?
Likely a typo.
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.
This can be done entirely with CSS or even HTML. Disabling JS only mitigates this, it isn't a solution.
How can a page modify the selection without JS?
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.
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.
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.
> 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?
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?
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?
It is still vastly different to paste a command you can inspect visually when copying than an unknown command injected imperceptibly.
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.
When such fooling around happens, you can select, then do "view selection source", then when source opens, already copy with Ctrl+C.
An alert that you did not copy what you think you copied would not be out of place in my opinion.
An OS window that flashes to show you what you just put in the clipboard would make life easier. Or a keyboard shortcut to show that content. Besides, it seems like the clipboard could use a redesign, the OS default has always been a stack of 1, unless you install a 3rd party tool to manage it.
Wait till people find out what Facebook does with the device clipboard.
IvanK_net(9)
Why is this being posted? This "issue" has existed for a long, long time, and it is not specific to any single browser.
The bug poster is a well known German tech blogger (blog.fefe.de , in German), so maybe that's why it's gained traction.
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.
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.
"Ten Thousand" https://xkcd.com/1053/
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.}}
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.}}
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.