On Mar 26, 2012, at 5:13 PM, Christopher Wright wrote: >> That seems kinda crazy... NPAPI has unrestricted access to the user's >> machine as far as I know. > > As opposed to ... ? Executable code is Executable code, no matter how you > slice it. >
In the case of QC and Safari WebKit, for instance, there's at least the "safe mode" mechanism that at least is capable of making "unsafe" patches not load. Circumventable, sure. > Incidentally, I believe your statement is incorrect - WebKit plugins can only > be run in-process (i.e., inside Safari), whereas NPAPI plugins can run > out-of-process (and thus as a users without privileges or in a tighter > sandbox). That seems completely the opposite of what you're suggesting. Exactly. http://code.google.com/chrome/extensions/npapi.html "Including an NPAPI plugin in your extension is dangerous because plugins have unrestricted access to the local machine. If your plugin contains a vulnerability, an attacker might be able to exploit that vulnerability to install malicious software on the user's machine. Instead, avoid including an NPAPI plugin whenever possible. Marking your NPAPI plugin "public" increase the attack surface of your extension because the plugin is exposed directly to web content, making it easier for a malicious web site to manipulate your plugin. Instead, avoid making your NPAPI plugin public whenever possible." If the dev leaves the plugin as "public", it's not a great scenario. There have also been noted weaknesses with many NPAPI plugins over the years, when working with stuff like Flash, Shockwave, Java, etc. Hey, you're right, exploits can always happen. There have been tons with WebKit over the years (which are always fun to read up about before they're patched, since it's public info with a nice lag between). Maybe it's just status quo. If Apple doesn't have the resources to keep the webkit plugin api going and secure, so be it. If it's just an arbitrary choice, or for other reasons that do make sense, so be it as well. -gt _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
