[webkit-dev] Allowing webkit clients to extend XHR security policy

[Aaron Boodman]

Hello all,

I'm working on adding extensions (aka "Add-Ons") to Chromium. One
thing we want to enable these extensions to do is to make limited
cross-origin XMLHttpRequests.

Rafael Weinstein, who is working with me, consulted with Adam Barth
and submitted a patch based on his ideas
<https://bugs.webkit.org/show_bug.cgi?id=24853> for this a few weeks
back. It has met with resistance though, and we're not really sure
where to go next.

So I wanted to back up, explain what we're trying to do at a high
level and get suggestions for the best way to implement this.


The Goal:

We want extension developers to be able to access multiple origins,
but for them to have to declare those origins ahead of time. The
origins would be declared using a pattern syntax, something like
'http://*.google.com'. Having to declare the origins ahead of time
reduces the damage a compromised extension can do because it can only
be used to access a subset of origins. Most use cases we envision
really only need to access a few origins, so this would be a big win
for us. This also seems like this is something that could be generally
useful for other webkit clients. I can imagine browsers wanting to
offer increased privilege modes to web apps, and then wanting to do
similar restrictions on access to cross-origin XHR.


Ideas:

1) A static call out of WebKit to a client from SecurityOrigin. This
is the current patch. A few problems people have brought up with it:

* Some people don't like the idea that the callback gets invoked on
multiple threads.
* some people think it's ugly to have SecurityOrigin making calls out
to static methods and think it should have a normal instance client.

2) Non-static SecurityOriginClient. I suggested this in the last
comment on the bug. The creator of a SecurityOrigin would have the
option to set a client which it could retrieve from FrameLoaderClient
(or some other client?). This doesn't solve the problem of getting
callbacks on multiple threads, but we could skip implementing it for
workers and when the refactor to move origin checking for workers to
the UI thread happens, it will automatically start working.

3) Something more specific to XMLHttpRequest. Since we're really only
interested in modifying the behavior of XMLHttpRequest, it might be
nicer to do something more targetted than SecurityOrigin. I was hoping
that I could add a method to FrameLoaderClient and call it from XHR,
but I don't see a nice way to get to FrameLoaderClient from XHR.

4) Refactor all access checking (current same-origin checks, "local
scheme" stuff, preflight stuff for AC) into DocumentThreadableLoader.
Then add a new callback for what we want on FrameLoaderClient. One
meta-question I have about this approach is whether it's really the
right thing to do XHR-specific access checks in
DocumentThreadableLoader and friends. In general, I'd rather not
embark on a big refactor to get this done, but I'm still open to it if
that's the only option.

That's about all the ideas I've come up with. Are any of them
appealing? Is there some other approach that would be better? I think
we can also do this outside of WebCore with some hacking, but I'd
rather avoid that and contribute some useful code to WebKit at the
same time if possible.


- a