Any time the demarcation between "remote page" and 
    "browser UI" is blurred, problems such as "phishing" 
    attacks become easier.

Hugely important; largely ignored.

Unfortunately, people whose training and experience exists only inside a browser either don't or can't see beyond those confines and the result is reimplementing perfectly adequate external functionality.

This is indeed a nice argument.

Sometimes I am doing something on the CLI and go back to the terminal and paste a text I copied from somewhere.

If the text is multiline my terminal will consume the lines without requiring an extra 'enter / return' key press.

Another possibility is copying something to web mail client without noticing there's something suspicious about it (JS isn't the concern here anymore nowadays, but loading stuff like images is a privacy concern).

However, this issue MUST be fixed at browser level. And when used without destroying user expectations / UX, this plugin is useful.

Malicious attacks are going to happen anyways if the browser permit such action to happen, so don't blame the plugin or the plugin writer. The browsers are broken. Ask the major browser developers to either never allow it to happen (like Safari does) or ask them to ask for permission (like for webcams) or add a confirmation modal.

re: browser support (which is where this problem should be fixed)

A trivial compromise that would be even easier to use than the current javascript/selection stuff would be a "copy to clipboard" variant of the <button> tag. Something like this should satisfy the use-cases where this clipboard nonsense is occasionally useful:

    <form>
      <input name="copy_souce" type="text" value="xyzzy" />
      <button type="clipboard" value="copy_source"
              name="Copy To Clipboard" />
    </form>

This wouldn't require any Javascript, and leaves the clipboard entirely under the control of the user where it belongs.

This could even be extended to allow copying of the various types of input tags, and if you wanted to get fancy, the button could reference an #id and copy that element's textContent (or innerHTML).

Or people could .. You know... Use their platforms existing copy functionality.

I know it's only existed on desktop computers since the Apple Lisa, and 30 years isn't very long for people to grasp the concept of copy and paste without a button to do it, but I have faith in people.

This button couldn't be customized, otherwise it's useless as someone could easily get away with hiding it / showing only a small portion of it where someone could click without even noticing / etc.

Maybe a small modal-like confirmation that can be placed anywhere on the viewport and is actually on top of everything natively (like Safari's copy/paste on iOS).

Of course, this modal-like confirmation must not be customized or its effect is useless.

Or let's just forget entirely and remove the functionality from the browsers.

An HTML5 page with no stylesheet or javascript is hugely functional, legible, and responsive, adapting itself to any device. If there is a problem with a website it's because a "web designer" or front-end developer broke it.

This seems to be a civil war taking place purely amongst software developers. Some developers want the web to be used for hypertext documents as it was originally intended, and others want it to be used for anything for which there is demand amongst a sizable group of people, technical and non-technical alike. I see the appeal of the first viewpoint, and it's likely I would share it if I had the luxury of working on non-web software, but as it is, most of us go where the users are and work on what the users want, and that question has been settled: they want rich functionality that looks nice and is delivered through the web on their desktop and a mix of web and native apps on mobile. Only other programmers (and only a small subset of programmers at that) complain about javascript and stylesheets. In most cases, it doesn't make sense to pander to such a tiny audience.

I think the situation is more nuanced than that: users may not know the terms to complain about JavaScript and stylesheets but they know when a page is slow or broken.

The discussion really should focus on how well apps degrade, which is really reaffirming that progressive enhancement is still the best approach to building web apps. While only a small percentage of users have intentionally disabled JavaScript entirely, it's effectively disabled for everyone while it's downloading and a larger percentage of users (particularly on mobile) will have errors which prevent those downloads entirely. If you build a rich application which still has the core functionality working, you've done a much better job than the people who make sites which take minutes or don't even render when their shiny framework hits a non-perfect network connection.

This is a really good point, and the better conversation to have than broad brush dismissal of anything but raw hypertext like the comment I replied to. Graceful degradation is a user-friendly, competitive, and all around fantastic feature. It is also expensive, and may or may not belong at the top of the list of things to optimize to improve user experience. Eliminating everything but raw hypertext may be a cheaper solution, but it isn't a good one.

I did not advocate eliminating anything but raw hypertext. I like CSS and javascript when they are used well. I like web apps.

Fair enough! I misread.