Hacker News Reader

Comment by po | Hacker News Reader

We've seen this kind of scammy stuff before, where people overlay a transparent div on top of another div. This is the first time that I've seen them attach to the cursor and follow it around.

Other than keeping your browser logged out of facebook at all times, what's the protection against this?

View on HN

The only possible protection that I can think of would be for Facebook to require confirmation when someone likes a page. Essentially it would redirect the user to Facebook where they would see a page that says "Are you sure you want to like ______?" Then, after they agreed, it would redirect them back to the original site. However, this would be highly undesirable for people who use the Facebook like button, because it could siphon away potentially valuable visitors who appreciated the site enough to like it.

Another option might be for Facebook to ban likes on a domain basis. If a domain is using spammy techniques like this then ban it from being liked by anyone. Of course that means more overhead and moderation.

I don't think there is a good solution to this, only work arounds.

Here's one: stop using facebook.

Facebook already does ban on a domain basis, but of course that's not a fix at all. These things are "viral" by the nature of the Like button since it posts on the user's wall automatically, so it's very easy for the "spammer" to make a new domain and get going again very quickly.

The easiest fix to the spreading of this issue is FB not broadcasting every single time you like something... but they're not gonna do that, we already know. So, the spam will continue.

What about forcing embedding sites to load a FB JS file, such that a standard Facebook confirm dialog pops up? This way the user doesn't navigate away from the site but some level of confirmation is made.

If the dialog pops up and is not within an <iframe>, then the page can simulate a click on the confirm button. Even if the JS library uses an <iframe>, it can always be reverse engineered to not use one, and the user won't know because iframes are not obvious to the user. The way above, where a new page is opened with the Facebook URL clearly displayed in the browser address bar, is the only way for Facebook to ensure that likes are legit short of putting CAPTCHA's next to the like buttons. Oh, and users never check the address bar anyway.

I don't see how reverse engineering to not use an iframe would help. Presumably Facebook would have some type of check on the iframed like page that ensures that the request is actually coming from FB. How would an attacker recreate an iframed page they don't have access to?

Subdomains and DNS mods with a proxy?

It'd be trivial to modify js behavior before the FB JS file loads.

For example...

window.confirm = function(m) { return true; }

Perhaps a batch confirmation once a week on facebook; "likes" don't become active until you look through a list of likes from the last seven days and ok them? Most of that sort of thing isn't very time-sensitive.

With imagemaps, there's no longer a legitimate reason to ever need to "click" on something that's transparent. Therefore, the browser should not allow objects that are not visible to receive "click" events.

I actually use this trick for good, not evil. It's a way of styling certain unstyleable elements in old browsers. But you have a point -- it's useless in modern browsers. That said, what is the standard? Is 5% enough?

Maybe we need fractional clicks. If you click on a 0% opaque button then you don't get a click. If it's 1% opaque, then you get 1% of a click event. :-)

Actaully... I started writing that as a joke but now that I think about it, if the browser embedded the opacity value of the clicked element in the GET or POST header, the webserver receiving the click could set the standard themselves.

Alternately, since facebook has lots of resources, facebook could make a request to the referring site themselves, render the page and determine if there are any shenanigans going on with z-ordering or opacity automatically. You could look at all of the css applied to all of the element affecting those pixels.

No... this is all crazy. Just pick a value like 30% and disallow clicks on anything less.

What about visibility: hidden?

What about background: transparent?

What about background: url(transparent.png)?

What about background: data:encoded-transparent-image...

Even browser-side "visibility" calculations can become an AI-level problem quickly.

There is an easy solution to the AI calculation though.

Anything not proven visible counts as invisible. Done!

Anything not "proven invisible"? So... any text on any image background? Any colored text on any background? (white text on white background...)

what's the protection against this?

Well, you could open these links in an Incognito window which doesn't have access to your Facebook cookies.

Obviously this solution doesn't scale to normal users.

This somewhat demonstrates why GET isn't supposed to be used to change server state. Somewhat.

Not particularly. If Facebook used POST internally to implement the Like button, the result would be the exact same.

Note the double use of "somewhat". They'd need to put the form to be POSTed on a page of their control that the browser would GET after clinking a simple link in the form a a "like" button.

Reply on news.ycombinator.com