874
edits
Labs/Jetpack/JEP/29: Difference between revisions
Jump to navigation
Jump to search
added 'code updating' section
(→Privilege Separation: rewording) |
(added 'code updating' section) |
||
| Line 110: | Line 110: | ||
Therefore, instead of raising cryptic errors like "Security manager vetoed action", the text of the error should include specific information on why the action violated a security policy and what the developer can do about it. | Therefore, instead of raising cryptic errors like "Security manager vetoed action", the text of the error should include specific information on why the action violated a security policy and what the developer can do about it. | ||
=== Code Updating === | |||
The exact criteria for how transparent code updates are, and in what cases they are even allowed to occur, is still in flux. The following represents some issues to be considered. | |||
As long as code is signed, updating it should be transparent. However, if the code isn't signed, and has medium to high privileges, users may need to provide permission to update the code; indeed, we may even need to prohibit code updating on such Jetpacks over non-HTTPS protocols due to the danger of man-in-the-middle attacks, as Firefox's current extension update mechanism does. | |||
Regardless, however, it should also be noted that allowing for the transparent updating of code can actually be ''beneficial'' from a security standpoint, as it's the easiest way to guarantee that the code has the most recent security fixes. | |||
== Social Factors == | == Social Factors == | ||