You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has come to our attention that none of the 3 manor browser engines block insecure iframes on websites hosted on localhost. While this was reported as a private security bug, we have decided to talk about this in public because all browsers behave the same. Firstly, because the impact is relatively low and secondly to foster better conversations. (We are working on making the above report public).
The test case is as simple as putting http://example.com in an <iframe> on a page hosted at localhost.
As per the [spec section §4.3 "Does settings prohibig mixed security contexts?"], mixed-content should kick in is based off of whether an origin is potentially trustworthy, which http://localhost definitely is.
We have prototyped a patch in Gecko but do not want to make a unilateral change without cross-browser alignment.
I can see these options:
Admit that all browsers behave the same and write it into the standard.
Agree on this being fixed across multiple browsers and collaborate.
Fix this but provide some sort of opt-out e.g. in DevTools.
For a while at least we thought we had the invariant that when a document was a secure context, all documents nested inside of it were a secure context too.
I believe that invariant got broken at some point, but I cannot find any evidence right now. In particular I thought data: URLs might break it, but they don't.
This would break it however. If this is truly the only exception, that would be rather unfortunate.
I agree with @annevk from a theoretical perspective.
Practically, my guess (in the complete absence of data) is that we'll find that a larger-than-desirable percentage of pages loaded from loopback would violate this constraint. I can add a metric to Blink to see how wrong that guess is, but I'd like to make a decision here with that number in hand rather than in the abstract.
It has come to our attention that none of the 3 manor browser engines block insecure iframes on websites hosted on
localhost
. While this was reported as a private security bug, we have decided to talk about this in public because all browsers behave the same. Firstly, because the impact is relatively low and secondly to foster better conversations. (We are working on making the above report public).The test case is as simple as putting
http://example.com
in an<iframe>
on a page hosted atlocalhost
.As per the [spec section §4.3 "Does settings prohibig mixed security contexts?"], mixed-content should kick in is based off of whether an origin is potentially trustworthy, which http://localhost definitely is.
We have prototyped a patch in Gecko but do not want to make a unilateral change without cross-browser alignment.
I can see these options:
CC @estark37, @annevk, @dveditz
(Edit: Credit belongs to Khiem Tran)
The text was updated successfully, but these errors were encountered: