Intent to implement and ship: construcing workers with 'data:' URLs

[Andy Paicu]

Contact emails

andy...@google.com, mk...@chromium.org

Spec

https://html.spec.whatwg.org/multipage/workers.html#dom-worker

Summary

Change to allow constructing workers with 'data:' URLs, that is:

new Worker('data:application/javascript,self.postMessage("Msg")');

Motivation

HTML specifies that `data:` URLs can be used to create workers with opaque origins. We should support this as a first step towards defining a sandboxing mechanism for Workers (and parity with other browsers).

Interoperability and Compatibility Risk

Edge: No signals

Firefox: Shipped

Safari: No signals

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=270979

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5633342665916416

Requesting approval to ship?

Yes

Andy Paicu

Software Engineer

andy...@google.com
+49 8983 9309409

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Jochen Eisinger]

still lgtm1 :)

[PhistucK]

By the way, why was it not supported up until now? Due to a security decision? Was it reversed and if so, why is it suddenly fine?

Will the underlying conceptual difference (data URL is not in the same origin of the calling origin) be amended across the engine?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike West]

On Thu, Feb 9, 2017 at 10:51 AM, PhistucK <phis...@gmail.com> wrote:

By the way, why was it not supported up until now? Due to a security decision? Was it reversed and if so, why is it suddenly fine?

In the distant past, WebKit blocked cross-origin Workers, and considered `data:` to be a cross-origin URL. In that same distant past, Firefox blocked cross-origin Workers, but considered `data:` to be a same-origin URL. This was somewhat confusing.

After a good deal of discussion, we decided to agree that `data:` was a cross-origin URL: see https://github.com/whatwg/html/issues/1753 and some related patches. We also decided to agree that a Worker with an opaque origin was actually a pretty useful concept, and we'll probably want to come up with a way of doing that explicitly, even for Workers created from URLs without unique origins. Supporting `data:` URLs is a first step in that direction that will allow us to work out what needs to change in our worker implementation if we no longer assume that everything is same-origin.

 

Will the underlying conceptual difference (data URL is not in the same origin of the calling origin) be amended across the engine?

The goal is for the created worker to have an opaque origin, yes.

-mike

[Marijn Kruisselbrink]

Interoperability and Compatibility Risk

Edge: No signals

Firefox: Shipped

Safari: No signals

The intent-to-ship template asks you to point to any web-platform tests for the change, or to explain why there aren't any. Are there any such tests yet, and/or are you planning on writing any?

[Philip Jägenstedt]

I think that https://github.com/w3c/web-platform-tests/pull/3943 covers this:

http://w3c-test.org/workers/data-url.html

http://w3c-test.org/workers/data-url-shared.html

LGTM2, and if those aren't the right tests please make sure it is well covered in web-platform-tests :)

[Chris Harrelson]

LGTM3

[Kinuko Yasuda]

Non-owner LGTM, but I think you'd better file a new bug for this one, the one linked from the intent looks a bit irrelevant for tracking the launch.

https://bugs.chromium.org/p/chromium/issues/detail?id=270979

[Victor Costan]

Is there any interest in being able to do something similar with Blobs? I'm thinking specifically of an easy way to mint Blob URLs with opaque origins. This came to my mind because it seems to me that getting a Blob and creating a URL out of it would be more elegant than URL-encoding a JS file for inclusion in a data: URL.

Thank you,

    Victor

[Jochen Eisinger]

it's already possible to create a worker from a blob

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Victor Costan]

Wouldn't the worker have the Blob's origin though?

    Victor

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Marijn Kruisselbrink]

Blob URLs with unique opaque origins wouldn't be particularly useful, since blob URLs can only be fetched via same origin fetches. But it sounds like a more generic sandboxing mechanism for workers is something people are thinking about, which presumably would allow you to sandbox a worker created via a blob URL, or any other same origin URL as well?

[Anne van Kesteren]

On Fri, Feb 10, 2017 at 6:50 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:
> Blob URLs with unique opaque origins wouldn't be particularly useful, since
> blob URLs can only be fetched via same origin fetches. But it sounds like a
> more generic sandboxing mechanism for workers is something people are
> thinking about, which presumably would allow you to sandbox a worker created
> via a blob URL, or any other same origin URL as well?

Yeah. (Though no concrete or even vague proposal has been made thus
far. Step 1 is getting data URLs consistent across browsers.)


--
https://annevankesteren.nl/