Open Bug 1321158 Opened 8 years ago Updated 2 years ago

Investigate if window.open() inheriting firstPartyDomain resolves breakage

Categories

(Core :: DOM: Security, defect, P5)

Product:
Core
Component:
DOM: Security
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox53 --- affected

People

(Reporter: allstars.chh, Unassigned)

References

(Blocks 1 open bug)

Details

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

No description provided.
See smaug's comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1315602#c15.
Blocks: FirstPartyIsolation
Summary: Should window.open() inherit firstParty → Should window.open() inherit firstPartyDomain?
Whiteboard: [tor][domsecurity-backlog1]
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.
Assignee: nobody → allstars.chh
Priority: -- → P3
P1 to investigate and then re-triage.
Priority: P3 → P1
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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.