[whatwg] Inline Web Worker

I believe it's a security feature.

Imagine that you download foo.html into your C:/ - according to the logic
below, script running in foo.html should be able to read *any file on your
C:/ drive*. That seems scary to me.

FWIW, chrome allows passing the --allow-file-access-from-files command line
flag to make it easier for developers to work locally without running an
HTTP server.

-atw

On Sat, Oct 16, 2010 at 8:19 AM, Samuel Ytterbrink <samuel at ytterbrink.nu>wrote:

> Good news. :D
>
> But then i got another problem, why is not
> "file:///some_directory_where_the_html_are/" not the same domain as
> "file:///some_directory_where_the_html_are/child_directory_with_ajax_stuff/".
> I understand if it was not okay to go closer to root when ajax,
> "file:///where_all_secrete_stuff_are/" or "/../../".
>
> You see i wonder why i need a web-server to try some things. And I'm sure
> that there are more developers than me that thinks that local single page
> Ajaxs applications have a  future. One thing that could probably solve this
> is if the File API will support folders. Then the user could select the
> files for the program...
>
> /Samuel Ytterbrink
>
> 2010/10/16 Simon Pieters <simonp at opera.com>
>
> On Sat, 16 Oct 2010 03:12:38 +0200, Jonas Sicking <jonas at sicking.cc>
>> wrote:
>>
>>  Allowing both blob URLs and data URLs for workers sounds like a great
>>> idea.
>>>
>>
>> FWIW, Opera supports data URLs for Worker (but not SharedWorker since it
>> could be used to cross the same-origin policy if two pages opened a
>> SharedWorker with the same data URL -- this could be solved while still
>> supporting data URLs but we decided to just drop it for now).
>>
>> --
>> Simon Pieters
>> Opera Software
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101018/21d90227/attachment.htm>

Received on Monday, 18 October 2010 11:28:15 UTC