Ian G wrote:
But that doesn't come anywhere near a level of security that's worth much: API compliance is not an exact science, as you never know when the plugin is going to go haywire or decide to start phoning home with the passwords. A breach of its address space for reading purpose may not be detected, but it sure as hell is something we want to avoid.
so this means.. mozilla's developers chose to ignore good coding practices?
No, they made some compromises forced on them by the marketplace. The market for browsers is pretty much limited to C/C++, so they have to make that compromise from the start, and accept buffer overflows in any code they choose to let loose within the address space.
(By way of comparison, in the same time frame, my company chose Java for desktop clients for security reasons, and even though our result is much more secure and robust, we can't get people to install Java without violence or blackmail, so much so that Java on the desktop is pretty much a failure for commercial purposes.)
(And even if Mozilla had picked Java, they'd still run into flack from the capabilities crowd, who'd point out how much of a mess Java is ... :) there's no easy answer here.)
specially with the performance hit of java.
that is my only reason for not having a java vm on my systems.
until sun pulls thier heads from thier butts and makes java a 100% machine code app, not requiring any additional interpreters, it will be too slow for real use. ( in my opinion )
been a few secunia advisories about jre lately also though, so it isn't perfectly secure either.
they decided to use m$'s drag and drop rad style coding rather than do any real coding? most common cause of buffer overflow errors is from bloated code, caused by using a drag and drop interface designer, linking to prebuilt libraries. this is what causes a continuation of buffer overflows, reusing libs with bloated interface design elements.
OK, but practically, I don't see what can be done about it. Buffer overflows are very hard to detect, outside and before the case. About the only thing I can think of is to run every plugin in a separate process, but I know too little about Microsoft arch to know whether that makes sense.
not sure about in m$ systems, but definately in the *x systems each plugin could be broken into it's own thread at least.
( not as much an issue on *x systems though )
yup, trade the absolute security of your system to be online. trade the security of your browser for features that don't add anything but bells and whistles.
I test my browser for vulnerabilities, never have any because of never having any extentions or clientside scripting enabled.
Right. For you that's grand. Trying to get the rest of the browsing community to do that is a non-starter. Question is, what is there that you do that could be used to help the average user?
for that, I'm not sure. it's more an attitude that those bells and whistles are a nuisance and irritation than an attitude that they are desirable. how to get that changed? ( the real question )
I have to write up the results, but a brief summary of a survey I did:
( 250,000+ people given survey )
80% leave sites as soon as they see flash
50% as soon as javascript noticed ( lack of functionality because it's not active )
all of them work or hobby with 3d graphics and animations, all with high speed internet.
most ( 68% ) expressed distaste at even animated gifs on websites.
so the javascript and flash for websites actually hurt business.
and animated image files ( .gif, .mng [ very few yet ]) are not appreciated.
( like I said brief summary )
Jaqui _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
