February 28, 2017

Archives for November 2007

Workshop: Computing in the Cloud

I’m excited to announce that Princeton’s Center for InfoTech Policy is putting on a workshop on the policy and social implications of “Computing in the Cloud” – the trend where companies, rather than users, store and manage an increasing range of personal data.

Examples include Hotmail and Gmail replacing desktop email, YouTube taking over as a personal video platform, and Flickr competing with desktop photo storage solutions. Facebook, Myspace and other social networks have pioneered new kinds of tools that couldn’t exist on the desktop, and more new models are sure to emerge.

I’m confident that this trend will reshape tech policy, and will change how people relate to technology. But I don’t know what the changes are. By drawing together experts from computer science, industry, government and law, I hope the Center can help those of us at Princeton, and workshop participants from around the country, get a better sense of where things might be headed.

The workshop will be held on the Princeton campus on January 14 and 15, 2008. It will be free and open to the public. We will have a series of panel discussions, interspersed with opportunities for informal exchanges of ideas. We’re still putting together the list of panels and panelists, so we haven’t yet published a schedule. If you’re interested in attending or want to get email updates about the workshop, please email David Robinson (dgr at princeton dot edu).

Here are some of the possible themes for panels we are exploring:

  • Possession and ownership of data: In cloud computing, a provider’s data center holds information that would more traditionally have been stored on the end user’s computer. How does this impact user privacy? To what extent do users “own” this data, and what obligations do the service providers have? What obligations should they have? Does moving the data to the provider’s data center improve security or endanger it?
  • Collaboration and globalization: Cloud computing systems offer new sharing and collaboration features beyond what was possible before. They make shared creation among far-flung users easier, allow or require data to be stored in many different jurisdictions, and give users access to offerings that may be illegal in the users’ home countries. How will local laws, when applied to data centers whose user base is global, affect users practice? Do these services drive forward economic growth — and if so, what effect should that fact have on the policy debate?
  • New roles for new intermediaries: Cloud services often involve new
    intermediaries such as Facebook, MySpace, eBay, and Second Life, standing between people who might have interacted more directly before these services emerged. To what extent are these services “communities”, as their providers claim? How much control do users feel over these communities? How much control do and should users actually have? How does the centralized nature of these intermediaries affect the efficiency and diversity of online experiences? Can the market protect consumers and competition, or is government oversight needed?
  • What’s next: What new services might develop, and how will today’s services evolve? How well will cloud computing be likely to serve users, companies, investors, government, and the public over the longer run? Which social and policy problems will get worse due to cloud computing, and which will get better?

Slysoft Commercializes Next-Gen DVD Circumvention

We’ve been following, off and on, the steady meltdown of AACS, the encryption scheme used in HD-DVD and Blu-ray, the next-generation DVD systems. By this point, Hollywood has released four generations of AACS-encoded discs, each encrypted with different secret keys; and the popular circumvention tools can still decrypt them all. The industry is stuck on a treadmill: they change keys every ninety days, and attackers promptly reverse-engineer the new keys and carry on decrypting discs.

One thing that has changed is the nature of the attackers. In the early days, the most effective reverse engineers were individuals, communicating by email and pseudonymous form posts. Their efforts resulted in rough but workable circumvention tools. In recent months, though, circumvention has gone commercial, with Slysoft, an Antigua-based maker of DVD-reader software, taking the lead and offering more polished tools for reading and ripping AACS discs.

You might wonder how a company that makes software for playing DVDs got into the circumvention business. The answer has to do with AACS’s pickiness about which equipment it will work with. My lab, for example, has an HD-DVD drive and some discs, which we have used for research purposes. But as far as I know, none of the computer monitors we own are AACS-approved, so we have no way to watch our lawfully purchased HD-DVDs on our lawfully purchased equipment. Many customers face similar problems.

If you’re selling HD-DVD player software, you can tell those customers that your product is incompatible with their equipment. Or you can solve their problem and make their legitimately purchased discs play on their legitimately purchased equipment. Of course, this will make you persona non grata in Hollywood, so you had better hire a few reverse engineers and get to work on some unauthorized decryption software – which seems to be what Slysoft did.

Now Slysoft faces the same reverse engineering challenges that Hollywood did. If Slysoft’s products contain the secrets to AACS decryption, then independent analysts can extract those secrets and clone Slysoft’s AACS decryption capability. Will those who live by reverse engineering die by reverse engineering?

