4 ms·

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

• NathanKP 16y ago
  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.
  • greenlblue 16y ago
    Here's one: stop using facebook.
  • jogle 16y ago
    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.
  • potatolicious 16y ago
    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.
    • pak 16y ago
      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.
      • lftl 16y ago
        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?
        • chopsueyar 16y ago
          Subdomains and DNS mods with a proxy?
    • points 16y ago
      It'd be trivial to modify js behavior before the FB JS file loads. For example... window.confirm = function(m) { return true; }
  • khafra 16y ago
    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.
• amalcon 16y ago
  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.
  • neilk 16y ago
    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?
    • po 16y ago
      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.
      • pak 16y ago
        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.
        • dLuna 16y ago
          There is an easy solution to the AI calculation though. Anything not proven visible counts as invisible. Done!
• carussell 16y ago
  This somewhat demonstrates why GET isn't supposed to be used to change server state. Somewhat.
  • duskwuff 16y ago
    Not particularly. If Facebook used POST internally to implement the Like button, the result would be the exact same.
    • carussell 16y ago
      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.
• statictype 16y ago
  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.