user or not". Instead, it's taking on a loan with an unknown interest
more likely it is that when security issues show up that involve
is they're doing, and dedicate their time to pushing a security release
out. Those releases are necessary to maintaining the security of all
Thunderbird users, but they take precious time away from other
Thunderbird work. Figuring out ways of minimizing the need for those
releases is a good idea.
On to the issues brought up in that thread:
a) As Boris and Joshua have pointed out, we have currently disabled the
infrastructure that we relied on to optionally offer it has changed, and
we didn't want to expose beta users to undue risk.
There are a few use cases which are impacted by this choice, and I
believe they need to be evaluated independently. The broad ones are:
The RSS content is the easiest one to think about, I think, because
feeds are subscribed to actively, and published via the same protocols
as the web. In particular, a large fraction of blog content includes
enough confidence of safety. There is lots of JS content there, and
given the subscription model, the exposure risk is lower.
risks involved, the vast majority of email users currently use email
recipient are quite low. As far as I understand it, that means that
some of the use cases mentioned (the photographer sending photos w/
animated previews) are unrealistic. Given the "push" model of email
(spam can carry malware payloads), the fact that only a tiny fraction of
the market is going, I'm still of the belief that the best way to
third-party add-ons, and I would strongly suggest that whoever writes
that add-on also try to ensure a degree of trust with the content before
small size of that user population and its cohesion makes me think that
long-term, an add-on that really provided better html authoring for news
content might be a better way to serve those users, without getting
tangled into the overall product policies. In other words, a "rich html
newsgroup addon" could give those users a better experience than what
Thunderbird can as-is, while not entraining security issues for the vast
majority of newsgroup users who don't use JS or HTML authoring.
b) Writing secure software is incredibly hard. As Bz has mentioned,
very, very few people are able to make the kind of analyses that we
need. We must be cautious, as Thunderbird stores lots of very sensitive
Thunderbird is not as easy as it could be. Unfortunately, that's in
part because the codebase responsible for that feature is, according to
what I've been told, hard to maintain, and even harder to evolve. I'd
be very interested in seeing those capabilities move forward, but that's
one of the areas for which the cost of making changes outweighs the
benefits we can get, at least for now. HTML authoring in general is an
incredibly hard problem, which I don't think anyone has solved well thus
far. I'm not keen to take it on at this stage in Thunderbird's evolution.
d) Thinking beyond these bugs.
The bit that I've found most interesting and encouraging about this
whole discussion is the motivation of why people are pushing the
security envelope of Thunderbird, as I see them as opportunities for new
features that would be both secure and more fun.
For example, Joe's suggestion of JS-enabled zooming photo thumnails --
It seems to me that Thunderbird should, by default, provide a better way
of sending and receiving images, using carefully audited code, great
design, and high usability. Why not bring that great feature to all
by writing the relevant code in Thunderbird, rather than putting it in
The description of the grandparent or grandchildren receiving animated
emails is also great. Let's figure out ways to build in those kinds of
features in such a way that the senders can focus their time on being
creative, without requiring them to put the recipients of their letters
at risk of a virus infection. I don't know what that feature would look
like in practice (an embedded animation markup language? connections
with a web service which would sandbox the animation from personal
data?), but that's an interesting discussion which might lead to a real
change in how people communicate.
I have a separate note about overall process coming up too.
About the lack of "security" of js:
I still say the risk is greatly overstated. I am acquainted with
great as implied here, not a week would go by without a major security
breech somewhere with someone. Stationery communities are very close
knit and spread such news immediately. In 6 years I have heard of *NONE!*
About your add-ons to achieve multimedia competence:
About 3 or 4 years ago "we" were having much this same discussion, maybe
even right here.
At that time, someone obviously vehemently opposed to *any* html content
anywhere, (he actually said in the thread "I don't think html is good
for the net") told me I should write an extension for html compatibility
since I/we in the multimedia community obviously wanted this function so
badly. Then he asked why I didn't actually write such an extension. He
answered his own question with, "Because you can't, can you?" He then
went on to remark there was no demand for such an extension, because if
there was demand, there would obviously be such an extension available!
And here we are still talking about add-ons and extensions as a way to
achieve full function in mail/news.
About that time, because of that attitude, I lost interest in
contributing to these discussions. It appears I haven't missed much.
> Stationery communities are very close
> knit and spread such news immediately.
Hey, speaking of which -- if you know of people who would be interested
in contributing high-quality 'stock' stationery for Thunderbird that
could rival what Mail.app includes, I'd be interested in hearing more.
As for rivaling Mail.app stationeries, that hasn't been possible since
the demise of Netscape Communicator 4.79.
My ignorance leads me to ask for better identification of what "Mail.app" is.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Your statement, "Due to the (very real) security risks involved, the
vast majority of email users currently use email clients that don't
Can you provide numbers to support the "vast majority"? My experience
shows that Outlook and Outlook Express dominate the email market, and JS
is supported in both.
I've used JS enabled versions of TB since the beginning of its
existence, along with the help of the EditHTML extension, that allows
scripting to be placed into the HEAD section, sometimes needs for JS to
work. I send out special scripts that those who have received it loved;
holiday, birthday, etc. No one has ever written back stating they
weren't able to view it properly. That's most likely because just about
everyone uses a JS enabled client.
I don't view my use (nor anyone else's use) of JS as "...pushing the
security envelope of Thunderbird...". Having me believe that the risk
is there is the same as no one ever having JS exploited in a mail
client. One side says, it WILL happen. The other side says this has
been discussed for years and nothing HAS happened. I guess when it
actually becomes reality is when users will take notice. And at that
time MS will probably make adjustments, as it is doing with IE.
To remove JS functionality in the TB program that is trying to get a
foothold in the market would not be taken as a technology advancement in
regards to security, but as a crippled too little too late client in my
opinion. I would think that if MS removes JS capability in OL & OE,
then it would follow suit that TB would do the same, but not before.
Unless there are no plans to try and have TB take away some of that
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.
Now that I know it's The Apple equivalent of the MS Vista Windows Mail I
can say with templates Tb could offer some ready made
stationery. To do so would need a bundle of files composed of images and
CSS. Where such would be installed would be part of the planning with
options of Globally in the program files tree or per Profile.
AFAIK, recent versions of Outlook have it quite hidden if available at
all. From what I could tell, the instructions to enable it in Outlook
2003 are quite complex
I haven't found any such instructions for Outlook 2007 or Windows Mail.
All major webmail systems (gmail, hotmail, yahoo mail, etc.) don't
interpret JS content, AFAIK. Mail.app doesn't, AFAIK. Mobile devices
don't, AFAIK. I'm pretty sure that OE and older versions of Outlook are
a minority at this point. I'll admit that I don't have numbers. If
anyone has numbers regarding distributions of email clients, it'd be
generally very useful. (cf Mitchell Baker's post about why some
aggregate data would be for the public benefit).
I think it's not even primarily that it would be that bad code, it's
primarily because it's code nobody has been actively maintaining for
ages, as the only person I know who was and is really good with the HTML
editing code in Mozilla (Daniel Glazman) has done 3-4 side projects in
the last few years that developed that code further to an almost usable
state, when he threw it away again and started new, without ever merging
any of that code back to the Mozilla codebase.
The code between Thunderbird/SeaMonkey HTML Mail editing and SeaMonkey
Composer Website HTML editing is largely shared, which is basically a
good idea, but if, as I said, nobody's working actively on it for years
and nobody's around any more that really knows the code, it doesn't help
All in all, I think the code is saner and better understandable than
libmime, but there seems less interest in actively working on it.
And Firefox designMode, for what it's worth.
The rest of what Robert says is spot-on. This is just code that hasn't
been owned in 7 years or so.
Right and there is now an additional HTML Editor named "Blue Griffon".
Cited from secnews.netscape.com:563/mozilla.netscape.thunderbird
> Looks like an old player in a new uniform:
> * Ron K...*
Yes it's the same one all along - Daniel Glazman.
Every version of mail or new reader I've tested on Mac have all used JS.
Mail use it. and Opera for Mac's mail newsreader section does as well.
Phillip M. Jones, CET mailto:pjo...@kimbanet.com
If it's "fixed", don't "break it"! http://www.vpea.org
G4-500 Mac 1.5 GB RAM OSX.3.9 G4-1.67 GB PowerBook 17" 2GB RAM OSX.4.11
Really? Apple's Mail.app? Could you please explain how to enable it? I
think it would be very useful to compare our implementation with theirs,
but I looked at every single option in every pref pane, and then googled
for instructions, and I couldn't find anything at all that even
suggested that there was any way to get Mail.app to support JS in mail
content. Your information would be a big help!
>> Looks like an old player in a new uniform:
> Yes it's the same one all along - Daniel Glazman.
Well, maybe this time he will make an effort to push his changes
upstream. But my hopes aren't high, glazou is good in talking, but
bad when it comes to delivering.
By the same token if that is the case should you ban or remove or make
incapable by Mozilla products in any form to use Active-X.
Active-X is by far 10,000 times more dangerous than JS.
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112 |pjo...@kimbanet.com, ICQ11269732, AIM pjonescet
If it's "fixed", don't "break it"!
and html in mail, rather than, as seems, letting it assume they must
be coexistent. HTML in email is of particular interest to marketers
and business, as well as those other situations described where used
recreationally or personal interest. It is business who set up The
Email Standards Project (http://www.email-standards.org/) and mostly
business interests who were the participants in the W3C HTML Mail
Workshop in Paris, 2007
(http://www.w3.org/2007/05/html-mail/minutes#attendees), The papers
for that workshop are interesting,
http://www.w3.org/2007/05/html-mail/papers and the Working Group is
intending to develop a White Paper on html in email. I know that all
the business type mail I receive myself such as notices of updates,
bills due, new products from places that I like and so on, all arrives
in html (because most of the message is missing as I have set to plain
text!). So while Thunderbird may wish to ignore development of html
in email, I think that in the end, there will be a loss in attraction
and popularity through loss in ease and functionality for a large part
of the market.
Personally, I never use html in email and have no interest in it but
that is not at all relevant. I would wish first simple functional
things implemented that would ease use, many of these are in bugs
already. I think also of a future where a completely different sort of
not so far as formatting and sending of the messages. No idea how this
could be separated, but mean things like a tiny toolbar that could be
moved around such as to be put on the left side if wished, or right
side or bottom. A scheme that comes to mind, and please take only as a
“balloon idea” is that of Xmind, a mind mapping which I like but
where, if you have time to spend, you can learn amazing features of
flexible toolbars, panels, as well as colourings. Incorporating
methods for photographs as others suggested seems ideal direction, I
use Slideshow Add On and it seems the very least that should be basic.
[orange is in ca using sympatico]