Hacker News Reader

Comment by asah | Hacker News Reader

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

View on HN

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

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.

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.

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

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

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.

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

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

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

Think about the reasons why e.g. CORS was invented and implemented, despite XHR requests across domains being a perfectly working feature.

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 :-( ).

Reply on news.ycombinator.com