Domain: privacyfoundation.org
Stories and comments across the archive that link to privacyfoundation.org.
Comments · 29
-
Re:I don't blame them...From a users prospective...
Pros:
Easy to get to and use.
Cons:
Where do you "store" your mail and attachments? Keep them on the server?
What if you have multiple accounts? You would have to check multiple web mail sites and or configure one webmail account to use POP to get the other ones. That mean password in the clear to the other accounts AND that password is stored on a third site. I dont know of any webmail sites that can be configured to fetch remote mail in any other manner then plain old POP.
Limited interface and functionality. You are bascially STUCK with whatever layout, filter options, spam solution (or lack of) that the provider feels is best for XXX amount of users they have. You are also stuck with the ads at login, during the session, and after logout (like Hotmail taking you directly to MSN after clicking logout). Hotmail specific but clicking on an email link always keeps Hotmail in a frame at the top of the page like a follow you function, even when opening in a new tab or window.
Stuck with HTML email along with all the web bugs and tracking links. This would be a spammers heaven. Of course with any modern browser (maybe even IE), you can turn of image loading with one click.
IMHO, I like web mail as an option but it is not a long term solutions for me.
-
Re:Images (gif, jpg) used as spam.
Anybody has some insight of this new kind of spam?
Well, if the image was on a remote server, then if your mail client loaded remote images when you read the email (many do) then you've just verified that your email address is valid. This is known as a Web bug. Web bugs are great for tracking when people read your emails,as even if they disable return replies, most still allow image loading.
Disable remote image loading in emails! -
This is already done on toll roads
This is not new. In Melbourne, Australia, a system operating on similar principles for a few years - http://www.perceptics.com/files/LPR.pdf.
Speed cameras here also operate in the same way, and have done so for years. No human will even see your traffic fine after it leaves the police van. The images get transferred back to the central computer, which then scan & enhance it, print the infringement notice and stuff it into a envelope. I assume a human carries it down to the post office. But it can't be to far off before the dammed things are delivered by email.
Scott McNeally's off the cuff comment Privacy is dead, deal with it! is spot on. Slashdotters may have as much trouble accepting that as the RIAA has accepting the way technology has gutted copyright, but the genie is out of the bottle. You can't put it back. No one is going to tear down the cameras that take 300 pictures of your average Londoner a day. No one is going to stop the hire car companies tracking you via satellite. Nobody is going to stop the police tracking your movements by asking Blockbuster when and where you last hired out movies.
David Brin was right. Trying to stop the collection is a lost cause. Instead fight to make your right to know who is collecting such information, what they have collected, and most importantly who has accessed it. If we can't keep their fingers out of our packets, at least we can keep the bastards honest!
-
Tivo, Privacy, and ReplayTV
Whoa there! I feel like
/. has been overrun by Tivo employees or something with all the gushing going on in this thread. ("Cult" of Tivo indeed!) Let's try to remember:
1) Tivo forcing users to record programs
2) The Privacy Foundation's report on Tivo points out that
a) Your Tivo serial number is sent multiple times during each phone call and there is no way to guarantee data is truly treated anonymously except to trust Tivo.
b) Tivo's definition of "personal" information is significantly more narrow than the average privacy policy reader would assume, and so guarantees about your "personal" information are hollow.
c) Tivo suggests that the viewing information is never transmitted. In fact, all of the constituent pieces of the personal viewing information are transmitted to TiVo's computers.
d) TiVo should disclose that their customer-identified diagnostic log can indicate when the TiVo remote control was in use.
3) Anyone heard of Replay TV here? They are actively fighting Hollywood to defend your rights. When a judge tried to force them to spy on users, they fought it. When Hollywood said users shouldn't be allowed to send programs to other devices, they fought it. When the networks said your skipping commercials was "theft", they fought it. I think a company that does all this for the privacy and rights of its users deserves our support (or at least a MENTION on this page).
Brian
Support EFF! http://www.eff.org
They're defending YOUR rights online! -
They have to develop and deploy new software too!
Here's part of the actual order. On April 26, Judge Charles Eick of the U.S. District Court, Central District of California, gave SonicBLUE 60 days to:
(1) take the steps necessary to use their broadband connections with ReplayTV 4000 customers to gather all available information about how users of the ReplayTV employ the devices, including all available information about what works are copied, stored, viewed with commercials omitted, or distributed to third parties with the ReplayTV 4000, when each of those events took place, and the like;
(2) implement Defendants' offer to collect available data from a second source -- the MyReplayTV.com web site -- about how users of the ReplayTV employ the devices, but for all time periods for which that data can be collected, rather than just for a short period;
(3) provide the foregoing data to Plaintiffs in a readily-understandable electronic format and provide any technical assistance that may be necessary for Plaintiffs to review the data;
(4) provide Plaintiffs with all documents about Defendants' consideration of what data to gather or not to gather about their customers' uses of the ReplayTV 4000; and
(5) provide Plaintiffs with any other documents (such as emails or logs) reflecting what works have been copied with the ReplayTV 4000 and how those works have been stored, viewed, or distributed.
Now who gets all of this data? The plaintiffs in the case against SonicBLUE (the makers of the ReplayTV 4000). Roughly, Time Warner, HBO, Warner Brothers, TBS, New Line Cinema, Castle Rock Entertainment, WB TV, MGM Studios, Orion Pictures, 20th Century Fox, Universal City Studios, Fox Broadcasting, Paramount Pictures, Disney, NBC, Showtime, United Paramount Network, ABC, Viacom, CBS, Columbia Pictures, Columbia TV, and Tristar. The plaintiffs are also ordered to pay 3/4 of the cost of gathering the data.
Come on. Our courts have no business ordering a company to spy on its own customers just because big media wants to put the company out of business. We at the Privacy Foundation saw a lot of consumer outrage after we released our report about TiVo's privacy disclosure and practices. TiVo did a pretty good job of responding to the situation; they spent a lot of time with the press, and they wrote a white paper explaining what had happened. (We still have some gripes about their system, but that's another story.) The point is that companies are very sensitive about tweaking their customers' privacy, because they know customers don't have much patience for it. So when the court orders a company to spy on their customers, it's basically a punitive act. The customers will revolt and get mad at everyone. I'm no lawyer, but I'm pretty sure the discovery of evidence phase of a lawsuit isn't supposed to be punitive.
In this case it's worse than just a privacy squabble. Either the court doesn't understand or the court doesn't believe ReplayTV's repeated explanation that they simply don't have the information demanded by this order. See, in April 2001 some months after our TiVo report came out, I showed a ReplayTV exec my traces that proved that their current model also collected some type of viewing information. This scared them, and in May 2001 - before the ReplayTV 4000 existed - they disabled the collection function, since they had never used the data for anything. This is what they told me, and this is what they've sworn to the court in testimony.
Now the ReplayTV 4000 is a different product than the one I investigated, and ReplayTV has said that they never reenabled the old tracking code, nor did they update it to make it monitor the newer features - like automatically skipping commercials and sending recordings to other ReplayTV 4000 units. But that's precisely the type of data that the plaintiffs are demanding to see in this case!
So what we have is a court ordering SonicBLUE to prepare a new software release that implements new spying features, and then ordering them to force it upon all of their customers, out of fairness to Big Media in their case against them. Considering that SonicBLUE has probably updated their customers' software only a few times ever, this is like ordering Microsoft to create, distribute, and maintain a new version of Outlook that checks to see if any of its users are sending MP3s as attachments!
I guess this is a sneak preview of the type of consumer broadband "protection" we can look forward to in the very near future.
What happens next: SonicBLUE is planning to file papers with the overseeing judge in U.S. District court objecting to this order. If that doesn't go their way, then I guess they'll be working on a new software release.
David Martin
http://www.cs.bu.edu/~dm -
They have to develop and deploy new software too!
Here's part of the actual order. On April 26, Judge Charles Eick of the U.S. District Court, Central District of California, gave SonicBLUE 60 days to:
(1) take the steps necessary to use their broadband connections with ReplayTV 4000 customers to gather all available information about how users of the ReplayTV employ the devices, including all available information about what works are copied, stored, viewed with commercials omitted, or distributed to third parties with the ReplayTV 4000, when each of those events took place, and the like;
(2) implement Defendants' offer to collect available data from a second source -- the MyReplayTV.com web site -- about how users of the ReplayTV employ the devices, but for all time periods for which that data can be collected, rather than just for a short period;
(3) provide the foregoing data to Plaintiffs in a readily-understandable electronic format and provide any technical assistance that may be necessary for Plaintiffs to review the data;
(4) provide Plaintiffs with all documents about Defendants' consideration of what data to gather or not to gather about their customers' uses of the ReplayTV 4000; and
(5) provide Plaintiffs with any other documents (such as emails or logs) reflecting what works have been copied with the ReplayTV 4000 and how those works have been stored, viewed, or distributed.
Now who gets all of this data? The plaintiffs in the case against SonicBLUE (the makers of the ReplayTV 4000). Roughly, Time Warner, HBO, Warner Brothers, TBS, New Line Cinema, Castle Rock Entertainment, WB TV, MGM Studios, Orion Pictures, 20th Century Fox, Universal City Studios, Fox Broadcasting, Paramount Pictures, Disney, NBC, Showtime, United Paramount Network, ABC, Viacom, CBS, Columbia Pictures, Columbia TV, and Tristar. The plaintiffs are also ordered to pay 3/4 of the cost of gathering the data.
Come on. Our courts have no business ordering a company to spy on its own customers just because big media wants to put the company out of business. We at the Privacy Foundation saw a lot of consumer outrage after we released our report about TiVo's privacy disclosure and practices. TiVo did a pretty good job of responding to the situation; they spent a lot of time with the press, and they wrote a white paper explaining what had happened. (We still have some gripes about their system, but that's another story.) The point is that companies are very sensitive about tweaking their customers' privacy, because they know customers don't have much patience for it. So when the court orders a company to spy on their customers, it's basically a punitive act. The customers will revolt and get mad at everyone. I'm no lawyer, but I'm pretty sure the discovery of evidence phase of a lawsuit isn't supposed to be punitive.
In this case it's worse than just a privacy squabble. Either the court doesn't understand or the court doesn't believe ReplayTV's repeated explanation that they simply don't have the information demanded by this order. See, in April 2001 some months after our TiVo report came out, I showed a ReplayTV exec my traces that proved that their current model also collected some type of viewing information. This scared them, and in May 2001 - before the ReplayTV 4000 existed - they disabled the collection function, since they had never used the data for anything. This is what they told me, and this is what they've sworn to the court in testimony.
Now the ReplayTV 4000 is a different product than the one I investigated, and ReplayTV has said that they never reenabled the old tracking code, nor did they update it to make it monitor the newer features - like automatically skipping commercials and sending recordings to other ReplayTV 4000 units. But that's precisely the type of data that the plaintiffs are demanding to see in this case!
So what we have is a court ordering SonicBLUE to prepare a new software release that implements new spying features, and then ordering them to force it upon all of their customers, out of fairness to Big Media in their case against them. Considering that SonicBLUE has probably updated their customers' software only a few times ever, this is like ordering Microsoft to create, distribute, and maintain a new version of Outlook that checks to see if any of its users are sending MP3s as attachments!
I guess this is a sneak preview of the type of consumer broadband "protection" we can look forward to in the very near future.
What happens next: SonicBLUE is planning to file papers with the overseeing judge in U.S. District court objecting to this order. If that doesn't go their way, then I guess they'll be working on a new software release.
David Martin
http://www.cs.bu.edu/~dm -
Re:Whats the general opinion on tivo?
decide for yourself
of course they could be biased and things might of changed etc but then they might not and be totally impartial, the choice is yours -
Re:The data mining level is pretty astonishing
Tivo explicitly promises not to use anything more specific than a zip code to identify your viewing details (see point 1.3 of their privacy policy); and that's nothing like as specific as you seem to think - unless everyone in Beverley Hills 90210 lives in the same house. Even UK postcodes aren't that precise: it's simply not true to say that "if i give my postcode to some companies they can tell exactly which house iam living in," unless your house is the size of a football pitch.
And if you don't want Tivo to collect your data at all, you can simply tell them not to. This is clearly stated in their terms and conditions - and indeed in the PrivacyWatch report you quote. Okay, you have to phone them, rather than pushing a button, but it's an offer they're under no obligation to make at all. And they even give you a toll-free number to call!
So I don't see any grounds for complaint. I mean, the users get a service they clearly love (see Slashdot stories passim) for a price they're happy to pay; the advertisers get invaluable data, freely given and broadly anonymous, again for a price they're happy to pay; and Tivo gets the revenue from both sides. Personally, I think that's wonderful. Tivo have managed to broker a stunning win-win business model, and best of luck to them. -
The data mining level is pretty astonishing
The actual level of data collected is way more than just what channel you are watching, the data is so specific it can tell how many times and what time you pressed any button on the remote at any time, be it volume control
,pause buttons anything!
This data to advertisers is known as "gold dust"
advertisers could find out things like:
did you watch their advert if so how many times
did you forward or rewind it if so how far
did you cut the volume if so for how long
did you flip channel if so did you flip it back
when you flipped what advert did you see on the other channel
and just about any viewing habit data they choose , and guess what , your paying a subscription for this service so for Tivo this is a win win win situation and must be laughing in their condos on malibu beach.
now this report is rather biased towards privacy and some say the report is flawed blah blah but the actual captured data logs are not.
Now whereas the data is "anonomous" it is linked to subscribers via postcode/zipcode and certainly here in the UK if i give my postcode to some companies they can tell exactly which house iam living in , not totally anonomous, and after all, they only need to know what the "house" is watching as everyone sits down and watches the same program together so individual advert profiling would be irrelavent.
devices like Tivo could work without selling this data to advertisers but the might hand of marketing is pretty good at persuasding poor companies that the financial recompence is worthwhile.
IMHO the whole point of a Tivo is data collection hence right from the start the units have been designed as profiling devices capturing all available statistical data, i mean what use is recording when i press volume buttons in determining that the simpsons is on and if i would like to watch it ?
the sooner people complain and see these companies for what they really are the better -
Re:Whoa whoa whoa...
"You mean that if I go out and get a Tivo, then they can tell exactly what commercials I watch?"
Yeah. Take a look at this report, which goes into some technical detail about what your TiVo sends back (they watched the modem line as data transferred):
http://www.privacyfoundation.org/privacywatch/ report.asp?id=62&action=0
Your TiVo machine basically just sends its syslog home every night, complete with information like this:
Jan 13 17:42:10 (none) LogTime[94]: WatchTV: change the channel: 0.015 sec
Jan 13 17:42:55 (none) LogTime[94]: Lineup: update the OSD: 0.949 sec
Jan 13 17:42:56 (none) LogTime[94]: Lineup: arrow up/down: 0.011 secExcept it's transmitted in a form that looks like this:
980389520|WatchTV|live|IFC|27666|980384400
980389546|MWEvent|tyTivo
980389550|MWEvent|tySurfDownand of course it's anonymized, traceable only to your zipcode.
The PrivacyFoundation.org report linked above broke the news that the way the anonymized data is FTP'd up to TiVo's homebase leaves a way that an insider employee (or an unscrupulous, lying company) could potentially correlate your syslog to your name, instead of just your zipcode. I've no idea whether TiVo has changed its practices after the report came out two years ago, but I'm not aware of them having done so.
-
Re:Thanks but ill pass on TIvo...why ?
This report by the Privacy Foundation actually spawned an inquiry by the FTC. The facts of the matter, summarized in TiVo's white paper here, were sufficient enough for the Commission to dismiss any further investigation into TiVo's practices. At best, the Privacy's Foundation's report was technically flawed. Judging from their agenda, however, it seems possible that it was deliberatly misleading.
-
Thanks but ill pass on TIvo...why ?
After reading this article i think ill stick to alternative devices, im not into paying someone to sell my viewing habits to advertisers if they are strapped for cash,
im suprised so many pgp military encryption loving /. readers are so nieve or am i .... -
Yes, here is the reply to RMS (fake) email by eEye
From: "Marc Maiffret" <marc@eeye.com>
To: "Richard M. Smith" <rms@privacyfoundation.org>,
"BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@SECURITYFOCUS.COM>
Subject: RE: Can we afford full disclosure of security holes?
Date: Fri, 10 Aug 2001 13:10:51 -0700
After about 3 weeks of little to no sleep and spending lots of my (and Ryan
Permeh's) personal time researching CodeRed and its many variants I have
grown tired of the small number of people who so ignorantly have pointed a
finger at eEye and are trying to somehow get people to think that we are
responsible. As an employee of a company I must hold back some of my
feelings... however as an individual I can tell you that this is all
complete and utter crap.
|Hello,
|
<snip>
|This $20 million figure begs the question was it really
|necessary for eEye Digital Security to release full details
|of the IIS buffer overflow that made the Code Red I and II worms
|possible? I think the answer is clearly no.
Where the hell do you or anyone get off by saying that eEye's advisory made
CodeRed possible? This sort of ignorance being spread in a public forum is
just one of the many things wrong with the security industry. Your making
claims that you have no data to back other than "well I think so."
|Wouldn't it have been much better for eEye to give the details
|of the buffer overflow only to Microsoft? They could have still
|issued a security advisory saying that they found a problem in IIS
|and where to get the Microsoft patch. I realized that a partial
|disclosure policy isn't as sexy as a full disclosure policy, but
|I believe that less revealing eEye advisory would have saved a lot
|companies a lot of money and grief.
Lets get the facts straight. CodeRed is based off of another worm that was
written for a .htr ISAPI buffer overflow. CodeRed is an almost identical
copy of the .htr worm. A worm which was released back in April. A worm which
exploited an UNPUBLISHED vulnerability within IIS which was silently patched
by Microsoft without notification to anyone. Therefore IDS vendors never had
a signature and the .htr worm went unnoticed. To bad a security company had
not found the flaw, then there would have been details, signatures made, and
IDS systems would have detected the first instance of CodeRed back in April.
So the facts are:
Someone found an unknown buffer overflow vulnerability within the IIS .htr
ISAPI filter, without any data from eEye.
Someone exploited that unknown buffer overflow vulnerability in order to
execute code on remote systems, without any data from eEye.
Someone took that exploit even further and turned it into a worm (Which is
what CodeRed is explicitly based off of) and launched it at the Internet,
without any data from eEye.
Now a few months later someone took that .htr worm and modified it to attack
the .ida vulnerability. They already had ALL of the knowledge they needed in
order to modify the .htr worm to be the .ida worm. There was nothing that
eEye gave them that made it any easier.
In fact when it comes down to it technically... eEye's technical exploit
information within the .ida ISAPI overflow advisory was actually put to
shame by a skilled programmer by the name of hsj. hsj published a working
.ida ISAPI overflow exploit which used a wide character overflow technique
which was far beyond (and nothing like) anything we talked about in our
advisory. So technically the CodeRed worm and hsj .ida exploit were
technically superior to anything that we (eEye) discussed in our .ida
advisory. They did not use ANY technique that had anything to do with our
advisory. If you, or any of the other small percentage of people pointing
fingers at eEye, actually had any technical understanding of buffer overflow
exploits then you might have understood that and not sent an eMail to a
public mailing list making harsh accusations which are totally inaccurate
and untrue.
|Unlike the eEye advisory, the Microsoft advisory on the IIS
|security hole shows the right balance. It gives IIS customers
|enough information about the buffer overflow without giving a recipe
|to virus writers of how to exploit it.
This isn't the 70's. People are easily able to write exploits simply from
the data that Microsoft gives within their advisories. To say that hackers
are not able to write exploits solely based off of a Microsoft Advisory is
to underestimate the underground, which is a _bad_ thing to do. Most of the
hackers we know have automated tools that allow them to compare the files
held within a Microsoft security patch to system files that are being
replaced and after running them through custom modules for IDA etc... they
have pinpointed overflows etc... by ONLY using the information held within a
Microsoft security bulletin and its patch.
|Thanks,
|Richard M. Smith
|CTO, Privacy Foundation
|http://www.privacyfoundation.org
There is a big bad world out there far beyond the technical information seen
on mailing lists like Bugtraq.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
-
Re:Comments from a Bugnosis authorThat's not Web bugs leaking the information to a third party, that's the main site deliberately giving that information to a third party. I may have concerns about the main site doing that, but Web bugs don't add anything to that concern IMHO seeing as the conduit exists without Web bugs.
I have to disagree. There is a very important difference between the info transfer with a Web bug (or equivalent) and just sending around log files behind the scenes. Our FAQ covers this.
In the scenario I described, OSDN ends up with both cookies. This allows OSDN to synchronize with Slashdot, allowing both sites to realize they're discussing the same user, no matter when the sites originally assigned the cookies, and without planning to synchronize in advance. If on the other hand Slashdot just sends a log file to OSDN, then the synchronization is much harder to achieve, and in practice, would probably not even be attempted.
Basically, it's the same old third-party cookie synchronization threat. Now, cookie sync can be done with banner ads or other 3rd-party content and is not uniquely associated with Web bugs. But when you encounter a Web bug, it is absolutely clear that (1) it's there for the info transfer alone and (2) it's trying to slip under the radar. That makes it a pretty interesting device, from a policy point of view.
By adding a Web bug to HTML email, you can track the progress of your emails, and under further assumptions, you can even intercept comments added by people who forwarded your email: see our email wiretapping report, originally described by Carl Voth. A yet-to-be-distributed version of Bugnosis examines Outlook and Outlook Express emails for Web bugs too.
-
Comments from a Bugnosis authorYep, we consider the OSDN image to be a Web bug, because it acts as a surreptitious information conduit between slashdot.org, the reader's computer, and osdn.com. Information sent through this path picks up both slashdot and OSDN cookies, so it bypasses the "same domain" rule preventing one domain from manipulating cookies set at another. Of course there's no way for Bugnosis to understand the business relationship and contracts that may restrict the use of the conduit (P3P will help with this). What's absolutely clear is that a facility designed for displaying images is being run in reverse to transmit information without the user's permission or knowledge.
Many people have been asking (cursing, etc.
:) for Mozilla, Mac, Opera etc. support. I think it would be great to investigate, and I have a student trying to learn something about Mozilla now. We just don't have the expertise yet. I'd be very interested in hearing from potential contributors. Heck, just a plugin or diff that shows how we can tap into browsing events and access the DOM in Mozilla could make it possible for us to proceed. Frankly, IE support was pretty easy because of all the books and sample code out there. Besides, we had just finished a long-winded report on IE browser extensions & their privacy practices when we started this project, which made Bugnosis pretty easy to envision.We decided not to make Bugnosis a Web bug blocker, just a good analysis and exposition tool. See, the problem with many "privacy enhancing technologies" is that they put the burden on users to protect themselves. I firmly believe that being concerned about privacy shouldn't mean that you have to make it a huge personal priority, say, by committing time to downloading, maintaining, and upgrading yet another piece of software. Privacy should just be built in. Bugnosis shows how the current infrastructure is being used, and so contributes to the debate on what reasonable standards should be. In the privacy arms race, I'd much rather be a reporter in the trenches than an arms manufacturer -- even defensive arms.
Any CS students interested in working with us? We'll be setting up at Boston University in the fall.
David
-
Hosting Images From (A Higher Bandwidth) ServerMy little web site is hosted from a slow 128k frame relay link. Doing this gets the server on my LAN, which really is needed to enable me to spend my free time working on it. As the traffic has grown (now about 150k pageview/month), my low bandwidth link couldn't keep up. The simple solution was to move the images to a higher bandwidth server.
If you poke around in the html you'll see that the images are hosted at "www.inetarena.com/~pjrc", and of course my site is "www.pjrc.com". Saddly, this web bug thingy will probably tell you that I'm conspiring with inetarena.com to track you, when in fact they're just my ISP providing some server space for the images. There are not web bugs on my site.
I really ought to set up the image server with a domain name like images.pjrc.com. That costs extra (ISPs love to find things to charge for that don't cost anything)... but the cost isn't the primary concern. My little ISP has changed admins and they're not as stable as one might expect paying for frame relay service. I'll probably move to a new ISP soon, and that'll be a good time to set up a proper name for the image server.
The point is that it makes a lot of sense for a site to host bandwidth hogging files from a different server. In my case, it's to facilitate spending my creative energy in my free time on the site (didn't do much on it for a couple years without direct access to the server). I regularily poke around looking at people's html source, and I've seen several major sites use a different server for images, PDF files, etc. It's not an uncommon practice, and there's a lot of good reasons to do it other than tracking users. From what I can see, it looks like the folks at the Privacy Foundation aren't aware of this.
-
Re:Don't like it? Just try to complain...Here's another good one:
To help us make e-mails more useful and interesting, we often receive a confirmation when you open e-mail from Amazon.com if your computer supports such capabilities.
In other words, "we use web bugs".
-
Links
The Privacy Foundation's statement.
TiVo's response.
The goat.
For what it's worth, they're the same folks that brought the Javascript e-mail bug issue to light, so whoever was proffering the idea that they might be in bed with Microsoft, seeing as how the timing of this (hot air blowing) coincides with Ultimate TV's release, well... I wouldn't be so sure of that. -
Since I despise spam I find this from the FAQ
Particularly problamatic
from the web bugs FAQ
11. Why are Web bugs used in "junk" Email messages?
To measure how many people have viewed the same Email
message in a marketing campaign.
To detect if someone has viewed a junk Email
message or not. People who do not view a
message are removed from the list for future mailings.
To synchronize a Web browser cookie to a
particular Email address. This trick allows a Web
site to know the identity of people who come to
the site at a later date.
Spam sucks
-
Re:And a web bug is...?See the web bug FAQ:
-
What about Web bugs?
I am extremely disheartened at this so-called "new" email exploit that has been in existence since Javascript enabled e-mail clients crawled out of their spawning pools. Big whoop. Besides, spamalicious webmasters and bulk mailers have been using those insidious 1 pixel by 1 pixel WEB BUGS to do exactly what this "new exploit" can do, all without requiring javascript.
The Sad Truth is that the Internet is a breeding ground for malicious applications of technology brought to bear against largely ignorant masses.
-
Old News
Although I am too lazy to go find the article, I remember Slashdot reporting on this several months ago. If I remember correctly, ssn1 (formerly HackerNewsNetwork) first publicized the story. And excellent FAQ on Web Bugs is available at:
http://www.privacyfoundation.org/education/webbug. html -
Too bizarre, also almost too unbelievable.
I wasn't aware that JavaScript had any object model to interact with outside of its context as a web page or what have you, which is to say: using JS, I can't detect when the back/next button is clicked and use it to trigger an event.
Apparently (according to the "Privacy Foundation"'s website, it piggybacks onto the base functionality that some clients provide that notify you when someone has read your message, and add in text to the payload when someone forwards (responds?) to the message.
They also claim that this has been in the wild since '98 at least, despite no big hubub over it? Fishy, fishy, fishy. I'm waiting to see the 'sploit code to buy it myself. -
This was discoverd in ms Word a while ago
The Privacy Foundation discovered this type of abusive capabilities in MS Word documents back in August of 2000. The potential uses for this exploit ranged from tracking the distribution of sensitive documents to malicious things similar to the ones described in the WebBug article. The advisory also mentioned the ability to perform the same functions in Web pages, Excel spreadsheets and Powerpoint 2000 presentations.
-
Re:Why web bugs are particularly eviltbo writes: Web bugs are more evil than your average URL link because you have to click on the link, whereas a web bug (and the potential attached evil code) gets loaded automatically if you have an HTML-enabled mail viewer Yes, downloading URLs without user involvement is evil. Part of the problem are the email clients that default to rendering message bodies of the first unread message and not asking the user to confirm remote image downloads. (E.g., Netscape Messaenger and MS Outlook, but - I think - not AOL 6.0 and others reported by other slashdot posters.) Again this is a security vs convinence tradeoff.
2) Automatically executing code from a remote, untrusted source is bad, kids. I haven't seen a web bug that actually executes remote code on the local client machine unless you consider JavaScript code to be unsafe. Sure JavaScript can be unsafe if your browser's intepreter has an implementation bug or you consider certain information like screen resolution, local timezone and other browser options to be private, but we are not talking virus risk here.
The Web Bug FAQ for more information. In particular note that it does list some non-evil uses for web bugs:
Another use of Web bugs is to provide an independent accounting of how many people have visited a particular Web site.
Web bugs are also used to gather statistics about Web browser usage at different places on the Internet.
E.g., If you want your site to run at the fastest posible speed, you might host static HTML with a globaly traffic managed web caching or hosting company like Akamai or Speedera But you still would like to get logs directly for anaylzing traffic to your site and comparing with the web hosting company's bills. So you place a web bug on your pages directly back to your origin site (or third party like LiveStat). The user experence is still fast if done right, because the slow logging to your server occurs after the page is rendered.
-
Re:General privacy/EULA/etc. watchdog info?The closest I know are Electronic Privacy Information Center and Junkbuster. But they don't "track" it if that's what you mean. They weigh in heavily with lobbying pressure and public notice as they did with Amazon. Otherwise, it's individual watchdogs like Gibson Research (Spy Ware stuff), or The Privacy Foundation where Richard Smith is a consultant. He's outed a few privacy holes. Privacy.Net covers stuff like this sometimes. Other groups like Interhack and Peacefire might be on the look out for technical underhandedness, but I don't think anyone is hawking and reporting privacy policy changes. It usually takes notice for the company and then complaints from customers to get noticed. (Did anyone realize Living.Com was trying to do the same thing as Toysmart in its bancruptcy proceedings, but was blocked by Texas courts?)
I think this would be a good idea but don't know if there's anyone with the resources to undertake the task. If you could make a business out of it, like maybe Enonymous' Privacy Ratings site, then that might work. I'd monitor it if there was such a site. Maybe someone would want to run something like FuckedCompany.Com but concentrate on slippery privacy practices.
I've found that PrivacyDigest and WebVeil do a pretty good job of keeping abreast of the news. Privacy Digest is better because it is more comprehensive, but WebVeil is selective, seeming to focus on privacy for consumers specifically rather than everything that is privacy under the sun. Otherwise, I just pay attention to and filter what the paranoids are saying in alt.privacy or check on the privacy issues section of Yahoo and Wired.
-
Re:Privacy Foundation on :Cue:C.A.T.
Here's their detail privacy advisory.
-
Privacy Foundation on :Cue:C.A.T.
The Privacy Foundation statement which was mentioned in yesterday's CNet story is now online.
-
Re:I have just one thing to say....
Star Office
Good point. From the Document Web Bugs FAQ:
4. Are there any other programs that can use document Web bugs?
Yes. The Privacy Foundation has found examples of this image linking ability in Microsoft's Office Suite, such as in PowerPoint 2000 and Excel 2000. They have also been detected in Sun Microsystems' Star Office.
HTH, HAND.
Cheers,