Some parts of changes are due to the File API work I have worked on. On Fri, Sep 3, 2010 at 2:50 PM, Adam Barth <abarth@webkit.org> wrote:

I was looking at SecurityOrigin.cpp today and I saw a bunch of code relating to Blob URLs. I don't really understand why this code is correct. Would someone be willing to explain it to me?

Some specific questions:

1) Why do blob URLs get exception from the unique origin check? How does that interact with the HTML5 sandboxing model?

The origin of blob URL is said to be the origin of the page under which the blob URL is created. It is encoded as part of the blob URL: blob:encoded_origin/id. We're not ignoring any security origin checks. Instead, we need to pull the encoded origin out of the blob URL and use it as the base for the origin check. The reason that we skip the unique origin check here is to allow a local running worker script to be able to access a blob URL. Do we want to disallow this case? If there is a security reason for doing this, I can go ahead to revert this part of change.

2) Why does SecurityOrigin::canLoad take a document as an argument? What are the semantics of this parameter? In particular, why does a SecurityOrigin::canLoad ignore |this| when called with a document argument on a blob URL? That seems like a very bad idea.

SecurityOrigin::canLoad is a static method. Does it have |this| to use?

In general, I'd prefer if folks checked with Sam or me before adding loopholes in SecurityOrigin. Although the class might appear simple, it's quite subtle.

Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev