Bugzilla

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: Experimenting with content:// URLs quickly leads to various exploits. How to construct an exploit to read internal files like cookies might not be immediately obvious, but any skilled researcher could definitely do that. We can squash the patches and add a vague commit message to mitigate these concerns, however I would assume that any ESR patch gets a lot of scrutiny anyway.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: Yes
* **Which older supported branches are affected by this flaw?**: esr only
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: Yes
* **If not, how different, hard to create, and risky will they be?**: N/A this code is only in ESR68
* **How likely is this patch to cause regressions; how much testing does it need?**: The code is involved, so regressions are possible. Worst case scenario is Fennec crashes when opening a download or an intent from a third-party app. We ran QA regression testing on these scenarios.

### ESR Uplift Approval Request
* **If this is not a sec:{high,crit} bug, please state case for ESR consideration**: sec-crit
* **User impact if declined**: Any webpage can easily steal all user data (cookies, passwords, etc)
* **Fix Landed on Version**: pending
* **Risk to taking this patch**: High
* **Why is the change risky/not risky? (and alternatives if risky)**: we have to close a few holes in our content:// protocol handling, also we don't have any baking in any other channel since this is a ESR only bug.

A marginally risky approach would be to remove the feature outright, that means that users would not be able to open attachments from email in Fennec, which has been a feature since 2018.
* **String or UUID changes made by this patch**: none

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: Experimenting with content:// URLs quickly leads to various exploits. How to construct an exploit to read internal files like cookies might not be immediately obvious, but any skilled researcher could definitely do that. We can squash the patches and add a vague commit message to mitigate these concerns, however I would assume that any ESR patch gets a lot of scrutiny anyway.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: Yes
* **Which older supported branches are affected by this flaw?**: esr only
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: Yes
* **If not, how different, hard to create, and risky will they be?**: N/A this code is only in ESR68
* **How likely is this patch to cause regressions; how much testing does it need?**: The code is involved, so regressions are possible. Worst case scenario is Fennec crashes when opening a download or an intent from a third-party app. We ran QA regression testing on these scenarios.

### ESR Uplift Approval Request
* **If this is not a sec:{high,crit} bug, please state case for ESR consideration**: sec-crit
* **User impact if declined**: Any webpage can easily steal all user data (cookies, passwords, etc)
* **Fix Landed on Version**: pending
* **Risk to taking this patch**: High
* **Why is the change risky/not risky? (and alternatives if risky)**: we have to close a few holes in our content:// protocol handling, also we don't have any baking in any other channel since this is a ESR only bug.

A marginally less risky approach would be to remove the feature outright, that means that users would not be able to open attachments from email in Fennec, which has been a feature since 2018.
* **String or UUID changes made by this patch**: none

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: Experimenting with content:// URLs quickly leads to various exploits. How to construct an exploit to read internal files like cookies might not be immediately obvious, but any skilled researcher could definitely do that. We can squash the patches and add a vague commit message to mitigate these concerns, however I would assume that any ESR patch gets a lot of scrutiny anyway.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: Yes
* **Which older supported branches are affected by this flaw?**: esr only
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: Yes
* **If not, how different, hard to create, and risky will they be?**: N/A this code is only in ESR68
* **How likely is this patch to cause regressions; how much testing does it need?**: The code is involved, so regressions are possible. Worst case scenario is Fennec crashes when opening a download or an intent from a third-party app. We ran QA regression testing on these scenarios.

### ESR Uplift Approval Request
* **If this is not a sec:{high,crit} bug, please state case for ESR consideration**: sec-crit
* **User impact if declined**: Any webpage can easily steal all user data (cookies, passwords, etc)
* **Fix Landed on Version**: pending
* **Risk to taking this patch**: High
* **Why is the change risky/not risky? (and alternatives if risky)**: The patch is android-only. 
We have to close a few holes in our content:// protocol handling, also we don't have any baking in any other channel since this is a ESR only bug.

A marginally less risky approach would be to remove the feature outright, that means that users would not be able to open attachments from email in Fennec, which has been a feature since 2018.
* **String or UUID changes made by this patch**: none