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

[Oliver Hunt]

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.

If you're wanting to manipulate the DOM that is purely a matter of  
having a DOM binding for Qt or just getting the js global object and  
using the standard JSC APIs to manipulate it.

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