Talk:Extension Blocklisting:User Interface: Difference between revisions

mNo edit summary
Line 7: Line 7:


The notification wizards described are dummied down too much, and don't imply enough warning or details on how vulnerable packages were determined. These dialogs bear a stricking resemblance to the windows "Unsigned Driver" warning, which most users don't read anymore & click through.
The notification wizards described are dummied down too much, and don't imply enough warning or details on how vulnerable packages were determined. These dialogs bear a stricking resemblance to the windows "Unsigned Driver" warning, which most users don't read anymore & click through.
[User:Robert Strong|Robert Strong]] 12:49, 5 Mar 2006 (PDT)
The details will be available on the blocklist web page. An important difference regarding any similarity between windows "Unsigned Driver" warning is that there is no option to ignore the warning.


I really dislike the blacklisting sterotype, and the vague reasons given for why a n extension would be on this list. If an extension has a known vulnerability or new exploit, it should refer the user to the published description of the vulnerability [http://www.kb.cert.org/vuls/ US-CERT Vulnerability Notes Database] and/or the authors website for discussion and support.
I really dislike the blacklisting sterotype, and the vague reasons given for why a n extension would be on this list. If an extension has a known vulnerability or new exploit, it should refer the user to the published description of the vulnerability [http://www.kb.cert.org/vuls/ US-CERT Vulnerability Notes Database] and/or the authors website for discussion and support.
[User:Robert Strong|Robert Strong]] 12:49, 5 Mar 2006 (PDT)
The details will be available on the blocklist web page which will be hosted on mozilla.com. The reasons why an extension is blocklisted will be available there and they should never be vague. I hope to have guidelines available as to what will cause an extension to be added to the blocklist and the general process that will take place which would include notification to the extension author prior to blocklisting except for security issues.


Extension and Plugin devs that wish to submit code for inclusion on the Mozilla Update site should be encouraged to sign their packages with PGP/GPG keys, which someone at Mozilla.org can verify on a key server. It should be someones job (or build community infrastructure) to test and audit the extensions, verify the keys  or repackaged with a standard mozilla key and validate CheckSums. The MD5 and SHA1 checksums should be made public, for anyone to validate, and any blacklist error messages a user gets when attempting to install the extension should indicate that the either the signed PGP/GPG keys or CheckSums do not match.
Extension and Plugin devs that wish to submit code for inclusion on the Mozilla Update site should be encouraged to sign their packages with PGP/GPG keys, which someone at Mozilla.org can verify on a key server. It should be someones job (or build community infrastructure) to test and audit the extensions, verify the keys  or repackaged with a standard mozilla key and validate CheckSums. The MD5 and SHA1 checksums should be made public, for anyone to validate, and any blacklist error messages a user gets when attempting to install the extension should indicate that the either the signed PGP/GPG keys or CheckSums do not match.
[User:Robert Strong|Robert Strong]] 12:49, 5 Mar 2006 (PDT)
All points to think on but outside of the scope for blocklisting.


http://www.openoffice.org/dev_docs/using_md5sums.html
http://www.openoffice.org/dev_docs/using_md5sums.html
Confirmed users
1,041

edits