Closed Bug 580442 Opened 14 years ago Closed 14 years ago

Insert>>html sanitizes certain tags [embed,iframe,marquee]

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 597784

People

(Reporter: JoeS1, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [tbtrunkneeds])

Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Shredder/3.2a1pre ID:20100718035309 Open an html composition window in current trunk. select Insert>>html attempt to insert any of the above mentioned tags via key entry or paste. Result: the tags are not allowed. Quick STR: Type in the following in the insert>>html window <marquee>test</marquee> The result is the text only, the marquee tag is sanitized. Regression Range: Works in 20100614 Shredder/3.2a1pre Fails in 20100615 Shredder/3.2a1pre I strongly suspect: Bug 520189 - Fix copy and test for the HTML editor; f=bzbarsky,dbaron r=sayrer,peterv,bzbarsky sr=roc http://hg.mozilla.org/mozilla-central/rev/208d7f999037
Editor is Core code, moving. Also reproduced in SeaMonkey's Composer on trunk, whereas Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 behaves as expected on the 1.9.2 branch.
Component: Message Compose Window → Editor
Product: Thunderbird → Core
QA Contact: message-compose → editor
This is intentional. Why don't you want that? I _guess_ we can add maruqee to the white-list, but I really don't want to encourage its usage that way! ;-) embed and iframe will not be added to the white-list though, because allowing them would mean security risks for the web.
(In reply to comment #2) > This is intentional. Why don't you want that? I _guess_ we can add maruqee to > the white-list, but I really don't want to encourage its usage that way! ;-) > embed and iframe will not be added to the white-list though, because allowing > them would mean security risks for the web. I guess it depends on your POV Editing content in a contenteditable div on the web, is far different from including an embedded audio selection in an email or newsgroup post for folks who enjoy that venue. Yes, you can "click on a link" but that's like getting a birthday card with a cd inside, then looking for a device to play it on. Just my POV: Mail/News!="the web" so why should the "core platform" dictate what can be done.
Blocks: CVE-2010-2769
Whiteboard: [tb32needs]
There are at least two ways to fix this behavior. 1. Replacing the paranoid fragment sink component in Thunderbird (and possibly Composer) with your own version of the component which basically doesn't block any tags/attributes. This is *NOT* something that I would recommend though, since that component might be used by other code as well. 2. Making cmd_inserthtml and paste/drop handlers go through different code paths, so that the former uses the non-paranoid fragment sink. This won't have any security risk, I think, because web pages are not allowed to issue that command on documents from other domains. Boris, what do you think?
If #2 is easy, sounds good to me... however wouldn't that affect sites too, if they cmd_inserthtml with an untrusted string? Can we skip the paranoid sink thing only when there's no way script can run in the content or something?
(In reply to comment #7) > If #2 is easy, sounds good to me... however wouldn't that affect sites too, if > they cmd_inserthtml with an untrusted string? Sure, but we don't block innerHTML setter based on the same rationale, do we? > Can we skip the paranoid sink thing only when there's no way script can run in > the content or something? How can we determine that?
(In reply to comment #8) > > Can we skip the paranoid sink thing only when there's no way script can run in > > the content or something? > > How can we determine that? Actually, we can't! Because the HTML might be sent to a server and be served as part of another web page later on.
> Sure, but we don't block innerHTML setter based on the same rationale, do we? Fair.... I don't have a good feel for how people use cmd_inserthtml in practice. What about copy/paste into a contenteditable suddenly running script with the site's permissions? That seems odd too...
It's not obvious to me what the motivation would be for fixing this bug. I'd be wildly surprised if most HTML supporting mail-readers in the world support the tags mentioned here at all, and if we ever want to spend valuable energy on growing the set of widely supported tags in the world, I'd hope we'd focus on the most important use cases. Eg, I could imagine caring about <video> and <audio> at some point in the future. It's not clear to me what the important use cases for the tags mentioned here would be, if there are any. Let me know if I'm missing something here...
(In reply to comment #15) > It's not obvious to me what the motivation would be for fixing this bug. I'd > be wildly surprised if most HTML supporting mail-readers in the world support > the tags mentioned here at all, and if we ever want to spend valuable energy on > growing the set of widely supported tags in the world, I'd hope we'd focus on > the most important use cases. Eg, I could imagine caring about <video> and > <audio> at some point in the future. It's not clear to me what the important > use cases for the tags mentioned here would be, if there are any. Let me know > if I'm missing something here... Curbing my urge to vent here... Prior to the video and audio tags embedding was possible way back in NN4.7 The new tags are just now supporting a culture and vision that was explored a long time ago. That is: the freedom to use mail/news in the way that you so-desire, with the content that you enjoy. So IMHO you are missing something..the popularity of You-Tube, the success of the social networks, and the ability to communicate with "flair". All of which require the ability to use these tags in mail/news.
I appreciate the urge-curbing :-). I think our views and interests are actually aligned in more ways than is readily apparent, and my hope is that the Thunderbird Product Notes doc at <https://wiki.mozilla.org/index.php?title=User:Dmose/Tb_Product_Notes> will actually be helping in working through that. (In reply to comment #16) > > Curbing my urge to vent here... > Prior to the video and audio tags embedding was possible way back in NN4.7 > The new tags are just now supporting a culture and vision that was explored a > long time ago. That is: the freedom to use mail/news in the way that you > so-desire, with the content that you enjoy. I think the goals of offering freedom to use mail/news in the way that a person desires and with the content that a person enjoys are not only good ones, but are also very much compatible with the Manifesto values mentioned on that page, particularly the "Individuals must have the ability to shape their own experiences on the Internet." So I see good values alignment here. I believe the disagreement is around strategy towards achieving those goals. In particular, there while you're quite right that fixing this bug is one step on a possible road towards achieving those goals, I'm going to claim that there are significantly better roads available to us. In particular, I believe that Tb's newly stated goal of "Maximize our impact in shaping the future of messaging on the Internet." is critical to us actually helping a significant number of people be able to do the things that you propose. > So IMHO you are missing something..the popularity of You-Tube, the success of > the social networks, and the ability to communicate with "flair". If I'm understanding you correctly, another way to frame communication with "flair" is simply rich and expressive communication, which I like as an idea. Perhaps it's even something that wants to be incorporated in a future version of the product notes. It's not clear to me what You-Tube and social networks have to do with this discussion. Can you elaborate? > All of which require the ability to use these tags in mail/news. It's not obvious to me why this would be true. Can you unpack the use cases for each tag that you're envisioning?
I realize in re-reading what I wrote, that the two paragraphs starting with "I believe..." don't actually make a lot of sense given the parts of your argument that I don't yet understand. So feel free to disregard those paragraphs in your response. :-)
(In reply to comment #18) > I realize in re-reading what I wrote, that the two paragraphs starting with "I > believe..." don't actually make a lot of sense given the parts of your argument > that I don't yet understand. So feel free to disregard those paragraphs in > your response. :-) I'll send you a personal email.(as we already lost bz on cc) It's a demo of my vision for tb subject: "special places" Please view it with plugins enabled, view as original html, view attachents inline "off" and with a very recent build of shredder.Like 20100721 Shredder/3.2a1pre ID:20100721033248 The attached text explains my views.
As far as I can tell, I haven't received such an email.
(In reply to comment #20) > As far as I can tell, I haven't received such an email. No idea why you did not receive..filters?? sent again Message-ID: <4C4F5582.4010407@bellatlantic.net> Date: Tue, 27 Jul 2010 17:54:10 -0400 From: JoeS <jsabash@bellatlantic.net> User-Agent: Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100722 Shredder/3.2a1pre MIME-Version: 1.0 To: Dan Mosedale <dmose@mozilla.org> Subject: Special Places Content-Type: multipart/mixed;
Whiteboard: [tb32needs] → [tbtrunkneeds]
xref bug 592601 The font tag is allowed, but the "face" attribute is not. It's completely understandable that the deprecated "font face" would be used in an html sig, since it is still used in TB html edits to select body font.
Blocks: 592601
No longer blocks: 592601
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
I use the ability to to test such code in newsgroups that allow such (Embed and Object) so that I can get a second opinion on something I can use in my website. In fact since this bug has reared its ugly head. I have discontinued upgrading SeaMonkey at 2.0.6 Gecko rv:1.9.1.11. And I will continue not upgrading until it is fixed or some method is created to bypass it through about config, a menu choice, or someone comes up a hack to get around it. No one has the right to tell me how I can use an application (especially an open Source application that depends upon the good graces of users to promote it). Most of the people that use such are honest, and intend no harm. Instead of going about the way why not have a preference setting to allow person on other end to block the items. Then the users get to choose whether they want to do or see or heard such. Again we have developer run amuck, deciding what they feel is right for the user rather than letting the users decide.
You need to log in before you can comment on or make changes to this bug.