Make "do this automatically for files like this from now on" work even with "content-disposition: attachment"

REOPENED
Unassigned

Status

()

Toolkit
Downloads API
P5
enhancement
REOPENED
9 years ago
7 months ago

People

(Reporter: Erik Staats, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 3 bugs, {sec-want, ux-control})

Trunk
sec-want, ux-control
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [p-chrome] [sg:want] [Advo][qx], URL)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Many users have requested in bug 331259 and others the ability to automatically download files even when the file is sent with the "Content-disposition: attachment" header.  They would like to ability to bypass the security guidelines in RFC 2183 and automatically download these files.

The fix in bug 331259 addressed an issue with saving the automatic download checkbox settings and did not attempt to address any issues related to RFC 2183.

Hopefully, this bug will serve as a better location for the discussion of the user requests, since bug 331259 has been marked fixed.

Reproducible: Always
(Reporter)

Updated

9 years ago
Version: unspecified → Trunk

Comment 1

9 years ago
Bugzilla is not a place for discussion. Please use nntp://news.mozilla.org/ mozilla.dev.apps.firefox or http://groups.google.com/group/mozilla.dev.apps.firefox

Comment 2

9 years ago
Automatically downloading attachment sent files is bug 285976.
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> Automatically downloading attachment sent files is bug 285976.

It sounds like bug 285976 is to disable the "automatically download" checkbox with "Content-disposition: attachment" headers.  That's not what users are requesting in bug 331259.

Comment 4

9 years ago
Sounds reasonable to me.  As far as I know, web sites use "content-disposition: attachment" as a security measure to mean "don't treat this as a web page served from this server", not "make sure the user is prompted before the file is downloaded".

Boris seems to be claiming otherwise in bug 285976, but I'm not convinced.  Even with his "deliberately unhelpful PDF reader application" use case, remembering the action as "download" wouldn't be a problem.  The only problem would be remembering the action as "open with (deliberately unhelpful PDF reader application)" and then not figuring out how to undo that remembering.  That problem exists even without content-disposition: attachment and I don't think working around it is a major use case for content-disposition: attachment.

RFC 2183's wording only makes sense to me in the context of mail messages, not in the context of link clicks.  I don't see how fixing this would be a security problem.  What would be a security problem is "fixing" bug 185618.

Boris, are you actually against having this UI change in Firefox, or are bug 236541 comment 38 through 48 just about implementation details?
Status: UNCONFIRMED → NEW
Component: General → Download Manager
Ever confirmed: true
Product: Firefox → Toolkit
QA Contact: general → download.manager
Summary: Provide option to bypass RFC 2183 security guidelines when downloading files. → Make "do this automatically for files like this from now on" work even with "content-disposition: attachment"
I can live with remembering the "save" action, no problems.  We just shouldn't be remembering the "open in app" or "view in browser" actions in this case.

Note that the behavior websites _really_ want here, typically, is to force save with no user choice (what IE does), and we're just giving the user more options.  We've had bug reports about the user having said options, but we sort of stand by that.

This is basically what bug 236541 comment 38 says, and honestly, I'm sort of tired of going over this argument again and again and again....

Comment 6

