Slashdot Mirror

ephraim writes "According to The Privacy Foundation, Microsoft Word documents have a 'feature' which allows the documents' creators to place web bugs within the documents that inform the author whenever somebody has opened the document via a web server's logging facilities. This 'feature' can also be used to set and view cookies on the reader's copy of Internet Explorer. The story can be found here. While this might be useful for tracking the distribution of confidential documents, it also raises serious red flags about privacy since most people probably aren't expecting their copy of MSWord to announce their reading habits every time they use it." Props to their CTO Richard M. Smith.

Here is what Microsoft had to say about it (emphasis added)...

Vendor Contact and Response

Microsoft was contacted about this issue on 8/4/00, and again on 8/25/00. They confirmed that Microsoft Word will access the Internet in order to fetch Web images that are linked to in a Word document. They went on to say that Word uses Internet Explorer to fetch images and therefore standard Web browser cookies can be both read and set from inside a Word document. However, the company claims that Word users can mitigate the use of cookies.

Regarding the potential use of Web bugs to track Word documents, Microsoft said that there is no evidence that such activities are occurring.

Three days ago, a small group called Interhack was featured in an AP wire story about some curious data transmission they'd found. The company receiving the data, Coremetrics, tracks unique visitors through its clients' corporate websites, and promises those clients "seamless performance," because: "data tags load invisibly as small transparent gifs, and information is encrypted to appear invisible to your customer." The customer is you, the user. The GIFs are web bugs. The information can be personally identifying, which most of its clients' privacy policies fail to mention. But -- importantly -- the company promises that "Any data Coremetrics tracks and reports is owned solely by our customers and we are contractually precluded from reselling or using this data." Is that enough? Emmett and I talked both to Coremetrics and to the hackers who put the spotlight on them.

Emmett Interviews Interhack

Slashdot: For those uninitiated, what's interhack all about?

Basically, we're a firm of hackers interested in pushing technology forward through research, making computing apply to people by developing custom products and consulting for folks who want to put the technology to use, and helping people understand exactly what the ramifications of these systems are. That's a pretty broad way of saying that we're all about the Internet and making it work.

Slashdot: When did you start researching this story, and how long did it take to put the pieces together?

Sometime in May, someone sent us a tip about Coremetrics and what it's doing. We took a quick look over their web site to see their advertised services and then started to look at how the service is actually implemented on various client sites. We examined several sites, most of which very clearly stated in their privacy policies that they're using Coremetrics for site monitoring and provided links necessary for people who don't like it to opt out of the system. Most of the sites with clear, full disclosure policies weren't even sending Coremetrics personally-identifiable information like names and addresses.

The more interesting part of our find was in the sites that did send personal information to Coremetrics, particularly those that carried the TRUSTe privacy seal. Over the course of about three weeks, we performed an investigation of these sites, gathering as much information as possible from them. We reverse-engineered the system by reading the sites' code, reading through the obfuscation, and comparing logs of our network's activity with the activity that would be perceived by an end user.

What we found was a clear difference in user expectations and what was actually happening, as well as a clear difference between what Coremetrics says it offers and what its eLuminate service makes technically feasible. After writing drafts of our report and press release, we decided to take a wait-and-see approach to the release. Specifically, we wanted to ensure that sites that just started to use the Coremetrics service had adequate time to update their policies and to have an accurate idea of what was happening with the system after having been in production.

After waiting and watching for more than a month, we decided to release our findings. So, on Monday morning, we sent a pre-release copy of our report to Richard Smith and some folks at Zero Knowledge Systems. In addition, we contacted each of the firms named in our report and Coremetrics so that if the failure to disclose or the ability to profile people across web sites was unintentional, there would be time for some investigation and a decision about how to fix the problem. After the end of business Monday, we released our report.

Slashdot: What needs to change? In a perfect world, how do we deal with this?

This is a very interesting question. In my perfect world, detailed levels of profiling would not take place at all. There would be no such thing as persistent cookies. In general, I'm just not comfortable with the level of privacy that the industry as a whole has given up for the sake of a little convenience.

How big of a deal, really, is it to have to enter your password when you login to a web site? Don't forget that the reason why we have passwords in the first place is so that you'll have to do something at the beginning of the session to prove who you are.

