Opening cross origin windows from a ServiceWorker

58 views
Skip to first unread message

Mounir Lamouri

unread,
Mar 3, 2015, 9:11:29 AM3/3/15
to blin...@chromium.org
(This can be seen as an intent to implement and ship but the goal is to
have a discussion so I am using a different form on purpose.)

Hi blink-dev,

tl;dr - are you okay with cross origin windows being opened from a
service worker?

As you know, Blink is now shipping some new ServiceWorker client
features. Among them, Clients.openWindow() which allows a ServiceWorker
to open a new window. Obviously, that call is only possible with some
user interaction. In the case of ServiceWorker, it means a Notification
click.

The version of Clients.openWindow() in Blink is currently limited to
same origin policy. The reasons being that a conservative approach was
easier to get trough and iterate on. Now that we have shipped that
version, I would be interested to remove that artificial limitation and
allow Clients.openWindow() to open cross origin windows.

The use case for opening cross origin windows is quite simple. For
example, a news aggregation website might want to send push messages for
breaking news but instead of sending the users to its own origin, it
would be more efficient to send them directly to the article. This use
case can already be implemented via redirects today, making the same
origin limitation weaker.

I think the main concern regarding cross origin windows is that it might
be harder for the user to link the notification with the website that
created it if the notification opens a window in another origin.
However, as said above, this can already be done with redirects and only
make developers' life harder to achieve the same goal. Unless we plan to
make redirects not work or less transparent, it might not make much
sense to not allow cross origin windows.

Allowing cross origin windows will obviously require more checks to make
sure no sensitive URLs are opened and given that the code path is
slightly different from window.open() it will not come for free. Those
are implementation details and probably out of scope for this
discussion.

-- Mounir

Jochen Eisinger

unread,
Mar 3, 2015, 9:21:20 AM3/3/15
to Mounir Lamouri, blin...@chromium.org
Just to clarify, the main point here is that a service worker can open a tab in any domain even when no tab is currently controlled by the service worker, however, only in response to the user clicking on a notification from that service worker, right?

Jochen Eisinger

unread,
Mar 3, 2015, 3:24:36 PM3/3/15
to Mounir Lamouri, blin...@chromium.org, fe...@chromium.org
+Adrienne Porter Felt for input on security ux

Mounir Lamouri

unread,
Mar 4, 2015, 11:50:42 AM3/4/15
to Jochen Eisinger, blin...@chromium.org
On Tue, 3 Mar 2015, at 14:21, Jochen Eisinger wrote:
> Just to clarify, the main point here is that a service worker can open a
> tab in any domain even when no tab is currently controlled by the service
> worker, however, only in response to the user clicking on a notification
> from that service worker, right?

Correct. Sorry if I wasn't clear.

-- Mounir

Adrienne Porter Felt

unread,
Mar 4, 2015, 5:29:30 PM3/4/15
to Jochen Eisinger, Mounir Lamouri, blink-dev, Joel Weinberger
+jww as well

I talked about this with Jochen earlier today. Given that redirects can cause this same behavior anyway, and I don't think we should start preventing redirects, I am fine with lifting the same origin restriction. By this same logic I don't think the target needs to be restricted to HTTPS either (jww, thoughts?).
Reply all
Reply to author
Forward
0 new messages