Bugzilla

> I'm also wondering if there are other sandbox / mitigation policies that we already (or in the future intend to) employ in Firefox itself that we don't necessarily want to impose on apps started from the downloads dir and that would bolster the case to revert the change from bug 1605308. Chris, can you comment on this?

Off the top of my heads, I can't think of anything coming down the pipeline that would treat the Downloads folder differently. This question might be a better fit for Freddy anyhow, as I think his team has a better idea of what high-level security features we might implement in the future.

As for solving this issue, I have a proposal that combines some of the ideas others have already mentioned above - Please feel free to poke holes or offer up suggestions for improvement! 

Let's combine two of the things suggested above: We switch back to using `ShellExecuteByExplorer` to launch programs out of the download folder (IE get rid of this special treatment for Downloads) **AND** we move DLL downloads into their own subfolder in the Download directory (Bikeshed alert: maybe we just call it `Dlls`?).

This has the added benefit that it protects our users if they open up the Downloads folder itself and double-click the executable, which the current solution doesn't prevent. In this sense, it's actually better that we use `ShellExecuteByExplorer`, since it's the same mechanism they would be using, and ideally we should protect our users even when they're not using Firefox if the potentially-dangerous situation is one that we allowed to happen.

(It also means that we don't have to rely on folks that write executables to ensure that they disallow adjacent DLL loading, which a lot of program authors would never think of)

It is mildly inconvenient to the user, but as was said above -- How often are people really downloading DLLs? And if they are, presumably they either: 1. Know what they are doing, so the concept of a subdirectory isn't going to throw them off, or 2. Don't know what they're doing, at which point they probably should not be doing anything with DLLs.

Curious to hear people's thoughts on this idea?

> I'm also wondering if there are other sandbox / mitigation policies that we already (or in the future intend to) employ in Firefox itself that we don't necessarily want to impose on apps started from the downloads dir and that would bolster the case to revert the change from bug 1605308. Chris, can you comment on this?

Off the top of my heads, I can't think of anything coming down the pipeline that would treat the Downloads folder differently. This question might be a better fit for Freddy anyhow, as I think his team has a better idea of what high-level security features we might implement in the future.

As for solving this issue, I have a proposal that combines some of the ideas others have already mentioned above - Please feel free to poke holes or offer up suggestions for improvement! 

Let's combine two of the things suggested above: We switch back to using `ShellExecuteByExplorer` to launch programs out of the download folder (IE get rid of this special treatment for Downloads) **AND** we move DLL downloads into their own subfolder in the Download directory (Bikeshed alert: maybe we just call it `Dlls`?).

This has the added benefit that it protects our users if they open up the Downloads folder itself and double-click the executable, which the current solution doesn't prevent. In this sense, it's actually better that we use `ShellExecuteByExplorer`, since it's the same mechanism they would be using, and ideally we should protect our users even when they're not using Firefox if the potentially-dangerous situation is one that we allowed to happen.

(It also means that we don't have to rely on folks that write executables to ensure that they disallow adjacent DLL loading, which a lot of program authors would never think of)

It is mildly inconvenient to the user, but as was said above -- How often are people really downloading DLLs? And if they are, presumably they either: 1. Know what they are doing, so the concept of a subdirectory isn't going to throw them off, or 2. Don't know what they're doing, at which point they probably should not be doing anything with DLLs.

Curious to hear people's thoughts on this idea...

> I'm also wondering if there are other sandbox / mitigation policies that we already (or in the future intend to) employ in Firefox itself that we don't necessarily want to impose on apps started from the downloads dir and that would bolster the case to revert the change from bug 1605308. Chris, can you comment on this?

Off the top of my head, I can't think of anything coming down the pipeline that would treat the Downloads folder differently. This question might be a better fit for Freddy anyhow, as I think his team has a better idea of what high-level security features we might implement in the future.

As for solving this issue, I have a proposal that combines some of the ideas others have already mentioned above - Please feel free to poke holes or offer up suggestions for improvement! 

Let's combine two of the things suggested above: We switch back to using `ShellExecuteByExplorer` to launch programs out of the download folder (IE get rid of this special treatment for Downloads) **AND** we move DLL downloads into their own subfolder in the Download directory (Bikeshed alert: maybe we just call it `Dlls`?).

This has the added benefit that it protects our users if they open up the Downloads folder itself and double-click the executable, which the current solution doesn't prevent. In this sense, it's actually better that we use `ShellExecuteByExplorer`, since it's the same mechanism they would be using, and ideally we should protect our users even when they're not using Firefox if the potentially-dangerous situation is one that we allowed to happen.

(It also means that we don't have to rely on folks that write executables to ensure that they disallow adjacent DLL loading, which a lot of program authors would never think of)

It is mildly inconvenient to the user, but as was said above -- How often are people really downloading DLLs? And if they are, presumably they either: 1. Know what they are doing, so the concept of a subdirectory isn't going to throw them off, or 2. Don't know what they're doing, at which point they probably should not be doing anything with DLLs.

Curious to hear people's thoughts on this idea...