Web browsers also need to be more intelligent. That is, they need to be able to identify things like dependencies on third parties so the user can know whether those images should be fetched or ignored. Right now, browsers -- for the most part at least -- just aren't very defensive. The model of parsing everything you're given worked fine in the Old Days for which some of us long so much but the fact of the matter is that you really can't blindly trust anyone on the Internet.

I'm not suggesting becoming a luddite. I'm suggesting that folks take a sort of "trust, but verify" approach a la Ronald Reagan. Right now, there's a lot of trust and almost no way to verify.

Slashdot: This all comes down to trust. How many policies are just there so people will shut up about personal information so they'll start buying stuff online?

I couldn't say. Policies are almost always written by lawyers. That probably speaks to the covering-one's-posterior-position value of privacy policies.

Slashdot: Since we can't trust written policies, what should people be doing before they start conducting business with these websites?

Verify everything. As I said earlier, though, we're severely lacking in tools that are accessible to most people that can help in that regard. I think Zero Knowledge Systems' Freedom network is a huge step in the right direction. Tools like Muffin (muffin.doit.org) also help, but it would be cooler for that kind of functionality to live right in the browser itself. There are opportunities for eager hackers on this front.

It's also important to stress that tools alone won't do it -- there is no silver bullet. People are going to have to have some understanding of what's happening in order to use these tools effectively.

Finally, where you see discrepancies, point them out. Most of the time, they're oversights. Look at how Lucy.com and Fusion.com dealt with this problem: they updated their sites. So although the problem shouldn't have happened in the first place, they did the right thing. Contrast that with Toys "R" Us, which issued a statement saying that what they're doing isn't a violation. And their privacy policy still doesn't say a word about Coremetrics. They still haven't said anything to address the issue of having information collected on children.

Companies that don't fix their problems don't take your privacy seriously, no matter how much lip service they pay. So don't go to their sites. Don't buy their stuff. Tell them why you're not buying their stuff. Tell their competitors why you shop where you do, lest the new places you shop get the bright idea to try to hide something.

Jamie Talks to Coremetrics

Here's the service Coremetrics provides to corporate websites:

Many companies demand accurate knowledge of how their sites are being used: what sections are popular, what paths visitors take through the site, where people click over from, and so on. It's like web log analysis but more specialized for large shopping sites.

Since these demands are very much the same, and the code to do the analysis is similar, outsourcing happens. From a CEO's viewpoint, Coremetrics fiddles with the website to do better-quality tracking than the company could do on its own, and then makes the resulting statistics available over SSL.

But from your viewpoint and mine, that "fiddling" results in cookie-carrying web bugs all over the sites we visit -- web bugs which usually send back to the Coremetrics servers a unique visitor tag, like any other cookie, but one that sometimes includes your name, email address or other personally identifying information.

Coremetrics promises that this information remains private. When DoubleClick collects data from <img> cookies across multiple websites, they do so with the stated intention of tracking you personally; this is part of their business plan.

According to Coremetrics, they do things very differently. Data is not cross-correlated between their client websites, they say, because their contracts with their clients prohibit this. In fact, their contract forbids them from doing much of anything with that data except statistical analysis.

I gave the Coremetrics PR person I talked to a chance to explain, using the example of their client Toys 'R' Us:

"Coremetrics is merely an agent that collects this data on behalf of an individual customer, for that individual's sole use only. We do not collect data, as was inferred very incorrectly by Interhack, across multiple unrelated websites, with any intention of selling it to third parties -- or even distribution to third parties. That's because we, as the agent, do not own that data, nor do we have any rights to that data. Toys 'R' Us, and Toys 'R' Us only, is the sole owner of that data. So legally, we cannot do any of the possibilities that Interhack had alluded to in their report."

But here's the interesting thing.

If I'm browsing my favorite website, Coremetrics is clearly a third party. They have a special contractual relationship to keep my data private, which we shouldn't ignore. But nevertheless -- a third party.

So why do some of their clients' privacy policies not mention this?

Toys 'R' Us is a good example. As Interhack made clear, they do send personal data to Coremetrics' servers. But their privacy policy reads, "We do not share any personally identifying data about our guests with anyone outside of Toysrus.com, its parent, affiliates, subsidiaries, operating companies and other related entities."

