Open Bug 416252 Opened 16 years ago Updated 2 years ago

[10.5] File | Save Page as invokes Tagging Downloaded Applications dialog

Categories

(Firefox :: File Handling, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: marcia, Unassigned)

Details

Attachments

(1 file)

Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3.

STR:
1. Load a web page, such as mozilla.com
2. File | Save Page as to the desktop.
3. Double click on the file to load it.

Expected: The page would load in the browser.
Actual: I get the tagged application dialog asking me if I want to open the application (see attached screenshot)

Not surprisingly, this does not happen using Safari when I save as  web archive or page source. It also does not happen using Seamonkey.
Summary: [10.5] File | Save Page as invokes Tagging Downloaded Applications → [10.5] File | Save Page as invokes Tagging Downloaded Applications dialog
I'm tempted to say this isn't a bug but a feature :-)

By default on OS X 10.5 (Leopard), downloaded binaries are considered
suspicious.  And you get this same warning whenever you run a
downloaded binary for the first time.

But there's an API in SecureDownload.h (a header file in Leopard's
Security framework) that (I think) lets a browser mark a download as
secure, so that you don't get the warning when you "run" it (even for
the first time).  I suspect this is what Safari uses.

I'm very puzzled why a SeaMonkey download wouldn't trigger the
warning, though.
I am additionally puzzled as to why if it is supposed to work this way that some other browsers I tried - Opera and Camino, for example, do not generate the same dialog when you save a page as. I guess would expect to get this if I were downloading an extension or app, but not a simple HTML page. Could get annoying if you do this a lot, and have to dismiss that dialog each and every time, even if it only the first time you save the page.
(In reply to comment #1)
> I'm very puzzled why a SeaMonkey download wouldn't trigger the
> warning, though.

It's possible Apple didn't force-opt-in SeaMonkey (or Opera).  I'm a bit surprised Camino isn't triggering this for you, though, since *everything* we emit (other than the profile and cache) is auto-quarantined by the OS (and I definitely get the quarantine alert when I do this in Camino).

Safari treats HTML (and a number of other unsafe file types) as "safe files", and it appears that they aren't quarantining them (although there are competing accounts; some say as of 10.5.1 HTML is considered unsafe, but for me it's still being treated as safe; see http://mymacinations.com/2008/02/06/changing-the-systems-default-settings-for-html-files-safe/).  I'm not sure if there's an API that lets other apps use the "safe files" lists, but I'm not convinced that doing so would be a good idea, anyway, given how many times Apple's poor judgement with that list has bitten them.
I _do_ see the problem with Camino (a recent nightly).

> It's possible Apple didn't force-opt-in SeaMonkey (or Opera).

As best I can tell, what Apple uses to do this (to opt programs into
the quarantine system) is a file called Exceptions.plist in the
Resources directory of the LaunchServices framework (under the
CoreServices framework).

This file has an Additions section where a bunch of program "domains"
are listed -- including org.mozilla.firefox and
com.operasoftware.opera, but not org.mozilla.seamonkey.

The Additions list doesn't include either Safari or Camino -- so I
guess Safari, like Camino, must "auto-quarantine".

I didn't know about
Library/Preferences/com.apple.DownloadAssessment.plist -- thanks for
pointing it out.  Though I'm puzzled that these settings don't also
effect Camino's behavior.

As for the API defined in SecureDownload.h:  I don't know how to use
it, but I get the impression that a browser (or any other quarantined
program) can use it to mark individual "downloads" as safe.  Now that
you've pointed out DownloadAssessment.plist, I'm less sure that Safari
actually uses this API.
(In reply to comment #4)
> I _do_ see the problem with Camino (a recent nightly).
> 
> > It's possible Apple didn't force-opt-in SeaMonkey (or Opera).
> 
> This file has an Additions section where a bunch of program "domains"
> are listed -- including org.mozilla.firefox and
> com.operasoftware.opera, but not org.mozilla.seamonkey.
> 
> The Additions list doesn't include either Safari or Camino -- so I
> guess Safari, like Camino, must "auto-quarantine".

Oh, this is funny.  Apple is opting in Chimera and versions of Camino < 1.0a1 (org.mozilla.navigator) and the Mozilla Suite (org.mozilla.mozilla) in, but not actually modern Caminos and SeaMonkeys.  So Camino is quarantining by virtue of us setting LSFileQuarantineEnabled ourselves when we set the exclusions, and SeaMonkey is not because they didn't set up exclusions (filed 426122 on SeaMonkey); nice find, Steven!
So, this is apparently invalid then, no?
There's certainly room for doubt ... which to my mind means that we can easily bump this to a Firefox 3 point release.
Product: Core → Firefox
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: