It's hard to resist the YouTube hotness -- especially if you feel like blogging about the adorable kittens you just saw on YouTube because all your friends must absolutely see it. Sarcasm aside, there are plenty of reasons to embed videos on a blog or web site, but there's something to consider: the embedded video might be used to track your visitors!
Frankly, any content embedded on your site but hosted by another site can cause privacy concerns. When the content is requested, the user's cookies go along with it. The effect is that not only does YouTube know what site a user is on when viewing the kitten video, but they potentially also know who the viewer is! This means that unless you log out of YouTube regularly, they know all the videos you've viewed and on what sites you saw them.
This isn't breaking news. This stuff has been around for a while, it's just Not Obvious.
So you run a blog or web site and you don't want to aid in YouTube tracking your visitors. What do you do? You have three options in my view:
1. Use YouTube's privacy mode. You can embed videos that suppress sending cookies until the visitor has clicked to watch them. This works by changing URLs for any content automatically loaded by your site from the domain "youtube.com" to "youtube-nocookie.com". This way the cookies (for youtube.com) aren't sent until more content is loaded from youtube.com after the click.
2. Don't trust 'em? Use EFF's MyTube. This does something similar, but the static content is loaded from your own site, then when the visitor clicks on the video, it is loaded from youtube.com and the cookies are sent.
3. Open Video FTW! If possible, host the video yourself (on your own website) and use the <video> tag! More info here. Flash is not the only way to display video on the web! Use open standards!
Thursday, July 01, 2010
Thursday, June 03, 2010
open and obvious privacy practices
Lately, there's been all sorts of hubbub about use of private information on websites (ahem, Facebook), but it's not really clear what's okay, and what's not okay.
Personally, I don't have a problem with sites using the data I give them as long as they're straightforward and actually Ask me for the data and admit they'll share it. I'll even hand out more extra credit brownie points if they tell me what the plan to do with it. And I'm not talking about linking to legalese privacy policies (maybe 0.5% of visitors to a site have read the privacy policy), it's gotta be up-front and in the main content. For most people, I imagine the feeling of violation comes in when there's perceived deception in data use practices.
For example, if a site says to me, "if you give me your address, I'll show you a list of stores selling fruit in your area", I'm happy to provide my address for that service. I feel comfortable in knowing what is happening with the data I provide, and this transparency gives me comfort.
On the other hand, if the same site doesn't say anything to me and simply infers my location from some sort of browser history sniffing trick, then shows me the same ads, I'll feel a bit violated when I figure out what happened. There are two points of friction in this second scenario: (1) I wasn't asked for the data, and (2) I was unaware of how the data would be used or with whom it would be shared.
Stephanie Clifford of the Times writes an article about sites that are starting to be transparent and straightforward with their data collection and use. When your users enter into a relationship with you knowing well that you intend to use the data they provide, everything works out swimmingly. If you instead just collect the data and later start using it for something new that users catch wind of, they are shocked, feel violated, and you end up in a predicament like Zuckerberg.
In a few upcoming posts, I'll go more in depth about my thoughts on web privacy. For now I'll conclude with hope that more sites will be upfront and transparent with what they do and will keep descriptions of their privacy-related practices accessible to users--users who armed with an understanding can make an educated choice on whether or not they should be sharing their data.
Personally, I don't have a problem with sites using the data I give them as long as they're straightforward and actually Ask me for the data and admit they'll share it. I'll even hand out more extra credit brownie points if they tell me what the plan to do with it. And I'm not talking about linking to legalese privacy policies (maybe 0.5% of visitors to a site have read the privacy policy), it's gotta be up-front and in the main content. For most people, I imagine the feeling of violation comes in when there's perceived deception in data use practices.
For example, if a site says to me, "if you give me your address, I'll show you a list of stores selling fruit in your area", I'm happy to provide my address for that service. I feel comfortable in knowing what is happening with the data I provide, and this transparency gives me comfort.
On the other hand, if the same site doesn't say anything to me and simply infers my location from some sort of browser history sniffing trick, then shows me the same ads, I'll feel a bit violated when I figure out what happened. There are two points of friction in this second scenario: (1) I wasn't asked for the data, and (2) I was unaware of how the data would be used or with whom it would be shared.
Stephanie Clifford of the Times writes an article about sites that are starting to be transparent and straightforward with their data collection and use. When your users enter into a relationship with you knowing well that you intend to use the data they provide, everything works out swimmingly. If you instead just collect the data and later start using it for something new that users catch wind of, they are shocked, feel violated, and you end up in a predicament like Zuckerberg.
In a few upcoming posts, I'll go more in depth about my thoughts on web privacy. For now I'll conclude with hope that more sites will be upfront and transparent with what they do and will keep descriptions of their privacy-related practices accessible to users--users who armed with an understanding can make an educated choice on whether or not they should be sharing their data.
Friday, May 21, 2010
view source
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:
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:
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"
Subscribe to:
Posts (Atom)