privacy icons - alpha

Aza posted a fantastic discussion of his privacy icons project, including a whole lot of detail about their purpose and use.

I think these little graphics are going to be incredibly helpful for people who are getting more and more excited about how their private data is being used on the global Internet.  Now, these aren't a perfect solution to make data sharing practices transparent, but it can be a powerful tool for those entities who want to be honest and need a way to tell people what they're doing in a concise, recognizable way that doesn't require them to have a law degree.

Link to http://azarask.in/blog/privacy-icons/

bah. blacksheep.

It's a deeply satisfying way to defeat an attacker: give him a taste of his own medicine, and the BlackSheep add-on attempts to do just that. This add-on listens for Firesheep's patterns on the network and warns a user that they are being watched. BlackSheep drops juicy bait for Firesheep (fake session cookies wrapped in legitimate-looking requests to sites) and waits for Firesheep to pick them up. When a Firesheep attacker tries to exploit these fake insecure sessions, BlackSheep picks up on it and alerts its user.

While there are some Firesheep users that will set off this alarm, the problem is a bit more serious. Many attackers have probably looked deeper into the fundamental flaw and also want to protect themselves from such an attack. These folks will be using a security-forcing add-on like Force-TLS, STS-UI on Firefox 4, HTTPS Everywhere or NoScript. All of the protected bad guy's connections to vulnerable sites will be secure, including the sessions that have been copied from other users on the network.

The upshot is that while BlackSheep may see the attacker connecting to vulnerable sites, it won't always know when the bait was taken. For many serious Firesheep-like attacks, BlackSheep will remain quiet.

There are many Firesheep users who are just playing around with the new, hot hacking tool, and so BlackSheep will cry out some of the time; it can't however be relied on to detect most Firesheep attacks. While I like the idea of an alarm like BlackSheep, solving the underlying problem (and stopping serious attackers that are more of a cause for concern) is a bit more complex and requires a different approach. Ultimately, we need to secure wifi networks, protect ourselves with HTTPS-forcing technologies, and ask sites to protect their users by using HTTPS for the whole session.

Managing HSTS Data

I blogged about HTTP Strict-Transport-Security before and how it's all new and shiny in Firefox 4. With all the happy firesheep attacks on the horizon, it's made it even more important that sites start using HSTS.

In case you don't want to wait for your favorite sites to start deploying strict-transport-security, here's a way for you to enable it yourself. I whipped up a quick add-on proof of concept that lets you add and remove HSTS data.

There are two ways to manage HSTS data for sites using this add-on:

1. Navigate to an HTTPS page, open the page info dialog, and tick the "Always access content from this site securely" box
2. Choose the "Manage Strict-Transport-Security..." item from the Tools menu, and enter the host names for your favorite sites there.

Let me know what you think!

UPDATE: Instead of maintaining the add-on in parallel with Force-TLS, I've decided to adapt Force-TLS to use the HSTS bits built into Firefox 4 and show you the same UI. Instead of the STS-UI add-on, try installing Force-TLS!

behavioral advertising icon

I think self regulation in the behavioral ad industry is generally productive, but this IAB press release suggests the newest effort is promoting something that will induce a false sense of disclosure.

This Advertising Option Icon thing is something I heard rumblings about a little while back. The idea is to badge ads that use your behavior, and badge sites who collect your behavior for this use.

A couple of things make me skeptical:

First, this is a stigmatizing mark -- a tattoo that will label pages as "spying" to some and other simply won't notice. I'm willing to bet that such an icon won't be an effective indicator (no matter what the self-regulating body claims) since people
won't pay attention. We all know how poorly the lock icon worked, and people actually paid attention to that one. As an added disincentive, major advertisers have to pay yearly to use the tattoo.

Second, not just advertisers do this tracking, and the advertisers can capitalize on this. They would likely find a way to use third parties for data collection in order to get around the requirement of showing the badge.

Finally, the icon is a play button looking thing. Nothing in the visual suggests what's going on. A pair of eyeballs might be a more intuitive representation.

Icons in web pages aren't going to help. My opinion is that if we want to represent hidden behavior to users we have to have more flexibility. Such visual representations shouldn't be limited to ads, because if we start using icons to represent this tracking behavior for other contexts, the number of icons users must understand multiplies.

Aza's privacy icons project is a good direction; I think it would encompass what is being attempted here without restricting it to ads and with more efficacy since it would be one comprehensive set for all the web.

AppSec USA was great

A bunch of us from Mozilla attended OWASP AppSec USA 2010 in Irvine, and I have to say, it was a pretty great event. There were some bits of the meeting that stood out in my mind as more productive than many conferences or workshops I've attended.

