[webkit-dev] [QtWebKit] exposing JScript Objects to Clients

[Robert Hogan]

On Tuesday 29 September 2009 10:02:01 Oliver Hunt wrote:
> If your goal is to specify the useragent string that can be done
> entirely in the API layer without modifying WebCore at all (this is
> how Mac browsers built on the system WebKit specify their app name).
> The changes you're requesting should not involve WebCore in any way.
>

Yes, that is certainly my understanding for navigator.useragent and 
navigator.appVersion. However, I'm not clear, from what you are saying, how 
Mac browsers get navigator.appName to return 'Safari' or similar. WebCore 
has a hardcoded return value of "Netscape" in NavigatorBase.cpp. I don't 
believe it's currently possible to override that from the API for any 
client. If it is, then that's what I want to find out how to do!

> If you're wanting to manipulate the DOM that is purely a matter of
> having a DOM binding for Qt 

I believe I'd have to manipulate the evaluated javascript if I was 
manipulating the DOM, and that would be extremely hard to get right.

> or just getting the js global object and
> using the standard JSC APIs to manipulate it.
>

I have a very poor understanding of how I could use the JSC APIs to 
manipulate the js globalobject. From looking at backtraces I can't see 
where any value I might set for a js object in the globalobject would 
prevent a call to the hardcoded values in navigatorbase.cpp, for example.

Do you have any pointers to code in webkit that could help me understand 
your suggestion better?


> --Oliver
>
> On Sep 21, 2009, at 10:58 AM, Robert Hogan wrote:
> > Hi there,
> >
> > At the moment WebKit does not deliberately expose any of the
> > properties of
> > Javascript objects to clients. Those it does expose seem to be as
> > much by
> > luck as anything else. One example is navigator.useragent, which in
> > Qt's
> > case ultimately returns whatever the client has set in
> > userAgentForUrl().
> >
> > The more common case is illustrated by the other properties of the
> > navigator object. Here is the return value for navigator.appname as
> > defined
> > in NavigatorBase.cpp:
> >
> > String NavigatorBase::appName() const
> > {
> >    return "Netscape";
> > }
> >
> > I would like to make it possible for the client to control the values
> > returned by JS objects - this is so that my project (http://
> > torora.net) can
> > ensure that the anonymity set of torora's users is properly
> > preserved. For
> > example, Torora would always ensure that the value returned for
> > navigator.platform would be 'WinXP' (regardless of the user's actual
> > OS).
> > This would protect the user from a website collating information on
> > a user
> > and possibly uniquely identifying them.[1]
> >
> > The only way I can think of providing this API is as follows (taking
> > the
> > navigator object as an example):
> >
> > 1. Copy WebCore/page/Navigator.cpp to WebCore/page/qt/
> > NavigatorQt.cpp and
> > exclude Navigator.cpp from the Qt build.
> >
> > 2. In NavigatorQt.cpp implement the return values by calling virtual
> > functions in QWebPage. Following the example of userAgentForUrl() this
> > would take the form of:
> >
> > String NavigatorBase::appName() const
> > {
> >     String appName =  m_frame->loader()->appName();
> >     if (appName.isEmpty())
> >        return NavigatorBase::appName();
> >     return appName;
> > }
> >
> > which calls:
> >
> > String FrameLoaderClientQt::appName()
> > {
> >    if (m_webFrame) {
> >        return m_webFrame->page()->appName();
> >    }
> >    return String();
> > }
> >
> > where page()->AppName() is a virtual function in QWebPage that
> > returns an
> > empty string if it is not reimplemented by the client.
> >
> > 3. NavigatorQt.cpp would have to do this for all elements of the
> > navigator
> > object that it wanted to offer for client control.
> >
> > The same approach would have to be used for the date, screen and
> > window
> > objects, though in the case of Torora there are other ways of ensuring
> > those values do not give away anything so my only actual requirement
> > at the
> > moment is to control the navigator object,
> >
> > I see a couple of disadvantages to this approach:
> >
> > 1. Likely performance hit.
> > 2. Customized implementations of functions in the qt/ folder of the
> > WebCore/page directory are for functions not implemented at all in
> > the base
> > code, rather than for replacing the ones that are.
> > 3. It's a very cumbersome way of doing things.
> >
> > A proper hooking mechanism (where clients could control all javascript
> > objects) for javascript would seem to require a major overhaul to
> > webcore/javascriptcore, and I have no idea how it would work or even
> > if it
> > would be possible.
> >
> > So my questions are:
> >
> > - Is the above approach acceptable for QtWebKit?
> > - Is there any effort already underway for a hooking mechanism for
> > jscore?
> > - Is there an alternative approach anyone can think of?
> >
> > [1] Torora already does this by providing a patch to webkit when
> > building
> > from source. The patch crudely overrides existing values with a
> > 'safe' set
> > of hardcoded values.
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev