Labs/Jetpack/JEP/29: Difference between revisions

Labs/Jetpack/JEP/29 (view source)

56 bytes removed , 9 October 2009

874

edits

@@ Line 115: / Line 115: @@
 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.
+As long as code is signed, updating it should be transparent, as it both relieves the user of the burden of having to authorize trusted code updates and also ensures that they're on the version of their software with the most recent security fixes.
-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.
+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.
 == Social Factors ==