- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 02 Feb 2010 15:59:52 +0100
- To: Leonard Rosenthol <lrosenth@adobe.com>
- CC: 'Joe D Williams' <joedwil@earthlink.net>, Adam Barth <w3c@adambarth.com>, Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
Leonard Rosenthol wrote: > Under your definition, Joe - if I have a plugin that does NOT have a script engine (for example, a TIFF displaying plugin) - then I am not really a plugin? Or what about a UA that runs a separate "script engine" to process specific content (say QuickTime) - is that a plugin, even if the UA is doing it by itself? > > This remains my problem - there is an attempt to disable "plugins", yet no one (including the editor who wrote the actual text!) has been able to provide a clear and concrete definition of what it means. > > If we can't define it, then I think it's clear that we can't prohibit it... > > Leonard > ... OK, trying to summarize: 1) HTML5 currently disallows instantiation of plugin from sandboxed iframe element. 2) HTML5 doesn't have a precise definition of what a plugin actually is (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=8828>). 3) HTML5 *could* add a "allow-plugins" switch (similar to other opt-ins), but that would actually require knowledge of what exactly the sandboxing of a plugin needs to prevent. (I started work at <https://wiki.mozilla.org/Plugins:SandboxedPlugins> for this). It would be great if we could make progress on item 2) over here. If we don't, then the normative requirements on not instantiating plugins will have to be removed. I'd also appreciate feedback about what exactly the effect of sandboxing a plugin should be (again -> <https://wiki.mozilla.org/Plugins:SandboxedPlugins>, and/or join the Mozilla plugin-futures mailing list). Best regards, Julian
Received on Tuesday, 2 February 2010 15:00:33 UTC