9 years ago
Not fixing this bug (and I mean a real fix, not Boris's preferred one) has caused me to switch to Chrome, which doesn't have this problem.

Sorry guys, Firefox was fun, but I download way too many .torrents to put up with this shit. I just want to open the damned things with with muTorrent instead of going through a downloading + finding in Explorer + opening adventure safari.
Can we *please* not have this turn into bug 331259 and actually follow bugzilla etiquette [1] here?  That means no comments saying "Please fix this" or "This made me switch to browser X".  The only impact it has on getting this fixed is a negative one because developers don't want to pay attention to a bug that has all sorts of comments like that.  Please don't scare away the developers.

[1] https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Updated

9 years ago
Whiteboard: [p-chrome]
From what I can tell reading through some of the backlog litany here, there are two issues concerning this bug:

Issue 1: "content-disposition: attachment" was created specifically and only to allow a server to specify "this file should be treated as an 'attachment' and only saved to the disk, not displayed inline"

Is there any other reason why servers would use "content-disposition: attachment" other than to signal that the file is not to be loaded inline? Are we running into a case where the actual State of The Web differs from the Intent of the Spec?

Issue 2: When users click "[ ] Always do this" the UI should listen

bz, you point out in comment 5 that this is probably OK to do as long as the actions don't include "view inline" or "open in app." I understand your objection to "view inline" since that's the entire point of "content-disposition: attachment", but "open in app" is simply saving the user a double click and I don't see any real argument why just because something is meant to be an attachment doesn't mean that if a user takes the action to click on it we can't automate the "open" step after the "download" step.

It sounds to me like what we actually want to do is ensure that "view inline" is never offered for files that are served with "content-disposition: attachment". Is that bug 285976?
bz isn't CCed, but he explained his reasons for why opening with a helper app is not a good idea in bug 236541 comment 40, bug 236541 comment 102, and bug 236541 comment 107.
(In reply to comment #8)
> It sounds to me like what we actually want to do is ensure that "view inline"
> is never offered for files that are served with "content-disposition:
> attachment". Is that bug 285976?

No. That bug is about disabling the "always do this" check box for content-disposition: attachment (because in those cases we're not going to honor it anyways).
(In reply to comment #9)
> bz isn't CCed, but he explained his reasons for why opening with a helper app
> is not a good idea in bug 236541 comment 40, bug 236541 comment 102, and bug
> 236541 comment 107.

bug 236541 comment 40 - this is about helper apps that view the content inline, which isn't the same as "Open in app" which launches an external application

bug 236541 comment 102 - this is about files which are downloaded to a temp directory, used by a helper app which views the content inline, and then deleted

bug 236541 comment 107 - OSX downloads now default to the Downloads directory, and seems to also be related to a common request to have PDFs viewed inline

In all these cases, I'd be fine if the files served with content-disposition: attachment were *not* handled by helper apps (which I see as equivalent to "view in browser") but rather forced to be downloaded and handled by external apps.

Allow me to make my point clear with an example: let's say I've got a page with a link to a PDF or a WMV:

 - if served using content-disposition: attachment, the options that the user would have would be "Save to disk" and "Open with [some app]". In both cases the file would be downloaded using the download manager, if the user selected "Open with [some app]" we'd run the open step as well. "View in Browser" would not be available, nor would we hand the file to a plugin/viewer registered to handle that content.

 - if served any other way, plugins/viewers would be able to download the file to a temp directory, view the content inline and then dispose of it; "View in Browser" would be an option in the handler window

This allows the UI checkbox to be honoured while, I believe, covering the cases and spirit of the RFC.

Comment 12

9 years ago
(In reply to comment #8)
> Is there any other reason why servers would use "content-disposition:
> attachment" other than to signal that the file is not to be loaded inline? Are
> we running into a case where the actual State of The Web differs from the
> Intent of the Spec?

Blogger uses content-disposition: attachment on images ex. http://4.bp.blogspot.com/_7ZYqYi4xigk/SLwuftMrEII/AAAAAAAABtU/eTT5kKVNxBE/s1600-h/collage_and_text.png which is actually a HTML page and if you right click and choose view image it is served as an attachment.
(In reply to comment #12)
> Blogger uses content-disposition: attachment on images ex.
> http://4.bp.blogspot.com/_7ZYqYi4xigk/SLwuftMrEII/AAAAAAAABtU/eTT5kKVNxBE/s1600-h/collage_and_text.png
> which is actually a HTML page and if you right click and choose view image it
> is served as an attachment.
I'm betting that's so people cannot hotlink images to their site from another site.

Comment 14

9 years ago
(In reply to comment #5)
> I can live with remembering the "save" action, no problems.  We just shouldn't
> be remembering the "open in app" or "view in browser" actions in this case.
>
> Note that the behavior websites _really_ want here, typically, is to force 
> save with no user choice (what IE does), and we're just giving the user more
> options.  We've had bug reports about the user having said options, but we 
> sort of stand by that.

Boris, I thank you (or whoever did it) for changing the behavior to disable the dialog when the option to "save to disk" is selected, and allowing users more choices and more freedoms to browse the web how they see fit. I believe the current issue (and it is an issue for many people) should follow the same spirit. No one's asking for an easy UI implementation that would easily bypass RFC 2183 (and thus increase the likelihood that people will accidentally make the change and not realize its consequences). Changing this behavior/setting could deliberately be buried and difficult to implement, but for those who really want to change it they can still do so. 

> This is basically what bug 236541 comment 38 says, and honestly, I'm sort of
> tired of going over this argument again and again and again....

We shouldn't be arguing about this. It's a simple matter of allowing the user to do what THEY want, not what YOU want or what some guidelines specify. It's not a law--no one is going to hunt you down, put a gun to your head, and force you to change it back. You could make this change if you wanted to. There are plenty of informed people out there who would gladly take the risk of inadvertently (or even unknowingly) downloading something harmful to avoid the *daily* hassle of this dialog box. 

Regarding the frequency of this behavior, in my experience files with the content-disposition:attachment header are at least as common as those with other headers that don't (supposedly) pose a security risk per RFC 2183. Actually now that I think about it, what would prevent malicious code from being placed into a file with a header that doesn't require RFC 2183???

The bottom line is that this is about user choice & freedom. Please consider making this change.
(In reply to comment #11)
> bug 236541 comment 40 - this is about helper apps that view the content inline,
> which isn't the same as "Open in app" which launches an external application
> 
> bug 236541 comment 102 - this is about files which are downloaded to a temp
> directory, used by a helper app which views the content inline, and then
> deleted
> 
> bug 236541 comment 107 - OSX downloads now default to the Downloads directory,
> and seems to also be related to a common request to have PDFs viewed inline
> 
> In all these cases, I'd be fine if the files served with content-disposition:
> attachment were *not* handled by helper apps (which I see as equivalent to
> "view in browser") but rather forced to be downloaded and handled by external
> apps.

The "helper apps" bz is referring to in comments 40 and 102 and what you call "external apps" are the same thing. They are distinct from plugins, which show content inline in the browser. Boris is talking about external apps that won't let you save the file while you're viewing it, which, due to the fact that we delete temp files after they've been used, means that there's no way to ensure that users are able to save the file (i.e. treat it like an attachment).

(The fact that we don't delete temp files on Mac, and save them on the Desktop by default, means that he is less concerned about allowing automatically opening the files in helper apps on Mac. This is what comment 107 is about.)

I'm not sure that I buy his argument, because I can't really think of any apps that don't let you save a copy the file once it's opened (e.g. "Save as").

Comment 16

9 years ago
Since there doesn't appear to be consensus on what to do, could you at least provide an about:config option for people who really want to change this ?
Duplicate of this bug: 463816

Comment 18

9 years ago
Summary of the elements of the issue:

1) RFC 2183 specifies content-disposition: attachment trigger a 'Save response as...' user prompt, requiring action by the user.

2) HTTP 1.1 echos this

3) User's desire is to have a save yet seamless low click experience

4) The desire of content providers to have access to differing ways of interacting with the user and user agent.

Three of the four elements support the current implementation.  So how can the UI be improved in a manner that does not detract from the spirit of RFC 2138?  It only requires that the 'Save response as...' dialog box be presented to the user so they can take appropriate action.  This does not require the user agent to have 'Save response as...' as the selected option, nor does it specify the other elements that can/cannot appear on the 'Save response as...' prompt.

This can allow for several UI options:
- Allow the 'remember my choice' to remember the last program that was chosen to be entered as the default helper app with browse next to it.
- Have 'open with' as the default selected option
- Integrate the list of programs into the dialog box and eliminate the 'browse' button.  An example of this would be take the existing list and integrate it on the right hand side of the dialog box, showing only if 'open with' is selected

Comparing the current version to a version with all three of these options implemented:

Current - user wishes to save file
-------
1. Click link
2. Click ok, saves to default location

Current - user wishes to open with program
-------
1. Click link
2. Click 'open with' option
3. Click 'browse'
4. Double click helper app
[possible](5). Click remember choice (thinking it will save this choice for next time)
(5-6). Click ok

Proposed - user wishes to save file
--------
1. Click link
2. Click save file
3. Click ok

Proposed - user wishes to open file with program
--------
1. Click link.
[if previously 'remembered']
2. Click ok.

[if first time for this type]
1. Click link.
2. Click 'open with'.
[optional](3). Click 'remember selection'
(3-4). Double click helper app

Lets say the user chooses to save 1 file and open 2:
- Current method total clicks: 12-16
- Proposed method total clicks: 9 (both when remembering and when not)

The reverse scenario to save 2 files and open 1 (assuming first time):
- Current method total clicks: 9-10
- Proposed method total clicks: 9-10

This I believe clearly shows why many users see this as a UI issue.  Those who use helper apps more often than saving are clicking 3-7 extra times where it is not needed.  This can further be improved by allowing 'Remember my selection' to also save the default selected radio button as well.  This allows users who save more often to select that as the default for that type and save 1 click per download there after while adding that click back to the 'open with' option.  

This proposal conforms to the RFC spec and requires the user to make a selection and improves the user experience across the board.

I'll be at the Changing The World conference on the 15th, I'm eager to hear Mike Beltzner's take on UI
Duplicate of this bug: 469746
Carrying over vlad's blocking flag from bug 469746
Flags: blocking1.9.1?
(In reply to comment #20)
> Carrying over vlad's blocking flag from bug 469746
So, I don't think that this should block 1.9.1 for a number of reasons (in no particular order):
1) We've shipped with this for ever (really, for ever)
2) This would make us violate RFC 2183 (cc'ing bz for this, and bz - sorry;  I know you are tired of discussing this issue)
3) We have no UX spec for this, and as submodule owner, I find it unacceptable to make this just work (for being in violation of RFC 2183).  In reality, that means I find that this should be WONTFIX.

With that said, I think comment 18 has some potentially better user experiences, and we should file a bug for the right user experience.
(In reply to comment #15)
> I'm not sure that I buy his argument, because I can't really think of any apps
> that don't let you save a copy the file once it's opened (e.g. "Save as").

Acrobat Reader, if the right bits are set on the PDF.  It'll let you edit the PDF, and read it, and print it, but not save it.  Yes, it's weird.  Yes, other PDF viewers have similar behavior if those bits are set.  Yes, it's required by the PDF spec last I checked.  Yes, plenty of PDFs out there have those bits set; about half of the job application PDFs Emma is running into as part of her job search seem to.  The expectation is that you fill it out, print it, and send it in, but don't save it, apparently.

It's also possible to create Word documents that behave this way, for what it's worth.  I don't know _why_ people do it, but they do.  Just Google "prevent save as in Word" for all the fun you want.

I've also encountered some image viewers (admittedly, harder to find nowadays) that have no "save as" at all, because they're just viewers, not editors.

Comment 15 is correct in terms of terminology.  If I meant "plug-in", I would say "plug-in".  "Helper app" is what we've used for external apps all along.

(In reply to comment #14)
> Actually now that I think about it, what would prevent malicious code from
> being placed into a file with a header that doesn't require RFC 2183???

Nothing, on your own site which would then get blacklisted as soon as the problem is discovered.  On the other hand, obeying RFC 2183 prevents you from uploading your malicious stuff to some other site that just wants to let people upload things.  At least if said other site is a little careful.

(In reply to comment #18)
We should already be saving the helper app the user selected last.  If we're not, that's a bug (and a regression from the XPFE dialog).  If we're not doing that, please file.  The only other thing proposed in comment 18 is that we remember the last-selected choice but don't execute it.  I would be fine with that, I think, since it gives the user a chance to select the other option if the default one is giving broken behavior.

(In reply to comment #21)
(1) Yes
(2) imo, yes, if we just run a helper app without prompting.  Certainly yes if
    we handle internally in any way, but I don't think anyone's suggesting that.
(3) Agreed on lack of spec.

That all said, if we in fact don't save the user-selected helper app, _that_ should be considered for blocking status, imo.  Even if Firefox has shipped that way "forever".

Comment 23

9 years ago
Created attachment 353350 [details]
Comment 18 Concept Mashup

I made a (very) quick mockup of my proposal.  Basically if open with is selected the options are available right away with "browse" for additional options.  It has a "Select this option next time" instead of "do this" so the user knows it will not be automatically done.  If "Save as" is selected it should disable but still show the right hand portion of the box.
(In reply to comment #22)
> That all said, if we in fact don't save the user-selected helper app, _that_
> should be considered for blocking status, imo.  Even if Firefox has shipped
> that way "forever".

Yep, that's the core of the issue I think -- the same dialog shows up as with non-attachment downloads, except that the "Open With: [...]" bit is always blank, even if there is a helper app defined for that document type.  Also, the "Always do this" checkbox is misleading in this case.  I think it would be perfectly acceptable if this dialog always popped up for attachment downloads, but without the checkbox, and with the helper app pre-filled if defined.

Comment 25

9 years ago
(In reply to comment #22)

> (In reply to comment #14)
> > Actually now that I think about it, what would prevent malicious code from
> > being placed into a file with a header that doesn't require RFC 2183???
> 
> Nothing, on your own site which would then get blacklisted as soon as the
> problem is discovered.  On the other hand, obeying RFC 2183 prevents you from
> uploading your malicious stuff to some other site that just wants to let people
> upload things.  At least if said other site is a little careful.

Well, then that's the point: Malicious files will be blacklisted as soon as they are discovered, so that should have no bearing on how the user wants to interact with their content. Without question, safeguards can and should be put in place, but they should not prevent a user from deliberately choosing to ignore them. There are innumerable ways in which a user could deliberately expose themselves to harm that are not barred by Firefox or any internet rules. So why is this case any different? I believe it is because the developers are misinterpreting the MIME standards.

I believe most (if not all) of this behavior occurs with application/octet-stream MIME types. According to RFC 2046 (addressing security issues in MIME types), under section 4.5.1 for application/octet-stream entities:

   "The recommended action for an implementation that receives an
   'application/octet-stream' entity is to simply offer to put the data
   in a file, with any Content-Transfer-Encoding undone, or perhaps to
   use it as input to a user-specified process.

   To reduce the danger of transmitting rogue programs, it is strongly
   recommended that implementations NOT implement a path-search
   mechanism whereby an arbitrary program named in the Content-Type
   parameter (e.g., an 'interpreter=' parameter) is found and executed
   using the message body as input."

A plain reading of this text reveals that it is RECOMMENDED to avoid automatically executing on undefined (/octet-stream) MIME types; it is not a strict rule to prevent such action by the user. 

According to RFC 2183, the purpose of the MIME framework is to provide "for the interchange of message content, but leaves presentation issues solely in the hands of mail user agent (MUA) implementors". This text suggests it is up to Mozilla to define how to handle presentation issues, and thus it is within the purview of developers to determine how Firefox handles these MIME types. I agree that the default behavior should be for increased security, but the MUA (program=Firefox) should not prevent the user from selecting another less secure behavior should they so desire. 

RFC 2183 does not explicitly state the MUA must disallow any potential non-secure behavior:

   "There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard."

The key text here is "A RECEIVING MUA MUST TAKE CARE THAT THE SENDER'S SUGGESTED FILENAME DOES NOT REPRESENT A HAZARD". Thus, it is up to the MUA (and by extension the user) to determine what is and is not a hazard. It does not require the implementor to prevent the MUA from choosing a potentially hazardous behavior. 

Finally, I believe most of the issue hinges on the following text from RFC 2183 section 2.2:

   "Bodyparts can be designated 'attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user.  The MUA might instead present the user of a
   bitmap terminal with an iconic representation of the attachments, or,
   on character terminals, with a list of attachments from which the
   user could select for viewing or storage."

A close reading of this text reveals that it does not specify this behavior must be followed each time the user receives an 'attachment' MIME type. Instead, the operative words are "should" and "might". It does not REQUIRE any particular behavior, rather it SUGGESTS what should be done. 

Therefore, since neither RFC 2046 nor RFC 2183 require the MUA or MUA implemetor to restrict any particular behaviors with respect to application/octet-stream MIME types, the desired change for this bug is not barred under those standards. 

Furthermore, it is not apparent to me who enforces these standards and what the potential liability would be for non-compliance. 

As such, I implore the developers to provide a workaround to this UI issue.
> I think it would be perfectly acceptable if this dialog always popped up for
> attachment downloads, but without the checkbox, and with the helper app
> pre-filled if defined.

That's the behavior it had in Seamonkey (then Mozilla suite) after the last time I touched it.  If someone broke things since, we should fix them, of course.  It might be good to have a new clean bug with just this, not the various other changes people want to make here, as the goal, and just fix it in the Firefox unknown content dialog.

I think I'm done here, since this bug is getting really spammy, just like every single other bug I've seen on this issue.
(In reply to comment #26)
> That's the behavior it had in Seamonkey (then Mozilla suite) after the last
> time I touched it.  If someone broke things since, we should fix them, of
> course.  It might be good to have a new clean bug with just this, not the
> various other changes people want to make here, as the goal, and just fix it in
> the Firefox unknown content dialog.
I agree, and I've filed bug 470332 to get that done.  As it stands, this bug is WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX

Comment 28

9 years ago
(In reply to comment #26)
> I think I'm done here, since this bug is getting really spammy, just like every
> single other bug I've seen on this issue.

Spammy? I think the number of posts (and duplicates of this bug) speak to how many people want to see this FIXED (and their frustration at the developer's stonewalling). This issue isn't going to go away just because you don't want to deal with it. 

Answer me this: how much effort would it require to implement the desired change? If it's really a cost-benefit (dev time/effort vs. the number of people who want it fixed) analysis, then say so. I can accept that. I just find it hard to believe the developers really want to adhere to standards (at least their interpretation of them) as the reason this UI behavior can't be changed. 

If you can't answer my comment #25 with a cogent argument against it, then tell us all what the real reason is for not addressing this concern?
No one is "stonewalling" - Shawn's filed bug bug 470332 on remembering the choice of helper apps, bug 285976 exists to cover not offering to remember when we won't save the choice, and I've just filed bug 470514 to cover making it possible to remember "Save as" as a choice, per comment 5. I think those bugs together address most concerns adequately.
Flags: blocking1.9.1?

Updated

9 years ago
Duplicate of this bug: 478893

Comment 31

9 years ago
I'm just a user, so excuse the stupidity, but could someone please tel me why I have to click twice to view a photo?  Firefox clearly recognizes that it is a picture, but is ignoring my request to just open the GD thing.  Is it a security issue?  If yes, why won't you let me be the judge of my own security?  Alternately, why have the box to check?  This is not a new annoyance, I've just been too lazy to do anything about it before.  But I've just had to open a couple of dozen pictures from my Yahoo email by clicking TWICE AS MUCH as I should have to, and it has officially gotten to be a pain in my butt.

Comment 32

9 years ago
I am in the same boat as comment #31. Very frustrating. Does the status "wontfix" mean that this will never be fixed and if so can anyone give a reason a layman can understand ?
Layman explanation:

* You don't need to click on anything to get something sent with content-disposition: attachment.
* Automatically opening arbitrary content enables drive-by attacks (go to page, page sends content containing an exploit, app gets launched to open content, user gets owned).
* This behaviour is effectively "let any page on the Internet pass arbitrary content to this application"
* Explaining why the oh-so-convenient option is actually compromising your system security is rather ineffective (see the various research on the incredibly poor effectiveness of warning dialogs).

Comment 34

9 years ago
Mike Connor's explanation doesn't make sense in the context of this bug report.  A web page could do all that stuff by just not sending the "content-disposition: attachment" header.

Comment 35

9 years ago
Without kicking a dead can, the point is to prompt the user as to what they want to do with the file and prevent people from just "assuming" it's safe because the browser launched it right away.  It also allows flexibility for developers as to how they want their files to be interpreted client side as well as keeping with the standard.  If any discussion should take place on the issue it should be in context of updating the standard to be more specific.

The only thing I see that could be improved to make all sides happy is what was proposed above (see my comment #18 and related attachment).  This is the only way I can see currently to adhere to the standard, prompt the user, but still allow for fewer overall clicks for the user.  Allows for security, standards, and is user friendly.

Comment 36

9 years ago
Setting aside for a second the issue of why it can't or won't be done, I haven't seen any explanation for why the option even exists for selecting "do this every time".  Why can't the option be grayed out or not included?

Comment 37

9 years ago
I tried this in IE and note there is no 'remember my choice' box . 

So at least as a dumb user I am not frustrated by thinking 'remember my choice' actually does something.

 I agree with Comment #25 - 
"Well, then that's the point: Malicious files will be blacklisted as soon as
they are discovered, so that should have no bearing on how the user wants to
interact with their content. Without question, safeguards can and should be put
in place, but they should not prevent a user from deliberately choosing to
ignore them."

I think the point of  users who want to see the JPG immediately are people are like me who want to see the image without junking up their hard drive. Seeing as how I am taking the responibilty by checking the  'remember my choice' box, I don't see why "Big Brother" wont just leave me to my fate.

I am resigned to not having it work as I want it to but could you please remove the 'remember my choice' box ? Its like waving a red flag at the bull.

Comment 38

9 years ago
Doesn't the function in question detect the file extension _and_ give the user
the option of method to open said file?  

#1) If I choose to always open file type "*.virus" with program "Destroy My
Entire Network", that's entirely MY BAD.  

#2) if I decide to always open file type "*.jpg" with program "Picasa" how in
the heck could this do bad things to my computer again????

Comment 39

9 years ago
(In reply to comment #29)
> No one is "stonewalling" - Shawn's filed bug bug 470332 on remembering the
> choice of helper apps, bug 285976 exists to cover not offering to remember when
> we won't save the choice, and I've just filed bug 470514 to cover making it
> possible to remember "Save as" as a choice, per comment 5. I think those bugs
> together address most concerns adequately.

I have not seen any argument against my analysis of the RFC standards in comment #25. This is stonewalling. Everyone who must deal with this asinine behavior will eventually switch browsers. I have.

Comment 40

9 years ago
Firefox's current behavior forces sites to choose between security and usability.  On the Web, content-disposition:attachment means the file should not be considered same-origin with the site.  Firefox punishes sites that use the header by not letting users view the files as easily as they can on other sites, ultimately hurting security.

I'm reopening this because it was resolved as WONTFIX based on a misunderstanding of the security concerns and an overzealous reading of an irrelevant spec.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Updated

9 years ago
Whiteboard: [p-chrome] → [p-chrome] [sg:want]

Comment 41

9 years ago
Thank you for doing us this favor.  Please also look into https://bugzilla.mozilla.org/show_bug.cgi?id=160144 as it has been 7 years since the bug report has been opened. I believe that that bug has been ignored because of an overzealous misunderstanding of the security concerns

Comment 42

9 years ago
I'm a bit confused...

I'm trying to set up Firefox so that it will always open .nzb files with my newsgroup reader. No matter how many times I tell Firefox to "do this automatically", it always prompts me. The alternative to clicking this every single time seems to be to tell it to always "save as", and then double click the downloaded file. Either way, I have to click twice for each nzb (once to initiate the download, and then once to "activate" it). Is this the same issue that's being discussed in this bug report, and, if so, why are developers so hesitant to allow users to determine how they want their browser to handle file downloads?

Comment 43

9 years ago
A prime developer concern should be to GIVE users what they want. Firefox is NOT a security application. Even a security application like a HIP or firewall application give the option to 'remeber my action', so why can't firefox. It seems to me a developer has said I won't do it so it can't be done.

Comment 44

9 years ago
I don't know if maybe this is beating a dead horse, but since this still hasn't been fixed after several years i guess i feel obligated to add my opinion:

1. I agree that the current reading of RFC 2138 is overzealous. Firstly, i think there is a very good case to be made for that spec being completely irrelevant to Web browsers (as opposed to actual mail clients). But secondly, and more importantly, i don't think that the behaviour proposed by the others here conflicts with even a strict reading of the recommendation. The purpose of the 'attachment' content-disposition is to prevent the client from opening the file in-line — allowing the user to always open it in an external application is PERFECTLY in synch with that recommendation. An external application is not in-line, even if the file is passed to it automatically, so there is no conflict at all.

2. I think the concerns of the opponents of changing the current behaviour regarding the desires of server hosts are completely valid, but i also think that the desires of the users (and anecdotally i would say it's a LOT of users) trump those concerns. The devs didn't put the wishes of server hosts ahead of those of the users when they implemented pop-up-blocking or the ability to install arbitrary extensions or anything else; what makes this specific scenario so sacred?

3. I think the concerns regarding security and RFC compliance are also valid, which is why the proposed behaviour should be very much an 'advanced' kind of thing — for example, something that would have to be enabled in about:config. Maybe even in a key that has to be explicitly added by the user first, just to add even one more layer of protection. Leaving RFC 2138's recommendation as the default behaviour — but allowing the user to change it with some effort — should please everyone, i'd think.

4. I might go even further than some of the other proponents of changing the behaviour here — i think that, in addition to being able to automatically open in an external application, there should also be the ability to automatically open it in-line, if it's set that way specifically.

For example, someone earlier mentioned how Blogspot (and they're not the only ones) use content-disposition to force normal images like JPEGs to always save to disk. This usage is not security- or usability-related or anything else, it's purely a tactical decision on the part of the host to prevent hot-linking. Some might even call it abuse. This shouldn't become my problem, any more than pop-up ads should — i just want to view the image in my browser like every other image! I should not have to open an external application, or an extra Firefox window even, to do that, if i really don't want to.

5. In summary, i think the following changes should be made to the current behaviour:

(a) The current behaviour should remain as the default, but the UI should be changed to notify users that the action can not be taken automatically when appropriate (this is a separate bug).

(b) An option should be added to enable the ability to automatically perform the selected action for 'attachment' downloads. This option should be sufficiently obscure to protect un-informed users from enabling it without knowing what they're getting into.

(c) Once enabled, option (b) should allow the user to automatically perform actions for individual file types exactly as they can with non-'attachment' downloads — that means saving to disk automatically if desired, or opening in an external program automatically if desired.

(d) An option should be added to enable the ability to view supported file types in-line for 'attachment' downloads. This should probably be a separate option from (b), because the ability to automatically open in an external application is less removed from the spirit of RFC 2318 (or not removed at all, really) than the ability to view it in-line is, and having one action perform both would thus be irresponsible.

(e) Once enabled, option (d) should allow the user to automatically view attachments in-line as specified by the browser's normal download settings (e.g., under Preferences > Applications). This should not pose any threat to usability or security, because these file types would be only the common ones that the browser is designed to open anyway (like JPEGs and PNGs).

An alternative to the above would be to just add 'hooks' so that this behaviour can be altered by extensions, which would allow for more complex download managers to deal with the specifics.

Updated

9 years ago
Duplicate of this bug: 501555

Updated

9 years ago
Duplicate of this bug: 503708
> On the Web, content-disposition:attachment means the file should
> not be considered same-origin with the site.

Unfortunately, that's not all it's used for.  Some sites use it this way (for HTML and such).  Other sites use it to mean "don't view inline" or "let user save" (for images and the like).

Updated

9 years ago
Duplicate of this bug: 347843

Comment 49

9 years ago
Now SeaMonkey is only affected (so far only in 2.0b). So we can expect many
more duplicates (as we had for bug 236541 which is fixed, actually not fixing
what all those dupes were reported for). In the end it is just a horrible user
experience. People choose to do some action and without any warning or hint it
does not happen.

I came to search this because of my bank account. There I encounter the issue.
Certainly there are few sites I would trust more with respect to security!

My logic goes as follows: The user want to handle certain files types by
opening with a named application. He trusts that he has done everything
reasonable (like setting up relevant virus protection etc.). He can launch the
file (after pressing the button or after saving). He wants it and will do it.
The dialog doesn't stop him and hence does not increase security.

Yes, this is not a new argument, but this is what the users experience. They
don't see MIME headers (the dialog box does not display that, but suggests it
will remember a decision made by the user).

pi

Comment 50

8 years ago
It seems kind of arbitrary that the "do this automatically" checkbox is grayed out for "content-disposition: attachment" given that, even if the checkbox is disabled, you can still force files of a particular MIME type to always save if you use the Tool -> Options -> Applications UI, if an entry for that MIME type exists in mimeTypes.rdf. The UI is unable to automatically add/remove MIME type records, so you have to manually edit mimeTypes.rdf. For example, to always save files of type application/octet-stream, insert

<RDF:li RDF:resource="urn:mimetype:application/octet-stream"/>

as an entry between <RDF:Seq RDF:about="urn:mimetypes:root"> and </RDF:Seq>, and add the following just before </RDF:RDF> (last line of file):

<RDF:Description RDF:about="urn:mimetype:application/octet-stream"
                 NC:description="application/octet-stream"
                 NC:value="application/octet-stream"
                 NC:editable="true">
  <NC:handlerProp RDF:resource="urn:mimetype:handler:application/octet-stream"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/octet-stream"
                 NC:alwaysAsk="false"
                 NC:saveToDisk="true"
                 NC:useSystemDefault="false"
                 NC:handleInternal="false">
</RDF:Description>

After making those edits, you can choose to always save the "application/octet-stream" type from Tool -> Options -> Applications, and Firefox should honor the setting, even in cases where the "do this automatically" checkbox would have been disabled because the file was served as an attachment.

If you are being served a different MIME type (e.g., application/x-rar-compressed), do a search-replace on "application/octet-stream".

Live HTTP Headers is useful for finding out the MIME type of the file you are being served:
https://addons.mozilla.org/en-US/firefox/addon/3829

More info on editing mimeTypes.rdf:
http://kb.mozillazine.org/MimeTypes.rdf

Comment 51

8 years ago
But that doesn't work for those of us who want to _open_ every time, I assume?

Since I'm here, I might as well mention an idea I'd had for a workaround: namely, creating an extension that just looks for the content-disposition: attachment header and always removes it. Given that there are a number of extensions to view HTTP headers and others to modify GET/POST data, I would imagine the APIs exist for modifying the headers themselves?

It's on my "to do in my very rare spare time" list, but maybe someone else subscribed to this bug knows enough about the extension APIs to make this a one-hour project? (My problem is that I'd have to learn how to write an extension, which seems like it might take a day or two... even if it would be a good skill to have.)

Comment 52

8 years ago
> But that doesn't work for those of us who want to _open_ every time, I assume?

No, I don't think it does, but I'm not 100% sure - I haven't thoroughly tested that side of it.

When browsing with Firefox I have found that pages seem to have the ability to launch files without user interaction. Upon opening a malicious page you can get the "You are opening..." dialog asking what to do with, for example, an .exe or .pdf file, without ever having clicked on a link to an .exe or .pdf file. I used to have Firefox set up to automatically open PDF files using the Adobe plug-in, but I changed it to "Always ask" after I had to quickly kill a "~.exe" process that was launched by a vulnerability-exploiting PDF that had apparently been opened in the background, without user interaction, by one of my tabbed Google search results. Now I occasionally get the "Always ask" dialog popping up and asking me what to do with a .pdf file, when I never clicked on a link to a .pdf file in the first place (but at least I can click "Cancel" now).

The point I'm getting to is that for "Always _open_ every time" there probably needs to be a quick OK/Cancel confirmation of some kind when files are launched without user interaction.

Comment 53

8 years ago
Hello,

I also have been struggling with this issue, but I have managed to solve it for my own purposes.

I'm using Privoxy [a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk]. It's open source software, which im currently using as universal ad blocker.

It can modify http headers, and because my main annoyances are .nzb files i just added the following to configuration file:

{ \
+hide-content-disposition{block} \
}
/.*\.(nzb)

And now Firefox opens these files with the program i've configured. This is of course not the solution for everybody, since it requires installing another software for the background.

I definately would like to see some sort of solution from Mozilla.

Mikko
Duplicate of this bug: 525910

Comment 55

8 years ago
(I post here instead of risking a new duplicate)

I click a link on a web page, and the dialog appears:
 - telling the file is a PDF document
 - with the selected (radio) option to open it with Foxit Reader
 - unselected radio option "Save File"
 - checkbox "Do this atumatically..." It is checked, as I checked it 1 minute before.

The checkbox is obviously not honored.

It should either be honored or not offered at all.

(FF 3.5.5 on WinXP)

Comment 56

8 years ago
From reading the comments of this and related bugs, it seems to me that the only real security concern here is drive-by attacks where the user has not clicked the link. If this is what is causing developers to resist remembering the user's choice of app and automatically opening without additional interaction then I see the point. This would not be safe, and although my initial thoughts were all centred around "remember my choice when i damn well tell you to", I don't think I should be able to do this as it stands, even in about:config. PDFs provide a good example of a format that often has serious security holes, and the risk of being hit with automatically opened PDFs without clicking deters me from wanting this change. Do I understand the position correctly?

HOWEVER, I am also incredibly irritated by this lack of functionality on an hourly basis and have been for years. There has, despite legitimate concerns, been some stonewalling and stubbornness. I think this bug should focus on technical solutions to what is a clear usability issue. The usability issues exists, regardless of other concerns. Let's fix it. How can we allow users to remember their choice of app for links that they DO click on? There are elements of things like pop-up blocking that seem to have knowledge of whether or not a user made a click. Is this information available in the download code path? Could it reliably be made available? How reliable? The massive majority of cases involve clicking a link, and requiring unnecessary extra clicks when it should be seamless. This needs addressing. I have only *ever* once been targeted by a download I didn't click on. Enabling these attacks is not a good thing, but working around them is essential.

At the very least, for immediate clarity if a real solution requires significant work: the dialogue should be re-worded or better the functionality changed. I believe there is another bug for this already? The remember check-box should be unchecked and disabled if the radio button for open is selected. Even better, check-box and text should be replaced to signify why the choice cannot be remembered. None of these things would constitute this bug being fixed.

I find it hard to see how ex

Updated

8 years ago
Duplicate of this bug: 538222

Comment 58

8 years ago
A suggested solution:
Similar to one of the popup-blocker's code, we could detect if this is an intentional action to download, by looking for explicit click/enter button actions.

If the user did click on it, then we know it is intentional, and if they have requested to bypass the dialog, then bypass the dialog.
Duplicate of this bug: 550503

Comment 60

8 years ago
i have been struggling with this issue for many years. I have had it with mp3, torrents, nzb files and many of others.

To the developers: If you don't feel like fixing this obvious usability flaw and rather do something else, just say so. Don't hide behind any outdated half relevant specifications. Because now there is absolutely no excuse for not thinking in terms of AND/AND. There is more than one way to protect the innocent from drive-by execution of malicious content AND allow automatic execution of daily or rather hourly of not more often task. Take pride in what you are doing and rather think in terms of solutions. It's quite possible you were not in creative mood when you were presented with this problem the first time and felt like you had to keep defending your decision all this years. Wake up and be a hero :) We will thank you for this!

Comment 61

8 years ago
If the reporter marks this as "blocks bug 565512" I feel it might have a marginally better chance of being taken care of.

I am definitely not in control when I tell the browser to "do X" and it blatantly refuses to, with no explanation whatsoever.

Updated

8 years ago
Blocks: 565512

Comment 62

8 years ago
Ok, here is what I would expect Firefox to do, from a user perspective:

1) If the server sends me something explicitly marked as download using the attachment header (or as possible drive-by-execution), I would expect the 'Save As' Option to be the default. 
Else it is quite easy to 'just click OK' in the dialog, and your downloaded file is a) somewhere lost in a temp-directory and b) gets executed anyway.
The argument that every 'Open-With' App has a 'Save As' option anyway is not valid, since media-players usually do not provide such an option (at least the ones I use, like VideoLAN player). 

(However it would be helpful to have a 'Save As' option in the Download-manager for downloads to a temporary location, although since temp-files should be deleted after they are used, having a 'Save As' option in the download-manager should therefore count as usage and prevent deletion of the temp-file until the entry is removed from the downloaded-files-list).

2) If I have an 'Open With' option, which I guess selects the application based on the file-extension (since it is available even if 'Always perform this..' is greyed out), the default action (Open with/Save as/..) should be set in the same way the 'Open With' action works, i.e. based on the file extension if the mime-type is not available/incorrect/octet-stream (setting a single default 'Open-with' or 'Save as' action for all 'octet-stream' mime-types is of course not a good idea :) ). 

From a user perspective, I am really not that interested in mime-types and server-configurations. If I get an 'Open With' option, based somehow on something the server sends (mime-type or filename), then the 'Always perform this..' option should work in exactly the same way. This should provide a much more consistent UI-feeling. If the option gets disabled for security or missing-information reasons, the UI should tell me so, not just disable the options.

3) I do not quite see how much good disabling the option does security-wise anyway, since it should be quite possible to just send a malicious PDF using a correct mime-type, which would then be opened automatically again.

4) Another helpful UI improvement (for me..) would be if 'Open','Save', .. would be buttons instead of a selectbox-list with an OK button (e.g. similar to Opera). For people (like me) who do not like the default selection (whatever it is), this saves one click and is much more 'robust' (if the buttons are always at the same position) because you do not need to hit a small radio-box (and to remember to do so!) but just a big button which always does the same thing.


However, I noticed that in the Options-dialog, some Content-Types are already based on extensions instead/in addition to 'application/whatever'. Setting the action to 'Save As' seems to work for me, but if set to 'Always ask', the 'Always perform this action' option is still disabled (which I would simply call a UI bug).

Updated

8 years ago
Keywords: ux-control

Updated

8 years ago
Duplicate of this bug: 581134

Comment 64

7 years ago
I'm not writing this as an opinion piece -- that would not belong here -- so let me state my problem as exactly as I can. 

Currently checking the box is a no-op under some well defined, common, and reproducible circumstances. 

Many users are surprised and annoyed by this behavior. IMNSHO the initial description of bug 331259 captured this quite well, but in search of an implementation, the bug drifted way off base. The bug this comment is attached to is apparently where the action has moved to, so this is why I'm writing it here.

----

Indicating an affordance with the UI, and then ignoring the action the user is lead to take -- without a reasonable explanation -- is a grave error in user design.

But, in trying to fix this with bug 331259, the focus shifted to a more technical interpretation and into RFC land. (I'm not trying to be disrespectful here. I have myself committed extensive specification nitpickery in various contexts for almost as good reasons as stated in bug 331259. Anybody who groks RFC 2183 has nothing by my respect and thanks.)

Unfortunately, the difference between the nitpicking of the RFC divinations and the more fundamental problem of user confusion is hard to see when you are a mere mortal. 

Us mortals just experience a consistent FAIL when we try something again, and again, and again. And when the browser just keeps encouraging us to try it one more time, while still ignoring our actions, we get frustrated. 

I'm not saying that the RFC interpretations are not correct, nor do I say that the RFC isn't saying this for some very very good reasons (such as "failure to follow RFC xxx causes p0wnage"), nor do I say that the people who are fighting to have the RFC's obscure dicta strictly followed are not doing the right thing, nor do I say the the fix must be that we bypass/ignore/re-interpret some aspect of some RFCs.

What I am saying is that if it doesn't fix the problem as it is seen by the user, then it isn't the fix for what the user is complaining about.

The original bug reported that a user's action was ignored and the user was left confused. The user is still left confused after bug 331259 has been "fixed", verified, and closed.

_That_ is the problem.

My hope is that this time somebody will look at the deeper problem of eliminating the user confusion before closing the bug.

I'll be happy even if it involves something as crude as a dialog explaining the problems and risks and explicitly asking "is _really_ what you want?" (and I _do_ hope there is a better way), or as sophisticated as reformulating the question such that the issue doesn't arise in the first place. 

Just don't claim the bug ("confused user when xxx") is fixed when seen from a particular narrow technical viewpoint, _however correct that viewpoint is_.

BTW, the most dangerous outcome here is not that some obscure RFC clause gets ignored or misinterpreted, but that it so much easier (and way way faster) to write an add-on that completely ignores the whole shebang and opens a big security hole as it just makes a complete bypass of it all.

I don't think anybody here wants such an add-on -- or even worse -- have it become popular.

Comment 65

7 years ago
Is this bug still open? I'm using 3.6.11 and it's extremely frustrating. I've started to use Chrome since it's much easier with opening files automatically.

Does anyone know of any Add-on that might assist with this issue. Thanks.

If this problem isn't fixed by the release of Firefox 4. I'm definitely moving on to Chrome.

Comment 66

7 years ago
There is add-on solving this problem for .torrent files made by Russian developers but it also creates new problem - inability to work with downloaded .torrent files in any other way.
http://forum.mozilla-russia.org/viewtopic.php?id=39820

Comment 67

7 years ago
Thanks. However, this doesn't deal with the underlying issue. I think I'm just going to move to chrome. Much more development going on, unlike Firefox which has a major bug for several years already, and hasn't been fixed.

Thanks for the advice though.

Comment 68

7 years ago
FlashGot seems to work with most files -- http://flashgot.net/

Comment 69

7 years ago
Back in the real world of people using their computers to download files, I get asked ALL the time why they have to click so many times to do something that appears to be so simple, and yet it's not.

These are the people who've embraced Firefox after deserting IE (on my advice) and now they get hit with this inane constant prompting.

Please either implement some kind of config setting (modified in about:config) if at all possible. I simply don't have the time to discuss the merits of various RFCs. I want my PC to be useful and assist me, not hassle me all the time. If I was to inform any of the people I deal with about dear Boris and his RFC ramblings, then I would be met with a blank look/confusion.

Multiply my frustration by a factor of all the other pro-posters here and I think you'll perhaps understand.

Comment 70

7 years ago
(In reply to comment #69)

Seconded

Comment 71

7 years ago
By the looks of it, Boris has left the building long time ago and is not following the discussion, just like any other mozilla developers (if there were any inthe first place). The only emails are on the CC list are probably of those who would like this issue to be solved. It also seems that there is no opposition to the changes proposed - the problem is that there is nobody ABLE AND WILLING to implement these changes. And as long as this issue is lost within this huge mozilla bugzilla swamp nothing will happen. Nobody and i mean ALMOST NOBODY knows about this little dungeon of despair. Mozilla bugzilla is very helpful to developers and sometimes users in many aspects but it is far from perfect and in this case IT DOES NOT WORK. 

A call to arms :)

I suggest setting up a webpage/blog outside of confines of this environment and use it raise the awareness of this issue. And i mean a real viral action. Something that can be actually be heard by those who CAN and motivate them to DO. I believe that we can encourage someone to do something about it especially if there is a publicly visible reward in the end to the hero programmer that had actually done it. and i am not talking about money - although that could be part of the campaign. but gratitude of all the thousands that we can make to sigh up a petition of a kind or something like that could mean a lot too.

I have difficulty expressing all the possible ways to market this project but i believe it can be a lot of FUN!!! 

I am talking about posting pictures of how this can be done, making Camtasia video's of current situations and how it should work and posting them on youtube. I am talking about creating a facebook page and placing those vids there and on the blog page. Getting people to "Like it" that facebook page and have this discussion in the open. We could have some fun playing with SEO and try and get this issue high in google and youtube ranking so that anyone typing "firefox problem" in google will see this issue and words like "stupidest firefox usability flaw" associated with it. We can make a lot of constructive  fun of Mozzila in any way imaginable :)

I am very busy with starting my own business and all the research i have done on marketing my upcoming business served as inspiration to write all of the stuff above. I would love to organize this thing but i will have my hands and head full coming months... Yet i will definitely actively participate and collaborate with anyone willing to do it together.  

I have created a blog http://dothisautomatically.wordpress.com/ but www.dothisautomatically.com is available so if any of you want go for it ...

If any of you would like to have some fun instead of waiting for some lost developer to blunder unto this unglorifying bug let me know
I don't think it will be lost. I continue to advocate for this issue. Set up your viral site and have fun, if you must, but feels like a waste of time and a presumption of intent based on facts not in evidence.

We should do this. Simple as that. We shouldn't base our browser's behaviour on an RFC intended for a mail client.

Comment 73

7 years ago
(In reply to comment #72)

> I don't think it will be lost. 
Hi Mike, i am not sure what you mean by this.

> I continue to advocate for this issue. 
I do continue to advocate for this issue as well. Unfortunately just advocating does not seem like getting us anywhere. This bug report was created 2 years ago and there is no one who came forward and said "I'll do it!" 

> Set up your viral site and have fun, if you must, 
I just have: http://www.dothisautomatically.com

> but feels like a waste of time 
it's quite possible that it will be a waste of time. On the other hand it might not... and it sure beats all the animo that comes from mozilla team. I give no guarantees that i will pull this through... BUT I'll try and hopefully get some some collaborators

>and a presumption of intent based on facts not in evidence.
You lost me here - which intent did i mistakenly presume?

> We should do this. Simple as that. We shouldn't base our browser's 
> behaviour on an RFC intended for a mail client.
From your mouth to mozilla gods ear :) Could not agree with you more!!! But who are those "We" you are talking about?

Comment 74

7 years ago
This drives me up the wall :(
Love Firefox, hate clicking.
(In reply to comment #73)
> > We should do this. Simple as that. We shouldn't base our browser's 
> > behaviour on an RFC intended for a mail client.
> From your mouth to mozilla gods ear :) Could not agree with you more!!! But who
> are those "We" you are talking about?
"Mike Beltzner is the Mise en Scène for Firefox: a product manager and director of sorts, setting direction and guidance for the delivery of Firefox to its millions of users worldwide." from https://wiki.mozilla.org/User:Beltzner
I'd say he's talking to/about all the Firefox devs :)

Comment 76

7 years ago
This drives me crazy too.  so much clicking, so little reward.  Please fix, patch or give us the option to hard code actions to filename extensions.

Updated

7 years ago
Duplicate of this bug: 622424

Comment 78

7 years ago
There is a blog page that was meant to boost some awareness of this ridiculous bug and hopefully find someone willing and able to fix it. Not much has come of it yet, but a clever guy from Russia made a Firefox add-on that provides this much needed functionality:
http://www.dothisautomatically.com/?p=1#comments
I still hope that someone within Mozilla wake up and do what should be done long ago.

Comment 79

7 years ago
(In reply to comment #78)
> There is a blog page that was meant to boost some awareness of this ridiculous
> bug and hopefully find someone willing and able to fix it. Not much has come of
> it yet, but a clever guy from Russia made a Firefox add-on that provides this
> much needed functionality:
> http://www.dothisautomatically.com/?p=1#comments
> I still hope that someone within Mozilla wake up and do what should be done
> long ago.

A nice find, thanks.
A proper fix is long overdue though!

Comment 80

7 years ago
Very cool, I'll have to try it out.

Everyday, I click the sad smiley in FF4 Beta and leave a comment regarding the fact that even in the beta for the next version this STILL isn't fixed.  I encourage everyone here to do the same. =)

Comment 81

7 years ago
Also consider voting for this bug (at the top of this web page).


(In reply to comment #78)
> it yet, but a clever guy from Russia made a Firefox add-on that provides this
> much needed functionality:
With a workaround in an add-on, the probability of a fix is even lower now. :-(

Comment 82

7 years ago
About the drive-by attack argument:
To circumvent this "protection", the attacker must just not use the "content-disposition: attachment" header? Is that correct?

Comment 83

7 years ago
Give up. This bug has been in every version of Firefox since the beginning. It's still in the latest 4x builds too. No one cares. No one is even making an attempt to fix it. It was reported years ago, and still no one cares. It isn't going to be changed.

Comment 84

7 years ago
Firefox is dead. Just use Chrome. It's better in every single aspect. Much more development and dedication to user experience.

I must say that I started using Chrome due to this specific reason. I needed it for work, and every time it would ask me which program to use instead of doing it automatically. This single reason alone, drove me to use Chrome. I haven't looked back since.

Hope this helps anyone looking for a fix.

Comment 85

7 years ago
Firefox is dead. Just use Chrome. It's better in every single aspect. Much more development and dedication to user experience.

I must say that I started using Chrome due to this specific reason. I needed it for work, and every time it would ask me which program to use instead of doing it automatically. This single reason alone, drove me to use Chrome. I haven't looked back since.

Hope this helps anyone looking for a fix.

Comment 86

7 years ago
(In reply to comment #82)
> To circumvent this "protection", the attacker must just not use the
> "content-disposition: attachment" header? Is that correct?
I think we've been through this: Firefox can and should differentiate between downloads triggered by user clicking on a link and "automated" downloads.

(In reply to comment #83)
> Give up. This bug has been in every version of Firefox since the beginning.
> It's still in the latest 4x builds too. No one cares. No one is even making an
> attempt to fix it. It was reported years ago, and still no one cares. It isn't
> going to be changed.
Because until short ago it was reported in bugzilla.mozilla only and out of millions of people who knownly or unknowingly suffer from this nonsense only a few dozens found their way into this dungeon. This is a place to help developers to funnel bugs, that's it! There is little you can do here if there is indifference or outright unwillingness to fix something. 

This mailing list is a medium from a year 2000. Things like blogs and social media have arisen since than. I believe this entire thread would have more impact if it took place on the blog page i've mentioned (or a dedicated Fzcebook Community page). If all 64 current thread followers (min a couple of Mizzila devs) were to click on "Like it", at least a couple of thousands of friends would see it, with a few chain reactions. Every time one of you posted a message, again another couple of thousands. Even reactions like "Just use Chrome" would be seen by a couple of thousands every time, instead of 60 FF addicts. That might make FF people take this more seriously. A Facebook App could be made "Tired of this weird Firefox behavior? Click here to send a complaint to Firefox team!".

Of course another idea is to tell Google team to advertise their browser on Torrent sites and tell everyone why in this particular case Chrome is better.

Comment 87

7 years ago
(In reply to comment #72)
> We should do this. Simple as that. We shouldn't base our browser's behaviour on
> an RFC intended for a mail client.

Mike, obviously you are on our side on this issue. And as you said, you would advocate fixing this within FF dev team. Have you tried? What were the results? Could you, as "the Mise en Scène for Firefox: a product manager and director of sorts, setting direction and guidance for the delivery of Firefox to its millions of users worldwide", give us some more insider information on why nothing has been done? Is it shortage of developers? is it because this usability flaw has low priority? is it lack of agreement that this "bug" is a bag at all? Any other reasons? 

Talk to us, man!

Comment 88

7 years ago
You had me up until all that stuff about citizen advocacy. I agree the devs themselves (or no one) will fix this though. After nearly 3 years of complete inaction I wouldn't hold out much hope however.

Even if they didn't change it to allow user selected actions to be remembered the dialogue should at least be changed to something that makes more sense. Offering to remember an action and to repeat that action for specific filetypes 'from now on' and then not doing it, just doesn't make any sense. I know there is an argument about the security issues this presents (although this has been proved baseless above), however if other browser can handle this action without difficulty then why not FF? 

I suppose this is what happens when you have 'design by committee'. Stupid bugs (and bureaucracy) emerge and become so intractable (due to so many conflicting perspectives) that it becomes almost impossible to fix them. This is why Soviet era cars were always so poorly designed too.

PS

I'm unsubscribing from this debate. I think waiting over 2 years for a fix is probably long enough.

Comment 89

7 years ago
(In reply to comment #88)
> After nearly 3 years of complete inaction

My understanding is that this has been a known issue for much much longer than that, but other older bugs have been closed as a duplicate of this. See e.g. bug 331259, shamefully closed as "VERIFIED FIXED".
Way back up in comment 1, kevin pointed out that bugzilla is not a discussion forum and he was right. This bug doesn't need advocacy, or calendar counting, or threats to move to other browsers, or righteously indignant demands, or consensus building, or massive grassroots whatever the hell.

It needs a patch.

That it hasn't gotten one from someone on my team yet is purely a function of them having too much other work to do. Anyone in the 89 comments above this one is, of course, welcome and invited to attach one - we'd love to fix this bug. Anyone up for it?

Comment 91

7 years ago
That is pretty dismissive of users opinions dude. How else are ordinary users supposed to bring glaring bugs like this to developers attention?

I agree threats to move to other browsers, or starting grass roots campaigns, or whatever else method of drum banging is used a a bit childish and pointless. But what you are dealing with here is ordinary users, so taking a typically elitist developers stand and telling ordinary users to go fix it themselves probably isn't all that helpful.

I'm sure if everyone in the world could write code, then someone would have fixed this by now - but that's why people in the world are divided into different specialities and different professions.

The only hope ordinary users have is to try to keep issues like this alive and keep brining them to developer's attention until someone decides to fix them. Otherwise what's to say someone won't just come along and randomly (as has happened in the past) mark the issue as 'fixed.'

Anyway I really am unsubscribing, just as soon as I can work out how to unsubscribe from a specific thread. Not because of some childish tantrum, but because I have simply lost interest (and hope) of the issue ever being fixed. I stayed quiet and watched this thread for well in excess of two years. I am I regret simply tired of reading about it now.

Updated

7 years ago
Duplicate of this bug: 331259

Comment 93

7 years ago
Because this bug report is still open and bug #331259 was marked as Closed/Fixed, I marked bug #331259 as a duplicate of this one.  

I must note that the overall problem was reported in bug #331259 on 21 March 2006, 2-1/2 years before this bug report was submitted.  Everyone should realize that this problem has been known for almost five years.

Comment 94

7 years ago
(In reply to comment #93)
> Everyone should realize that this problem has been known for almost five years.
You were already told off for altering the other bug wrongly, but I'll point out that this was known about in bug 285976, six years ago. That's the bug that would disable the "Do this automatically" checkbox so you can't tick it in the Content-disposition: attachment case, including an explanation. The usage of that HTTP header has changed since then to be in far wider use which is why this bug was reopened.

Comment 95

7 years ago
(In reply to comment #94)
> I'll point out that this was known about in bug 285976, six years ago.
Correcting myself, the original report was bug 236541, seven years ago, dealing only with remembering the "download" action, this bug is for the "open with" action.

Comment 96

7 years ago
workaround
I've made an extension that fix this bug:
https://addons.mozilla.org/en-US/firefox/addon/do-this-automatically-modif/

Comment 97

7 years ago
It doesn't work in FF4. Besides although possibly useful, extensions don't fix bugs that should probably be fixed anyway.

Comment 98

7 years ago
(In reply to comment #97)
> It doesn't work in FF4. Besides although possibly useful, extensions don't fix
> bugs that should probably be fixed anyway.

Works great in Firefox 4,The above is incorrect.
Thanks for that!

Comment 99

7 years ago
Not in Beta 12.

Comment 100

7 years ago
Besides it really is worth remembering that this is a work around and not a fix. It may even have the effect of removing any motivation there may have been (although there doesn't appear to be much) of fixing this bug to begin with.

Comment 101

7 years ago
(In reply to comment #99)
> Not in Beta 12.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre

;)

Comment 102

7 years ago
Sorry to add to the noise, but ...
I have read all the comments, RFC 2183, RFC 2616 (esp. 15.5 Content-Disposition Issues), etc.
RFC 2183 is for email (not HTTP).
RFC 2616 is HTTP and explicitly states that "Content-Disposition is not part of the HTTP standard."
I understand some of the security issue(s) and the philosophy that attachments require user action(s).
If the underlying behavior is WONTFIX then, in this case, the "do this automatically" checkbox should not be available and should be replaced by text indicating the issue.  I will try to put this comment with the correct bugs.
For me personally, this is a king size pain esp. with streaming media whether or not I want to use a plug-in or an external program.  If I right-click and "Open Link in Ext. App." then I can get my streaming audio.  Again for me personally, I do not even get the dialog because I get the ZoneAlarm download dialog and must download the (entire) file, then run it.

Thanks for listening.

Comment 103

7 years ago
For the life of me, I cannot find where to change an attachment from OpenOffice to MS Word. It just automatically wants to use O.O.

Comment 104

7 years ago
Voting...

Comment 105

7 years ago
(In reply to comment #103)
> For the life of me, I cannot find where to change an attachment from OpenOffice
> to MS Word. It just automatically wants to use O.O.
life of me, I cannot find where to change an attachment from OpenOffice
> to MS Word. It just automatically wants to use O.O.

This isn't anything to do with this bug. This isn't even a bug. This is down to your own lack of knowledge. The best place to resolve this is either via Google (probably quicker) or the Firefox MozillaZine forums. http://forums.mozillazine.org/viewforum.php?f=38
Duplicate of this bug: 404166

Updated

7 years ago
Duplicate of this bug: 660510
Regrouping:

The issue represented by this problem report is that when we see a file served with content-disposition: attachment we always ask the user if they want to save it or open in a helper app instead of just automatically handing to the helper app (as we would for a MIME type served without content-disposition: attachment).

Bug 470332 was meant to ameliorate the situation by remembering the list of helper-apps in the drop-down; I can report that although it's marked as FIXED, it doesn't always work. Presumably that's because sometimes we just can't actually remember it (as no MIME type given, I suppose?). In those cases bug 285976 was meant to not show the "always do this" UI, which would be only slightly less frustrating (in that we wouldn't be promising to do something we couldn't) but doesn't really fix the issue.

Further, in comment 4 and comment 40, Jesse argues that this header is often used as a way of providing additional security by not inheriting the origin of the referring website; our poor user experience from that choice is problematic.

I believe that Firefox should simply ignore content-disposition: attachment; the number of cases where it's being used properly (to encourage someone to download the file because helper apps may not allow saving) is, in my experience, vastly outweighed by the number of poor user experiences it creates ("I clicked on this file and Firefox didn't just open it in whatever"). We're also somewhat unique in our handling of the header, meaning that Firefox "seems" broken to people although by the very strictest letter of the RFCs, we're doing the right thing.

Perhaps in the fullness of time it will be easy to also add an infobar or prompt that asks users if they also wanted to just save the file, but for now, I think people will be able to find their way to right-click and "Save As..."

(NOTE: Please do *not* add advocacy comments to this already busy bug. If you agree, that's great, be quiet. If you disagree, and have an alternative proposal or factual clarifications, feel free to add a comment)

Comment 109

7 years ago
[quote]by the very strictest letter of the RFCs, we're doing the right thing[/quote] 

As per comment 22, the RFC in question is only meant to apply to mail programs.  Firefox is adhering to an RFC that it shouldn't.

Comment 110

7 years ago
So if I understand this correctly, the content-disposition header is only relevant if the user would normally want open the file automatically? 
In that case, if the user has selected 'Save As' as default action, there is no need to show the dialog, only if the user has selected 'Open with'. The 'always do this' checkbox could be disabled only for the 'Open with' selection, if the dialog is shown for a download with a content-disposition header.

One problem is that the behaviour is not transparent to the user, because he does not know that the server sent that header / requested to save the file, hence it looks like a bug. So displaying something like a yellow infobar-like box (to draw the attention of of the user without looking like a warning/error) with a text like 'The server encourages you to save the file' instead of the disabled 'always do this' checkbox could go a long way regarding user experience, ideally including a check/select/radio-box 'Always ignore what [a|this] server wants [for this file type]' (and only if Open With is selected if content-disposition is ignored when 'Save As' is the default action).

I would be willing to write a patch for this (provided I find the time), but I would like to make sure that it has some chance of being accepted first ..

Comment 111

7 years ago
(In reply to comment #109)
Apologies, comment 109 should have stated comment 72 as it's reference not 22.

I very much like the idea behind comment 110 but would expand upon it slightly.  Use a bar akin to remember password. Allow the user to save a default action and should action be anything other than "Save as..." a bar come across indicating possible actions.

If the action is anything other than save as a simple bit of text akin to comment 110:

"The server [insert domain] recommends saving this file, your default action is [insert default action].

Along with buttons:  "Save as...", "Change action", "Dismiss"
Dismiss = close message continue action
Save as = open save as dialog box
Change action = open dialog for selecting a one time action with an option to make it the default action, take the new action

In doing so it should not attempt to stop or delay the execution of the default action.  Akin to if you click a link the browser continues to load until given new instructions.  This then has the added benefit of being able to open and save a document simultaneously.

Comment 112

6 years ago
workaround
For users still annoyed by this bug, I would like to point out a workaround is available in the form of the InlineDisposition extension. It works like a charm, and much better than the old Do This Automatically extension.

https://addons.mozilla.org/firefox/addon/inlinedisposition/

Comment 113

6 years ago
Per addons.mozilla.org, the InlineDisposition extension is not compatible with SeaMonkey 2.2.  Although I might be able to tweak its install.rdf file to make it compatible, this clearly illustrates why extensions are merely workarounds for bugs and not solutions.

Comment 114

6 years ago
I'm writing this using Chrome. I finally switched yesterday, after years of using Firefox. This bug is the reason.
Duplicate of this bug: 541945
Duplicate of this bug: 723697
Keywords: sec-want

Updated

6 years ago
Duplicate of this bug: 756487

Updated

5 years ago
Duplicate of this bug: 801786

Updated

5 years ago

Comment 119

5 years ago
I think that request bug 801786 is not a duplicate of request bug 453455.

Request bug 453455 is about making Firefox remember the user choice in case of an "attachment" header sent by the server.

In request bug 801786, I explain that the choice I want is missing. So this request is not about remembering the user choice, it is about offering to the user the choice which is currently missing.

Comment 120

5 years ago
it does this with .torrent files too...

Updated

5 years ago
Whiteboard: [p-chrome] [sg:want] → [p-chrome] [sg:want] [Advo]

Comment 121

5 years ago
I think that constant referencing to RFC is incorrect approach to this problem.
Yes, browser should adhere to RFC and it is good thing. That's why FF should popup "Opening" dialog by default for any file that is marked as "attachment".

But it must be up to user to be able to override this behavior. I don't understand why drag for years this argument for feature that is obviously should be given at user's decision! If I deliberately mark some file type to be opened automatically - why FireFox decides that for me? Why it assumes that it "knows better"? Aren't we all tired of Microsoft's strategy "we know better than you what you need"? Flexibility was always strength of FireFox, why become stubborn on this feature?
If user wants to shoot himself in the leg (like I do) - please let him do it.

Comment 122

4 years ago
I use an extension Web page fixer. It is not ideal solution. Please just fix this bug.
Duplicate of this bug: 914009

Comment 124

4 years ago
text transfer from bug 57342:

i am using Waterfox 24.0 (64 bit build version of firefox) on Windows 7 x86 64 bits.

when visiting this page: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/1_10_00_23/index_FDS.html
(might require a free account to view or download)
and downloading the windows version (*.exe) of the file set
then i can select any option for opening or saving including the "remember my decision" option.

but when going for the linux version i only get offered two options: open with an application (default here is VLC) or download but the "remember" button is grayed out.

for my impression the browser should be able to remember decisions for explicitly html/mime tagged file formats as already realized. but for for non-tagged or "wildcard"-tagged files and it shall be check for the file name extension (or absence of such an extension - this happens more often than you would think) and decide based upon that extension. so the browser needs not only a mime type default action configuration database/listing but an extension based handling if mime type is not that useable. maybe even the user can pass down certain mime types to the extension based treatment. thus the mime type layer should see a new option: "handle by file extension".

@Sergio - thats a nice proposal in that area. i can support that. its all about options.

BTW i think the dialog does not mention the mime type so i am a bit lost in diagnostics for that my faulty cases using purely the browser. the dialog should mention the mime-type he asks me about.

Comment 125

4 years ago
Created attachment 8338484 [details]
screenshot of browser file reception dialog that has a grayed out "remember" item

Updated

4 years ago
Duplicate of this bug: 526156

Comment 127

4 years ago
(In reply to Alexander Stohr from comment #124)
> text transfer from bug 57342:

> for my impression the browser should be able to remember decisions for
> explicitly html/mime tagged file formats as already realized. but for for
> non-tagged or "wildcard"-tagged files and it shall be check for the file
> name extension (or absence of such an extension - this happens more often
> than you would think) and decide based upon that extension. so the browser
> needs not only a mime type default action configuration database/listing but
> an extension based handling if mime type is not that useable. maybe even the
> user can pass down certain mime types to the extension based treatment. thus
> the mime type layer should see a new option: "handle by file extension".

I think this is exactly what is needed.
I'm going nuts with PDFs that FF don't want to open with my (external) PDF-Reader anytime, just because of "something" (Mimetypes) that obviously are not suitable to recognize a PDF properly, what can by done by fileextension easily; I recognize the files and have to click open every time ...
an example is here: http://www.dandelon.com/servlet/download/attachments/dandelon/ids/FL001847F924468B0CB3CC12572670027878A.pdf

Updated

3 years ago
Blocks: 773942
Flags: firefox-backlog?
Flags: firefox-backlog?
Depends on: 1055623
Comment hidden (me-too)
Comment hidden (me-too)
Whiteboard: [p-chrome] [sg:want] [Advo] → [p-chrome] [sg:want] [Advo][qx]
Comment hidden (me-too)

Updated

3 years ago
Duplicate of this bug: 941708
Comment hidden (advocacy)
Comment hidden (me-too)
Comment hidden (me-too)
Blocks: 1244854
Priority: -- → P5
Comment hidden (me-too)
Duplicate of this bug: 1292599

Comment 137

7 months ago
Should this bug explicitly be marked as duplicate of older bug 236541? or the other way around?

Comment 138

7 months ago
(In reply to martin.monperrus from comment #137)
> Should this bug explicitly be marked as duplicate of older bug 236541? or
> the other way around?

Neither. Bug 236541 comment 38 restricts the patch to only the case when "save as" is the choice.

Comment 139

7 months ago
Hum, this subtlety isn't visible in the bug title:
"do this automatically for files like this" doesn't work when Content-Disposition:attachment is used
Make "do this automatically for files like this from now on" work even with "content-disposition: attachment"

According to your comment, I understand that "do this automatically for files like this" doesn't work only when "open with" is selected?
You need to log in before you can comment on or make changes to this bug.