Do we Understand OBA and Tracking?

With all the discussion in the social and political spheres about online behavioral advertisements (OBA), there's an awful lot of heat underneath the two points of view about tracking.  On one side, people are firmly asserting that most folks don't want targeted ads, while on the other side the assertion is that targeted ads are much much better (and less annoying) and people actually prefer them.

I think there's a bit of a gap in which assumptions are employed.  It's not clear how much the average consumer knows about targeted ads, and without knowing that, we can't assume anything about what they want. Furthermore, if we ask questions that assume unknowns, the results are useless -- asking for approval of targeted ads means two different things if the respondent does or does not understand that the ad network has to profile them to accomplish this.

Collecting Data.
First of all, it's important to acknowledge that these ad networks are already accumulating a whole lot of information for a variety of purposes: click-through rates, ad placement effectiveness, ROI, etc.  They just don't directly tell consumers about this.  In fact, many networks have been tracking individuals from ad impression all the way through purchase (conversion tracking) as yet another metric of successful advertising -- and for those of you who buy ads, you understand how powerful this knowledge is.  These already existing uses of data are incredibly helpful for advertisers (and the networks too, for ad placement), but it's not clear if consumers realize this is happening.

Online behavioral advertising is probably just a new use for already collected data.  The data's already warehoused, and it would take an awful lot of arm-twisting to reduce what ad networks collect -- because it's used for more than just OBA.

So I think the set of questions we ask consumers should be changed from "do you want targeted ads?" to the more precise pair of queries: "is it acceptable for ad networks to build a profile on you?" and "may ad networks use this profile to customize ads you see?"  We don't yet understand if people want this data collected, moreover want it used for OBA.  This distinction is necessary, because I think there are three groups of people here:

1. people who don't want a profile built or their browsing habits recorded at all.
2. people who accept conversion tracking but want to see the same ads as everyone else.
3. people who accept tracking and want the profile created to be used for displaying targeted ads.

My hunch is that group 2 is smaller than 1 and 3, but I haven't seen a survey measure precisely this.

Measuring Desire.
Gallup has taken a step to gather preliminary information about consumer preference; unfortunately, it only seems to address the vague question "is it okay if ad networks show you custom ads?"  I'd really like to see a series of questions that measure habit-tracking approval as well as approval for use of tracking in OBA.  Once we know this, we can figure out if people need a tool to opt-out of data collection, or if a tool to control data use is enough.

My personal point of view (not that of my employer or anyone else) is that OBA is not an invasion of privacy -- the stealth collection of data about my preferences is the invasion.  Perhaps it's worth the convenience like cell phones or ez-pass toll devices, or perhaps it's not.  Whether or not this invasion of privacy is acceptable should be ultimately up to you.  As with many things, you can trade bits of privacy for something new.  Would you like to "buy" better ads with your browsing history?

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.