Download in other formats: Plain Text Link in 1.0 RC Used to view in browser, now downloads file

[miked@…]

I made ​a post to the mailing list after I updated Trac and the behavior of the “Plain Text” link under “Download in other formats” changed.

The link used to display the wiki markup in the browser, but now it causes my browser to download a text file.

The new behavior logically make more sense as it does say download, however there are others, such as myself, that prefer the old behavior. Should we wish to download it's still possible.

On the mailing list I was instructed to open a ticket regarding this.

Thanks.

[Remy Blank]

As mentioned in that thread, this was done in the context of #10412 to work around an XSS vulnerability in IE. So the only reason I could see to revert it would be to "prove" that the vulnerability isn't present anymore in recent IE releases (≥ IE7, I would say).

[anonymous]

rblank are you ryan.j.ollos from the CC added above and the mailing list who sent the email saying "rblank agrees with your comment ;)"?

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to anonymous:

rblank are you ryan.j.ollos from the CC added above and the mailing list who sent the email saying "rblank agrees with your comment ;)"?

No, rblank knows way more about Trac than I do ;)

[miked@…]

Oh so you are the guy from the mailing list, and the one who CC'd but not rblank. OK I understand.

How did you add yourself to CC (I already am getting emails for this one, but I want for the other ticket as well, I made a comment there).

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to miked@…:

How did you add yourself to CC (I already am getting emails for this one, but I want for the other ticket as well, I made a comment there).

Enter you name and email under prefs. After you do that you'll see an Add to Cc: checkbox in the Modify Ticket section.

(In the future, topics like this are better addressed through the mailing list)

[Mike Doroshenko II <miked@…>]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

Replying to miked@…:

How did you add yourself to CC (I already am getting emails for this one, but I want for the other ticket as well, I made a comment there).

Enter you name and email under prefs. After you do that you'll see an Add to Cc: checkbox in the Modify Ticket section.

(In the future, topics like this are better addressed through the mailing list)

Thanks.

[Jun Omae]

Replying to rblank:

As mentioned in that thread, this was done in the context of #10412 to work around an XSS vulnerability in IE. So the only reason I could see to revert it would be to "prove" that the vulnerability isn't present anymore in recent IE releases (≥ IE7, I would say).

All IE releases still have the vulnerability. If IE8+, we could send X-Content-Type-Options: nosniff header to avoid it. Otherwise, we should send as a attachment.

See "MIME-Handling: Sniffing Opt-Out" in ​http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx.

[Christian Boos]

I think we could have some user preference for this, for those who really want to have the unsafe behavior. There we could easily add a hint to explain the issue.

e.g.

[ ] Open plain text attachments directly in the browser

This can present a security hazard as some browsers will try to "guess" the MIME type of the file from its content regardless of what was specified. If someone crafts an attachment which contains malicious HTML markup (think XSS), you'll be vulnerable.

[Mike Doroshenko II <miked@…>]

Thanks :)

The only person accessing my Trac is me, so I should be safe, especially since I don't use IE for Trac. The only way I see myself vulnerable would be if I did use IE and if it would be possible for me to accidentally put something bad.

Replying to cboos:

I think we could have some user preference for this, for those who really want to have the unsafe behavior. There we could easily add a hint to explain the issue.

e.g.

[ ] Open plain text attachments directly in the browser

This can present a security hazard as some browsers will try to "guess" the MIME type of the file from its content regardless of what was specified. If someone crafts an attachment which contains malicious HTML markup (think XSS), you'll be vulnerable.

[Remy Blank]

Replying to cboos:

I think we could have some user preference for this, for those who really want to have the unsafe behavior. There we could easily add a hint to explain the issue.

Do you really want to leave a security decision to the end user (as opposed to the admin)? I would prefer not. I would rather have a site-wide config option than a per-user preference.

[Christian Boos]

Well, it's a security issue that can affect the end user, so consider the opposite point of view: would you like that an administrator puts you at risk? And the admin has no ways to know that all the users will use safe browsers (for example, here we would never activate such an option, so you wouldn't have a way to get back the "view as plain text in browser" feature on t.e.o). At most, to enforce a stricter control, an extra admin setting could forbid users to change the default (the user setting wouldn't even appear in the prefs page, and changing it "manually" (POST) wouldn't take effect).

So I think have a safe default is fine, leaving it to the user to take the risk for himself should be fine as well, and for truly paranoid environments, the admin could forbid the users to expose themselves.

[Remy Blank]

Replying to cboos:

Well, it's a security issue that can affect the end user, so consider the opposite point of view: would you like that an administrator puts you at risk?

He won't, because I don't use IE. As do most users who know about such risks, but we're a minority. Most users don't understand, know or even care what the risk is. Do you really want to hand them a gun?

And the admin has no ways to know that all the users will use safe browsers (for example, here we would never activate such an option, so you wouldn't have a way to get back the "view as plain text in browser" feature on t.e.o).

That's what I would expect, yes. The option should be turned on only in very specific cases where all content submitters are trusted. Probably only on internally-facing installs.

So I think have a safe default is fine, leaving it to the user to take the risk for himself should be fine as well, and for truly paranoid environments, the admin could forbid the users to expose themselves.

Is this feature really *that* important that it should get its own user preference? In any case, please make the config option disable the feature by default.

[Christian Boos]

Replying to rblank:

Is this feature really *that* important that it should get its own user preference?

I think most users won't care, but for those who will, they'll be please to see they can tweak the system to their liking.

I just installed a few Chrome extensions today. For one of them, the Options pages lists, I don't know, something like 50 options. And why not? For the most part I kept the defaults, but for the few items I really cared about, I've been able to change them. So… I think making more room for individual fine-tuning won't hurt.

In any case, please make the config option disable the feature by default.

Sure.

[Remy Blank]

Replying to cboos:

I just installed a few Chrome extensions today. For one of them, the Options pages lists, I don't know, something like 50 options. And why not? For the most part I kept the defaults, but for the few items I really cared about, I've been able to change them. So… I think making more room for individual fine-tuning won't hurt.

And did any of the options say "Allow any web page to steal my banking credentials, erase my hard disk and kick my dog"? Probably not. The preference you propose has at least the potential to do the first one (I haven't found an actual exploit with a quick search, though, most sites only mention phishing).

Although, come to think of it, that plugin probably has access to your banking credentials anyway, because you gave it the permission. Web security really is weird.

[Christian Boos]

Replying to rblank:

And did any of the options say "Allow any web page to steal my banking credentials, erase my hard disk and kick my dog"? […] Although, come to think of it, that plugin probably has access to your banking credentials anyway, because you gave it the permission. Web security really is weird.

Yes, just so! The installation of the extension said something close: This extension can access: Your data on all websites . There was however a notice saying "don't worry; we don't want to be evil"™, so I felt safe after having read that ;-)

The preference you propose has at least the potential to do the first one

Well, I'd really like to find the proper way to handle this kind of situation:

• provide safe defaults
• give the ability to advanced users to override the safe settings ("Trust me, I know what I'm doing" ;-))
• …without tempting the average user to do the same!

Perhaps a special permission could be given (ADVANCED_CONFIG), which would unlock an Advanced tab in the prefs?

Of course, if this is only about that little feature, such a mechanism is probably overkill. However, if we have again such a trade-off…

[Ryan J Ollos]

Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.

[Ryan J Ollos]

Milestone renamed