Investigate if window.open() inheriting firstPartyDomain resolves breakage

NEW
Unassigned

Status

()

Core
DOM: Security
P5
normal
2 years ago
4 months ago

People

(Reporter: allstars, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox53 affected)

Details

(Whiteboard: [tor][domsecurity-backlog1])

Comment hidden (empty)
See smaug's comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1315602#c15.
Blocks: 1299996
Summary: Should window.open() inherit firstParty → Should window.open() inherit firstPartyDomain?
Whiteboard: [tor][domsecurity-backlog1]

Comment 2

2 years ago
The reason for my comment was that it might simplify the setup a bit. It would be guaranteed that top level content docshell has empty fpd always. Easier to assert random things and such.
(Reporter)

Updated

a year ago
Assignee: nobody → allstars.chh
Priority: -- → P3

Comment 3

4 months ago
P1 to investigate and then re-triage.
Priority: P3 → P1

Updated

4 months ago
See Also: → bug 1425287

Comment 4

4 months ago
We don't want window.open to inherit the first party domain. That's be confusing to users (Why is this gmail tab not logged in? How come when I login to it, but then type gmail.com in a new tab I'm still not logged in?) and would allow the window.open-ed domain and the opening domain to share state as well as communicate. (Communication is only possible if restrict_opener_access is off though.)

It would be interesting to know; however, if relaxing this would solve some of the breakage situations. If it did, I still don't think we should relax it, but at least we would understand better why things break and how to recommend changes.
Assignee: allstars.chh → nobody
Priority: P1 → P5
Summary: Should window.open() inherit firstPartyDomain? → Investigate if window.open() inheriting firstPartyDomain resolves breakage
You need to log in before you can comment on or make changes to this bug.