the problem with the "like" trade

earlier today randy abrams posted an interesting take on facebook advertising and how misleading the word "like" can be (http://randy-abrams.blogspot.com/2011/12/facebook-misleading-advertising.html). this reminded me of a beef that i've apparently had going back at least as far as may of this year (judging by the timestamp on the screenshot i took).

specifically, randy said the following:

If I have to “like” a page to get the information I want, I don’t have a problem with that

well, with all due respect to randy, i do have a problem with it. randy makes some good points about the way people's pictures get used in facebook ads when they "like" things, but a point he neglected is that forcing users to "like" or otherwise post about something before they can see the content they've been lured with is a popular tactic in facebook scams.

now, i'm not trying to suggest that security companies making use of this marketing methodology are scam artists (though i am tempted to say that all marketing is in some way a scam) but they should be aware that by utilizing this sort of marketing they are effectively endorsing a marketing methodology (developed by facebook) that breeds victims. i don't expect facebook to care about such things, since such trickery is how they make their money, but i certainly expect security companies (especially ones with as strong a leaning towards empowering users as eset) to know better than to go along with facebook's questionable methods and do things like this:

"like"s are not something to be bought from users in exchange for free or otherwise tempting content. they are an endorsement and as such can't be legitimate until after the user has sampled the content. the idea of exploiting illegitimate user endorsements should be recognized as unethical and should be understood to have consequences. by using the sort of techniques that scam artists thrive on, one is basically training people to be victims. i expect better from security companies and i think you should too.

facebook's ticker: a ticking privacy timebomb?

there's a lot of pixels and bits being dedicated to the major changes that are underway at facebook, but most of the attention seems to be focused on the timeline feature. i tend to think the ticker feature deserves a lot more attention and, frankly, concern.

first off, it seems clear that facebook wants to be the destination for an ever increasing number of activities - not just farmville or mafia wars, but consuming print, audio, and video media, and even purchasing goods too. fine, facebook wants to be the web portal to end all web portals - the next AOL or compuserve - it's fine to have aspirations like that; although actually being AOL or compuserve doesn't seem to have worked out that great for AOL or compuserve in the end.

but with that breadth possible activities in mind, the idea that facebook will now be sharing everything you do automatically seemed really rather stupid to me at first. maybe there is too much friction inhibiting sharing right now, maybe clicking a button isn't easy enough, but truly "frictionless" sharing that happens without any action taken on the user's part takes the intent out of sharing. sharing loses all meaning that way. it no longer tells you the sharer thought this article was insightful or that video was funny, it doesn't give any hint what so ever as to whether the sharer thought something was worthwhile, it just collects everything in one big activity profile. indeed, was the person performing those activities really the sharer in that situation, or is the sharer facebook themselves?

at first you might think that the resulting poor signal/noise ratio would render facebook as irrelevant as myspace and it's blinking, glittery profile pages has become. the folks at facebook seem to have realized this, though. they don't want people's main feeds to get filled with all that noise. they recognize that from a personal interaction standpoint, this data is too voluminous and unimportant. that's why they've relegated the data to a new place - the ticker.

the question you should be asking yourself right now, however, is this: if this data isn't actually useful to users when they're connecting with their friends, why is facebook interested in automatically sharing it? who is interested in that data? the answer is simple - advertisers. a large profile of everything you read, watched, listened to, and did online is for all intents and purposes your web history. in this case it will be your web history as seen through the eyes of facebook. we in the security community get upset about browser vulnerabilities leaking our browser history, or tracking cookies being used to track where we've been; the data collected for ticker is not going to be inherently different than the data acquired through those other means. furthermore, it's too voluminous and granular to be useful to anything other than an automated process that looks for certain types of patterns and trends. the kind of process you'd use for the automated targeting of ads - targeting based on your activities, your behaviour.

the ruse of "frictionless sharing" appears to be a trojan horse (not the malware variety one might traditionally think of, though) for introducing behavioural profiling for the purposes of targeted advertisements. social spyware at it's best.

but even if that's not the case, even if that data really is meant for a user's friends to see and use, there is a profound implication buried in the automated sharing of everything. you can't control your public image if the choice of what you share about yourself is taken away from you. for all the hand wringing recently about the damage that real name policies do (eliminating your ability to control the personal information that your identity represents), the elimination of your ability to control your public image means the elimination of the persona - something that has been part of the social experience of humans since the dawn of mankind if not longer.

our true selves, the nature that we keep hidden behind the masks that we each present the world, is something that we innately keep private. i simply cannot believe that our social norms are headed in the direction of completely removing those social masks. giving up that private information in exchange for access to a service is a privacy bargain that we have never faced before.

so, if you thought the ways facebook could violate our privacy couldn't get much worse, you were dead wrong.

thoughts on viral facebook scams

in response to a certain discussion on twitter, i found some ideas floating around in my head that just don't fit in a tweet, so i thought i'd share them here instead.

one of the ongoing problems on facebook is the phenomenon of viral scams - scams that spread in a viral manner across the facebook userbase and trick users into doing various things (whether it be installing a rogue facebook app, clicking an invisible link, or copy-n-pasting javascript into the URL bar).

there are at least 2 contentious aspects to this phenomenon. the first is whether facebook has things under control. there are certainly those who are arguing that it's not under control, that the numbers are ever increasing. there are also those who argue that, on the whole, facebook is acting in a timely manner to deal with these threats to their users. my own experience is that i rarely actually encounter these viral scams so that certainly could support the argument that they're getting killed quickly - quickly enough that they die before they make their way to me. on the other hand, though, when i do encounter these scams it doesn't appear to me that facebook is dealing with them expediently at all. a day or more to kill a viral scam campaign? really? i think they could do better - in fact, i have some specific ideas that i intend to share a little further on.

the second contentious aspect is what's the best way to deal with these scams: whether it's better for facebook to police it's network more effectively or alternatively to go after the industry whose gray areas are responsible for the lions share of the scamming (ie. the cost per action / CPA marketing industry). technical defenses employed by facebook will always be a bit of a game of whack-a-mole, but they're relatively quick and easy to implement without involving a lot of other parties. investigation and enforcement of legal authority against CPA firms can certainly have some long-lasting effects but there are problems; it takes a lot of time and coordination from the law enforcement community, and CPA is only the current low-hanging fruit from a malicious business model perspective. that means, ultimately, going after CPA firms or even entire industries will also wind up being a game of whack-a-mole, it'll just much slower and it will be law enforcement playing the game instead of a technology company.

i believe both technical defenses and legal authority are appropriate tactics. technical defenses are useful for dealing in the near term with that which has not yet been dealt with in the long term, while exercising legal authority tends to have more of a long term effect and creates a much bigger disruption to malicious business models (potentially requiring entirely new malicious business models to be developed to compensate). right now we don't yet have the benefits that legal authority can provide so we need to use technical defenses as a stop-gap at the same time as we pursue legal avenues. if/when legal authority manages to take out most of the CPA abuse channels that the scammers are currently exploiting, those scammers will monetize something else so we'll continue to need those technical defenses as we adjust our legal tactics to their new business models. in essence, technical defenses and legal authority represent compensating controls in a multi-layered approach to the problem.

to that end, i have some specific technical ideas for facebook.

all viral scams must exploit one of facebook's many communications channels. facebook needs to monitor these channels and apply some heuristics to help identify the viral scams.

to start out with, they should apply a k-nearest-neighbor algorithm or some other suitable similarity measure  to the communications (do not use hashing - i hardly ever see the scams but even in the few i have seen, i've seen hash busters being used) in a sliding window of time (to limit the size of the corpus facebook would need to analyze). messages, wall posts, events, etc that cluster together as being highly similar are likely all part of the same viral campaign and should be classified as such. being part of a large cluster should cause the message (or rather the entire set of messages) to be flagged for additional review at the very least. if that review is manual, one could prioritize the review based on the size of the cluster. not all viral communications are bad, mind you - it could just be a really good joke, or a political activist campaign, or something else legitimate - that's why virality alone isn't enough to classify something as bad, but it is a good start for narrowing the scope of the analysis.

now, even if facebook stopped at this point, they'd still have something very useful for killing viral scams. identifying the set of nearly identical messages that a particular message belongs to means that you can aggregate data and judgments about those messages. an abuse report for one message is an abuse report for all, a flag to disable display of one message is a flag to disable display of all, a flag indicating one message was verified clean is a flag indicating all are verified clean, etc.

if facebook were to go further, though, the next thing they could do as a simple static heuristic is to check to see if the message contains javascript code that is displayed to the user. most users cannot read or understand javascript. for most, the only reason they'd see that in a viral message is if they're supposed to copy and paste it in order to bypass facebook's existing defenses against malicious javascript. that makes it a pretty good indicator of malicious intent.

another simple heuristic would be the presence of a link whose destination is obscured by a URL shortener. a much more contentious heuristic, of course, but i'm not really suggesting any of these on their own should be taken as proof of malice - only that they each incrementally increase the level of suspicion.

a third simple heuristic would be links to facebook applications where the app developers haven't been registered very long. it's not impossible to hit it big on facebook right out of the gate, but there are nuances that aid in growing an application's popularity that you wouldn't really expect a newbie to know right off the bat. a really big viral cluster for a really new app developer should definitely raise some eyebrows.

next, as an active heuristic, an automated process attached to a dummy facebook account could be sent to click it's way through the trail laid out in any message that has a link in it in order to see if any path results in the dummy account sending out a message belonging to the same viral campaign it started from. this means adding applications where requested, following links to outside pages, even pasting the contents of the clipboard into the URL bar when the trail leads back to facebook's domain.

finally, recognizing that different viral clusters could be related, there needs to be a mapping between inputs and outputs of those dummy accounts so that facebook can catch the condition when an incoming message from viral campaign A leads to outgoing message from viral campaign B and which in turn goes through 0-N other viral campaigns as inputs and outputs before arriving back at campaign A.


i don't know what methods facebook is using right now, but if they were aggregating nearly identical messages it shouldn't have taken a day or more to kill the last viral scam i encountered and it shouldn't still be possible to easily find something like this half a month later:

those may be neutered to the extent that they can't contribute to viral spread in facebook's environment anymore, but who knows what the pages those point to could be changed to do to people's PCs now that the main campaign is dead. those events should have been deleted a long time ago. leaving remnants of viral scams in people's accounts is a little like leaving remnants of viral code in disinfected programs.

facebook's developer verification isn't that bad an idea

earlier this month ryan naraine penned a post critical of facebook's latest effort to crack down on rogue facebook applications.

facebook plans to force app developers to verify themselves either by submitting a phone number or credit card information - essentially to establish a less anonymous identity.

ryan naraine contends:

While this is clearly a step in the right direction, this won’t stop rogue apps from wreaking havoc on the social network.

and he suggests:

Instead of these minor roadblocks, Facebook needs to implement some sort of code signing or code inspection process for every app that’s submitted to its platform.

while he is right that developer verification won't stop rogue apps, what he apparently fails to realize is that NOTHING will really stop the rogue apps, short of closing the application platform to the outside world entirely. preventing web-based malware is comparable to preventing traditional malware that runs on the desktop - there is no panacea, no magic bullet that will make the problem go away.

code signing, for example, can also be bypassed by the serious criminals. don't believe me? we've already seen examples of malware getting digitally signed by gatekeepers of the sort ryan naraine likely has in mind, and the reason is easily deduced - digital signing protects against malicious alteration of legitimate content, but it has no intrinsic strength against malicious parties getting their own content signed. the people who do the signing aren't qualified to determine the safety of the code, and that's not what a signature establishes anyways, it establishes the authenticity of the code.

likewise code inspection is not going to work because facebook just doesn't have the expertise necessary to determine the safety of the code running on it's platform. even if it developed that expertise, it wouldn't scale, and scalability is important. especially when you consider that the malicious facebook developers appear to be taking a page out of traditional malware creator's playbook and going for volume as a means of compensating for the disabling of individual apps.

verifying or certifying the developer instead of the code means that for a malicious developer to continue using a volume-based strategy he'd need to establish a fake identity for each copy of his rogue app. while facebook hasn't set the bar for this very high, it is higher than it used to be and in so doing makes the strategy more expensive for the attacker. additionally, with this framework facebook could easily make it harder or more expensive in the future without changing all that much besides the verification process itself.

it seems clear to me that developer verification will do some good. there will always be room for improvement, regardless of what approach one takes, so let's not pretend like there's a perfect solution out there and facebook is making a mistake by not choosing it - there isn't and they aren't. we'll see how the bad guys adapt to this countermeasure soon enough and then we can start dreaming up new countermeasures for their countermeasures. like the war against desktop malware, web-based malware is going to be another game of cat and mouse / measure-countermeasure - that much was inevitable.

mark zuckerberg, privacy, and default behaviour

a while back graham cluley had some choice words about how facebook founder mark zuckerberg has shaped the privacy paradigm at the social networking site.

Mark Zuckerberg, the founder of Facebook, says that most people want to share.
If he really really believes that, then why doesn't he give those users the ability to "opt-in" to share their personal data rather than force people to "opt-out"? After all, if he's right then that business model would work just fine.

now graham used to make software, once upon a time, and i wonder how long it's been since he's done so.

zuckerberg's stated belief that most people want to share is completely compatible with an opt-out privacy paradigm. don't make things too difficult or too much work. if most people want X then give them X by default, don't make them jump through hoops to get it. even if X is sharing.

that being said, i personally would prefer opt-in over opt-out and if you look at zuckerberg's own facebook profile you might be mistaken for thinking he'd prefer that too - his stated belief that most people want to share appears to be hypocrisy because he certainly does not share very much. granted his date of birth and hometown are up there, but if you're looking for anything truly personal the best you'll get are a list of "like"s (including himself, so i guess he's sharing a bit of narcissism). does zuckerberg think he's somehow different from the average person? does he not believe in eating his own dog food? no one wants to share willy-nilly, everyone is at least somewhat selective about what they share and with whom. facebook's privacy defaults should be designed with that in mind.

bad advice: disable your av

i'm sure you can probably think back and remember at least one example of a piece of software you've installed in the past that came with directions suggesting you disable your anti-virus before you install.

that little pearl of anti-wisdom has been with us a long, long time and has always irked me. the software industry, whether too lazy, too hurried, or to ignorant to know any better, decided that rather than resolve whatever conflict they may encounter with security software it would be better to train users to drop their defenses.

what could possibly go wrong?

plenty could go wrong, of course, not the least of which being that once the users are effectively trained to drop their defenses when told it would be trivial for malware authors to distribute their wares with instructions telling people to disable their av. who needs to develop technical measures to bypass anti-virus when you can simply tell users to turn it off for you and have them do it like good little trained monkeys.

well, nowadays more and more applications are being delivered to users over the internet, specifically over the web, and along with that, anti-malware products are focusing increasingly on web-borne threats. as such you can probably guess this was bound to happen eventually:

yeah, this WTF moment was brought to you by a facebook application development company called chainn who thought it would be a good idea to tell users to disable (or even remove) norton anti-virus. hey, it worked well enough back in the days of desktop applications, right? why not facebook applications too? i mean, really, what's more important, online safety or finding out how you fit in amongst your friends?

apparently they also have some problems with adblock plus - i wonder why?

can facebook sanitize application content?

while reading through some blogs this evening i happened across this article by ryan naraine pointing to a register article by dan goodin about an apparent security vulnerability in facebook's 3rd party application platform that allows arbitrary (and possibly malicious) javascript to be executed...

what struck my eye was a notion that facebook was failing to sanitize application content...

this struck me as an odd statement... i've heard of sanitizing input/data - that's something that makes sense since data should adhere to a strictly defined format... names don't go where dates should be, numbers should actually be numeric, escape sequences should be filtered, etc... it's possible to reject everything that doesn't meet the pre-defined criteria...

i'm going to put on my computer scientist hat and say the same is not applicable to applications written in a turing complete language (which javascript is)... the only way to truly 'sanitize' them is to come up with an entirely new and decidedly less than turing complete language for people to use instead... that is likely outside the scope of what facebook or any other application platform provider is willing to invest their time in - especially since it creates a far more restrictive and less rewarding environment for 3rd party application developers to work with, leading to the very likely result of driving them to other, less restrictive platforms...

that's not to say there aren't some specific instruction sequences that facebook can try to filter out, however with all the ways to obfuscate javascript i doubt it would accomplish much - and even if obfuscation weren't a problem the turing completeness would be; you'd never be able to list (never mind filter) all the possible malicious sequences of instructions, nor could you definitively say that those instructions would ever actually be interpreted by the javascript interpreter of a visitor's browser... detecting malicious sequences of javascript instructions in 3rd party applications is similar to detecting malicious programs like viruses or worms - in fact, they are identical problems and so it should come as no surprise that detecting such malicious sequences of javascript instructions (a necessary precursor to sanitizing the javascript) is reducible to the halting problem... therefore facebook may technically be correct in saying there's no vulnerability (though i have no idea if they actually analyzed the issue in this manner) in the sense that most people would consider... just because you can do bad things doesn't mean there's a vulnerability... sometimes it just means there's more flexibility than you were expecting or wanted...

at any rate, facebook has other ways of dealing with malicious application content - they block the entire application once they discover it's bad... after all, even if they did somehow manage to sanitize javascript, what about flash? or java? or activex? it's not feasible to manually audit all applications before they're allowed to go live on facebook, and it's not possible to find all the malicious code with automated auditing because of the halting problem - so, like more traditional forms of malicious code, malicious facebook applications are something that must inevitably be dealt with after the fact...