>> > 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?
>>
>> The access rights of locally running content are controlled by a
>> WebCore::Setting. Currently, Chrome sets that setting to the most
>> restrictive value to mitigate the harm a downloaded HTML file can
>> cause. It doesn't seem like a good idea to circumvent that security
>> setting.
>
> Ok, this sounds right. It means that we should not allow accessing a blob
> URL from a local worker script per the settings, right? If so, I can get
> rid of this particular step.
Yes, great.
>> I don't quite understand what this code is trying to do:
>>
>> bool SecurityOrigin::canLoad(const KURL& url, const String& referrer,
>> Document* document)
>> {
>> #if ENABLE(BLOB)
>> if (url.protocolIs("blob") && document) {
>> SecurityOrigin* documentOrigin = document->securityOrigin();
>> RefPtr<SecurityOrigin> targetOrigin = SecurityOrigin::create(url);
>> return documentOrigin->isSameSchemeHostPort(targetOrigin.get());
>> }
>> #endif
>>
>> Why should canLoad care about isSameSchemeHostPort? In the past,
>> canLoad's job was to stop web sites from loading content from your
>> local file system (e.g., in frames or as images).
>
> Per the File API spec, the blob URL should not be accessed from the page in
> other security domain. Checking isSameSchemeHostPort will help us enforce
> this policy when other page in different domain that tries to load this URL
> from the cache. Probably I need to put better comment here or maybe find a
> better place to do such check.
Sorry canLoad is poorly named. I'm working on a patch now to rename
it to something more sensible (canDisplay, perhaps?). We use canLoad
to control things like <frame src="..."> and <img src="...">. When
you say "not accessible," do you mean that they shouldn't be able to
be displayed with the image element?
Yes. Let me use an example to explain this.
Suppose page1 (
http://foo/page1) creates a blob URL "blob://id1" from an image file. In page1, blob://id1 is loaded and put into cache when we replace any img element. In page2 (
http://bar/page2), it grabs this blob URL in some way and uses it towards its img element. We should not allow this happen per the File API spec. Without this check in canLoad(), page2 has no problem to use it directly from the cache.