So is Coremetrics one of their affiliates or a related entity? I wouldn't think so, but I'm not a lawyer. One interesting thing is hidden in that privacy policy's HTML; after the closing </html> tag is the hidden message: "<!--CoreMetrics Information if enabled-->." Hmmmmmm.

Coremetrics lists twenty clients; I tried to contact seventeen of them for comment, with marginal success by press time. Three reported that they had not yet activated Coremetrics or had decided not to use the service at all. One (guru.com) reported not sending any personal information -- presumably, only tracking visitors with a non-identifying unique ID.

Two sites (lucy.com and fusion.com) began mentioning Coremetrics in their privacy policies on August 1, the day after the Interhack report. One site (thewest.com) did not even have a privacy policy until yesterday; they'd been working on it, and my email may have made it a priority because it was on their site three hours later.

According to Coremetrics, they encourages all their clients to disclose the use of their service in their privacy policy, and include a link for users to opt out. But some sites reported as using or planning to use Coremetrics' services have privacy policies that could use some clarification.

Altrec.com informs me that "...in the near future ... we plan to add to our privacy statement our use of Coremetrics and the fact that Coremetrics neither owns, distributes, nor has rights to the data it sorts on Altrec.com's behalf." However, their current privacy policy states very simply: "Altrec.com will never sell or give your e-mail address (or any other information about you) to anyone else without your permission. Period."

(Last-minute update -- just before press time, Altrec.com clarified that they are "sending unique ID (unique to Altrec.com) and city, state and zip. No other personally identifiable information is being sent to Coremetrics.")

Bravanta.com bounced me between different people until I got to leave voicemail that wasn't returned by press time. Their policy says they "do not and will not sell, trade or rent the personal information of our customers or gift recipients to any third parties."

