COMSEC: February 2009 Archives


February 28, 2009

This East Bay Express article claims that Yelp manipulates rankings in order to extract advertising revenue. For instance:
A San Francisco wedding photographer relayed a similar story. About two years ago, a Yelp sales rep contacted her to advertise. The photographer -- we'll call her "Mary" -- declined the offer. But the sales rep was pushy; Mary said she received about three phone calls and as many as ten e-mails per week asking her to advertise. Still, she declined. "All of a sudden my reviews started disappearing," she said. "I called them up and said, 'I'm a little curious why my reviews are disappearing.' They said, 'Well, people stop reviewing, we take them down.' ... I talked to the clients -- they're still actively reviewing."

"Ellen," who only agreed to be interviewed if not identified by name, owns an Oakland business with more than twenty Yelp reviews, and averages a 4.5-star rating. She says she began to receive solicitations to advertise soon after her business began receiving positive customer reviews. But she declined. "The prices were cost-prohibitive," she recalled telling the sales rep. "I can't pay $300 a month when I pay $90 for Google AdWords. After that, reviews started to disappear."

When Ellen questioned her sales rep as to why some reviews had disappeared, the rep told her reviews can be taken down based on the company's algorithm. Reviewers must follow certain guidelines to post a legitimate review, the rep replied. "They had to have pictures, friends, be part of the community," Ellen recalled the rep telling her. But Ellen says the reviews that were removed fit the profile of acceptable reviews. Ellen turned down the offer again, and more reviews disappeared. She says she's now down to 50 percent of her original reviews. "Just today I got three more e-mails from Yelp. They're aggressive. ... But it's blackmail."

Yelp denies this:

"There is irrefutable evidence that we do not do that," Stoppelman told CNET News on Thursday when asked whether the placement of some reviews is determined by advertising deals. "It's absolutely ridiculous that somebody would say we are going to write a review and call a business (to sell advertising). That's not how you build a sustainable business...Trust and integrity are key to staying in business."

The problem, according to Stoppelman, lies in the company's secret sauce for filtering out reviews.

Basically, merchants are at the mercy of a computer algorithm just like Web sites are at the mercy of what is known as the "Google Dance"--the monthly update of the Google search engine's index. One tweak of the Google index can potentially make or break a business.


Asked to explain why Estelle's negative reviews of the moving company were repeatedly removed, Ichinose said she could not go into specifics or risk revealing information that people could use to game the system.

Really, there are two issues here that you need to think of separately:

  • Creation and removal of reviews.
  • Ordering of reviews on the site.

Creation and removal of reviews are a real problem for any reputation system like Yelp. The basic problem is that it's trivial for people to generate fake reviews to benefit or damage a given merchant. The problem then becomes how to exclude (or at least downrate) such fake reviews. There are a bunch of possible techniques here, for instance: weight by how many reviews the reviewer has done/how long they've been on the system; meta-reviews where you ask people to rate the usefulness quality of other reviews; forensics to try to detect reviews which look like they've been all been generated by the same party; requiring real user authentication, etc.) but ultimately, if you're going to allow quasi-anonymous reviews, as Yelp does, then there's only a limited amount you can do, and it's likely to involve some heuristics and human judgement. In that case, it's not completely nuts for Yelp to want to keep their procedures secret to make gaming the system more difficult.

Of course, the flip side of such mechanisms is that they leave the system operator very open to charges of gaming the system by removing positive reviews as a form of extortion; reviews just disappear and you end up saying "we think this is fake", but you generally can't prove it. Of course, you can mount the opposite type of extortion ("pay up or I'll publish a bad review") without collusion from the site operator, but it helps if the site operator colludes since that makes it harder for the victim to get your negative reviews removed.

This brings us to the topic of reordering. One way to deal with concerns about unfair removal is never to remove posts but simply to attempt to prioritize them by whatever estimates of veracity you're using. This avoids making sharp distinctions between real and (suspected) fake posts, you just push the (suspected) fake posts down towards the end of the reviews for a given merchant, but now justifying this exact order gets even harder. One natural choice is to use deterministic orderings (most recent, highest first, etc.). That's pretty clearly undesirable for a system like Google where you have to sort an enormous number of candidate choices, but actually it seems pretty suitable for a review site like Yelp where I doubt their ordering algorithms actually add that much value over simple orderings like these. Obviously, this isn't a perfect answer, since it doesn't really let you discriminate against fake reviews (though you can make posting fake reviews harder by, for instance, prioritizing frequent reviewers), but on the other hand if people don't trust your site's objectivity that diminishes the value of the site as well.


February 23, 2009

Lately I've had several people contact me to complain about bogus certificates with their email servers. Why are they contacting me? Well, the certificates are labelled RTFM, Inc.:
Version: 3 (0x2) 
Serial Number: 0 (0x0) 
Signature Algorithm: md5WithRSAEncryption 
Issuer: C=US, O=RTFM, Inc., OU=Widgets Division, CN=Test CA20010517 
    Not Before: May 17 16:01:14 2001 GMT 
    Not After : Dec 25 16:01:14 2006 GMT 
