Complexity and Scams

All of us use gadgets—cars, phones, computers, what have you—that we don’t really understand.  We can use them, and use them very effectively, but only because a great deal of effort has been put into making them seem simple.  That’s all well and good—until suddenly you have to deal with the complexity.  Sometimes, that happens because something has broken and needs to be fixed; other times, though, scammers try to exploit the complexity.  The complaints released today by the FTC illustrate this nicely (the press release is here; it contains links to the actual filings), with lessons for both consumers and software developers.  (It turns out that programmers speak a different language than normal people do—who knew?)

It’s a long story, but I can summarize it easily enough: scammers call people claiming to be from a reputable vendor.  They trick their victims into thinking that their computers are infected, and persuade them to fork over $100 or more.

The scam starts innocently enough: people receive a call telling them that their computer “may” be infected.  (The call itself may be illegal if it’s a “robocall”—do you know about the forthcoming FTC Robocall Summit?  Even if it’s not a robocall, it’s illegal if the recipient is on the Do Not Call list.)  The caller will claim to be from a computer or computer security company. (I received such a call, well before I joined the FTC; that person claimed to be from Microsoft.  Yes, I’m on the Do Not Call list.)  The victim will be talked through some steps designed to “demonstrate” that their computer is infected.  You’re then given the “opportunity” to pay them for fixing it.

Lesson 1: Be extremely skeptical if someone calls you; reputable security companies don’t “cold call” people.  If you have any doubt whatsoever about the legitimacy of the caller, call back using a number you’ve learned independently, perhaps using a phone number from their web site.  (This issue is broader than just this scam.  For example, if a caller claims to be from your credit card company, don’t give out any information; instead call back using the number on the back of your card.  And don’t believe Caller ID; it’s easily spoofed.  There are also lessons here for developers, but I’ll save those for another post.)

 This is the most important lesson to learn: “Don’t call me; I’ll call you.”

It’s worth noting that scammers in this case did in fact use Caller ID spoofing, to make the calls appear to be coming from the U.S. rather than India.  That turns out to be remarkably easy to do.  Here’s the crucial question: when a call starts on one phone company’s network but terminates on another’s, how does the receiving company know the caller’s number?  Answer: the receiving company believes whatever it’s told, whether the information is coming from another phone company or a private branch exchange (PBX).  This worked tolerably well when there were only a few, large telcos; now, though, there are very many—and every Voice over IP (VoIP) gateway to the phone network counts as a telco or PBX.

That trust model no longer works.  There are many more telephone companies than there once were, and there are very many VoIP gateways.  If even one doesn’t check the Caller ID asserted by its customers—and there are valid technical reasons not to, in some situations; consider the case of an employee who wants to make an expensive international call via the company PBX—it’s very easy for a malefactor to claim any number he or she wishes.  (Note that using fake Caller ID “for the purposes of defrauding or otherwise causing harm” is illegal.)  One of the accused firms here claimed to be calling from Quinnipiac University or New York City; another claimed to be from Texas, etc.

In this particular scam, the victim is asked to run a program called the “Event Viewer”.  Most computer systems log various things that take place, including mildly anomalous conditions; Event Viewer is the way to display such logs on Windows.  The information is often quite cryptic, but invaluable to support personnel.  Cryptic?  Yes, cryptic, as you can see below.

The point is that you’re not expected to understand it; it’s information for a technician if you need help.

The consumer is then directed to look for “Warnings”.  That sounds scary, right; your computer is warning you about something.  Lesson 2: Programmers use words differently.  On most computer systems, warnings are less serious than errors; you generally don’t need to do anything about a warning.  Contrast “Warning, your disk is 90% full” with “Error: no space left on disk.”  That isn’t normal usage (to the Weather Service, a storm warning is more serious than a storm watch, which is why programmers get confused when they listen to weather reports…), which gave the scammers one more thing to exploit.

Next, of course, it’s time to scare the consumer—“Jesus, did you say warning?”—followed by completely bogus cautions to avoid clicking on the warnings.  (What happens if you do click on one of those messages?  Nothing bad; you just get a new window with more information, and a URL to click on to get even more details.  That’s what the screen shot shows.)

It’s also worth realizing that even most of the errors logged are quite irrelevant and harmless.  That isn’t always the case, but more or less any machine will experience many transient or otherwise meaningless failures, perhaps induced by things like momentary connectivity outages.

There’s also a lot of technical doubletalk, presumably intended to impress the victim with the caller’s expertise.  Most of this is pure nonsense, such as (in one call from an FTC investigator) learning that “DNS” is “dynamic network set-up”.  The DNS, of course, is really the “Domain Name System”, the Internet mechanism that translates things like www.ftc.gov into a set of numbers that the underlying hardware really understands.  My favorite was hearing that “the Javascript in your computer has been fully corrupted”.  Javascript is indeed a programming language, but its primary use is creating dynamic web pages.  It’s not normally “on” your computer in any permanent sense; rather, Javascript programs are downloaded to your  web browser when you visit most commercial web sites.  (These programs are run in what is called a “sandbox”, which in theory means that they can’t affect anything on your computer.)

Lesson 3: Just because someone can spout technical terms it doesn’t mean they’re knowledgeable or legitimate.  Of course, asking them to explain what they’re saying doesn’t prove much; they can respond with more glib doubletalk.  A legitimate support tech can probably explain things somewhat more simply; however, while lack of technical details might be a good reason for suspicion, the presence of them says very little.