(Update two hours later: Bravanta reports that they also have decided not to use Coremetrics' service, and are not currently using it.)

Mall.com didn't get back to me either, and their policy reads "We will NEVER release your name and personal information to a third party..."

Getplugged.com has a rather confusing privacy statement that begins, "Any personally identifiable information GetPlugged.com collects will be used solely for the purposes stated within this Privacy Statement" and wanders around from there. I'm not sure what to make of it, frankly.

All these polices may indeed be correct, if the sites are stingy with personal data. Like guru.com (and altrec.com), they may be using the Coremetrics service only with non-personal IDs. But, as with Toys 'R' Us, that may also not be the case.

(fusion.com, getplugged.com, and altrec.com also happen to be TRUSTe licensees, but TRUSTe wasn't able to comment by press time. In the AP wire story on Monday, they had harsh words but were speaking hypothetically; no comment since then.)

It's hard enough to read privacy policies already. Most of them are designed to protect companies legally, and mostly manage to confuse users. The distinction between Coremetrics as a third party; or affiliate; or agent, is a little too fine for the average consumer, and needs to be spelled out in each policy, as Coremetrics itself recommends.

But is all this a tempest in a teapot? If a signed contract forbids a company from misusing data, is that all we need to know?

I don't think so. In the first place, at the very least, companies like Toys 'R' Us need to disclose such things in their privacy policies. That's just common sense.

In fact, according to Coremetrics privacy advisor Dave Farber, they plan contractually to require such disclosure with future clients. (The company could not confirm or deny this at this time.)

More importantly, we as consumers are being asked to trust a third party whose reputation we know nothing about. In fact, 99% of us will never even have heard of them and might not understand what they do. We're told that a contract protects us, but we're still being asked to trust something we can't see. And when evidence of policy violations is turned up by a group of hackers, that erodes our trust.

After speaking at length with Coremetrics' PR, I get a general feeling of trust from them. (Of course that's a large part of their PR staff's job, earning reporters' trust.) More importantly, Dave Farber is well-respected, and his confidence carries weight -- with me at least.

Still, as Interhack says, our motto should be "trust but verify." That's why I proposed, to Coremetrics, that they publicly post, on their website, the paragraphs from their clients' contracts which assure that our private data remains private. If the actual legal words that protect our data are up there for us to see, we don't have to trust anyone.

When I mentioned this to Coremetrics' PR person, he promised to consider it; Dave Farber thought it was "a very good idea." It's unusual for corporations to make contracts public, even in part, but in this case it would do a great deal to put everyone's fears to rest.

Three days ago, a small group called Interhack was featured in an AP wire story about some curious data transmission they'd found. The company receiving the data, Coremetrics, tracks unique visitors through its clients' corporate websites, and promises those clients "seamless performance," because: "data tags load invisibly as small transparent gifs, and information is encrypted to appear invisible to your customer." The customer is you, the user. The GIFs are web bugs. The information can be personally identifying, which most of its clients' privacy policies fail to mention. But -- importantly -- the company promises that "Any data Coremetrics tracks and reports is owned solely by our customers and we are contractually precluded from reselling or using this data." Is that enough? Emmett and I talked both to Coremetrics and to the hackers who put the spotlight on them.

Emmett Interviews Interhack

Slashdot: For those uninitiated, what's interhack all about?

Basically, we're a firm of hackers interested in pushing technology forward through research, making computing apply to people by developing custom products and consulting for folks who want to put the technology to use, and helping people understand exactly what the ramifications of these systems are. That's a pretty broad way of saying that we're all about the Internet and making it work.

Slashdot: When did you start researching this story, and how long did it take to put the pieces together?

Sometime in May, someone sent us a tip about Coremetrics and what it's doing. We took a quick look over their web site to see their advertised services and then started to look at how the service is actually implemented on various client sites. We examined several sites, most of which very clearly stated in their privacy policies that they're using Coremetrics for site monitoring and provided links necessary for people who don't like it to opt out of the system. Most of the sites with clear, full disclosure policies weren't even sending Coremetrics personally-identifiable information like names and addresses.

The more interesting part of our find was in the sites that did send personal information to Coremetrics, particularly those that carried the TRUSTe privacy seal. Over the course of about three weeks, we performed an investigation of these sites, gathering as much information as possible from them. We reverse-engineered the system by reading the sites' code, reading through the obfuscation, and comparing logs of our network's activity with the activity that would be perceived by an end user.

What we found was a clear difference in user expectations and what was actually happening, as well as a clear difference between what Coremetrics says it offers and what its eLuminate service makes technically feasible. After writing drafts of our report and press release, we decided to take a wait-and-see approach to the release. Specifically, we wanted to ensure that sites that just started to use the Coremetrics service had adequate time to update their policies and to have an accurate idea of what was happening with the system after having been in production.

After waiting and watching for more than a month, we decided to release our findings. So, on Monday morning, we sent a pre-release copy of our report to Richard Smith and some folks at Zero Knowledge Systems. In addition, we contacted each of the firms named in our report and Coremetrics so that if the failure to disclose or the ability to profile people across web sites was unintentional, there would be time for some investigation and a decision about how to fix the problem. After the end of business Monday, we released our report.

Slashdot: What needs to change? In a perfect world, how do we deal with this?

This is a very interesting question. In my perfect world, detailed levels of profiling would not take place at all. There would be no such thing as persistent cookies. In general, I'm just not comfortable with the level of privacy that the industry as a whole has given up for the sake of a little convenience.

How big of a deal, really, is it to have to enter your password when you login to a web site? Don't forget that the reason why we have passwords in the first place is so that you'll have to do something at the beginning of the session to prove who you are.

Web browsers also need to be more intelligent. That is, they need to be able to identify things like dependencies on third parties so the user can know whether those images should be fetched or ignored. Right now, browsers -- for the most part at least -- just aren't very defensive. The model of parsing everything you're given worked fine in the Old Days for which some of us long so much but the fact of the matter is that you really can't blindly trust anyone on the Internet.

I'm not suggesting becoming a luddite. I'm suggesting that folks take a sort of "trust, but verify" approach a la Ronald Reagan. Right now, there's a lot of trust and almost no way to verify.

Slashdot: This all comes down to trust. How many policies are just there so people will shut up about personal information so they'll start buying stuff online?

I couldn't say. Policies are almost always written by lawyers. That probably speaks to the covering-one's-posterior-position value of privacy policies.

Slashdot: Since we can't trust written policies, what should people be doing before they start conducting business with these websites?

Verify everything. As I said earlier, though, we're severely lacking in tools that are accessible to most people that can help in that regard. I think Zero Knowledge Systems' Freedom network is a huge step in the right direction. Tools like Muffin (muffin.doit.org) also help, but it would be cooler for that kind of functionality to live right in the browser itself. There are opportunities for eager hackers on this front.

It's also important to stress that tools alone won't do it -- there is no silver bullet. People are going to have to have some understanding of what's happening in order to use these tools effectively.

Finally, where you see discrepancies, point them out. Most of the time, they're oversights. Look at how Lucy.com and Fusion.com dealt with this problem: they updated their sites. So although the problem shouldn't have happened in the first place, they did the right thing. Contrast that with Toys "R" Us, which issued a statement saying that what they're doing isn't a violation. And their privacy policy still doesn't say a word about Coremetrics. They still haven't said anything to address the issue of having information collected on children.

Companies that don't fix their problems don't take your privacy seriously, no matter how much lip service they pay. So don't go to their sites. Don't buy their stuff. Tell them why you're not buying their stuff. Tell their competitors why you shop where you do, lest the new places you shop get the bright idea to try to hide something.

Jamie Talks to Coremetrics

Here's the service Coremetrics provides to corporate websites:

Many companies demand accurate knowledge of how their sites are being used: what sections are popular, what paths visitors take through the site, where people click over from, and so on. It's like web log analysis but more specialized for large shopping sites.

Since these demands are very much the same, and the code to do the analysis is similar, outsourcing happens. From a CEO's viewpoint, Coremetrics fiddles with the website to do better-quality tracking than the company could do on its own, and then makes the resulting statistics available over SSL.

But from your viewpoint and mine, that "fiddling" results in cookie-carrying web bugs all over the sites we visit -- web bugs which usually send back to the Coremetrics servers a unique visitor tag, like any other cookie, but one that sometimes includes your name, email address or other personally identifying information.

Coremetrics promises that this information remains private. When DoubleClick collects data from <img> cookies across multiple websites, they do so with the stated intention of tracking you personally; this is part of their business plan.

According to Coremetrics, they do things very differently. Data is not cross-correlated between their client websites, they say, because their contracts with their clients prohibit this. In fact, their contract forbids them from doing much of anything with that data except statistical analysis.

I gave the Coremetrics PR person I talked to a chance to explain, using the example of their client Toys 'R' Us:

"Coremetrics is merely an agent that collects this data on behalf of an individual customer, for that individual's sole use only. We do not collect data, as was inferred very incorrectly by Interhack, across multiple unrelated websites, with any intention of selling it to third parties -- or even distribution to third parties. That's because we, as the agent, do not own that data, nor do we have any rights to that data. Toys 'R' Us, and Toys 'R' Us only, is the sole owner of that data. So legally, we cannot do any of the possibilities that Interhack had alluded to in their report."

But here's the interesting thing.

If I'm browsing my favorite website, Coremetrics is clearly a third party. They have a special contractual relationship to keep my data private, which we shouldn't ignore. But nevertheless -- a third party.

So why do some of their clients' privacy policies not mention this?

Toys 'R' Us is a good example. As Interhack made clear, they do send personal data to Coremetrics' servers. But their privacy policy reads, "We do not share any personally identifying data about our guests with anyone outside of Toysrus.com, its parent, affiliates, subsidiaries, operating companies and other related entities."

So is Coremetrics one of their affiliates or a related entity? I wouldn't think so, but I'm not a lawyer. One interesting thing is hidden in that privacy policy's HTML; after the closing </html> tag is the hidden message: "<!--CoreMetrics Information if enabled-->." Hmmmmmm.

Coremetrics lists twenty clients; I tried to contact seventeen of them for comment, with marginal success by press time. Three reported that they had not yet activated Coremetrics or had decided not to use the service at all. One (guru.com) reported not sending any personal information -- presumably, only tracking visitors with a non-identifying unique ID.

Two sites (lucy.com and fusion.com) began mentioning Coremetrics in their privacy policies on August 1, the day after the Interhack report. One site (thewest.com) did not even have a privacy policy until yesterday; they'd been working on it, and my email may have made it a priority because it was on their site three hours later.

According to Coremetrics, they encourages all their clients to disclose the use of their service in their privacy policy, and include a link for users to opt out. But some sites reported as using or planning to use Coremetrics' services have privacy policies that could use some clarification.

Altrec.com informs me that "...in the near future ... we plan to add to our privacy statement our use of Coremetrics and the fact that Coremetrics neither owns, distributes, nor has rights to the data it sorts on Altrec.com's behalf." However, their current privacy policy states very simply: "Altrec.com will never sell or give your e-mail address (or any other information about you) to anyone else without your permission. Period."

(Last-minute update -- just before press time, Altrec.com clarified that they are "sending unique ID (unique to Altrec.com) and city, state and zip. No other personally identifiable information is being sent to Coremetrics.")

Bravanta.com bounced me between different people until I got to leave voicemail that wasn't returned by press time. Their policy says they "do not and will not sell, trade or rent the personal information of our customers or gift recipients to any third parties."

(Update two hours later: Bravanta reports that they also have decided not to use Coremetrics' service, and are not currently using it.)

Mall.com didn't get back to me either, and their policy reads "We will NEVER release your name and personal information to a third party..."

Getplugged.com has a rather confusing privacy statement that begins, "Any personally identifiable information GetPlugged.com collects will be used solely for the purposes stated within this Privacy Statement" and wanders around from there. I'm not sure what to make of it, frankly.

All these polices may indeed be correct, if the sites are stingy with personal data. Like guru.com (and altrec.com), they may be using the Coremetrics service only with non-personal IDs. But, as with Toys 'R' Us, that may also not be the case.

(fusion.com, getplugged.com, and altrec.com also happen to be TRUSTe licensees, but TRUSTe wasn't able to comment by press time. In the AP wire story on Monday, they had harsh words but were speaking hypothetically; no comment since then.)

It's hard enough to read privacy policies already. Most of them are designed to protect companies legally, and mostly manage to confuse users. The distinction between Coremetrics as a third party; or affiliate; or agent, is a little too fine for the average consumer, and needs to be spelled out in each policy, as Coremetrics itself recommends.

But is all this a tempest in a teapot? If a signed contract forbids a company from misusing data, is that all we need to know?

I don't think so. In the first place, at the very least, companies like Toys 'R' Us need to disclose such things in their privacy policies. That's just common sense.

In fact, according to Coremetrics privacy advisor Dave Farber, they plan contractually to require such disclosure with future clients. (The company could not confirm or deny this at this time.)

More importantly, we as consumers are being asked to trust a third party whose reputation we know nothing about. In fact, 99% of us will never even have heard of them and might not understand what they do. We're told that a contract protects us, but we're still being asked to trust something we can't see. And when evidence of policy violations is turned up by a group of hackers, that erodes our trust.

After speaking at length with Coremetrics' PR, I get a general feeling of trust from them. (Of course that's a large part of their PR staff's job, earning reporters' trust.) More importantly, Dave Farber is well-respected, and his confidence carries weight -- with me at least.

Still, as Interhack says, our motto should be "trust but verify." That's why I proposed, to Coremetrics, that they publicly post, on their website, the paragraphs from their clients' contracts which assure that our private data remains private. If the actual legal words that protect our data are up there for us to see, we don't have to trust anyone.

When I mentioned this to Coremetrics' PR person, he promised to consider it; Dave Farber thought it was "a very good idea." It's unusual for corporations to make contracts public, even in part, but in this case it would do a great deal to put everyone's fears to rest.

The ever-vigilant Brill's Content sent a freebie to the ever-vigilant Politech that makes us long for vigilante justice. It seems the odds-on favorite for this century's Big Brother, DoubleClick, has contracted to put 1x1 pixel graphic Web bugs on porn and medical sites. Read all about it. But don't worry, we're assured by the porn sites that although "DoubleClick [secretly] collects the information [that you, John Q. Doe, personally spent 12.2 minutes at a girl-on-girl fetish page and then spent 19.7 minutes reading up on your prostate problems], it does not have the technical skill to understand it."

The source code for this news story is the bugzilla report, so read the source if you really want to know what's going on. Mozilla's M15 build has a feature to block webpage images that come from another site: it blocks banner ads. The feature's a little buggy, but it could probably be worked out. Four weeks ago, the feature was removed: "it went the way of management decree" says a Netscape employee. It sounds like AOL-Time-Warner-Netscape didn't want an ad-unfriendly feature in the web browser they're financing. But Mozilla contributors say this has been misinterpreted. What's the real story?

"Please don't jump to conclusions." That's the advice from the developer whose bugzilla postings got people concerned in the first place. OK, so let's take this slow.

Oh, and - this is the second story on Slashdot today that puts generous, overworked open-source contributors under the microscope, and I feel a little bad about that. I hope they understand we're not denigrating their efforts, and that we are grateful for their work.

The feature at issue here lets you block images from a webpage if they come from a foreign site. If you're reading www.slashdot.org, any images from www.foreignsite.net will simply not be loaded. Say, hypothetically, www.doubleclick.net. That would be one example.

Is this the most important feature in the world? Not really. But is it important? Yes. Not just because it blocks most ad banners. It also eliminates what Richard Smith calls web bugs: a technique which can track you across the net without your knowing. The extra privacy is probably a good thing.

(On the bright side, the feature that blocks foreign-site cookies is still in place; this is a very good idea.)

One thing that complicates the issue is that the image-blocking feature was having a few problems. The example given was that, on AltaVista's homepage, the "submit" button graphic comes from a domain owned by the same parent company - but because the domain name is different, the button does not appear. There was concern that users might not understand this. A proposed alternative was to add a dialog warning of such unexpected behavior, and/or to give users more options for how graphics would be blocked.

My thinking is that the problems could have been solved. The person in charge of UI design issues suggested a design workaround that probably would have made the feature quite usable.

I should point out that just because this bug has been marked as WONTFIX, that doesn't mean it won't be reopened; this has happened thousands of times. Actually, now the bug has been marked INVALID, indicating the removal of the feature from the menu is not considered a bug but ... a feature. Well, OK, so its removal was intentional; will the feature be re-added later? Possibly.

But why was this feature removed? In mid-April, shortly after it had disappeared from the current build, one volunteer spoke to a Netscape employee and summarized events as "management had told them to strip the feature."

This sounded uncomfortably like AOL influencing the browser design to suit their needs. I suspect that the Time-Warner media empire might take in a few dollars from banner ads. I suspect they might not like giving users a way to block almost all banner ads with just a few clicks. They don't mind a small percentage of us using a squid proxy, Junkbusters, or creative /etc/hostsing. But to turn that power over to everyone would seriously threaten their revenue stream.

As one might expect, the preview release of Netscape6, the "AOL version" of the browser that was spun off of the Mozilla project, has a preferences dialog that looks a lot like Mozilla's except when it comes to this feature. The foreign-cookie blocker is in place; the foreign-image blocker is not. (But they spun it off an earlier release - maybe the feature wasn't written then; I don't know.)

One of the volunteer developers, at least, has been loudly protesting the implication that anything is wrong. On kuro5hin.org, they are free to state their case and there's some good discussion. And this morning, the same volunteer who originally logged the "went the way of management decree" message appended another log entry, worth reading in full:

"This has gotten a little out of control. The only thing Steve Morse informed me was that as of now, the image blocking prefs have been *publicly* removed from the build. This means that though you CAN still retrieve the feature if you so desire, the menu options and interface are not -- by default -- accessible. This is done often for testing purposes; if something you're working on seems to be conflicting with the image blocking module, you can simply opt to turn it off to complete your work. Who the heck said anything about it being removed permanently? Admittedly, my note wasn't clear, but I think blaming AOL for the supposed 'removal' of this feature is absurd and a little conspiracist, don't you think? To the news sites carrying this: I'm sorry, but what we have here is a nonissue. [...]

"To clarify: the ONLY piece of information Steve gave me was that the feature, as of now, did not appear to be in the latest builds, but really was. His words that the feature 'went the way of management' decree simply refer to the fact that 'management' (NOT AOL management or even AOL-related, mind you) told him to turn the image blocking preference off by default in the latest nightly builds (probably so some technical issues that the feature's causing can be ironed out). That's it - I apologize for the ambiguity of my original words, but they never meant to imply the removal of this feature. Nor did Steve's."

I'm a little skeptical of what would be accomplished by removing this feature from the menu and dialog, but then I'm not the one who's working on the source, am I?

I'm less skeptical about all this now than I was this morning. Part of what worried me was this same volunteer's earlier comment on kuro5hin.org:

"...there's still quite a easy way to get the image blocking preferences back (IMHO, I believe they were removed in the first place because it is ads that heavily supports Netcenter), by adding a certain line in your prefs.js file."

But in email today, he said that this was just a guess and he no longer believes it's true. Fair enough.

Getting any developers to talk about this bug has been like pulling teeth. Only one of the developers I contacted (repeatedly) even bothered to return my email.

What's important to understand is that having to restore the preferences by editing a Javascript preferences text file isn't the same as having it in the right-click menu. If people could block ads with a right-click and just a little poking around, the nature of the web would change drastically.

Finally, here's the same volunteer, again on kuro5hin.org:

"This has been blown way out of proportion.

"I am now hearing from other NSCP employees that this feature has only been taken out temporarily due to complications with the PSM module.

"Furthermore, can you all _please_ stop assuming things from Steve's statement? Steve said it went the way of management decree. This means whatever happened to the image prefs, it came by way of a couple people labeled 'management' (not AOL management, nor AOL-related in any way, mind you). _I_ was the one who suggested the feature was stripped. In reality, this feature may be being improved on, may have been removed temporarily (this happens often to many commonly used features in testing), or a number of other things that would explain its current disappearance.

"Please don't jump to conclusions."

OK. And those are nice hypotheticals for what could be something perfectly ordinary. If the explanation is that simple, though, I wish that someone else had just answered my email to say so.

The nice thing about an open-source web browser is that, even if M16 comes out with a NoPrivacy(tm) feature that uploads everything you do directly to whitehouse.gov, we're all free to fork our own project with the M15 source. We can include this feature or any other.

Conversely, Mozilla is not Netscape 6; AOL is free to add or remove whatever features they like when they release 6.0.1.

But, the official release of Mozilla will be widely distributed. I hope its functionality will be all it could be. If you want the Mozilla development team to make this feature work, and keep it in the next builds, post a comment below to let them know it's important to you. And be nice. They work hard.

No cookies with offsite GIFs: that's the privacy solution implemented by IDcide (take a moment to register the pun, OK, there ya go). Here's technical background on offsite cookies; here's the CNNstory; here's the software FAQ (it's only available for Windows/MSIE). If you're not sure why offsite cookies matter, you must read this. And, not to rain on IDcide's revenue model -- their product does other stuff too -- but why isn't offsite cookie rejection built into all browsers? Anyone from Mozilla want to talk about this?

Today's Chicago Tribune story on Richard M. Smith details his singlehanded crusade to uncover corporate privacy leaks. This one guy has done more than many major organizations to bolster confidence about whether our personal information is getting leaked. He also finds security holes. He's frequently informed Microsoft how they can make their software better (the fix always seems to be "turn off ActiveX"). All I need is a few dozen clones of this guy and I'll feel much better about using the net.

Today's Chicago Tribune story on Richard M. Smith details his singlehanded crusade to uncover corporate privacy leaks. This one guy has done more than many major organizations to bolster confidence about whether our personal information is getting leaked. He also finds security holes. He's frequently informed Microsoft how they can make their software better (the fix always seems to be "turn off ActiveX"). All I need is a few dozen clones of this guy and I'll feel much better about using the net.

Richard Smith just keeps uncovering security holes. Today it's the Email Cookie Leak. By reading mail, you unknowingly register your email address in someone's database, and accept their cookie. Next time you browse their site, or a site they have banner ads or other GIFs on, you are essentially broadcasting your email address while you surf. As Smith points out, just wait until banner-ad companies start taking advantage of this. I repeat the suggestion I made in October: browsers (and all clients that speak HTTP) should reject cookies not sent with the page.

Richard Smith just keeps uncovering security holes. Today it's the Email Cookie Leak. By reading mail, you unknowingly register your email address in someone's database, and accept their cookie. Next time you browse their site, or a site they have banner ads or other GIFs on, you are essentially broadcasting your email address while you surf. As Smith points out, just wait until banner-ad companies start taking advantage of this. I repeat the suggestion I made in October: browsers (and all clients that speak HTTP) should reject cookies not sent with the page.