Subject: C=US, O=RTFM, Inc., OU=Widgets Division, CN=Test

This is happening for customers of Comcast, Charter, and Cox (at least).

So, these actually are my certificates, distributed with an article I wrote a few years back about how to program to OpenSSL, but I'm certainly not intercepting people's email. Obviously, this could be an attack, but you'd think an attacker competent enough to capture connections to an ISP's mail servers would manage to get a certificate that (1) isn't expired and (2) doesn't have localhost in the name.

That said, it's hard to see how this could be a simple misconfiguration problem. My guess is that some server is shipping with these certificates as a default and the ISPs are neglecting to change them after they install the software. Pretty amazing it's this widespread, though.

Acknowledgement: Thanks to Danny McPherson for helping me make contact with the ISPs. Anyone with more information please contact me at


February 17, 2009

Joe Hall posts about TrapCall, a system for circumventing caller-id blocking (it also does call recording and voicemail transcription). I thought it might be worth explaining what's going on for those who aren't too familiar with the innards of telephony.

The important thing to know is that telephony systems are nearly all digital now (the specific protocol is called signaling system 7 (SS7). The only part of the system that's analog is the part between the handset in your house and the nearest central switch, where the A-D and D-A conversion happens—and not even then if we're talking cellular telephony,. The way that caller-id works on analog phones is that the originating switch sends the caller's phone number (and potentially a name) in the SS7 setup message to the terminating switch, and the receiving switch encodes that information in the silent inter-ring interval where it's decoded by the callee's phone and displayed to the callee. The situation is basically similar with cell phones except that the connection between the cell phone and the switch isn't analog.

One of the basic assumptions of SS7 is that any device which gets to connect to the telephony network and speak SS7 is trusted. In particular:

  • The originating switch can put any information in the setup message it wants, including advertising random numbers that aren't actually connected to the switch.
  • Caller-id blocking (when the caller doesn't want their id propagated), is implemented by having a bit in the setup message that tells the receiving switch not to encode the caller-id information onto the callee's line.

The first point implies that you can't really trust anything you see on caller-id. If you can get a digital connection to the phone network, such as in a call center, a PBX or a home ISDN line, you can generally put any information you want in your messages [Technical note: this protocol is Q.931, not SS7, but you can think of it as SS7 for now], including false caller ID information. Since it's not at all hard to get this kind of access, caller-id from the telephone network is basically unreliable. The second point implies that caller-id blocking isn't that trustworthy either. If you have a digital connection to the network, there is a reasonable chance that you will get the caller-id information for any caller even if they have turned on blocking—you may see the bit that tells your phone not to show you, but nothing makes it obey that. In principle the receiving switch could suppress this information in the Q.931 but my understanding is that generally switches don't.

As far as I can tell TrapCall uses some combination of these features. You arrange to forward blocked calls to TrapCall, which acts as if it were your voicemail provider (I imagine that if someone really leaves a voicemail they just proxy it to your real voicemail box) which then reads the caller-id information and calls you back with spoofed caller-id matching the caller's (blocked) caller-id.

Acknowledgment: Jon Peterson filled in some of the details here. All mistakes are mine, etc...]


February 13, 2009

NYT reports on Hughes Telematics' plans to provide networked access to various aspects of your vehicle's operations:
Hughes Telematics, which is behind the communications systems in Chrysler and Mercedes-Benz vehicles that are to make their debuts this summer, is headed in that direction. Its next-generation technology, expected to appear in 2010, would allow drivers to install software in their cars, just as iPhones let users download applications to their handsets.


Other applications proposed by Hughes include remotely starting a car, resetting its alarm or unlocking the doors with an iPhone. Unlike wireless key fobs, commands could be sent to the car over the Internet.

I hate to sound like the stereotypical computer security guy, but the risks here seem pretty obvious: it's one thing to have your car stereo Internet accessible, after all if you're driving your car stereo from your iPhone, you already have that. It's quite another to have your engine be remotely controllable, which is obviously necessary for a remote start. One has to wonder what other parts of the car's operational electronics are accessible from the same computer. It's bad enough that someone could potentially steal your car remotely, though key fob to car protocols are often pretty insecure anyway; you really don't want someone turning off your car remotely. You might think that this problem could be solved with adequate comsec measures and firewalls to prevent remote penetration of the car computer. That's a hard problem in and of itself, but as soon as you start adding communications-style apps you need to worry about remote malware infection.

Obviously, what you really want here is to have the operational electronics airgap isolated from anything that you can install new software on. Ordinarily I would expect the people designing this kind of system to do that (No, really, I've met some of them and they're cautious), but if you're going to have remote start, you need some kind of integration, so I wonder how this is expected to work.