firstPartyDomain shouldn't be propagated to mozbrowser frame

NEW
Unassigned

Status

()

Core
DOM: Security
P3
normal
2 years ago
8 months ago

People

(Reporter: allstars, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox57 fix-optional)

Details

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

<smaug> allstarschh: you have document A and if it has <iframe mozbrowser> and iframe's has then document B. I _think_ we don't want to inherit firstPartyDomain to document B
<smaug> so, A and B might have different firstPartyDomains
<smaug> in other words, <iframe mozbrowser> would be handled as if the iframe was a <xul:browser type=content> in a chrome document
<smaug> allstarschh: makes sense ? :)
<allstarschh> smaug: so if B has an iframe C, will it get firstPartyDomain from B?
<smaug> yes


document A
  +-----  mozbrowser B
      +---- iframe C

A, B and C are documents, not docshells.

A will have its own firstPartyDomain from domain(A), however this won't be propagated to B.
B will also have its own firstPartyDomain from domain(B), and this domain(B) will be propagated to C.


So we should have a test for verify this.

I think this is not tor-related bug so didn't set [tor] flag on this.

Comment 1

2 years ago
Does this bug apply to usercontextid and privatebrowsing flag too?
Flags: needinfo?(allstars.chh)
no, should be related to firstPartyDomain, which is also an origin attribute. So I tagged it as [OA].
Flags: needinfo?(allstars.chh)

Updated

2 years ago
Priority: -- → P3
Whiteboard: [OA] → [OA] [domsecurity-backlog1]

Updated

2 years ago
Whiteboard: [OA] [domsecurity-backlog1] → [OA][domsecurity-backlog1][tor]

Updated

2 years ago
Blocks: 1299996
Hi Tanvi
I have problems on understanding these keywords, [tor], [OA]
As I said in Comment 0.

from the etherpad


WHITEBOARD TAGS

    [OA] -- origin attributes bug.  these bugs need to be landed to make origin attributes work.

    [userContextId] -- anything that is required to make containers work.  most of these bugs are also tagged [OA] but the ones that aren't are containers bugs.

    [userContextId-UI] -- this is to distinguish a containers bug that is only UI work.

    [OA-testing] -- any bug that is used to validate that the isolation created by origin attributes is correct.

    [TOR] -- all bugs that are associated with a tor browser patch uplift.

    [TOR-testing] -- bugs that are associated with tor test patches and used to validate that our patch uplift resulted in equivalent functionality. 


I am 100% sure this is NOT a tor browser patch, as they don't use mozBrowser frame.
Why do we tag [tor] on this?
Flags: needinfo?(tanvi)

Comment 4

2 years ago
Hi Yoshi,

I added tor because this bug related to firstpartydomain.  So I assumed it was tor related.  If tor doesn't use mozbrowser, then you are right.  Looking closer at this bug, I see your comment 0 that says don't set tor on this.  Sorry about that and thank you for pointing it out!
Flags: needinfo?(tanvi)
Whiteboard: [OA][domsecurity-backlog1][tor] → [OA][domsecurity-backlog1]

Updated

2 years ago
No longer blocks: 1299996

Updated

8 months ago
status-firefox57: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.