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

Robert Hogan lists at roberthogan.net
Mon Sep 21 10:58:27 PDT 2009


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.



More information about the webkit-dev mailing list