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

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


>> 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?


> 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?

Well, I said scriptable from the DOM and this meant both ways; the 
plugin can talk to he DOM and vs versa. It needs the kind of 
interfaces defined by NAPI. If the object is not alive and active, 
like a dead ol tiff, then use img. Or, as was the very first step in 
getting some kind of live context hosted in an html docucment, then 
<embed>.
Whether or not it contains its own script engine may not be a factor 
but one thing for sure, it will never be sharing the host script 
engine. The fact that it may have its own script engine or shares the 
host script engine may be important. If the object element internal 
tree or graph is directly accessible (in the same namespace) by the 
host DOM then it is not really a plugin.

A TIFF is not a good example, more like an example of what about jpeg 
before jpeg was "bulitin' and not proprietary. It is a special class 
that requires a specific viewer/player/plugin due to some 
restrictions, like pdf or some others used to be. Now apple has 
'builtin' pdf? Is that not a "plugin'?
This is mainly a matter of how an 'external' execution context appears 
to the author. If there are no interfaces, or no scripting, or all is 
totally 'internal' an <object> is not necessary.

Take X3D or SVG for example. If the vocabulary is part of the language 
and I can code it inline without any container, then the DOM 
representation is entirely different than if the same code is included 
by <object>. The author doesn't care how it is done, plugin of no, I 
just want a predictable and consistent representation in the DOM.

So simple stuff, like TIFF or other dead stuff, along with browsers 
that would treat .html in <object> and <.html> in iframe essentially 
the same way, is really out of bounds for <object>. .

> 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?

Whether or not it is quicktime or not is invisible in html5. There is 
a video element. If somebody needs to specify QT to play an object, 
then there is @classid.
As for your example, most anything that is some fun has a high 
performance engine buitl into it.
Whether or not it is allowed to run may be one question.
Another is allow it to run but not affect content outside the 
container?
Another is allowing a set of interfaces like NAPI to play with its 
guts, and how much.

> 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.

For <iframe> it is an entirely different problem. <object> is built to 
allow control of the thing so the author and user can decide what to 
allow. The boundaries are the <object> container. It has hard 
boundaries as defined by NAPI. <iframe> is not that kind of container 
so the entire concept of what a sandbox is and how to control it is 
unique to sandbox.

If plugins are allowed, we can't 'disable' certain functionality from 
the outside. They will do what they are told to do. The container must 
restrict where they can reach and what they can do. <object> is set up 
for this. <iframe needs different ways to do this. If I say sandbox 
and it still starts a plugin that has scripting that tries to access 
the outside, then the host must disallow it. A plugin that has 
internal scripting but doesn't try to reach outside its context is not 
dangerous, I think.

> If we can't define it, then I think it's clear that we can't 
> prohibit it...

This is for <iframe>, right. Why not just keep it simple and only 
allow 'native' html5?
and certain container objects. Certainly there should be no problem 
with iframe containing literally anything except an <object> that was 
able to obtain access to the host DOM or the UA, or host OS, or 
network. If the host browser can't control this in iframe by making 
the boundaries enforcable, and the author requested sandbox, then 
what?
Use <object> it is built for that.
But certainly, <embed> and <object> are the only two elements that 
could possibly cause any trouble. <audio> and <video> <canvas> <img> 
should be totally safe. How does sandbox affect these when included in 
<iframe>?

>> Leonard

Thanks, Leonard and Best Regards,
Joe


-----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 21:36:15 UTC