Closed Bug 401748 Opened 17 years ago Closed 5 years ago

[10.5] Provide quarantine information for downloads on Leopard

Categories

(Firefox :: File Handling, defect, P4)

x86
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 337051

People

(Reporter: stuart.morgan+bugzilla, Unassigned)

Details

(Keywords: sec-want, Whiteboard: [sg:want])

I'm not sure what the right component is for download handling, so filing General/UNCO. OS X 10.5 has a file quarantine system that will mark downloaded files as such, so that a warning can be shown when they are launched. By default it will just say something generic about it being downloaded, but apps are encouraged to add metadata to the file (using LSSetItemAttribute, with kLSItemQuarantineProperties as the key) so that the dialog can give information about when it was downloaded, and from what site LSQuarantine.h has details about the dictionary. While we couldn't use the header itself, since it's 10.5 SDK, the appropriate constants could be added directly where necessary.
Historically these types of bugs (e.g. bug 90918, maybe one about the "Where From" transient metadata) have lived in Core:File Handling, though from the component descriptions, Networking:File might be more appropriate.
Component: General → File Handling
QA Contact: general → file-handling
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
This does not appear to be a dup to me at all. There are two distinct aspects of quarantine: 1) Opt in to having quarantine set on files created by Firefox (or whatever). This is done at the level of the application's Info.plist (perhaps it would be possible to set manually, but I don't think that's at all the intention) 2) Provide information through launch services with specific information about where a file came from, and when. These are not done at the same layer, or through the same APIs, so it probably doesn't make sense to track them in the same bug. This bug is about 2 specifically; the description of bug 401744 seems fairly clear that it is about 1, which is why I went ahead and filed this. Reopening based on that; if I'm mistaken, then it seems like bug 401744 needs to be in a different component, with a different description.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Is there a point to even doing bug 401744? Apple has apparently opted us in magically (looks to be bundle ID sniffing). We *definitely* want this.
Requesting blocking. Rationale: Apple automatically opted us in to the basics, where files we download are marked as not trusted (that flag is removed later by the OS, for example for applications it happens when the app is opened). However, we can explicitly set extra metadata like the URL that an application was downloaded from that significantly enhance the utility of the warning dialog that comes up (it can take you back to the page where you clicked on the download link from, for example). We can also set what type file it is (download from web vs. attachment from email or IM or Calendar), which probably affects the wording of the dialog when opened, would be useful for other apps. I don't think this is a high priority bug, but it is definitely wanted material (and I don't see how to flag just wanted and not blocking). Might also be [good first bug] material if there is a straightforward place in Gecko to put this stuff. See LSQuarantine.h on a Leopard machine for details about how to set the properties.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
+'ing this, but it's a lower priority than other blockers.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
A version of the patch in bug 407215 can be put somewhere that toolkit apps can take advantage of it. I suggested mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp in bug 407215 comment 3.
Given Comment 6 moving to wanted
Flags: wanted1.9+
Flags: blocking1.9-
Flags: blocking1.9+
Whiteboard: [sg:want]
I provided a patch for bug 337051, which also addresses this one. It adds the following information for each download: kLSQuarantineTypeWebDownload, kLSQuarantineOriginURLKey, kLSQuarantineDataURLKey. As a consequence, the MacOS LaunchService dialog shows the URL from where the file was downloaded and also provides a button to open the respective URL.
Product: Core → Firefox
Version: Trunk → unspecified

Is this still relevant?

Flags: needinfo?(haftandilian)

(In reply to Tom Ritter [:tjr] (OOTO until 5/1?) from comment #10)

Is this still relevant?

I don't think there is anything more to do here. The code in CocoaFileUtils::AddQuarantineMetadataToFile() adds the keys when a download occurs. For example,

(lldb) po mutQuarantineProps
{
    LSQuarantineAgentName = NightlyDebug;
    LSQuarantineDataURL = "https://download-installer.cdn.mozilla.net/pub/firefox/releases/74.0/mac/en-US/Firefox%2074.0.dmg";
    LSQuarantineIsOwnedByCurrentUser = 1;
    LSQuarantineOriginURL = "https://www.mozilla.org/en-US/firefox/download/thanks/";
    LSQuarantineTimeStamp = "2020-04-03 16:58:42 +0000";
    LSQuarantineType = LSQuarantineTypeWebDownload;
}

And when opening a download the Finder warns me and tells me where it was downloaded from using the LSQuarantineOriginURL value and xattr shows the com.apple.metadata:kMDItemWhereFroms data.

Status: NEW → RESOLVED
Closed: 17 years ago5 years ago
Flags: needinfo?(haftandilian)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.