The victim is then told to download and run a program from the scammer’s web site.  That’s bad, too—you should never run a program from an unknown source—but of course by this time the victim does trust the caller.  But this is really dangerous: once you run someone else’s code, it could be game over for your computer; it’s really, really hard to disinfect a machine thoroughly. The same applies to credit card numbers: once you give it out, you could be charged far more and far more often than a one-time payment to a scammer.

Where does this leave us?  Like most con artists, the callers here are trying to gain your trust before ripping you off.  The best thing is to cut them off at the start.  Remember Lesson 1—“Don’t call me; I’ll call you.” —and use a number that you’ve looked up on your own.

FTC Settles with Google over Cookie Control Override

[Updated (4:35pm EDT, August 9, 2012): Added to the description of the HTML file quoted in this post, to say when I recorded it.]

Today the FTC announced a settlement with Google, in which the company agreed to pay $22.5 Million to settle charges that it  misled consumers about its use of tracking cookies on the Safari browser.   The Complaint and Order, which were approved by the Commission, are the official statement of the FTC’s position on the case.  In this post I’ll explain some of the technical background in more detail–speaking just for myself.

Google’s DoubleClick ad network uses tracking cookies to record a history of a user’s activities across different web sites.   A DoubleClick tracking cookie looks like this:

id: c5bffdc4700000c||t=1343680985|et=730|cs=002213fd484b7cb9af91248086

Google also uses cookies to offer an opt-out.  If a consumer clicks the opt-out button, Google creates an opt-out cookie, which clobbers any tracking cookie that was in place before.  The opt-out cookie looks like this:

id: OPT_OUT

If you have the opt-out cookie, Google won’t place a tracking cookie on your computer.   On most browsers this all works as described.

But Apple’s Safari browser–the default browser on Macs, iPhones, and iPads–puts more stringent limits on how sites can use cookies.  In its default setting (“Block cookies: From third parties and advertisers”) Safari blocks most cookies coming from third parties.    Users can change this setting, but very few do change it, so from here on, let’s assume that Safari is in its default configuration.

Safari allows a site to deposit a cookie onto your computer whenever at least one of the following things is true:

1. you are visiting the site directly–that is, it is the “first party” site whose URL appears in the browser’s address bar, or
2. the site already has a cookie present in your browser, or
3. the site is responding to a form that you submitted.

One consequence of this design is that Google’s opt-out cookie mechanism doesn’t work for Safari users–Google’s attempt to deliver the opt-out cookie will fail because none of the three conditions hold.

The FTC alleged that Google told Safari users that they didn’t need to worry about the unavailability of opt-out, because Safari’s cookie controls would provide the same protection as the opt-out.

Unfortunately, according to the FTC, this promise wasn’t kept.  Google ended up placing tracking cookies in many Safari users’ browsers despite its promise to give those users the same treatment as opted-out users.

Google placed the tracking cookies in two different ways.

First, if you went to the doubleclick.net website, perhaps by typing in the URL but more likely by clicking an ad placed by DoubleClick, then you would be given a DoubleClick tracking cookie.  Safari allowed this because it treated DoubleClick as playing a first-party role in this interaction–but no cookie would have been given to an opted-out user of another browser.

(An important detail here: Though people sometimes talk about “first-party cookies” versus “third-party cookies,” there is nothing about the cookie itself that is marked as either first-party or third-party.   Instead, first-party and third-party are roles that a site can play in a particular interaction–in the same way that “home team” is not a permanent attribute of a sports team but merely a role that the team might occupy in today’s game.    When somebody says “first-party cookie,” you should read that as “cookie associated with a site that is playing a first-party role at the moment.” )

The second way that Safari users got DoubleClick tracking cookies was more complicated–and this is the one that has gotten the most attention.   This part of the story starts with Google wanting to put a “social advertising” cookie onto users’ computers.  “Social advertising” is a feature that lets you click a “+1″ button on an ad you like–and then shows the same ad to your friends with an indication that you liked it.   If implemented in a straightforward way, this wouldn’t work on Safari because Safari would block the placement of Google’s social advertising cookie.

So Google overrode Safari’s cookie controls.   They sent Safari a file that looked like this:

<html>
<head></head>
<body> 
    <form id="drt_form" method=post action="/pagead/drt/si?p=XXX&ut=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">
    </form> 
    <script> 
        document.getElementById('drt_form').submit(); 
    </script> 
</body> 
</html>

I recorded this file in mid-December, 2011.  The line that starts with “document….” is Javascript code that told the browser that the user had submitted a form–even though the user had done no such thing.   (The “form” was invisible and had neither content nor a Submit button,  so the user could not actually submit it.)   Safari, believing that the user had chosen to submit a form, would then allow Google to put a DoubleClick cookie on the user’s computer.   This was allowed under condition number 3 above.

Once the first cookie was in place, Safari would then–according to condition number 2 above–allow Google to deliver additional cookies from doubleclick.net, including the DoubleClick tracking cookie.   So the end result of Google’s form submission was to put DoubleClick tracking cookies on Safari users’ browsers, despite Google’s alleged promise not to do so.

If you use Safari, you probably received a DoubleClick tracking cookie from Google during the relevant time period.  As part of the settlement, Google agreed to destroy as many as possible of the DoubleClick tracking cookies placed on Safari users’ computers during the relevant period.   To its credit, Google started destroying those cookies early, without waiting for the settlement to be finalized, so virtually all of the relevant cookies should be gone by now.

[Note:  I modified the HTML snippet above, putting 'X' characters in place of parts of the URL in the form tag.   I am not disclosing any of the exact URLs that we saw in our experiments, as a precaution against the possibility that they might reveal something about our investigative procedure.]