Hello World! I am the new Chief Technologist at the Federal Trade Commission, continuing the blog steps of my predecessors. I am grateful for the service of Ed Felten and Steve Bellovin. With the office developments they have left behind, I am able to blaze a new trail forward.
I've had a great time at the FTC, but today is my last day; I'm returning to academe--what Tom Lehrer aptly described as "ivy-covered professors in ivy-covered halls". In due course, this blog and the @TechFTC Twitter account will be taken over by my successor; stay tuned.
There’s been yet another report of security problems with SSL. If you run a website or mail server, you may be wondering what to do about it. For now, the answer is simple: nothing—and don’t worry about it.
A while back, I wrote about passwords and promised a later post on salting. This is it: a deeper look at how servers should accept and store passwords. This is a complement to the usual articles on passwords, which focus on the user (you know the ones: “pick strong passwords”); here, I’ll be looking at the server side, and in particular how to store passwords for web sites.
It’s a ritual we’ve all grown accustomed to: something needs a software update to repair security flaws. Traditionally, it’s been our computer; increasingly, it’s our smartphones or their apps. In the not very distant future (possibly now, for some of us), it will be our printers, our thermostats, our cars, our “anything that uses software”—and that will be more or less everything. WiFi-controlled light bulbs are already on sale in some countries; if it’s WiFi-controlled, it ma
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.
The FTC has just announced a broad settlement with Google. Let’s talk about one aspect, the consent order on “standard-essential patents” (SEP). It’s an important issue; the New York Times noted that “legal experts say Google’s settlement with the F.T.C. signals progress in clarifying the rules of engagement in high-tech patent battles, and thus could ease them.”
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.
We all know about links on web pages. We’ve all also noticed that links we’ve visited look different.
You’ve never visited this one, right? (I’m pretty sure you haven’t, since the link is to a randomly-generated URL.) On the other hand, if you’re reading this blog you probably have visited http://www.ftc.gov/ or https://www.ftc.gov/news-events/blogs/techftc. (If not, visit one of them now and come back to this page.) You can see from this example how they look on this blog.
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
There are many problems with passwords; Ed Felten explained the issues very well a few months ago. One big problem is that they can be stolen: the bad guys can somehow get hold of your password and use it themselves. But how can this happen? It turns out that there are many different ways, each of which requires a different protective strategy.
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?
[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.]
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.
Today the FTC is announcing new initiatives to address robocalls: those annoying automated sales calls from businesses you have never heard of.
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.
When I wrote previously about differential privacy, a mathematical framework that allows rigorous reasoning about privacy preservation, I promised to work through an example to show how the theory works. Here goes.
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.
I have been writing recently about data and privacy. Today I want to continue by talking about aggregate data. A common intuitions is aggregate data--information averaged or summed over a large population--is inherently free of privacy implications. As we'll see, that isn't always right.
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 conclus