[webkit-gtk] Arbitrary GObject exposition in a WebFrame js context... ie. Seed and WebKitGtk

[Alexandre Mazari]

Le jeudi 28 juillet 2011 à 08:47 -0300, Gustavo Noronha Silva a écrit :
> Hey,
> 
> On Tue, 2011-07-26 at 10:44 +0200, Alexandre Mazari wrote:
> > Thinking along this line, it occurs to me that such a mecanism might
> > prove interesting within webkit-gtk both as an API user and a contributor.
> 
> Yes, I think it would be very, very useful. I even tried to discuss this
> year back or so, you may remember, but it didn't get far =(.
> 
> > The HTML5 FileSystem specification looks like a good candidate to be
> > implemented in this way.
> > (http://dev.w3.org/2009/dap/file-system/pub/FileSystem/).
> 
> No, that sounds like a very bad idea to me. It means we will be putting
> the nicely structured WebKit implementation aside and replacing it with
> a potentially buggy and (maybe even only subtly) incompatible
> implementation.
> 
> I'm very pro giving the API users the power and ease of use of seed for
> exposing GObjects in their WebViews, hopefully with separate security
> domains of sorts, but I think we would be shooting ourselves in the foot
> if we started implementing DOM APIs ourselves with GObjects.
> 

Yeah, sounds indeed not such a great idea.

> > even a full application UI, see SeedKit ;)
> 
> I have actually done this myself as a test; I wrote a patch to seedkit
> which is probably in bugzilla still, that allows you to initialize seed
> with an existing JSCore context. And I then used GObject APIs from
> inside my web application.
> 
> > The idea is already implemented by Qt and Apple ports
> > http://doc.qt.nokia.com/latest/qwebframe.html#addToJavaScriptWindowObject
> > http://developer.apple.com/library/mac/#documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/ObjCFromJavaScript.html
> 
> Similar API would be good to have, yes.

> > Still, some restructuration might be needed to make the imported Seed
> > code a bit more flexible and hardened security-wise.
> > 
> > Would such an addition be worth ? Have some brain cycle to share ?
> 
> I think we could start small, just providing APIs similar to those
> available to Qt, so a way to have applications add GObjects to the
> window object, and maybe a way to expose all libraries too, with a huge
> warning saying this should not be done to WebViews that might access
> untrusted content.
> 
Great you buy in. We'll hopefully be able to import introspection code
from seed if/when the licences become compatible.
At what level should that be implemented ?
Wrapping GObject as JS object might go in Javascript/gtk and used in
webkitwebframe.cpp/h.

> Then when we better understand the security functionality that is made
> available by JSC we can improve on that and provide more granular and
> sophisticated APIs.

As the HTML5 specs that require authorizations, we could base security
on explicit user allowance for each GObject from a specific security
domain.
In the case of fully local applications, dev might want to shortcut
that. Or set them at installation time so user aint bothered with ugly
requests ("GAwesomeApplication wants to access
'GAwesomeApplicationController' object. Allow?").

Anyway, a GObject should *never ever* be exposed to unknown content
source, being local or remote. How should we declare/keep this strong
exclusive unidirectionnal link between a gobject and a resource ?

Thanks for you answers,
Happy coding,
Alex