RE: What defines a "plugin"? WRT sandboxing?

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

-----Original Message-----
From: Joe D Williams [mailto:joedwil@earthlink.net] 
Sent: Wednesday, January 27, 2010 12:48 PM
To: julian.reschke@gmx.de; Adam Barth
Cc: Leonard Rosenthol; Maciej Stachowiak; public-html@w3.org
Subject: Re: What defines a "plugin"? WRT sandboxing?

> What defines a "plugin"?

How about just the idea of it is a plugin if it is scriptable from the 
host DOM, but a separate active realtime execution context that may be 
running its own independent script engine that can talk directly to 
the host DOM, directly to the UA, directly to the host OS, directly to 
the client hardware, and directly to the network?
That is why we have the <object> element. For example, seems like I 
should have a completely new browser context in there if I want to do 
.html in <object>. I mean, I would expect no direct access to the 
contained DOM except through carefully defined callbacks and methods 
'trusted' bits or whatever (currently as defined by NAPI and ActiveX) 
and the hot DOM.
Still one of the best uses of <object> is to completely control the 
host UA. It is a key to accessibility.
However, there must be limits. Please notice there is no seamless and 
no sandbox.
<object> produces a true "sandbox" where the host controls plugin 
access to host DOM and maybe other client features where necessary, 
and the hosted object comepletely controls access to its internals. In 
this case, the limits are defined by standards like NAPI. When those 
are clear then the plugin maker, even if the plugin is some varrsion 
of an html browser, will understand the steps needed to register the 
plugin via mime and get it hosted as expected for an object in the 
host DOM.

Thanks and Best Regards,
Joe



.

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Adam Barth" <w3c@adambarth.com>
Cc: "Leonard Rosenthol" <lrosenth@adobe.com>; "Maciej Stachowiak" 
<mjs@apple.com>; <public-html@w3.org>
Sent: Wednesday, January 27, 2010 9:06 AM
Subject: Re: What defines a "plugin"? WRT sandboxing?


> Adam Barth wrote:
>> On Tue, Jan 26, 2010 at 9:10 PM, Julian Reschke 
>> <julian.reschke@gmx.de> wrote:
>>> Adam Barth wrote:
>>>> The long term solution is to let plugins participate in the 
>>>> sandbox
>>>> security model and then add an allow-plugins directive that 
>>>> re-enables
>>>> them, which is where this thread started N thousand words ago.
>>> Indeed.
>>>
>>> Can we please try to make process here?
>>
>> Yes, that would be much better than going in circles here.  :)
>>
>> There was another fellow from Adobe who was interested in helping 
>> with
>> specifying the API.  Have you synched up with him?
>
> Leonard, are you subscribed to plugin-futures yet?
>
>>> I have started a Wiki page at 
>>> <https://wiki.mozilla.org/Plugins:SandboxedPlugins>,
>>
>> That looks to be mostly requirements.  I think we need someone to 
>> step
>> up and propose an API.  I can help, but it will take me a bit to 
>> get
>> up to speed on NPAPI.  We should continue this discussion on
>> plugin-futures.
>> ...
>
> I'd like to nail down what the requirements are first; this is, as 
> Maciej pointed out, necessary for the discussion how to specify the 
> allow-plugins attribute.
>
> Mapping the requirements to an API proposal doesn't appear to be 
> hard...
>
>>> and I have also pointed
>>> out that HTML5 currently doesn't have a solid definition of 
>>> "plugin" (see
>>> <http://lists.w3.org/Archives/Public/public-html/2010Jan/1275.html>) 
>>>  --
>>> should I open a BugZilla issue for that?
>>
>> That can't hurt.  :)
>
> I've done that in the meantime.
>
> Best regards, Julian
>

Received on Wednesday, 27 January 2010 20:21:45 UTC