Closed Bug 28327 (ImgInMail) Opened 25 years ago Closed 20 years ago

No server hits at HTML mailnews reading - privacy (disable remote content/web-bugs)

Categories

(MailNews Core :: Security, defect, P3)

Product:
MailNews Core
Component:
Security
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: BenB, Assigned: mscott)

References

(Blocks 2 open bugs)

Details

(Keywords: fixed-aviary1.0, helpwanted, privacy, Whiteboard: [need info])

Attachments

(4 files)

Evaluations mail settings..
20.44 KB, image/jpeg
Details
html stripping in Mail.app
151.24 KB, image/jpeg
Details
Information tracked when reading a mail with remote contents.
18.66 KB, text/html
Details
the fix
697 bytes, patch
Details | Diff | Splinter Review
Spammers may insert and invisible IMG tag into a HTML mail page, which loads an URL, which contains information about the recipient, e.g. allows to tracking reading of msgs. This is a privacy issue. It's especially bad together with bug #22994, but not limited to it.
Should better be implemented as pref (with default=no hits?), as there may be legal applications in an intranet.
Summary: No server hits for at mailnews reading → No server hits at mailnews reading
What, you mean you don't like receiving a webpage by e-mail! :-( By blocking images in e-mail (which is what this report is advocating), you will lose that ability. In essense, you will be destroying the browser's file/send-page command.
webpages by e-mail should be sent using multipart/related. Or one should send a link and have the user click on the link.
Summary: No server hits at mailnews reading → No server hits at mailnews HTML reading
Summary: No server hits at mailnews HTML reading → No server hits at mailnews HTML reading - privacy
Agreed, "Send page" should include images in the mail - otherwise I loose the ability to read my mail offline.
I think *any* URL can be abused this way. I doubt it's safe to assume that any network connection initiated from mail is secure and/or private.
The "HTML" I put in the summary is meant to refer to the type of mail containing the URL. I'm trying to make this bug visible to people searching for issues with HTML mail.
Summary: No server hits at mailnews HTML reading - privacy → No server hits at HTML mailnews reading - privacy
I believe that there is widespread support outside of Netscape for preventing the mail client from making any network connection whatsoever except to the mail server. Another way to picture this is just an automatic way of toggling online/offline when switching from browser to mail. For some reason Netscape and Mozilla are fiercely resistant to this idea, but I haven't heard anyone outside of Netscape voice any opposition.
> Another way to picture this is just an automatic way of toggling > online/offline when switching from browser to mail. No, this is a violation of multitasking. Statisically, mails are the second largest "out-of-band" source for URLs. All I want is to disable network traffic (other than to the mail server) caused by mail reading *itself*. Otherwise, we can disable URL recognition as well.
That is what I meant, I just left out the *itself* part. I should've been a little clearer.
I feel this should ultimately be performed by a bug #7380 type arrangement, which prompts by default. The prompts should give a note about spammers, and would allow the user to remember decisions globally, on a site-by-site, URL-by-URL, etc. basis.
7380 proposes an extremely complex UI, which will be hard to understand and be prone to error. A usable mail reader should not have modal dialog boxes popping up in response to viewing a message. Configurability is no excuse for poor defaults.
Bug 28612 (META refresh allowed in mail/news) is a related bug.
Status: NEW → ASSIGNED
Target Milestone: M15
Bulk moving all MailNews Security bugs to new Security: General component. The previous Security component for MailNews will be deleted.
Component: Security → Security: General
> I believe that there is widespread support outside of Netscape for preventing > the mail client from making any network connection whatsoever except to the > mail server. I'd be interested to know more about this. Could you provide the names of some products which do this?
There aren't. I am assuming that Mozilla is trying to be conservative here and figures no need to implement features not already done by someone else. If this is the case, I would like to make a preemptive comment: I hope Mozilla has not been reduced to a project seeking to combine features of other packages and offer no innovation of its own.
7380 is an essential feature for power users who don't want the defaults of novices. There are no sensible defaults. The dialogs are there to make it easier for novices to choose which sites they trust using 7380 - letting the user specify who to trust is the only way to properly address this. Sure, dialogs are invasive, I'm open to better ideas.
That is only half a fair comment Jerry, as Mozilla is still behind other products (eg Nav 4) in some areas. Hence it is best to catch up before trying to pass. In this circumstance, however, the new feature is more important than many of the old ones.
I think, this is a MUST for final. beta2 nomination.
Keywords: beta2
bulk move to M16. Not an M15 stopper. If you disagree, pls comment in bug and cc: selmer@netscape.com
Target Milestone: M15 → M16
Keywords: nsbeta2
This bug is a subset of bug 36484.
Keywords: beta2
norris, any comments or insights to help here. A feature request, thoughts for PR2.
Whiteboard: [NEED INFO]
I agreeed with jgmyers that webpages need to be sent as multipart/related message. This requires a fair amount of work. However, there is no guarantee that other mail clients will do the same. Using a pref with default value set to "no" seems to be the right way to go. I believe Steve has done the work. Steve?
The work I've done is to block images from selected sites. As you browse, you will encounter offending images that you can right-click on and add to the list of sites from which you want images blocked. Then when you read a mail message and it contains an image from that site, the image is not loaded.
Removing the [NEED INFO] for PDT re-eval.
Whiteboard: [NEED INFO]
Blocking images does not at all fix this. An offensive sender, knowing that images can be blocked, can include an external applet, stylesheet or whatever to get the server hit.
Putting on [nsbeta2-] radar. Not critical to beta2. But adding nsbeta3 keyword for a fix prior to PR3.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
Depends on: 37983
Changed QA Contact to czhang@netscape.com
QA Contact: lchiang → czhang
As noted earlier, blocking images (and cookies) from a site doesn't help until after the fact, and any object that can be loaded from a remote server can act as an involuntary return receipt. All that is needed is to throw in a unique identifier somewhere like a query string then parse the server logs for it. For example, a CSS object, though this can be done to images, HTML files, audio files, etc.: http://server.domain.com/dir/stylesheet.css?UniqueID=victimsusername%40domain.co m%20isValidEmail The query string does not in fact run a query, and does not affect the loading of the object. But it is logged by the server and thus can easily be examined later. This is a great way for spammers to confirm a valid address they've sent to, because this way they can ignore the bounced e-mails by falsifying their From: headers and still build a database of known good e-mail addresses by running web server log reports on the query string. (This all is exactly the method reported in bug 22994, just applied more broadly.) There is only one way to fix this, and that is to provide an option to disable all network calls from the mail/news client. The option to disable cookies and images on a site-by-site basis is great, but too little too late for someone targeted with this type of attack.
The concerns expressed about Mozilla working with Web pages that have been mailed are red herrings at best. Mozilla should not emulate Netscape 4.X's behavior of only sending the HTML and not the images and associated objects with the page. IE sends everything, and Mozilla should too. This also eliminates the need to allow any network activity from mail and news except for to mail servers specified in the prefs. I have a feeling that I share the opinion of many readers in that if I want to visit a site, I will either go there myself, or click on a link to it.
Whilst sharing sharing the concerns I have two comments: 1) I used to run a genuine, opt-in HTML email newsletter through the Netscape Inbox direct program. It was about financial markets and contained references to graphics on the server for two reasons: a) Graphics that were used every day remained in the browser cache and saved unnecessary network traffic and download times b) a stop-press graphic could alert users to any major change since the mail was sent. You may ask why not go to a web page, but our site statistics showed that there were users that liked receiving the information this way - their choice, supported by Netscape. 2) Is there evidence that nefarious receipt function is taking place? Does it matter - once a spammer has your address, that address has had it anyway and will be passed around with no evidence of it working. If this leads to non-working addresses being removed so much the better for network traffic and mail server administrators of dead accounts. 3) The challenge when addressing issues such as this one is that many, many users do not change their preferences so how does the default get set - to block these images or not?
The nefarious receipt function has indeed been used by a well known vendor of personal finance and income tax software. They include a tagged URL to a 1x1 transparent GIF. The default should be privacy.
The user expectation is that correspondants will not know when they read email, unless an explicit "read receipt" is approved. Thus the default must be either full privacy, or "ask the user".
Can this not be fixed with the new content policy hooks? (I'm not sure if the DOM can let us figure out that we're loaded in a mail context, if not we can figure something out.)
Severity: normal → major
Keywords: mail4
Target Milestone: M17 → M18
Thanks for increasing importance of this bug (nsbeta3 and mail4 nomination, severity major). I'll spend a round of donuts for the Mailnews team, if you fix this before release :). > > preventing >> I believe that there is widespread support outside of Netscape for preventing >> the mail client from making any network connection whatsoever except to the >> mail server. > Could you provide the names of some products which do this? While Jerry propably referred to customers' support, there are indeed a lot of clients honoring this kind of privacy: plaintext UAs :). (Indeed, I think, some amount of plaintext mailer users chose these clients because of security and privacy concerns.)
Hell, I'll pitch in a case of beer to the developer that does this :) Seriously
Whiteboard: [nsbeta2-] → [nsbeta2-][b3 need info]
What info is needed to make a b3 +/- decision?
Whiteboard: [nsbeta2-][b3 need info] → [nsbeta2-]
- per mail triage. Behavior is the similar to Communicator 4.x.
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]
> - per mail triage No donuts. > Behavior is the similar to Communicator 4.x. ...which was a privacy thread. <rant> I don't think, we will win many users, if our bugs are a superset of those in 4.x. </rant> being a bit more constructive: Adding helpwanted and filing bug 49021 for a (hackish) workaround.
Keywords: helpwanted
Hmm, Microsoft just got harpooned in the New York Times for this exact issue. See http://www.nytimes.com/cnet/CNET_0_4_2652562_00.html . What's our exposure? CCing ekrock.
If I understand this correctly, Navigator 4 Mail also had this issue, right? Our minimal security goal for RTM is to be *as* secure as Navigator 4. Being more secure is of course desirable, but that's an enhancement request, and the time for implementing enhancements has long since passed. This is really a question of Mail security policy, so I'm cc:ing sol. I note that someone has already marked this [nsbeta3-]. If Nav4 Mail indeed had the same issue, I agree and recommend Future as well.
Yes, this has been this way since HTML mail made its way into Netscape 2.x - rhp
I am curious why the goal of Mozilla and Netscape is only to maintain parity with NN4 in terms of security. Why not just keep the parity with CSS compliance and HTML too?
Thats not the goal. The goal is to always exceed previous products and be 100% standards compliant, but if you want to ship a product in any of our lifetimes, you come to a point where stuff has to be cut. We are at that point. - rhp
And security was nominated for weeding out. Can outside contributors make a vote of no-confidence in the body responsible for this decision. It is quite illuminating about Netscape's prioroties however. AIM must work - privacy...screw it.
If you want to be sarcastic and negative, that's your choice. I was just trying to provide some information on this issue. Sorry I tried to take part in the process. - rhp
It's not personal. My view is what good is a CSS compliant browser if it chugs along spewing personal information and violating my privacy? Netscape has never taken security very seriously unless someone turns on the light of the media and then Netscape scrambles to look "concerned". I am not saying that there are not individuals at the company that are concerned, but that the company overall doesn't care until there is some serious negative publicity. That is what is wrong here - that security is almost =always= put on the back burner for other things that are not even half as important except to drooling marketing droids.
PDT should have the following goal: Prevent Netscape 6 from receiving bad press for things where microsoft has already received bad press. Shaver could you please direct this concern to someone who can affect policy. Or commment otherwise? Thank you.
Presumably you can read mail off-line if you are worried about this kind of thing. Worked for me in 4.x, that might be a good enough answer for now. ekrock: doing things the same as 4.x may not be good enough; the world has changed. two years ago only the hair-shirt prophets in the wilderness were complaining about privacy, now it's a big issue that has attracted lots of press and lawsuits. jerrybaker: you are an idiot if you think we haven't taken security seriously. Your hair would curl if you knew some of the potential attacks that have been discovered and fixed in Mozilla. It's certainly too bad we didn't get to do a privacy enhancement like this, but it's not a true security issue. Meanwhile, we have a cookie manager and an image blocker (both useful in this situation), both of which are significant privacy enhancements over 4.x. As long as we don't regress privacy in other areas (and this isn't worse) I'd say we're making forward progress.
What's a "hair-shirt prophet"?
perhaps an over-contraction on my part of "hair-shirt wearing, locust-eating prophet", i.e. all those biblical dudes who didn't get much respect yet were nonetheless proved utterly right in the end. Maybe I should have gone with "Kassandra" instead.
("Kassandra" with a K is inauthentic spelling of the Trojan seer's name, although that phrase is a line from the movie "Warlock"!) Also, jerrybaker shouldn't be faulted for not seeing certain bugs where Mozilla has sweated security attacks devised by folks like Georgi Gunninski, because netscape.com chose to make those bugs Netscape-confidential in bugzilla. I still think many to most of those bugs should be wide-open, certainly now that we are past beta2. /be /be
Jerry, please don't assume that some overworked Netscape engineers' de-prioritizing this particular issue, which is obviously a pet peeve issue for you, reflects anything about Netscape's commitment to security. It's not that we don't care until exploits hit the press, it's that you only hear about it when it does hit the press. Anyway, that's why we're open source; if something really bugs you, either fix it or find someone (not necessarily at Netscape) who's interested in fixing it.
Kassandra with a "k" is a perfectly fine spelling, used, for example, by Richmond Lattimore is his Illiad. (He did go with the latinized Cassandra in his translation of Aeschylus's "Agamemnon" published around the same time, though.)
Lattimore, eh? I'm old school (or maybe old-new school), I was raised on Cassandra with a C. Is this bug long enough yet? More to the point, is anyone going to cough up a patch that I can approve? Who is up to the coding task? /be
The reason this is a "pet peeve" of mine is because this one issue represents one of the largest and possibly most insidious security holes excepting viruses or other things that cause physical damage. Being able to tie a user by email address to visited Web sites because the Mozilla team doesn't feel it important is literally a tragedy. Can we at least get Mozilla to come by default with images blocked from all sites known to exercise this behavior?
From what I can tell, the following are =known= to have used Web bugs in email marketing campaigns: Barnes and Noble eToys Cooking.com Microsoft InfoBeat
Alright, I'm going to make this bug a little longer: I wish jerrybaker at least would stop using "the Mozilla Team" to mean netscape.com, a business with scarce resources it disposes as it sees fit, and (in opposition), the royal "we", at least himself. The Mozilla community contains lots of people capable of hacking a fix here. I am cc'ing a few. Complaining about netscape.com is fine; maybe it will change the PDT's mind. But producing a patch, or a partial patch even, is better. There is no Mozilla Team preventing that. Why not talk this bug up in the newsgroups with an appeal to get a patch cobbled together? A patch to filter HTTP accesses from inline images in HTML mail would be a start. It shouldn't hardwire evil domain names. How should it then access a configurable, possibly shared list of domains? /be
I do not want to get the two confused, but the lines between what is mozilla.org and what is Netscape are =very= blurry (not just in this bug).
The line between security and privacy is very confused in this bug.
> A patch to filter HTTP accesses from inline images in HTML mail would be a > start This is what bug 49021 is about.
> The line between security and privacy is very confused in this bug. Actually not. There are two things going on here. One is that invisibile images can be inserted into email sent to me in order to log when I read my mail - this is a privacy issue. The second thing is that a cookie can be set with this image in order to associate that cookie with an email address - this is a security hole.
I'm with Steve: I don't see how setting a cookie is a security issue. I'd say it's a privacy risk, and I spend a fair amount of time thinking about this sort of thing. (Modulo implementation bugs like buffer overflows in the cookie handling, but those are risks for all content.) As far as not allowing external content to be loaded from mail, I don't see why the content-policy hooks aren't sufficient. Can't you use them to poke up the DOM chain and see if you're in a mail message, and then veto any inappropriate URL load attempt?
Setting cookies is not a security issue. When people browse, they realise the context of their browsing. They are on the Web - the Web has cookies. Email present a different context. I don't think people would expect that cookies can be set by email messages to later be read while browsing the Web (which is the effect of this). Sure one could argue that email is in the same context as Web browsing since both are the "Internet", but then by that argument so is opening Word while online...oh wait.
Help me, jerry, I'm lost. First you wrote: > The second thing is that a cookie can be set with this image > in order to associate that cookie with an email address - this is a security > hole. and then: > Setting cookies is not a security issue. I agree with your second personality, but not your first. =)
It's really easy: Setting cookies in email: security problem Setting cookies over Web: Fine Regardless of Netscape's desire to integrate Web mail with email, email is an entirely different context than the Web.
Can you please explain the _security_ (not privacy -- that part is crystal clear to everyone, I hope) implications for setting a cookie via email? That part is totally eluding me, and I consider myself a pretty savvy guy when it comes to web-related security issues. (Or, better: don't answer that question, and just write a patch to wield the content-policy hammer against this particular nail.)
Jerry, you make me laugh. Who at mozilla.org (not netscape.com now, please don't be insulting shaver@zeroknowledge.com, blizzard@redhat.com, hecker@collab.net, or brendan@meer.net by insinuating that we are controlled by netscape.com) ever was "fiercely resistant" to the right privacy-protecting defaults here, or elsewhere? The mozilla.org folks beholden to netscape.com have never uttered a word on this topic. "Help, help! I'm being repressed!" This isn't some student protest exercise where talk is the main by-product because we're all oppressed by the system. This is do-the-coding-yourself, put-up-or-shut-up open source. There is no way mozilla.org can or should coerce netscape.com into fixing this bug if for whatever reason(s) netscape.com fails to see its priority. How about helping out with implementations of shaver's general content-policy interface (bug 37983) instead of making this bug any longer, mmmkay? /be
I'm glad to provide you with entertainment. If you think that privacy and security are funny, then there is probably nothing I can do to change your mind. But, THIS IS NOT a put up or shut up system. You, and others, are coding a browser for the general public, but you don't want feedback from the general public. This is part of the problem that I have been making all this noise about.
> THIS IS NOT a put up or shut up system This part of the world is exactly that. If you want to take on the corporate monolith, take it on through its front door, the marketing department and customer feedback. Going around the back and shouting at the engineers through the open-source door is, in my opinion, somewhat rude.
I'm fine with that then. I will file a bug on Bugzilla to get the Bugzilla bug pages to add, "If you do not intend to code a solution to a problem you have found, do not report it to us. We are not interested". Is that wording OK?
> I'm glad to provide you with entertainment. If you think that privacy and > security are funny, then there is probably nothing I can do to change your > mind. Get off your high horse, Sir. > But, THIS IS NOT a put up or shut up system. No, that's exactly what open source is, and you are not putting up anything but noise. I'm not the type to killfile irrational people, and even a broken clock is worth listening to twice a day. So keep your feedback coming, but maybe in a better forum than this bug, eh? And (for the last time) try to enlist some competent hackers to help fix the problem reported by this bug, please. The existing pool of developers are pretty busy with their own priorities, and they are not mine to command. > You, and others, are coding a browser for the general public, but you don't > want feedback from the general public. What are you talking about? We want and get feedback all the time, including your vague, windy complaining. Who says I have to like it, but I'm not stifling you, killfiling you, or kicking you out of bugzilla, nor would I or any staffer do such a bad thing. If you think pdt@netscape.com is ignoring you, then why aren't you bothering them instead of us who read updates to this bug? > This is part of the problem that I have been making all this noise about. Oh brother, here we go again. Have you no shame? Stop whining! /be
It should simply say "Since you're not paying for this product, no-one is under any obligation to fix any problems you report, although we do try to. If you don't agree with our priorities, you can fix it yourself or you can try to persuade us (or our management) to change our priorities. Just don't get all whiny if you fail." Over and out. You know where to find me :-).
Jerry, calm down. My guess is that Moz 1.0 (which luckily will be some time *after* N6) won't ship with this bug. N6 will propably ship with it, but well... :).
Removed my vote, please move this discussion to the newsgroup(s) it's not helping anything here by driving votes away.
With jefft's permission, I'm reassigning this bug to myself. Shaver and I are working on this bug, bug 18352, and probably bug 46859 in a concerted way that may result in patches soon enough to consider for Netscape 6 RTM. /be
Assignee: jefft → brendan
Status: ASSIGNED → NEW
Setting target milestone to mozilla0.9. Hoping to get something done much sooner, shaver and I welcome help. /be
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla0.9
What does bug 46859 have to do with this bug? I hope, you don't intend to pop up dialog for external msgs? Many msgs with web bugs also contain normal (visible) external images, so an uninformed user would propably allow images to be loaded, if asked. How can I help?
Brendan, shaver, could you please define the fix you have in mind? I hope it doesn't involve any new "security warining" type dialog boxes. How do you propose to solve this problem?
Ben: bug 46859 has nothing to do with the solution to this bug, but it's part of the cleanup we think we'll do at the same time as we fix bug 18352. Boy, you guys must think we fell off a turnip truck. Shaver and I are even more averse to the "add yet another dialog in the naive user's face" theory of customization. Shaver and I currently think we just need to extend the image blocking to block images loaded from mail messages, based on a domain name blacklist. Everyone seems to agree that it'll be important to distinguish the mail case from the browsing case, so some extension seems required. How to specify the blacklist? Prefs, with UI later comes to mind. BenB, the first thing you could do to help is comment on this idea. Also, help test the patches developed in the related or coinciding-in-code bugs that we're trying to fix. Thanks, /be
I still think you need the general case of block all external images since blocking from blacked out domains is fine so long as you know they smacked you with a webbug, since most user's won't know and by the time they do its too late. I think the point at which to prune this tree is to identify local domains not bad domains, if an IMG tag refers to a domain outside the local domain list then its blocked otherwise its allowed. This if you like is much the same as a blacklist, except its a whitelist which is much shorter and easier to manage. It should also be slightly quicker in usage. At the same time I'd use a different broken image icon to help the user identify (once they understood what the icon meant of course).
Can the image blocking feature be used to block other kinds of included content (embeds, applets, iframes, etc)?
Personally, I don't see too much value in customizing the domains from which image loading is allowed, especially not enough value to have UI for it. Also, what mstoltz said. I would like to see an opt-in approach, i.e. one that blocks *all* loading of external resources, even those that don't exist yet (because somebody might add a feature like external stylesheets to layout and not think of the "content" loading policy), unless specifically allowed. Because of that, nsIContentPolicy seems more appropriate to me than the image blocker. Do you intend to merge the current image blocking code/interfaces and |nsIContentPolicy|?
I'm in the process of adding a security call, nsScriptSecurityManager::CheckLoadURI everywhere an URL is loaded by web content. This seems related. Could the policy be implemented there? This would (in theory) cover all secondary loads, not just images.
Is there no way to add this is a more central place, e.g. netwerk, or don't we have enough information (e.g. about the initiator) at this point?
Umm well its considerably more secure to enable such off-network images than to disable. That way if you have an electronic magazine mailed to you with legitimate images you can enable it.
Just my idea, but since I don't know anything about how necko works, take it for what it is. Can Mozilla just be told not to load any requests for external resources that originate from a mail window (maybe before the URI even makes it to Necko?)? Since JavaScript can be disabled in mail&news separately from the browser, it seems to me like the parser knows when it is in a mail or news window and when it isn't. Couldn't the parser just be told to ignore requests for external resources that originate in a mail (or news?) window?
We could do what jerrybaker describes using CheckLoadURI. This will stop the load before it ever gets to Necko, if used properly.
that adds an overhead to every CheckURI to check the origin, I looked at that it looked very expensive
> That way if you have an electronic magazine mailed to you with legitimate > images you can enable it. Althought that argument is frequently made, I can't see any real justification. The user is going to have to download the images whether that occurs when the mail is downloaded, or when the images are loaded when the mail is opened. The only edge case where a valid argument might be made is when the external link is to a dynamic image that conveys some sort of time sensitive information.
> that adds an overhead to every CheckURI to check the origin, I looked at that > it looked very expensive So I take it that the parser does not know when it is parsing mail content vs. browser content? If it does, why do you need to check the URI at all? Just refuse it flat out.
slucy: we could have a whitelist or a blacklist. It isn't hard to do both. We could even allow subdomains to be blacklisted from a superdomain that passes the whitelist. If there is no whitelist, only the blacklist applies. How does this sound? BenB: you wrote "Do you intend to merge the current image blocking code/interfaces and |nsIContentPolicy|?" Yes, although not all at once, and not in a way that makes it hard to get a patch fixing this bug into the Netscape 6 branch. Note that nsIContentPolicy is interface only, so we need to write new code, or morph old code, to implement the new interface. mstoltz: if you haven't yet, please check out nsIContentPolicy, shaver already went to the trouble to add uses of it when loading several kinds of elements. See http://lxr.mozilla.org/mozilla/search?string=nsIContentPolicy and let's talk. It seems shaver intentionally added the nsIContentPolicy check after the nsIScriptSecurityManager one in places where both are needed, to let security mechanism have first crack. I think that's right -- privacy policy should not go through the script security manager. Thoughts? Jerry: nsIContentPolicy is used to stop loads in layout code from ever reaching Necko. /be
> I think that's right -- privacy policy should not > go through the script security manager. Thoughts? It seems to me that you need the privacy check whereever you need the security check |nsScriptSecurityManager::CheckLoadURI|. So, if you want to keep a privacy and a security interface, then add a new one, covering both pirvacy and security, which is called where |nsScriptSecurityManager::CheckLoadURI| is called now, and its implementation then calls |nsScriptSecurityManager::CheckLoadURI| and you privacy interface. Should we move this discussion to bug 18352 or even the newsgroup?
Ben: let's move the design discussion to bug 18352, if not to a newsgroup. The current nsIScriptSecurityManager interface can't express the "shouldLoad" and "shouldProcess" results that nsIContentPolicy can, which (if false) lead to no failure codes (unlike nsIScriptSecurityManager, which can only fail the check). The CheckLoadURI method also doesn't take an enumerated typecode indicating what kind of URI load or processing is about to happen. Mitch: can you update bug 18352 with the places beyond http://lxr.mozilla.org/mozilla/ident?i=CheckLoadURI where you intend to add calls to the security manager? /be
agreed on the whitelist and blacklist, I was thinking of other privacy apps when considering that, its a well known concept so it shouldn't be difficult to get across or produce a UI for. jerry: I think the point is that some people want images delivered and you can't militate for website/email design only give them the best fit, starting with a whitelist of local domains implies no other domains would be used to deliver images (or other misused tags), and at the same time lets the user opt out by adding trusted sites. and agreed it doesn't belong in script but if there's a ContentPolicy that can identify quickly without addrefs that its in email then that seems more than reasonable. And this whole area seems to need a newsgroup/list to itself :-)
slucy: nsScriptSecurityManager::CheckLoadURI doesn't look as cheap as one might like, but it will be called no matter what -- at least in any browser where the caps/src code is included. And AddRef costs are the least of CheckLoadURI's costs. I updated bug 18352 with a new comment. /be
> jerry: I think the point is that some people want images delivered and you > can't militate for website/email design only give them the best fit I can live with that, but can I make a quick point? Choice is always good, and taking away user's choice is always bad, under one condition - that the choice being taken away somehow causes a loss of usability or convenience. As I was saying before, whether a user downloads the images in a mail message (because they are all there with multipart/related) or whether they have to download them from some remote server when they open the message makes no difference to the end user. In fact, the email may be quite a bit faster as POP servers are usually not that far up the pipe from the user. I could understand hesistating to remove the ability to include remote content if there were not another way to add that content, but there is. The only reason that a mailer could be upset that they could not use remote content is because their mailer won't let them do multipart/related (rare), or because they want to make use of this privacy hole.
>I could understand hesistating to remove the ability to include remote content >if there were not another way to add that content, but there is. The only >reason that a mailer could be upset that they could not use remote content is >because their mailer won't let them do multipart/related (rare), or because >they want to make use of this privacy hole. I'm confused, that's dealing with life the way it should be, not the way it is. The user wants to receive, say, an HTML mag in his email and it contains images and tagged images and refresh meta tags and god knows what, plugins probably as well. Since the user has no control over the designer of the page, and since its unlikely the senders of the mag want to have a different version for email or send every damn image to everyone at the time of mailing its pretty likely that the images aren't going to be sent. That's perfectly valid. I can't see how multipart related helps, but perhaps I'm thick :-)
Ok. One more comment :-) All HTML mail readers that are capable of displaying a Web page in email are also capable of displaying multipart/related images, so that knocks down the objection that the mailer wants to be 'compatible" with all mail readers in some way or another. Second, the mailer not wanting to send images with the mail (presumably because of bandwidth) doesn't hold much water after all. The recipient has to use their bandwidth to get the images off of their server anyway, what is the difference whether this bandwidth usage occurs at the time of mailing, or at the time of reading? *All future discussion of this should probably be in n.p.m.security.
>what is the difference whether this bandwidth usage occurs at the time of >mailing, or at the time of reading? There's a huge difference. I get WebMonkey delivered in email, i probably don't bother looking at it more than once a month, it gets delivered to say 5,000 (or 50,000 whatever), people they look at it when they see it, probably quite a majority within an hour, but its likely to be some kind of sine wave with time zones and the like. If they send out every image (and advert), then their mail server grinds exceeding slow and so on downstream and take a hit regardless of when people read the content.
Is 18352 the one you wanted to add to Brendan? That seems to be about the extensions directory.
Posted <news://news.mozilla.org/39DACD11.FD472602@bucksch.org> my reply to .security.
nsIContentPolicy is about more than just privacy -- it's also for general browsing prefs, like banner blocking and the like -- but I could see value in unifying the hooks. I don't think that we should unify them under the banner of nsScriptSecurityManager, because people might want to control content policy without our (unavoidably JS-biased) caps/ implementation, or for reasons other than security. (If we're going to discuss the mechanics in another bug, which seems sage, let's leave poor 18352 alone and use 37983.)
Nominating for rtm.
Keywords: rtm
QA Contact: czhang → junruh
This is a problem in messenger as well as in mail/news.
Messenger == Mailnews!?!
oh, i meant netscape instant messenger. sorry for the confusion.
As far as this Mozilla hacker is concerned, the problem with Netscape Instant Messenger is that it's not open source, not that it has any specific privacy characteristics.
shaver, AIM is similar to Mailnews in that you get content you didn't choose yourself. I heard that AIM is a particular bad place for spam. Doesn't it support HTML, too? If yes, you should protect it just as you protect Mailnews. But, of course, this would have to be done by Netscape.
Keywords: mozilla1.0
Keywords: mozilla0.9
rtm-, we've already had the discussion and we're not doing this. Without a patch attached, there's no chance anyway.
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-][rtm-]
Sorry for the extra mail. Removing mail4 keyword.
Keywords: mail4
Not doing what? If you mean blocking webbug type junk in email I thought it was underway, if you mean AIM that should really have a different bug
Keywords: privacy
Adding nsbeta1 keyword. This should either be fixed or marked Wontfix.
Keywords: nsbeta1
why does it need to be WONTFIX if it's not going to be fixed for a particular Netscape beta? In fact, it's not assigned to a Netscape person, which is a reasonable indication that a "nsbeta" marking is inappropriate or meaningless. Clearly Netscape has no interest in this feature (if you're that paranoid you can turn off all images) but that doesn't mean it's not a good thing for mozilla folk to eventually add finer granularity to the image blocking.
QA > ckritzer
QA Contact: junruh → ckritzer
Servers can also be contected via Javascript (embedded in the mailnews msg) loading images or automatically submitting forms. This will have to be covered, too.
Bug 60676, which looks like a duplicate of this bug, contains some UI suggestions
*** Bug 60676 has been marked as a duplicate of this bug. ***
Want a security issue on this bug? Try this in an email: <img src="http://www.yahoo.com/+++ATH0.gif"> When this email is displayed on screens of some modem users, it will disconnect their modem (should be obvious why). Sounds like denial-of-service to me, admittedly a pretty minor one. Possible potential for making it e.g. dial a premium-rate/international number, too, which I haven't tried and may well not be doable, but if it is possible it could prove profitable via spam. This is actually a bug in some Rockwell V90 modem firmware, as modems are supposed to require a 1-second pause between +++ and AT. And even if it *wasn't* a bug in the modem it would then be a bug in the TCP stack, not Mozilla. However, even though it isn't a Mozilla bug as such, it is yet one more security hole which 'allowing email do more or less anything it likes' is bound to provide. (BTW I don't know what proportion of modems it affects; only tried three, two of them - both cheap internal modems, one shipped with a Dell computer - were affected, the other - a USR external - was not. It may not be a major problem, or it may be.) Anyway, just for information. Apologies if this is already well-known. --sam
> Servers can also be contected via Javascript That's why there is an "Enable JavaScript for Mail and News" preference. An elaborate UI with per-site control would a be nice thing (I wouldn't think it worthwhile for just this bug), but an "Enable Remote Content for Mail and News" preference is essential. I can't imagine anyone disabling the latter but not the former.
<img src="http://www.yahoo.com/+++ATH0.gif"> has _nothing_ to do w/ this bug, IMO it's a TCP stack bug however if you feel that we should do something about it, then you should file a bug in networking: http.
Keywords: nsbeta2, nsbeta3, rtm
Whiteboard: [nsbeta3-][nsbeta2-][rtm-]
Wow, chatting a modem with a URL, who'da thunk. /be
Keywords: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Load-balancing. Performance first, anyone who wants this and can fix it, please feel free to take it. /be
Keywords: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 86627 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I'm not going to get to this in the next milestone. Help definitely wanted. /be
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Brendan, How do you propose to solve this? It basically means going offline while we parse and read mail, right?
It's part of the ContentPolicy plan. Obviously that has to be implemented first.
*** Bug 96062 has been marked as a duplicate of this bug. ***
It has been implemented in KMail, which is opensource, so one can have a look at how it's been done. See this bugtraq post that mentions the option in KMail: http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1% 26start%3D2001-08-19%26fromthread%3D0%26threads%3D0%26mid%3D206015%26end%3D2001- 08-25%26
*** Bug 99616 has been marked as a duplicate of this bug. ***
*** Bug 99904 has been marked as a duplicate of this bug. ***
I still have no time for this -- does anyone? /be
Keywords: mozilla0.9.2
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Blocks: 104166
See also bug 104802: it might be necessary to disable all plug-ins in the mail window (even ones in multipart messages) in addition to not loading images from the web.
*** Bug 104802 has been marked as a duplicate of this bug. ***
FYI: This is the HTML mail option in Evolution: -- in HTML mails -- ( ) Never load images off the net (o) Load images if sender is in addressbook ( ) Always load images off the net
'Load images if sender is in address book' could become useless if it interacts with the 'Collected Addresses' address book.
"Load images if sender is in address book" isn't very useful anyway. All a spammer would have to do in order to make me load an image is know *one* address in my address book and spoof that address. One easy guess would be the victim's own address, and additional guesses could be other addresses on the same page the victim's address was found on.
*** Bug 110432 has been marked as a duplicate of this bug. ***
my preference would be to bring the old NN4 button back (bug 55657), so I would see the html attachment in the attachment plane and could open it as any other attachment.
Footprint/perf works take precedence. Reiterating helpwanted. /be
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 111043 has been marked as a duplicate of this bug. ***
*** Bug 110720 has been marked as a duplicate of this bug. ***
*** Bug 114677 has been marked as a duplicate of this bug. ***
About Comment #31 [Newsletters: Loading graphics from server causes less traffic because graphics are saved in cache] One way to resolve this, is that even if you selected an option like "Do not download images from a remote server while reading email" that can get an option like "Download all images for this e-mail" with a checkbox "remember this option for this recipient".
Or simpler, put a button somewhere (and keyboard shortcut) that loads the images and other network stuff once you've glanced at a mail and decide it's OK.
*** Bug 118473 has been marked as a duplicate of this bug. ***
Dylan_G@bigfoot.com has stepped up (yay!). Ben, I've taken the liberty of making you QA Contact (ckritzer is long gone from netscape.com). /be
Assignee: brendan → Dylan_G
Status: ASSIGNED → NEW
QA Contact: ckritzer → mozilla
Status: NEW → ASSIGNED
> Dylan_G@bigfoot.com has stepped up (yay!) Great news. I would suggest Mac OS X's Mail.app as an emailer that gets it right. Cf. attachment, which shows the same message (1) in Mozilla, and (2) in Mail.app. In Mozilla, opening that message (merely by deleting the previous one!) caused me to confirm my address for the spammer :-( , due to this tag in the HTML source: <img src="http://uweb.savingbot.com/chkmailview.php?to=hysterion@mac.com&title=SavingBot_20020125"> In Mail.app, you can prevent this by leaving the pref "Download all images, animations, and other HTML attachments" unchecked. And still the general layout is rendered with all elements in evidence, including that pesky "chkmailview.php". (On top of that, also pictured is a button to *bounce* unwanted mail, but I guess that's another RFE.) I also agree with comment #146, that a button to override that pref on a message-by-message basis would be great.
Well, here is my plan (which is being hampered by me being unable to build Mozilla consistenly currently): I need to trace down where gekco is involved and have a pref checked to see if the HTML should be ignored (just use default rulesets, or some ASCII convert). Once I familiarize myself with Gecko's core more, I want to adda pref for "sandboxed" HTML email (only MIME encoded images are loaded: nothing else). So you can default to unsafe, sandboxed, or paranoid. I just have to find where this code path is :)
An alternative to stripping HTML would be to just stick a new content-policy object in the chain when this pref is set, and that object can refuse to load all content with a protocol that isn't the same as the enclosing document. (I think that's a _better_ alternative too, for a whole variety of reasons.) You can look at the image manager's code for an example of content policy objects and how to deal with them. We might need to teach the content policy service a better way to handle dynamic registration of objects -- I can't remember if I ever got to that -- than category poking, but that's easy. (I volunteer, even!)
> I need to trace down where gekco is involved > and have a pref checked to see if the HTML should be ignored (just use default > rulesets, or some ASCII convert). That would be bug 30888, I guess. It wouldn't fix this bug, just provide an alternative for people already knowing about the problem.
Cool, thanks for the help, Mike :) I'll start trying to grok that part of the tree. Feel free to link the content registration stuff as something this bug depends on (or tell me which bug I need to link).
Next milestone while I continue to work..
Target Milestone: mozilla0.9.8 → mozilla0.9.9
> > have a pref checked to see if the HTML should be ignored (just use default > > rulesets, or some ASCII convert). > That would be bug 30888, I guess. It wouldn't fix this bug, just provide an > alternative for people already knowing about the problem. Update: I am working on that. See <http://bugzilla.mozilla.org/show_bug.cgi?id=69529#c32> for current state.
Ben, thanks for your work, it's just coincidence that I happen to make a comment :) Lots of comments in this bug, trying to summarize and some new ideas: Blocking loading of images is not enough, because any embedded URL (e.g. CSS) could contain the identification hint. Blocking ? query strings is not enough, because URLs like host.com/cgi-bin/SpammerNumberToAddressMapping would still work. One bug was duped that suggested Mozilla should simply ask before allowing the request. Ideally, I think, this bug should be solved in a way similar to the "load images privacy" privacy feature. I think, in addition to "cookie sites" and "image sites" we should have "allow html by mail" sites. That would bring up a confirmation prompt when the email component triggers loading of embedded HTML content from a site for the first time. When a mail is displayed, the HTML source is local already. I suggest, when executing the calls to render that HTML, that call should be extended by an optional "internal rendering requester" identifier. That identifier should be passed on (either as a parameter or by a member of some object) to any code involved in loading embedded objects or rendering the HTML. In our case it would be an "mailnews" identifier. (When browsing the web, the rendering engine would be given a "browser" identifier.) That way, the code which is responsible for fetching would bring up the "new site wants to load content triggered by mailnews, do you allow?" warning. If the user denies, the HTML mail will be partially rendered correctly. Who knows how we could pass that "internal orignator" bit all the way down?
I don't think that rendering of HTML is an issue here at all, in that HTML without the server hits is basically, for purposes of this bug, rich text. (Excepting scripts and cookie adjustment, but we have ways to turn off script in mail anyway.) I guess I don't understand why you need to pass in a magic token when we have the URL for both the containing document and the desired URL coming in already to your content policy object. Back In The Day, we talked about a window-type parameter for the content policy hooks, but I seem to recall us deciding it wasn't worth the trouble, given that you already had the URL of the containing document. Now, it looks from quick LXR diving that we no longer call the content-policy hooks for external style sheet references, and I'm not sure what the path is like for site icons, but these are small bugs to be resolved once the big pieces are in place.
> I don't think that rendering of HTML is an issue here at all, in that HTML > without the server hits is basically, for purposes of this bug, rich text. Right, I was referring to text only rendering. > (Excepting scripts and cookie adjustment, but we have ways to turn off script in > mail anyway.) Right, and for cookies I wouldn't introduce a new settings category, but use the same cookie management we already have. > I guess I don't understand why you need to pass in a magic token when we have > the URL for both the containing document and the desired URL coming in already > to your content policy object. Back In The Day, we talked about a window-type > parameter for the content policy hooks, but I seem to recall us deciding it > wasn't worth the trouble, given that you already had the URL of the containing > document. I didn't knew that, if we have the containing URL available everywhere, that's great, and we can make the decision (whether this request falls into the mailnews category or not) based on that's URL protocol. > Now, it looks from quick LXR diving that we no longer call the content-policy > hooks for external style sheet references, and I'm not sure what the path is > like for site icons, but these are small bugs to be resolved once the big pieces > are in place. Sounds good. Does somebody object to a new category "sites allowed to load html embedded content triggered by mailnews" in addition to images sites and cookie sites? If this suggestion gets accepted, is the implementation identical with the following? - duplicate "image sites" preferences code, and adjust it - find the right place to catch any protocol request, (maybe it helps to find out where the test is implemented that checks whether the request falls into the "image site" category) and check whether the following condition is true: is containing document's URL (as seen in content policy) protocol in [imap, pop3, news, localmail] and ( user allows any mailnews triggered content loading or user allows "mailnews triggered fetching" from requested site {if unknown prompt user} ) Re the target network protocol, I'd not make a difference between protocols, and not even allow file://, because that could confuse users when an email shows them their local system configuration files in an IFRAME etc.
In a perfect world, one message would not even be able to load content from a different message. A message should be able to load content from the same message (using multipart/related)
Checking stylesheets and javascript files would probably help solving at least part of bug 53968 (where's the related bugs field...)
Blocks: 108004
Blocks: 31907
I am making progress on bug 108153, which is another workaround for this bug.
Adding CC.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Keywords: mozilla1.0+
Keywords: mozilla1.0
Is this bug truly blocked by bug 37983? Dylan, how's it going for 1.0? /be
Ok, here's where I'm at. I know roughly where mailnews decides to parse, thanks to the patch where it completely disables HTML. At that point I need to put in a decision (based on a user pref) whether our policy on parsing the HTML in the email is NO REMOTE or REMOTE ALLOWED. Mike S. sent me a description: "- you need to implement nsIContentPolicy and register your implementation (http://off.net/~shaver/content-policy.html has some tips, and I think it's still largely correct). - your content policy implementation needs to make its shouldLoad decision based on the prefs you mention" From there it's a matter of testing. So the big hurdle is wether or not I can quickly write the code which makes the load decision. I can make a whitelist of allowed protocols for each path and parse the decision on based on that, but the actual description isn't clear enough to me (with my level of exprience with Mozilla). I was going to spend next week going over the bits I can do easily first.
> I know roughly where mailnews decides to parse, thanks to the patch where it > completely disables HTML. At that point I need to put in a decision (based on a > user pref) whether our policy on parsing the HTML in the email is NO REMOTE or > REMOTE ALLOWED. If you mean my patch for bug 30888, that is not the normal HTML parsing. Normally, libmime just parses MIME stuff and writes HTML content directly (unchecked) into the result stream. That result stream is rendered in the msg pane, leaving it up to Gecko to sort it all out.
I have a suggestion on how this feature could be implemented. Basicly, you just implement a set of preferences similar to the existing prefs under privacy-images with the folowing items: a set of radio buttons that read 1.Do not load any external content for emails 2.Do not load external content for emails except when the user accepts the server 3.Accept all external content for emails Option 1 would never load external content Option 2 would basicly pop up a box everytime a HTML email with external content was loaded and say "do you wish to block this external content" and it would add the domain name to a blacklist that could be edited with some kind of blocker Option 3 would always show external content As to what option to make the default, I dont know.
I'd prefer an additional choice of "Always ask".
Probably for the 1000th time, but I'm going to add it to this way too long comment list anyway. I recently switched to Mozilla for e-mail and really don't want to change back, but this issue forces me to do so. In my opinion there's no way to separate good HTML mail from bad. Instead of thinking out and planning for very complex and flexible solutions, why not simply add a preference that disables *any* HTML rendering of email by default (by displaying the text alternate or HTML source). And provide an option to show a selected/opened message with HTML rendering on. This would be easy to implement, can default to current behaviour, solves the issue for me (and others) while better ways to restrict HTML rendering can be implemented. Please don't get mad at me for repeating what others have said already, but I didn't read any objections to a solution like this. This feature would also be usefull for other situations which would not be handled by restricting connections or certain HTML tags. On the subject of using third party software to block connections made by the mailreader: My firewall can't distinguish if the connection is comming from the browser component or the mail component because the executable is 'Mozilla.exe' in both cases. This also has reverse affect allowing the browser component to connect to my POP server.
bvr: I want html rendering but no server hits (other than my mail server to download the mail) to read mail (privacy, spam prevention). That's what this bug is about. It's not a problem of html mail but of html mail with links to external resources.
> why not simply add a preference that disables *any* HTML rendering of email by default I said it above already, but some people obviously missed it: That's what bug 30888 implements. Patch is waiting for review.
Sorry that this won't be in 1.0, but it's actually a lot harder than I thought it'd be to fix :) I'm learning XPCOM based around what Mike Shaver's told me of how to tackle it, but I'm finding that the other examples of the nsISupports through the code (for other security things) are inconsistent at best (some have bitrotted away, the entire security setup needs a review by someone who knows more about it). If you know anything or can help, please pitch in.
*** Bug 135298 has been marked as a duplicate of this bug. ***
FYI: bug 108153 and bug 30888 (which both provide a workaround for this bug) have been check into the trunk (not the 1.0 branch yet). See <http://bugzilla.mozilla.org/show_bug.cgi?id=30888#c169>.
*** Bug 138151 has been marked as a duplicate of this bug. ***
Blocks: 138249
*** Bug 139743 has been marked as a duplicate of this bug. ***
*** Bug 141012 has been marked as a duplicate of this bug. ***
*** Bug 141559 has been marked as a duplicate of this bug. ***
*** Bug 141774 has been marked as a duplicate of this bug. ***
I think a whitelist/blacklist is unlikely to be too useful to the average user without associated button(s) to allow/block image load for a given message. I'm of the opinion that the blacklist should default to *, too - but that would require something to confront the user and explain, and I'm not sure that's a good thing. The idea of just going "offline" is all well and good... for POP3 mail. A bit of a pain for IMAP. I'd be inclined to suggest blocking all images by default, with an icon/button to enable image loading for (1)this message (2) all messages From: this sender and adding a prefs dialog option to change the default from block all to allow all. Perhaps (dreaming, here) even block all except x (intranet, etc) as per whitelist/blacklist suggestions in this thread. The question is, can this be made user-friendly enough? I think it _has_ to be implemented one way or another. I read the Postmaster account from Mozilla, and the amount of bugged spam is nothing short of astonishing.
If we are reading IMAP mail we already know the server's name, and the same with POP. Is it really that hard to disallow the initiation of any network activity whatsoever from within a mail message EXCEPT to the mail server?
The solution is as follows: The HTTP getremote functionality checks if it's being called from an HTML document (which succeeds, although things like referrer are striped from file:// base docs), or from mail (which will be blocked by default; else allow if pref is set to allow remote content in email). I've been too busy with RL happenings (most importantly finding work) to sit down and figure out how to modify the content policy handlers. Once that's done it's a small amount of work for a UI dialog in prefs and testing.
*** Bug 144781 has been marked as a duplicate of this bug. ***
Spammers are making major use of this loophole. I strongly urge that outgoing network activity based on the act of reading email require explicit user authorization.
Bryce: If you select View -> Message Body As -> Simple HTML, then there're no server hits.
Alex, and where exactly is that option? I'm using RC2, and see nothing like that.
It's in the nightlies. But that setting doesn't stick between sessions.
Alex, "View as Simple HTML" is nice, but not nearly good enough. On some messages neither "as Simple HTML", nor "as plain text" show me anything at all, while the message is still entirely self-contained and can be viewed properly w/o any server hits! In other words, I do want "complex" HTML, I just want it to only use the content that's already available in the message itself.
Mikhail: As Torgeir mentioned, the option is in the nightlies, which you can download here: http://ftp.mozilla.org/pub/mozilla/nightly/latest/ Torgeir: At least with 2002051604 (on Win2k), the setting seems to be persistent for me :-/. Aleksey: I'm not proposing that "Simple HTML" is the solution to this bug, merely a workaround until it's fully completed :).
I'd like "complex html", as long as all the content & images are contained within the message. It's also critical that it be easy to say "this one's fine --- let it load images". The issue is broader than HTML. I'd like Mozilla to promise me that reading email is a fully private activity, resulting in no network activity. Any activity (return receipts, url loading, etc) should require my permission. -BN I'd also like to be able to mark spam as read without reading it, but that's a seperate matter.
Can't this get put at a much lower level within the codebase? If the rule is that mailnews can only talk to it's mailserver, can't a block be put at the network layer? In one swell foop, you'd block (or catch) all the cases with potential privacy violations. There are lots of ways to violate privacy based on rich email. Cookies for example ( Bug #22994 ), or images ( Bug #144781 ). With a network layer block, you don't have to think of all of them in advance.
"<i>can't a block be put at the network layer?</i>" It can. That's precisely what I want to have, and am working on, for the patch. However, the XPCOM stuff which lets you define the methods for doing the boolean decision about if something is OK to load or not from context info (in this case, the context is loading from mail/news area) is a bit beyond my current abilities, plus I've been going through a job situation -- thus the slowness of my patch to come out.
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
*** Bug 148386 has been marked as a duplicate of this bug. ***
*** Bug 148859 has been marked as a duplicate of this bug. ***
*** Bug 151017 has been marked as a duplicate of this bug. ***
Spammers are sending out things like the following. The image, of course, is too small to be seen. I deleted the spam domain and my email address from the snippet below. <p>Hi, did you receive my previous email message?</p> <p>I sent it 2 weeks ago, but I&nbsp;still didn't get an answer, please check in your old email.</p> <p>Anyway, I'll send you another copy tomorrow or the day after, you don't need to reply to this email.</p> <p><img src="http://[SPAM DOMAIN DELETED]/w.cgi?email=[MY EMAIL DELETED]" border="0"></p> <p>Regards,</p> <p>John Laplace</p>
waldemar: So, for that, you just turn off images in MailNews, eh? (see also bug 97055) And, I realize that bug 97055 only covers a subset of this bug, but it helps.
Waldemar: what is your point in comment 197? That's what started this bug.
Blocks: 158464
*** Bug 159151 has been marked as a duplicate of this bug. ***
Alias: ImgInMail
Looks like we will miss the target milestone. pi
Could someone please remove supradave@earthlink.net from the maillist to this bug. I haven't wanted to submit a bug about it, but I keep getting mail about it and I don't know about or how to fix it. Thanks, Dave
sincere apologies for spam, but just so everyone knows that Dave's had a reply... Dave - you're getting mail about this bug because you've voted for it. Go to the bugzilla page, and in the page footer, you'll see a link that says "My votes". Follow that link, uncheck the box next to this bug, and click the "change votes" button.
Blocks: majorbugs
FYI: even with "cookies off in mail&news" cookies are enabled...:( set Mozilla to "dont accept cookies" in Mozilla Mail set Mozilla to "dont show remote images" in Mozilla Mail set Mozilla to show "original HTML" now send a mail to browserspyhtmlmail@gemal.dk read the reply mail that comes back now check your cookies in the Cookie manager. A cookie from gemal.dk is now present! that bug 168258
*** Bug 168174 has been marked as a duplicate of this bug. ***
I removed myself from this bug but it keeps emailing me... Re-adding myself and removing myself again...
*** Bug 176165 has been marked as a duplicate of this bug. ***
According to http://www.msnbc.com/news/829223.asp?0si=- next Outlook will have this feature enabled by default.
With the additions of "do not load remote images in mail & newsgroups" and "enable plugins for mail & newsgroups" (bug 147877), and "disable cookies in mail & newsgroups" -- what else is there to be fixed before we close this bug? The only thing I can think of is defaulting with these settings to be secure, and maybe adding them to a global section of the security tab in mail/news preferences. Comments?
dylang, I think comment #5 pretty much sums it up. It's one thing to block images, plugins, and cookies, but quite another to block all network activity originating from an email message. That would be far more secure. For example, what about frames or iframes? What if a spammer includes a stylesheet that points to a CGI? What about prefetching? What about shortcut icons? And the list goes on. :-) I think a block at the network layer *does* make sense...
I suppose as long as the correct combination of those preferences can absolutely guarantee that no network activity will be initiated by reading a mail message, then it's all covered. If, however, there is any way to trigger network activity without explicit user input, then this has not been fixed in a satisfactory manner.
Jerry, as has been pointed out previously, they cannot. And even if they could it would be good to have a main switch on the network level.
FYI: As the summary indicates, this bug has always been intended by me (the reporter) to include *any* possibility of network activity, not just images. See commment 25.
I'd like to make a radical, and possibly impractical, suggestion. If you're considering a network-level switch to fix this bug, why not fully separate MailNews's network-level status? There are certainly times of slow connection when I'd want my browser online but my mailNews offline - then I can browse, delete, etc. my mail at local speeds but still get online data in the browser. [Of course, that solution would require a real, working offline mail client. Bugs like <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=67172">67172</a> would become more pressing]
Impractical, yes :)
The optimal solution I've alsayws wanted in a hook in network code. Right now Mozilla, at the network level, will not fill out the HTTP request structure the same way if it's in the mail/news area (because we don't want to leak the specific message, etc, to a remote server via referrer). Extending this to simply ignore all network activity if origin is mail/news shouldn't be too hard, it's just that I haven't had time to fully go through all the code (there is a lot :-/) to make sure that such an idea wouldn't lead to new bugs elsewhere. The offline solution isn't applicable to people using IMAP (myself, others), because IMAP has to be online to look at new messages if you don't have your brower set to autodownload messages (the default). I look at my mailbox from many locations, and value the online features :)
If somehow the Mail/News reader would be running NOT as Mozilla.exe it would be possible to solve this whole problem with a firewall or IP filter by disabling all outgoing communication (or making different rules for it). However, as comment 168 says, currently it is not possible to distinguish between the Mozilla Mail/News reader and the browser (both identified as application Mozilla.exe). Wouldn't it be easier to do this as a preliminary solution? I know that under Windooze it would certainly solve my problem. Under Linux however, I did not find such a personal firewall/IP filter, which can do IP filtering by application.
Did this make it in 1.0.1? If not target should be updated.
*** Bug 181338 has been marked as a duplicate of this bug. ***
Isn't this a preference now? In Privacy > Images preferences, I see a preference that prevents remote images from loading in Mail/News. This build is 2002123108 on Win XP Home SP1.
Brant: Not exactly. CSS files, for example, could act as a unique identifier (see also comment #29). PS Be sure to add yourself to the CC list on bugs, otherwise might might not receive any of the responses ;).
Re: comment #220 Also, ideally we would want to allow loading images that are included in the message itself, and only prohibit loading *external* images (while the current preference, as I understand, would prohibit any kind of images). And see also comment #210.
Aleksey: I think the current pref already does that. That's what "remote" is there for in "Do not load remote images in Mail & Newsgroups", right? :-)
I've just made the bug #187984, that is like to be a duplicate of this one. I think that loading remote contents without the user being informed about privacy risks is really a bad privacy issue. A warning similar to the one that appear posting form data would be apreciated. A bettere idea, allowing the user to select if any remote contents should be loaded or not. Try the http://www.readnotify.com/, that sell a service of mail tracking, that use remote contents loading to collect a lot of informations about the mail and the recipients. Isn't it a very nasty service? :)
*** Bug 187984 has been marked as a duplicate of this bug. ***
*** Bug 188235 has been marked as a duplicate of this bug. ***
bringing over some comment from sfraser's duplicate bug: sfraser writes: Currently, viewing a mail message can fire off remote loads for images (controllable via a pref), iframe contents, style sheets, and other stuff. Not only is this a security issue, it's also a privacy issue: spammers can use weblogs, or FTP images requests, to gain information on when a mail message was viewed, and from what IP address. Image requests may even reveal your email addresss (depending on pref settings). I think mail needs an option, defaulting to _on_, to turn off loading of all remote content in mail. Only display what is contained in the mail message, and nothing more. clearing the target milestone. dylang, is this still on your radar?
Target Milestone: mozilla1.0.1 → ---
Would this cheap short term solution work: If we flag the message as spam (by our spam detection code) then when the user try to display it, only display as plain text? Should be pretty cheap to add that. I think Seth mentioned to me the other day that he wants to disable images for messages that are marked as spam as well.
If this bug is to be fixed even when JavaScript is enabled in mail messages, it depends on bug 65224.
I agree with Simon's suggestion. Give the user an option to not access non-local content, of any kind, without explict permission. I don't think that spam-detection is sufficient. Mozilla can put a box in the message header area that the user can click in order to load the non-local content. This will make it easy for the user to determine if the message is spam.
Note that for this purpose, "local" must include mail on the IMAP server configured for the account.
That's true. Local perhaps should mean "under the user's control". A remote mounted home directory, for example.
In addition to #227 from Seth Spitzer: I agree to it's suggestion, I think it would be necessary to add such a feature. I could imagine that this feature could work like the "Cookie Manager" with same options: either ask at every mail which wants to load remote content or define locations that will be allowed to load remote content from. Of cause allowing or denying loading all remote content should be possible as well.
There is an a partof a message sent my by the Readnotify service: <IMG SRC="http://www.dvvorzk66t4nx8.ReadNotify.com/nocache.pl/dvvorzk66t4nx9/footer0.gif" border=0 height=1 width=1 alt=""> <iframe width=1 height=1 src="http://www.dvvorzk66t4nxo.ReadNotify.com/iframe.asp?dvvorzk66t4nxp=2" frameborder=0 STYLE="width: 0; height: 0px; border:0px"></iframe><table height=1 width=1 border=0><tr><td background="gopher://gopher.dvvorzk66t4nxy.ReadNotify.com/gb.dvvorzk66t4nxz.gif"></td></tr></table> as you can see, they try to load many types contents using different protocols (also the gopher) The mail tag-id are embedded in may part of the url (also in the server address...) Now, I'm going to post an attachment with informations collected about that mail by the read notify service .
Original informations included also a map of the recipient possible location, detected using the IP used for loading remote contents.
tv@beamnet.de wrote me: > Just for the sake of couriosity: Do you know what happends when you > select the various "view/message body" options? > This might be of interest to other people subscribed to the bug, too, > but I thought I'd ask privately to not generate too much noise. This is a VERY interesting question. If you select plain/text or simple HTML remote contents of the message sent me using Readnotify service (containing remote img iframe and table's BG) are not loaded at all. I'm sure about that because I opened a tracked mail and the tracking system was not aware of that. I guess that also other type of remote contents (using any HTML tag that allow it and any protocol) should not be loaded.
Yep, Simple HTML (aka Sanitized HTML) and Plain Text are designed to strip away all references to remote content.
I've been using Simple HTML, and it seems to do the trick. It would just be nice to have a convenient way to tell it to load all of the email's content. I could go up to the menu and enable full HTML, but then I have to remember to switch back when I'm done. Maybe a button in the headers.
Heh, I guess that's one reason for this article -- being able to read the original mail and all the local content in the original format without fear of triggering remote load.
midori@paipai.net -- we don't need examples of why this bug is bad. The fix to this bug is fairly logical. Go look at bug 83038. (On a side note: the fix for that bug originally was a blacklist of bad protocols instead of a whitelist of allowed, remote referrer protocols, and thus needs to be revistited by someone to be updated in a new bug) The fix is to simply to stick a new content-policy object in the chain when this pref is set, and that object can refuse to load all content with a protocol that isn't the same as the enclosing document (as Mike Shaver said in comment 151). It's all a matter of sitting down and figuring out exactly where (and a bit how) to implement nsIContentPolicy and shouldLoad. Having been through 3 jobs in the past 9 months hasn't sped up that part of my approach to this bug.
*** Bug 189806 has been marked as a duplicate of this bug. ***
Mail triage team: need info.
Whiteboard: [need info]
*** Bug 175258 has been marked as a duplicate of this bug. ***
So....., What's the official word on this bug? Is there a work around? I read the rest of the comments and there doesn't seem to be any. Telling, that this bug is over 3 years old now. Bet if outlook implemented this tomorrow, it would be in mozmail by the end of the week :) Anyway, I think giving the user the option to not load any remote items is a very important privacy feature. Suspect that not having this feature is contributing to the growing amount of spam I am receiving. Giving the high dup count and votes, I suspect a lot of people agree.
In mailnews, go View -> Message Body as -> Simple HTML Problem solved.
cool, thanks. Two things... (i) Maybe the View->"Message body as" option can be placed under Edit->Preferences->"Mail and News" somewhere; maybe under the "Message Display" property sheet. (ii) Why is this bug still open?
> (ii) Why is this bug still open? The "simple HTML" feature is _very_ far from what this bug requests. I want to be able to view _full_ HTML mail, with images, CSS, etc - but only when those images and CSS are included in the email and are not on a remote server. The "simple HTML" feature restricts _way_ too much.
(i) It must be easy to change. In prefs it would be too far away.
>Telling, that this bug is over 3 years old now. Bet if outlook implemented this >tomorrow, it would be in mozmail by the end of the week :) Evolution has implemented it, though.
>>Telling, that this bug is over 3 years old now. Bet if outlook implemented this >>tomorrow, it would be in mozmail by the end of the week :) >Evolution has implemented it, though. And KMail
*** Bug 204438 has been marked as a duplicate of this bug. ***
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
something that thunderbird and the trunk will want for 1.5 alpha. taking from dylang@thock.com, send me mail if have a patch started, and want this back.
Assignee: dylang → sspitzer
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla1.5alpha
Will thunderbird run as a separate process? If it will, then it would be a pretty easy WORKAROUND to use a personal firewall to block all connections from the process other than to mailservers. Still, hope to see this soon!
Re: #254: This is why I currently use Mozilla for browsing only, and a different software (Netscape 4.x, actually) as a mail client. The mail client is configured to assume I use a proxy, and the provided proxy address is nonexistent. This way, all HTML connections resulting from mail-reading simply fail.
Tip: you could also use a second mozilla profile to do the same thing. Simply start mozilla with a command-line flag to select the correct profile for mail or www access. Easily incoporated into a toolbar link / shortcut / script or whatever your platform uses. IMHO, this is 99% fixed with the "enable plugins for mailnews" and "load remote images in mailnews" options.
Tal, Craig: Thanks for the workarounds. Craig's I think will mean that clicking on a link in an email won't work as it should; I'd hate that. How to enable bug 108153's workaround, as far as I can tell: posted to said bug.
Implemented Already!!? Has anyone here ever heard of the open source project called SquirrelMail? It is an IMAP web-based mail client. It is coded in PHP and usually runs on Apache with modPHP installed. Anyways, see http://www.squirrelmail.org/ The reason I bring this up is that the developers of SquirrelMail opted to (by default) block all images from a foreign server! Yes, all of them. There is actually a plugin that allows the administrator of the webmail to re-instate the ability to see these "unsafe images." The plugin is called "unsafe image rules." Deep link: http://www.squirrelmail.org/plugin_view.php?id=98 FOR THE WHOLE RESAON why anyone should care about this bug, or why the SquirrelMail people chose not to allow (by default) the viewing of any image from a foreign server, SEE THIS LINK! http://www.squirrelmail.org/wiki/en_US/UnsafeImages Okay, so there is a precedence for completely blocking every image in an e-mail that didn't come inside the e-mail! There is also a precedence for allowing a user to selectively reinstate the normal image view of HTML mail. You would probably guess that most users were pretty disappointed when these "usafe images" were being blocked. But for some of us who *do* receive a lot of SPAM, I actually preferred viewing my mail with the SquirrelMail interface until I came across something I needed to see from a legitamate source. Having the unsafe image RULES (via the plugin) makes this feature votable for Mozilla Mail! Or, "I wish Mozilla Mail did this, too."
*** Bug 210403 has been marked as a duplicate of this bug. ***
sliding out
Target Milestone: mozilla1.5alpha → mozilla1.5beta
*** Bug 212752 has been marked as a duplicate of this bug. ***
*** Bug 214046 has been marked as a duplicate of this bug. ***
IMHO the inevitable flexible solution is: Unique allowed-domains lists and proxy-setups for each email account. Within one process using one profile, you configure the browser's proxy, optionally override by a global default email proxy and allowed-domains, and optionally override proxy setup and allowed-domains on each email account. The allowed-domains is a domain list field similar to no-proxy-for but with a separate boolean to turn on or off use of this field. To access all domains from an email account: set the boolean false. To block all: set true (use list), but with empty list: none allowed. Behind a firewall, set true and list your own local domains as allowed (allow access by HTML-email to images, css, plugins... within your own network). I don't know the state of the javaScript-able proxy function in Moz, but provided such a user-configurable JS proxy function had access to whether the browser or an email account (and which email account) was triggering this particular DNS-to-IP resolution, then a user can code up the above effects (defer to different proxies appropriately, and enforce separate allowed-domain lists). That JS-proxy would be a minimum start giving much power long before any GUI need be conceived for this, similar in spirit to user prefs that don't have a GUI yet. Care needs to be taken so any IP caching is also separated or multi-layered, so previous browser hits don't "enable" HTML-email hits to the same site by skipping the JS-proxy based enforcement by virtue of already-cached (or simply provide option to disable IP-cache use from all HTML-email).
Don't you think it's easier to say, "the mail window wants to initiate a network request that didn't result from a user click -- is the request to the mail server? If not, block the request. Done."
I doubt that an allowed domain list is the solution for email problems, though it's ok for browser cookie settings. What makes me think this? Occasionally we're receiving Junk mails from one of our own domains. While browsing I'm actively requesting a certain domains content, reading mail makes me read what somebody else wants me to read. Allowed domain lists would be valid for known accounts *and* signed mails only, being somewhat more complicated than [reb at cypress-dot-com]s suggestion. Olaf
Olaf, (I'd hope that) The domain whitelist is for outbound targets, not for appearant E-Mail originators (as these can be forged, of course). I don't get that much spam that refers to images on my own webserver. Cheers Thomas
sorry, missed that. However, related to past comments, I'll second comment 247 for this bug: Show everything that is enclosed with the respective mail and prohibit any contact to any server outside, e.g. show full images and stylesheets as long as they are attached to the mail (plugins give another problem with that, but that has already been solved in one of the last years... :-) But then, viewing mails plain text only has saved me from reading dozens of viagra spams, so I currently don't really miss this feature :-) Olaf
I for one could really do with a domain whitelist, as I get automated emails that refer to images on our intranet webserver (and not having the images makes for a useless email).
*** Bug 218627 has been marked as a duplicate of this bug. ***
My comments as to the best way to handle this, although they could easily spill into seperate bugs: Make privacy the default. External objects do not load without user interaction. Allow selective loading, possibly via right click "Allow object to load." Allow full loading, either via right click, Load External Objects, or via chrome similar to the junk mail indication in thunderbird. Provide seperate toggles for previewing and opening a message, perhaps make privacy default for the preview pane, and default to allowing external objects when opening in a window. Provide sender and site whitelists and blacklists that take precidence regardless of the global privacy settings
*** Bug 229038 has been marked as a duplicate of this bug. ***
I joined the mozilla bugzilla group just for this one option. And then I found it! In 1.5 it is under [Preferences... -> Privacy_&_Security -> Images -> Do_not_load_remote_images_in_Mail_&_Newsgroup_messages]. I expected it to be under [Preferences... -> Mail_&_Newsgroups] or in the Server Settings in [Mail_&_Newsgroups_Account_Settings...]. Just an observation, not a complaint. Happy happy happy happy, Steve PS: When does this bug get closed out?
When it is possible to make Mozilla NEVER talk to any server except by explicit user action (e.g., clicking on a link). As it is images don't load, but you can do all kinds of other stuff instead.
FYI, current versions of Pegasus Mail also block images by default. His solution was to pop up a message saying "This web page has images, do you want to load them?" or something like that, with the option to either load or not load by default, and the option to disable the popup. If you choose to disable image loading, right-clicking on any message gives you the option to "Show Pictures (HTML)".
What about remote style sheets, flash, javascript, java applets, or anything else for that matter?
Any network connexion outside should be avoided inside a message. This shous include stylesheets and urls inside stylesheets. This could be implemented by filtering out urls outside the message own url. Mozilla-mail access mailboxes via urls like : mailbox://nobody@Local%20Folders/folder/message imap://user:password@imap.serveur.net/folder/message Or disallow any other protocols than mailbox: or imap: inside a mail message.
With 26 dupes, this bug needs a clearer summary. I'm appending "(disable remote content/web-bugs)", but feel free to change that to something easier to search. BTW, starting with WinXP SP2, this feature will included in Outlook Express. See http://www.pcmag.com/image_popup/0,3003,s=1841&iid=62601,00.asp Prog.
Summary: No server hits at HTML mailnews reading - privacy → No server hits at HTML mailnews reading - privacy (disable remote content/web-bugs)
*** Bug 232843 has been marked as a duplicate of this bug. ***
Perhaps this has been addressed in the 278 comments before mine... I am happy with the 'blocking of remote images in Mail' feature, but now I want to be able to UNBLOCK images in some emails. I don't see any easy way of doing that, other than allowing all remote images, then viewing the message, then blocking again. I would like to be able to permanently allow remote images in emails when the images are on certain servers. So in the Browser, I can BLOCK images from some servers. In Mail, I want to be able to ALLOW images from some servers, with the default being to deny. This would keep me safe from random spammers, but would allow me to view my HTML newsletters etc, once I had configured everything correctly.
Asking for blocking in 1.8a because this is a major privacy concern. pi
Flags: blocking1.8a?
No, given that bug 108153 (Simple HTML mode) is implemented, it isn't. One reason why I fixed that bug was that I wanted to fix this one (28327), and IMHO it did. That fix protects you not just from tracking, but also from the vast majority of potential security exploits and automatic viruses. I wonder if it's still valid at all, and if so, only in very few edge cases. Before you flame me, note that I am the original reporter of the bug. ;-)
(In reply to comment #281) > No, given that bug 108153 (Simple HTML mode) is implemented, it isn't. Simple HTML mode is not enough: a user might like to see HTML messages as intended by the author, but not trigger web bugs. If this feature is implemented, messages in which all the content is attached to the email using cid: URLs would display properly AND web bugs would be stopped. Using the Simple HTML feature means you can do only one of these at a time.
I agree with comment 282, simple HTML is a very nice feature (And I use it), but since Outlook has functionality for not giving away emailadresses (not downloading pictures, etc from remote locataions) one can expect a lot of companies to embed them in the message. In some cases I want the simple HTML (especially in the case of suspected SPAM), but most of the time I just want to be sure that my emailadress isn't given away, while I read the email with the layout as intended by the sender. My point is that these two issues (simple HMTL and No server hits) resolves two completely different problems. Simple HTML blocks content that doesn't generate a server hits and is required for proper displaying of the message.
(In reply to comment #280) I support pi as long as it doesn't get too long :-) > Asking for blocking in 1.8a because this is a major privacy concern. ... and security. I am talking about iframes. What about 1.7? Too late? The scenario in bug 64066 comment 31 already has happened! (which is a browser bug, so I was sent here) > spammer might just start attaching .au or .wav files to emails for this purpose? Please see: bug 191460 comment 24 and bug 191460 comment 84 - Virusmail executes embedded virus. (netsky.p@MM, W32/KLEZ.H@mm) (This is partly solved for Windows by bug 239160 and a MIME patch but the iframe problem still exists) bug 213280 - denial-of-service-attack using iframe & telnet-urls
This bug is not a security concern. It only blocks fetches to the *Internet*, it should not block fetches to msg parts, because e.g. inline image loads should continue to work. So, if there is a security problem, you can always exploit it by attaching the exploiting doc and refering to it with an appropriate URL - indeed, the worm described in bug 191460 does just that -, and this bug (28327) won't stop it by design. "Sanitzed HTML" did.
*** Bug 230274 has been marked as a duplicate of this bug. ***
I think the best solution was mentioned in Comment #150: Put mails in a sandbox and don't allow them to access anything outside of themself. For special cases there could be exceptions like Mails from foo@bar.com may access urls matching http://www.deadbeef.com/* ...
Flags: blocking1.8a? → blocking1.8a-
*** Bug 244593 has been marked as a duplicate of this bug. ***
I think fixing this will be easier and cleaner (at this point) for tbird. tbird has it's own content policy, see http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMsgContentPolicy.cpp in the tbird ui, mscott has: privacy [ ] block loading of remote images in mail messages in 1.7 (so I assume trunk, too), we have: privacy and security images image accept policy [ ] do not load remote images in Mail & Newsgroup messages so for tbird, maybe this will be acceptable: 1) keep the pref name the same (mailnews.message_display.disable_remote_image) 2) but change the UI to be "block loading of remote content in mail messages" or "block loading of remote files in mail messages" 3) fix nsMsgContentPolicy::ShouldLoad() and maybe do: -else if (aContentType == nsIContentPolicy::TYPE_IMAGE) +else (or we might want this check for remote content before the check for plugins, as "don't load remote content" might take precendence over plugin content handling) note, I'm not sure if that will address the "don't load remote css problem" or the "don't load any iframes" problem. (see bug #243306) the reason, besides UI, why this is easier in tbird is we won't break browser as we have a separate policy in a separate app. let me attach the text of my conversation with bz for some background.
Status: NEW → ASSIGNED
here's a conversation I had about this with bz. <bz> So as far as blocking everything <bz> I'm looking at nsMsgContentPolicy::ShouldLoad <bz> It's a matter of replacing the line <bz> 124 else if (aContentType == nsIContentPolicy::TYPE_IMAGE) <bz> With the line <bz> 124 else <bz> I suspect that should be sufficient... <sspitzer> I'll look into that frame thing. <sspitzer> as remote iframes should be loaded in mail either. <bz> yeah <bz> Agreed. <bz> Iframes are TYPE_SUBDOCUMENT <bz> on trunk <bz> and SUBDOCUMENT on branch <sspitzer> you mean, add an else check for: nsIContentPolicy::TYPE_SUBDOCUMENT (like we have for nsIContentPolicy::TYPE_IMAGE) <bz> yeah <bz> Note that that won't block stylesheets... <sspitzer> don't we already block those? <bz> I would think we would want to apply the image pref to all content regardless of type <bz> Not that I'm aware of. <sspitzer> I think I was thinking of (Link: http://bugzilla.mozilla.org/show_bug.cgi?id=184948)http://bugzilla.mozilla.org/show_bug.cgi?id=184948 <sspitzer> what's the right way to block all remote content? <sspitzer> or is that not possible? <bz> well... <bz> just don't do a type check? <bz> Run the code that checks the scheme no matter what type the thing is?
Target Milestone: mozilla1.5beta → mozilla1.8beta
Here you can find a list of web bugs : http://www.freedom-to-tinker.com/archives/000610.html
*** Bug 256839 has been marked as a duplicate of this bug. ***
Even Outlook Express has fixed that issue in their latest release: Screenshot: http://microcephale.free.fr/priv/OEprivacy.PNG It is kinda trivial to block images AND other external content. Without blocking other content, the image blocking feature is totally and utterly useless.
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Flags: blocking1.8a4?
restoring aviary1.0 nomination, only project leaders can set blocking status.
Flags: blocking-aviary1.0+ → blocking-aviary1.0?
taking
Assignee: sspitzer → mscott
Status: ASSIGNED → NEW
*** Bug 248853 has been marked as a duplicate of this bug. ***
*** Bug 248857 has been marked as a duplicate of this bug. ***
*** Bug 259091 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a4? → blocking1.8a4-
Flags: blocking-aviary1.0? → blocking-aviary1.0+
*** Bug 260962 has been marked as a duplicate of this bug. ***
Attached patch the fix — — Splinter Review
this may be too agressive. Testing will let us know for sure. I may also change the string text to refer to remote content instead of remote images in the UI.
> this may be too agressive. Testing will let us know for sure. Doesn't it affect Thunderbird RSS reader? It generate e-mails with iframe loading the remote article.
(In reply to comment #301) > > this may be too agressive. Testing will let us know for sure. > > Doesn't it affect Thunderbird RSS reader? > It generate e-mails with iframe loading the remote article. Yes, this bug by design will break these messages, and I see no way around it. IMHO, the RSS reader should be changed in some way (need to figure out how).
No this change has no effect on Thunderbird's built in RSS reader. Things will still load fine for RSS folders.
Flags: blocking1.8a1-
*** Bug 261520 has been marked as a duplicate of this bug. ***
I checked this into the branch and the trunk last week and so far I haven't gotten any complaints about it being too aggressive yet. I may end up changing the string we show in the UI down the line but I'm not going to keep this bug open just for that issue. Also need to do some further testing to see if the remote style sheet code calls through the content policy manager...
Status: NEW → RESOLVED
Closed: 21 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
This is not blocking iframes on the trunk (2004101505), but is working for thunderbird (20041009). I double-checked that the patch here was checked into the trunk, why wouldn't it work there?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I should also note that it looks like nsMsgContentPolicy is explicitly blocking ftp, http, and https only. Not gopher (found "in the wild", see comment 234) or any other scheme that might be supported by us or the OS. A scheme that opened a new window, like an external app or one of the news protocols, wouldn't be useful as a commercial web-bug, but a one-off snoop attack where you don't care if the recipient knows that you know could still succeed.
*** Bug 264828 has been marked as a duplicate of this bug. ***
*** Bug 265296 has been marked as a duplicate of this bug. ***
*** Bug 266462 has been marked as a duplicate of this bug. ***
(In reply to comment #305) > I may end up changing the string we show in the UI down the line but I'm not > going to keep this bug open just for that issue. Bug 266503 opened for the UI update. > Also need to do some further testing to see if the remote style sheet code > calls through the content policy manager... Apparently it does not; I've tested, and remote style sheets (via <link>) are still loaded with TB version 0.8+ (20041028), Win2K. However, as noted in comment 306, the <iframe> tag is being blocked with TB; but not for MailNews 1.8a5-1019. How is it that the patch was checked into the trunk with neither review nor superreview?
*** Bug 260039 has been marked as a duplicate of this bug. ***
This is possibly the subject of Secunia advisory SA13086: "Mozilla 1.7.3 / Thunderbird 0.8 Valid Email Address Enumeration Weakness" http://secunia.com/advisories/13086/ Adding blurb to help catch duplicate filings.
(In reply to comment #311) > Apparently it does not; I've tested, and remote style sheets (via <link>) are > still loaded with TB version 0.8+ (20041028), Win2K. I can't confirm this for TB 0.9final, Win2K. The remote stylesheet is not loaded before clicking on the "Show Images" button (ensured via Ethereal).
(In reply to comment #315) > I can't confirm this for TB 0.9final, Win2K. The remote stylesheet is not > loaded before clicking on the "Show Images" button (ensured via Ethereal). In TB 0.9, I see that also.
Product: MailNews → Core
Blocks: 239954
If it was good enough to block aviary 1.0, it is good enough for 1.1.
Flags: blocking-aviary1.1?
Blocks: 278176
bug 274866 made the pref to block images in mailnewd (for seamonkey) to block all remote content, the same way as thunderbird does it.
(In reply to comment #318) > bug 274866 made the pref to block images in mailnewd (for seamonkey) to block > all remote content, the same way as thunderbird does it. I reopened this because of the suite. If that's being handled elsewhere then this can get re-closed.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
It would be useful if someone explained how to use it. Is there UI for this? If not it won't be available to most users. pi
Just set the good old pref to not show images in mailnews. (like i tried to say in comment 318 (there are too many comments here)) Bug 287672 is about fixing the wording of the pref panel text.
Flags: blocking-aviary1.1?
No longer blocks: majorbugs
(In reply to comment #319) > (In reply to comment #318) > > bug 274866 made the pref to block images in mailnewd (for seamonkey) to block > > all remote content, the same way as thunderbird does it. > > I reopened this because of the suite. If that's being handled elsewhere then > this can get re-closed. Was this handled elsewhere? I didn't see it anywhere, yet this was closed. Thanks.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: