Tech@FTC

Most attacks are pretty mundane.  Some aren’t, though, and we can learn a lot from them.  Let’s consider the recent case of the New York Times being hacked, allegedly by China.

As has been widely reported, the FTC recently amended its COPPA Rule enforcing the Children’s Online Privacy Protection Act. There’s a lot to be said about the new amendments to the Rule—indeed, a lot is being said—but as this is the FTC Tech Blog, I’m going to restrict my comments to technical aspects. Today, I’m going to talk about signaling—the way that a website can signal its COPPA status to the operators of other sites who provide it with some of the content that users see.

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 c

I’m delighted to succeed Ed Felten as Chief Technologist of the Federal Trade Commission. He’s a hard act to follow! But what does the FTC do, and what is the role of a technologist?

One of the reasons it's hard to think carefully about privacy is that privacy is fundamentally about information, and our (uneducated) intuition about information is often unreliable.

As a teacher, I have tried different approaches to helping students get over this barrier.  It's not too hard to teach the theory, so that students learn how to manipulate logical formulas to answer contrived story problems about information and inference.  What is more difficult is augmenting the formal theory with a more accurate intuition that is useful outside the classroom.

One of the principles of Privacy by Design, as advocated in the FTC Privacy Report, is that when you design a business process, it's a best practice to think carefully about how to minimize the information you collect, retain, and use in that process.  Often, you can implement the feature you want, with a smaller privacy footprint, if you think carefully about your design alternatives.

We use passwords all the time.  Sometimes they're called "PINs" or "access codes" or "lock combinations" but they amount to the same thing, a sequence of symbols that must be provided in order to get access to something.    Passwords have one big advantage: ease of use.  But this comes with several disadvantages.

In recent posts, I explained why hashing and pseudonyms often fail to provide anonymity.  These problems, and the well-known examples of people re-identifying supposedly anonymized data sets, might tempt you into believing that any data set can be re-identified given enough effort or that there is just no way to provide access to data in a privacy-preserving way.   But those conclusions would be incorr

Let's continue our discussion of "anonymous" data by talking about pseudonyms.

A pseudonym is any kind of identifier, other than a name, that is associated with a person or (what often amounts to the same thing) a device.  Pseudonyms are very common.   Examples include the random ID value in a tracking cookie; a device ID such as a WiFi MAC address or a phone's UDID; a synthetic identifier such as an "OpenUDID"; a mobile phone number; or a Twitter handle.