The Booth: we don't often have a vendor booth at security conferences (honestly, what are we selling?), but this time we did and I found it fantastic. A variety of people approached us to learn what security features are available for web sites, and a few had pretty specific questions about CSP.

The Audience: the community present in Irvine was mostly composed of security contractors and security specialists from organizations with big web properties. The meeting was a fantastic opportunity for us to connect with folks who work on securing sites and make sure our efforts in Firefox are pragmatic and useful.

The OWASP Leaders: some of the community leaders from OWASP organized a "browser lunch" meeting with two goals: (1) to bring everyone up to date with what the others are working on and (2) figure out how OWASP can affect the security of the web through browsers. This was an incredible high-bandwidth discussion where we were able to quickly convey all the hard work we're putting into web security and also learn about concerns and new security research being done by industry leaders. It turned out that our goals were pretty much aligned with the security research community, and CSP is a big step in the right direction.

So my takeaway is that OWASP AppSec USA was incredibly productive -- rich with high energy researchers, vast resources and knowledge -- and I am looking forward to working with the OWASP community to reach our common goal of making the web a safer place for us all.

HTTP Strict Transport Security has landed!

It was a year ago now that I first blogged about ForceTLS, and it's matured quite a bit since. I revised ForceTLS to be more robust, and began actually implementing it as HTTP-Strict-Transport-Security in Firefox. I'm excited to say that my patch has been reviewed and landed in mozilla-central.

What's that mean? Look for it in the next beta release of Firefox 4! If you can't wait, grab a nightly build, but when 4.0 is released, HTTP Strict-Transport-Security will be built-in and turned on by default.


Though the feature's core functionality is there, work on HSTS is not completely finished. There are still a few tweaks I'd like to make, mainly providing a decent UI so people can add/remove HSTS state for servers themselves -- but none of this is necessary to be specification compliant. As landed, HSTS is the behind-the-scenes implementation that listens to the HTTP Strict-Transport-Security header and follows those instructions.


In case you don't feel like trawling through the IETF Internet Draft specification but you want to figure out how it works, here's a quick summary:

1. Over an HTTPS connection, the server provides the Strict-Transport-Security header indicating it wants to be an HSTS host. It looks something like this:
   

   Strict-Transport-Security: max-age=60000

   The header's presence indicates the server's desire to be an HSTS host, and the max-age states for how many seconds the browser should remember this.
2. For an HSTS host (e.g., paypal.com), any subsequent requests assembled for an insecure connection to that host (http://paypal.com), will be rewritten to a secure request (https://paypal.com) before any network connection is opened.
3. Optionally, the header can include a second includeSubdomains directive that tells the browser to additionally "upgrade" all subdomains of the serving host. That looks like this:
   

   Strict-Transport-Security: max-age=60000; includeSubdomains

If Firefox knows your host is an HSTS one, it will automatically establish a secure connection to your server without even trying an insecure one. This way, if I am surfing the 'net in my favorite cafe and a hacker is playing MITM with paypal.com (intercepting http requests for paypal.com and then forwarding them on to the real site), either I'll thwart the attacker by getting an encrypted connection to paypal.com immediately, or the attack will be detected by HSTS and the connection won't work at all.

There are more details in the specification, like some further restrictions on cert errors and the like, but this is the general setup, and I believe a pretty nice feature to increase your site's security.


Also: Jeff and Andy at Paypal are working hard at standardizing this.

facebook again

Aarrghh!

I was gonna blog about this new Facebook data collection feature, but why rehash a the same thoughts? From Michael Coates:

"The last thing to consider is facebook's track record on protecting data. How long will it be until advertisers find a way to pilfer this data from people? Or what about the next privacy setting overhaul which changes the defaults or makes it more difficult to control who sees your location data?"

And the vicious cycle begins again. I don't agree that it's all about advertisers (I'm an optimist here), but the wash-rinse-repeat cycle gets tiresome: (1) add new data collection feature (2) public outrage (3) respin privacy settings (4) repeat.

OWASP AppSec USA

Michael Coates writes:

Several Mozilla employees will be attending this year's OWASP AppSecUSA event held in Irvine, CA (Sept 7-10). OWASP conferences focuse entirely on application security and are considered the premier event for this area of security.

I'm one of those mysterious Mozilla folk going to the meeting, and if you're there drop by and say hi. If you're not, you should consider coming! OWASP does wonderful things for web application security, and there are always fantastic talks to look forward to at AppSec USA.

This year, I'm hoping to spread the word about Content Security Policy a bit more; if you run a web site (or better yet, if you secure one) come find us at our booth or harass one of the Mozilla folk in the hallway and we'll be more than happy to help figure out how CSP can make your site more secure for your users.