View-source and inspection techniques are probably the most important feature set for the open web. It is creativity lubricant, and helps aspiring web authors learn new tricks. I strongly believe that this is one of the main forces driving rapid innovation on the web. What other platform is so open that you can just pop the hood and take a peek? Yeah yeah, cars have hoods, you can pop them and peek, I know; to make a car you need lots of fabrication equipment or at least parts and an engine hoist, but to make a web site you just need a computer and vi.
Software is a magnificent, intangible product that is completely the result of imagination at work. One could liken it to art: software is a clever rearrangement of bits of digital data whereas art is a clever rearrangement of "bits" of color and texture. When we can inspect how the artist creates, we learn new tricks that evolve our own web-art. A web without inspection tools is like viewing low-resolution copies of famous paintings; the artists' brush strokes and exact color choices aren't present, so hints to any method is gone and you only see the end image. I can't grow my skill as an artist by knowing what other artists paint, but I can learn an awful lot by seeing their brush strokes up close.
When I asked him what he thinks is the best part of the web, Cory Doctorow said "view source." He spends lots of time thinking about technology with respect to its benefits and drawbacks, so I give much credence to his opinion. Inspection is also how I learned to make my bits of the web, so I am a bit partial.
Related:
Friday, May 21, 2010
Monday, May 03, 2010
facebook privacy erosion
I went into my privacy settings on facebook to turn off the "instant personalization" program (I don't really want facebook to provide my info to other sites automatically), and was a little miffed by the experience of disabling it:
First, I unchecked the box that said "Allow select partners to instantly personalize their features with my public information when I first arrive on their websites." This was me reverting backwards towards previous policies facebook had back when it was not sharing data with third party sites.
Anyway, when I checked the box, I got the usual "are you sure?" dialog that attempted to convince me to reconsider. In addition, it let me know that checking the box won't completely opt me out, since my friends will still be leaking my information to these third party sites.
Kudos on facebook for telling me this, but why can't the check box actually control both the data I allow to be transmitted and that sent by my friends? They explain in the dialog (and in fine print on the pref page) that I can block the application and that will stop my data flowing from my friends, but for the life of me I can't figure out what the application is called and how to block it. Any advice here?
I don't like that I have to review the facebook privacy policy and the settings page what seems like every time I log in; this is a nasty side-effect of the slow erosion of their privacy policy and settings. I constantly have to be figuring out what kind of relaxing of the privacy policy facebook is doing next. I realize the importance of monetization (and I'm impressed that they're trying to find something new, something not advertisements to make them money), but I guess I value control of my data a bit more than facebook does.
First, I unchecked the box that said "Allow select partners to instantly personalize their features with my public information when I first arrive on their websites." This was me reverting backwards towards previous policies facebook had back when it was not sharing data with third party sites.
Anyway, when I checked the box, I got the usual "are you sure?" dialog that attempted to convince me to reconsider. In addition, it let me know that checking the box won't completely opt me out, since my friends will still be leaking my information to these third party sites.
I don't like that I have to review the facebook privacy policy and the settings page what seems like every time I log in; this is a nasty side-effect of the slow erosion of their privacy policy and settings. I constantly have to be figuring out what kind of relaxing of the privacy policy facebook is doing next. I realize the importance of monetization (and I'm impressed that they're trying to find something new, something not advertisements to make them money), but I guess I value control of my data a bit more than facebook does.
Friday, April 09, 2010
history sniffing fix has landed
David Baron's history sniffing fix has landed in the trunk repository (VCS nerds, click here for details)! This means you can grab one of our nightly builds and try out the fix for yourself -- but be warned, these nightlies aren't always stable, since they're rapidly changing.
While the fix isn't in the final version of Firefox yet, it should be in the next feature revision (3.7, or whatever major comes up next), and is shipping in alpha releases starting with 1.9.3a4. We're hoping to use the incubation time in nightlies, alphas, and probably a beta or two, to make sure the fix works and get feedback from some users. If you are skeptical about our fix or just want to test drive it, grab a nightly build and let me know what you think!
While the fix isn't in the final version of Firefox yet, it should be in the next feature revision (3.7, or whatever major comes up next), and is shipping in alpha releases starting with 1.9.3a4. We're hoping to use the incubation time in nightlies, alphas, and probably a beta or two, to make sure the fix works and get feedback from some users. If you are skeptical about our fix or just want to test drive it, grab a nightly build and let me know what you think!
Wednesday, March 31, 2010
turning off the :visited privacy leak
Since I started at Mozilla, I've been trying to increase momentum on fixing the history sniffing privacy leak. I've been able to get lots of people interested, and David Baron has worked hard to come up with a fix. This is a hard problem, and the stars have finally aligned: the Firefox source code, our thinking, research, and a need have come together to get this done.
David has nearly finished an implementation of a plug for the leak, and it's a pretty nice solution that strikes a balance between privacy and utility. In the end, we're going to have to break the web, but only a little bit, and in ways we believe can be recreated with other techniques.
The fix has three parts:
I don't think web sites should be able to extract your browsing history without your consent; this is one of the bits of the web that rubs me the wrong way, and I'm excited we've made some progress towards removing this from the web. If it rubs you the wrong way too, and you just can't wait for our upcoming fix, you can turn off all visited links in Firefox 3.5 and newer. This breaks the web even more, but is an immediate hack if you want to hide from the sniffers.
Over the last few years, I've been collecting a list of sites that show how this trick can be abused. Hopefully all of them will stop working with the new fix!
More reading:
David has nearly finished an implementation of a plug for the leak, and it's a pretty nice solution that strikes a balance between privacy and utility. In the end, we're going to have to break the web, but only a little bit, and in ways we believe can be recreated with other techniques.
The fix has three parts:
- :visited is restricted to color changes. Any size or other types of layout/loading effects are disabled. This is foreground, background, border, SVG outline and stroke colors.
- getComputedStyle and similar functions will lie: all links will appear unvisited to the web site, but you'll still see the visitedness when the page is rendered.
- The layout code has been restructured to minimize the difference in code path for laying out visited and unvisited links. This should minimize timing attacks (though it can't remove them all).
I don't think web sites should be able to extract your browsing history without your consent; this is one of the bits of the web that rubs me the wrong way, and I'm excited we've made some progress towards removing this from the web. If it rubs you the wrong way too, and you just can't wait for our upcoming fix, you can turn off all visited links in Firefox 3.5 and newer. This breaks the web even more, but is an immediate hack if you want to hide from the sniffers.
Over the last few years, I've been collecting a list of sites that show how this trick can be abused. Hopefully all of them will stop working with the new fix!
More reading:
Friday, January 29, 2010
cookies by many different names
Cookies are great, and everyone loves them (chocolate chip are my favorite) but if we leave the Internet to its own device it could potentially drive itself into a state of udder deception where other technologies are secretly used in place of cookies for tracking and identification purposes.
Spending the past two days submerged in various privacy discussions, I've started again deeply thinking about cookies and tracking. The fundamental privacy concerns about HTTP cookies (and other varieties like Flash LSOs) come from the fact that such a technology gives a web server too much power to connect my browsing dots. Third-party cookies exacerbate this problem -- as do features like DOM storage, google gears, etc.
Come to think of it, cookies aren't unique in their utility as dot-connectors: browsing history can also be used. A clever site can make guesses at a user's browsing history to learn things such as which online bank was recently visited. This is not an intended feature of browsing history, but it came about because such a history exists.
But wait, cookies, Flash LSOs, DOM storage, and browsing history aren't uniquely useful here either! Your browser's data cache can be used like cookies too! Cleverly crafted documents can be injected into your cache and then re-used from the cache to identify you.
In fact, all state data created or manipulated in a web browser by web sites has the potential to be a signal for tracking or other dot-connecting purposes. Even if the state change seems to be write-only there could be other features that open up the other direction (e.g., the CSS history snooping trick mentioned above -- or timing attacks).
Stepping Back and thinking about these dot-connecting "features" in the context of the last couple days' privacy discussions has got me wondering if there's not a way we can better understand client-side state changes in order to holistically address the arbitrary spewing of identifying information. I think the first step towards empowering users to protect themselves better online is to understand what types of data is generated by or transmitted by the browser, and what can be used for connecting the dots. After we figure that out, maybe we can find a way to reflect this to users so they can put their profile on a leash.
But while we want to help users maintain the most privacy possible while browsing, we can't forget that many of these dot-connecting features are incredibly useful and removing them might make the Web much less awesome. I like the Web, I don't want it to suck, but I want my privacy too. Is there a happy equilibrium?
How Useful is the web with cookies, browsing history and plug-ins turned off? Can we find a way to make it work? There are too many questions and not enough answers...
Spending the past two days submerged in various privacy discussions, I've started again deeply thinking about cookies and tracking. The fundamental privacy concerns about HTTP cookies (and other varieties like Flash LSOs) come from the fact that such a technology gives a web server too much power to connect my browsing dots. Third-party cookies exacerbate this problem -- as do features like DOM storage, google gears, etc.
Come to think of it, cookies aren't unique in their utility as dot-connectors: browsing history can also be used. A clever site can make guesses at a user's browsing history to learn things such as which online bank was recently visited. This is not an intended feature of browsing history, but it came about because such a history exists.
But wait, cookies, Flash LSOs, DOM storage, and browsing history aren't uniquely useful here either! Your browser's data cache can be used like cookies too! Cleverly crafted documents can be injected into your cache and then re-used from the cache to identify you.
In fact, all state data created or manipulated in a web browser by web sites has the potential to be a signal for tracking or other dot-connecting purposes. Even if the state change seems to be write-only there could be other features that open up the other direction (e.g., the CSS history snooping trick mentioned above -- or timing attacks).
Stepping Back and thinking about these dot-connecting "features" in the context of the last couple days' privacy discussions has got me wondering if there's not a way we can better understand client-side state changes in order to holistically address the arbitrary spewing of identifying information. I think the first step towards empowering users to protect themselves better online is to understand what types of data is generated by or transmitted by the browser, and what can be used for connecting the dots. After we figure that out, maybe we can find a way to reflect this to users so they can put their profile on a leash.
But while we want to help users maintain the most privacy possible while browsing, we can't forget that many of these dot-connecting features are incredibly useful and removing them might make the Web much less awesome. I like the Web, I don't want it to suck, but I want my privacy too. Is there a happy equilibrium?
How Useful is the web with cookies, browsing history and plug-ins turned off? Can we find a way to make it work? There are too many questions and not enough answers...
Monday, December 14, 2009
sluggish xorg
I have been fighting with what I thought was a really slow window manager, and so I changed to a lighter weight one and it still took forever to draw things. After fiddling with stuff on and off for a few months, it turns out to be pretty simple: the radeon driver decided to use the CPU for too much of its own job.
I set a couple of flags (thanks to linportal), and everything is speedy again. So if you're fighting with a radeon driver that seems to be worthless (especially with multiple displays) try setting the "MigrationHeuristic" option to "greedy" in your xorg.conf's device section.
Option "MigrationHeuristic" "greedy"
I set a couple of flags (thanks to linportal), and everything is speedy again. So if you're fighting with a radeon driver that seems to be worthless (especially with multiple displays) try setting the "MigrationHeuristic" option to "greedy" in your xorg.conf's device section.
Option "MigrationHeuristic" "greedy"
Friday, November 20, 2009
update on HTTPS security
Version 2.0 of my Force-TLS add-on for Firefox was released by the AMO editors on Tuesday, and in incorporates a few important changes: It supports the Strict-Transport-Security header introduced by PayPal, and also has an improved UI that lets you add/remove sites from the forced list. For more information see my Force-TLS web site.
On a similar topic, I've been working to actually implement Strict-Transport-Security in Firefox. The core functionality is in there, and if you want to play with some demo builds, grab a custom built Firefox and play. These builds don't yet enforce certificate integrity as the spec requires, but aside from that, they implement STS properly.
The built-in version performs an internal redirect to upgrade channels -- before any request hits the wire. This is an improvement over the way the HTTP protocol handler was hacked up by version 1 of Force-TLS, and doesn't suffer from any subtle bugs that may pop up due to mutating a channel's URI through an nsIContentPolicy. I'm not sure that add-ons can completely trigger the proper internal redirect, since not all of the HTTP channel code is exposed to scripts, and add-ons would need to replicate some of the functions compiled into the nsHttpChannel, opening up a possibility of obscure side-effects if the add-on gets out of sync with the binary's version of those functions.
Edit: The newest version of NoScript does channel redirecting through setting up a replacement channel in a really clever way -- pretty much the same as my patch. It replicates some of the internal-only code in nsHttpChannel, though, and it would need to get updated in NoScript if for some reason we change it in Firefox.
On a similar topic, I've been working to actually implement Strict-Transport-Security in Firefox. The core functionality is in there, and if you want to play with some demo builds, grab a custom built Firefox and play. These builds don't yet enforce certificate integrity as the spec requires, but aside from that, they implement STS properly.
The built-in version performs an internal redirect to upgrade channels -- before any request hits the wire. This is an improvement over the way the HTTP protocol handler was hacked up by version 1 of Force-TLS, and doesn't suffer from any subtle bugs that may pop up due to mutating a channel's URI through an nsIContentPolicy. I'm not sure that add-ons can completely trigger the proper internal redirect, since not all of the HTTP channel code is exposed to scripts, and add-ons would need to replicate some of the functions compiled into the nsHttpChannel, opening up a possibility of obscure side-effects if the add-on gets out of sync with the binary's version of those functions.
Edit: The newest version of NoScript does channel redirecting through setting up a replacement channel in a really clever way -- pretty much the same as my patch. It replicates some of the internal-only code in nsHttpChannel, though, and it would need to get updated in NoScript if for some reason we change it in Firefox.
Thursday, November 12, 2009
OWASP AppSec DC '09
I'm at OWASP AppSec DC '09 this week. If you're there too, come find me and say hi!
Subscribe to:
Posts (Atom)