Further adventures in personal credit

In our last installment, I described how one of the mortgage vendors who I was considering for the loan for my new home failed to trigger the credit alerting mechanism (Debix) to which I was signed up. Since then, I’ve learned several interesting facts. First, the way that Debix operates is that they insert a line into your credit reports which says, in effect, “you, the reader of this line, are required to call this 1-800 telephone number, prior to granting credit based on what you see in this report.” That 800-number finds its way to Debix, where a robot answers the phone and asks the human who called it for their name/organization, and the purpose of the request. Then, the Debix robot calls up their customer and asks permission to authorize the request, playing back the recordings made earlier.

The only thing that makes this “mandatory” is a recent law (sorry, I don’t have the citation handy) which specifies how lenders and such are required to act when they see one of these alerts in a credit report. The mechanism, aside from legal requirements, is otherwise used at the discretion of a human loan officer. This leads me to wonder whether or not the mechanism works when there isn’t a human loan officer involved. I may just need to head over to some big box store and purchase myself something with an in-store instant-approval credit card, just to see what happens. (With my new house will inevitably come a number of non-trivial expenses, and oh what great savings I can get with those insta-credit cards!)

So does the mechanism work? Yesterday morning, as I was getting into the car to go to work, my cell phone rang with an 800-number as the caller-ID. “Hello?” It was the Debix robot, asking for my approval. Debix played a recording of an apparently puzzled loan officer who identified herself as being from the bank that, indeed, I’m using for my loan. Well that’s good. Could the loan officer have been lying? Unlikely. An identity thief isn’t really the one who gets to see the 800-number. It’s the loan officer of the bank that the identity thief is trying to defraud who then makes the call. That means our prospective thief would need to guess the proper bank to use that would fool me into giving my okay. Given the number of choices, the odds of the thief nailing it on the first try are pretty low. (Unless our prospective thief is clever enough to have identified a bank that’s too lazy to follow the proper procedure and call the 800-number; more on this below).

A side-effect of my last post was that it got noticed by some people inside Debix and I ended up spending some quality time with one of their people on the telephone.  They were quite interested in my experiences.  They also told me, assuming everything is working right, that there will be some additional authentication hoops that the lender is (legally) mandated to jump through between now and when they actually write out the big check. Our closing date is next week, Friday, so I should have one more post when it’s all over to describe how all of that worked in the end.

Further reading: The New York Times recently had an article (“In ID Theft, Some Victims See an Opportunity“, November 16, 2007) discussing Debix and several other companies competing in the same market. Here’s an interesting quote:

Among its peers, LifeLock has attracted the most attention — much of it negative. In radio and television ads, Todd Davis, chief executive of LifeLock, gives out his Social Security number to demonstrate his faith in the service. As a result, he has been hit with repeated identity theft attacks, including one successful effort this summer in which a check-cashing firm gave out a $500 loan to a Texas fraudster without ever checking Mr. Davis’s credit report.

Sure enough, if you go to LifeLock’s home page, you see Mr. Davis’s social security number, right up front. And, unsurprisingly, he fell victim because, indeed, fraudsters identified a loan organization that didn’t follow the (legally) mandated protocol.

How do we solve the problem? Legally mandated protocols need to become technically mandatory protocols. The sort of credit alerts placed by Debix, LifeLock, and others need to be more than just a line in the consumer’s credit file. Instead, the big-3 credit bureaus need to be (legally) required not to divulge anything beyond the credit-protection vendor’s 800-number without the explicit (technical) permission of the vendor (on behalf of the user). Doing this properly would require the credit bureaus to standardize and implement a suitable Internet-based API with all the right sorts of crypto authentication and so forth – nothing technically difficult about that. Legally, I’d imagine they’d put up more of a fight, since they may not like these startups getting in the way of their business.

The place where the technical difficulty would ramp up is that the instant-credit-offering big-box stores would want to automate their side of the phone robot conversation. That would then require all these little startups to standardize their own APIs, which seems difficult when they’re all still busily inventing their own business models.

(Sidebar: I set up this Debix thing months ago. Then I get a phone call, out of the blue, that asked me to remember my PIN. Momentary panic: what PIN did I use? Same as the four-digit one I use for my bank ATM? Same as the six-digit one I uses for my investment broker? Same as the four-digit one used by my preferred airline’s frequent flyer web site which I can’t seem to change? Anyway, I guessed right. I’d love to know how many people forget.)