[FirstPartyIsolation] <iframe> inside WebExtension page (moz-extension://) does not have access to login and other settings
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: CoolCmd, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fp-triaged][domsecurity-backlog3][dfpi-ok])
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
set privacy.firstparty.isolate=true
open extension page like moz-extension://xxxxxxxx/index.html
this page contains <iframe src=https://example.com/>
Actual results:
the <iframe> does not have access to example.com's cookies and localStorage (firstPartyDomain === "") and thus useless
Expected results:
i have not found workaround for this issue. probably you should make some of exception for browser extensions to allow iframes get access to domain of iframe src attribute?
|
||
Comment 1•5 years ago
|
||
This might be by design? Should framed example.com be "the same" in all extensions?
|
||
Comment 2•5 years ago
|
||
Who knows! We'll talk about it though.
|
|
||
Comment 3•5 years ago
|
||
We talked about it and we think it makes sense to treat the iframe as a first party context. (But we're open to hearing arguments for not doing that too.)
We're tagging this as P3, if anyone can provide examples of particular workflows that are broken we can consider re-prioritizing.
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
(In reply to Tom Ritter [:tjr] (ooto until Jan 6th) from comment #3)
We're tagging this as P3, if anyone can provide examples of particular workflows that are broken we can consider re-prioritizing.
as i said in the bug description, privacy.firstparty.isolate prevents the <iframe> with chat from working in the extension. if privacy.firstparty.isolate=true, then the extension is useless and should be uninstalled.
7 months and so quiet... yes, this extension is not developed by facebook or google, so there will be no workaround for this bug in 2020?
As the addon has not been named in this bug report, it's the "Alternate Player for Twitch.tv" with 20.000 users: https://addons.mozilla.org/en-US/firefox/addon/twitch_5
I don't understand though why you block the whole extension from working instead of just the chat function @CoolCmd
(In reply to spineeye from comment #5)
I don't understand though why you block the whole extension from working instead of just the chat function @CoolCmd
without chat the extension is useless for most people.
ok, if i leave chat in read-only mode, two cases are possible:
-
users will complain why the login does not work. no one read help, unfortunately (see the extension reviews).
-
if
privacy.firstparty.isolatehas just been changed, then old login data will be available in the chat for some time. the user can log in to website with a different account, but the chat will use the old one, and perhaps the user will not know about it. this case is even worse than 1).
i do not have time to support this complicated mess, so i just stop the extension if privacy.firstparty.isolate=true is detected.
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
Those bugs allows to embed <iframe> into browser extension:
https://bugzilla.mozilla.org/show_bug.cgi?id=1629436 (allow cookie)
https://bugzilla.mozilla.org/show_bug.cgi?id=1625599 (turn off tracking protection)
https://bugzilla.mozilla.org/show_bug.cgi?id=1595652 (ignore http header)
As logical continuation, fixing this bug should allow to embed <iframe> when privacy.firstparty.isolate=true.
Description
•