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

On 25.01.2010 15:19, Julian Reschke wrote:
> ...
> Looking into this I just realized that, to begin with, we may have to
> fix the definition of plugin. It used to be non-critical, but now it's
> referred to for iframe/@sandbox it is.
>
>  From <http://dev.w3.org/html5/spec/Overview.html#plugins>:
>
> "The term plugin is used to mean any content handler for Web content
> types that are either not supported by the user agent natively or that
> do not expose a DOM, which supports rendering the content as part of the
> user agent's interface."
>
> - "Web content type" appears to be undefined. Is it just a media type?
>
> - "do not expose a DOM": that seems to the content handler for JPGs a
> plugin, right?
> ...

This was raised as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8828>; 
and we now have a new definition:

"The term plugin is used to mean any content handler that supports 
displaying content as part of the user agent's rendering of a Document 
object, but that neither acts as a child browsing context of the 
Document  nor introduces any Node objects to the Document's DOM.

Typically such content handlers are provided by third parties, though a 
user agent can designate content handlers to be plugins."

That's better, as it doesn't rely on undefined terminology.

I'm still confused about whether the code that displays a JPG is a 
plugin or not. It seems to fall under the definition above.

Also:

"Typically such content handlers are provided by third parties, though a 
user agent can designate content handlers to be plugins."

I have a hard time understanding what the 2nd part of this sentence 
means; can somebody help me with that?

The text continues with:

"One example of a plugin would be a PDF viewer that is instantiated in a 
browsing context when the user navigates to a PDF file. This would count 
as a plugin regardless of whether the party that implemented the PDF 
viewer component was the same as that which implemented the user agent 
itself. However, a PDF viewer application that launches separate from 
the user agent (as opposed to using the same interface) is not a plugin 
by this definition."

That's good; it clarifies that a PDF viewer built into the UA (such as 
on Safari Mac) has the same status as Acrobat Reader.

Looking at

"...However, a PDF viewer application that launches separate from the 
user agent (as opposed to using the same interface) is not a plugin by 
this definition."

...we might want to consider to coin a term for this; it might be needed 
in other places ("helper application"?).

Going back to Bugzilla; Ian writes in 
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=8828#c5>:

> It's possible for a plugin to support JPG types, yes. More common is for
> browsers to natively support SVG or PDF yet have that support fall into the
> "plugin" definition. Really the only effect is whether <embed> can display the
> content or not.

So this confirms that any code that displays a JPG falls under the 
definition of "plugin".

I fail to understand the comment about <embed>, unless it's mean to 
apply to <object> as well.

The whole thread was started because of "sandboxed" vs plugins. The 
definition of <iframe> currently says:

"The sandboxed plugins browsing context flag

     This flag prevents content from instantiating plugins, whether 
using the embed element, the object element, the applet element, or 
through navigation of a nested browsing context."

Does that imply that a plugin that was invoked through <img>, <audio> or 
<video> would be allowed to run?

Best regards, Julian

Received on Wednesday, 17 February 2010 15:29:47 UTC