WebChannel doesn't work in a container tab

REOPENED
Unassigned

Status

()

Core
DOM: Security
P3
normal
REOPENED
a year ago
7 months ago

People

(Reporter: hectorz, Unassigned)

Tracking

(Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox53 affected, firefox57 fix-optional)

Details

(Whiteboard: [domsecurity-backlog2][OA][userContextId][tor])

(Reporter)

Description

a year ago
Try using WebChannel from within a container tab will throw an error:

> {webChannelId} error message. No Such Channel

This is because when using origin as originOrPermission when creating a WebChannel, `_originCheckCallback` will check `{allowedOrigin}.prePath === requestPrincipal.origin` to find a matching WebChannel[1];

Since a) another check for WebChannel already uses `originNoSuffix`[2] and b) `userContextId` are ignored when matching permissions[3], I think it might be okay to just use `requestPrincipal.originNoSuffix` here?

[1]: https://dxr.mozilla.org/mozilla-central/rev/0534254e9a40/toolkit/modules/WebChannel.jsm#184
[2]: https://hg.mozilla.org/mozilla-central/rev/af0f02e07f6a#l21.53
[3]: https://hg.mozilla.org/mozilla-central/rev/299a09f24493

Updated

a year ago
Component: General → DOM: Security
Product: Firefox → Core
Ethan, is this also an issue for Tor?
Flags: needinfo?(etseng)
Priority: -- → P1
Whiteboard: [domsecurity-active][OA][userContextId][tor]
That's not Ethan's email, let's change to right one(ettseng@mozilla.com).
Flags: needinfo?(etseng) → needinfo?(ettseng)
(Reporter)

Comment 3

a year ago
Dupe of bug 1319904, which was already fixed.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1319904
I'm not sure this is a duplicate.  Reopening for now and we can decide after further investigation.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to Tanvi Vyas [:tanvi] from comment #1)
> Ethan, is this also an issue for Tor?

I went through comments in bug 1319904.
It looks to me this is a general Origin Attributes issue that has to be fixed in WebChannel.
So yes, I assume it also affects Tor First Party Isolation.

Arthur, can you help to confirm this?
Flags: needinfo?(ettseng) → needinfo?(arthuredelstein)
(In reply to Ethan Tseng [:ethan] from comment #5)
> (In reply to Tanvi Vyas [:tanvi] from comment #1)
> > Ethan, is this also an issue for Tor?
> 
> I went through comments in bug 1319904.
> It looks to me this is a general Origin Attributes issue that has to be
> fixed in WebChannel.
> So yes, I assume it also affects Tor First Party Isolation.
> 
> Arthur, can you help to confirm this?

Sorry for the delay -- yes, it looks to me like the issue affects first-party isolation as a part of originAttributes. As far as I can tell, the patch in bug 1319904 should solve the problem for first-party isolation as well.
Flags: needinfo?(arthuredelstein)
Bug 1319904 makes WebChannel NOT isolated by Origin Attributes.
Set it as blocking First Party Isolation for tracking.
Blocks: 1299996
Tanvi, this is was marked as a P1, got closed and reopened? Do we need to set a new priority? Potentially we need to find an owner for this one! Can you have a look please?
Flags: needinfo?(tanvi)
(In reply to Tanvi Vyas - behind on bugmail [:tanvi] from comment #7)
> Bug 1319904 makes WebChannel NOT isolated by Origin Attributes.

You're absolutely right. Sorry for my mistake. Indeed this looks like we need to implement a fix for first party isolation.
As discussed in the meeting, this bug is low priority but nice to have.
Priority: P1 → P3
Whiteboard: [domsecurity-active][OA][userContextId][tor] → [domsecurity-backlog][OA][userContextId][tor]
(In reply to Ethan Tseng [:ethan] from comment #11)
> As discussed in the meeting, this bug is low priority but nice to have.

Clearing my ni? queue at the moment. Thanks Ethan for de-prioritizing this work in comment 11. Clearing the ni? for Tanvi in that case.
Flags: needinfo?(tanvi)
Whiteboard: [domsecurity-backlog][OA][userContextId][tor] → [domsecurity-backlog2][OA][userContextId][tor]
You need to log in before you can comment on or make changes to this bug.