5 ms·

How exactly would you block this behavior without getting rid of a substantial portion of web functionality, even around simple document styling? It's not a Ja

How exactly would you block this behavior without getting rid of a substantial portion of web functionality, even around simple document styling? 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.

tobr 7y ago
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.
- danShumway 7y ago
  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.
derefr 7y ago
> 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.
- chmod775 7y ago
  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).
  - jameshart 7y ago
    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.
    - chmod775 7y ago
      > 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.
  - tjoff 7y ago
    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.
millstone 7y ago
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.
- danShumway 7y ago
  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.
- skunkpocalypse 7y ago
  > This highlights the tension between the web as publishing vs an application platform. It also highlights the importance of acknowledging that tension. Notice how the app-app-rah-rah-rah crowd gets very hostile when the fact that it exists is even mentioned.
chrisweekly 7y ago
> "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.

tobr 7y ago

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.

danShumway 7y ago
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.

derefr 7y ago

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

chmod775 7y ago
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).
- jameshart 7y ago
  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.
  - chmod775 7y ago
    > 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.
- tjoff 7y ago
  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.

millstone 7y ago

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.

danShumway 7y ago
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.
skunkpocalypse 7y ago
> This highlights the tension between the web as publishing vs an application platform. It also highlights the importance of acknowledging that tension. Notice how the app-app-rah-rah-rah crowd gets very hostile when the fact that it exists is even mentioned.

chrisweekly 7y ago

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