218980 2020-11-16 05:53:59 -0800 Treat loopback addresses (127.0.0.0/8, ::1/128, localhost, .localhost) as potentially trustworthy URL 2024-10-09 19:10:21 -0700 1 1 1 Unclassified WebKit Page Loading Other Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=254991 https://bugs.webkit.org/show_bug.cgi?id=232088 https://bugs.webkit.org/show_bug.cgi?id=281149 InRadar P2 Normal --- 218623 218627 1 fred.wang webkit-unassigned achristensen beidson gsnedders jfernandez julian.fortune kevin.flanagan lidel me rik smoley webkit-bug-importer youennf oldest_to_newest 1707786 0 fred.wang 2020-11-16 05:53:59 -0800 Preliminary work is done in bug 218623 and bug 218627, but it is including the loopback URLs directly in the definition of "a priori authenticated URL" (https://w3c.github.io/webappsec-mixed-content/#a-priori-authenticated-url) rather than in the one of "potentially trustworthy url" (https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url). This bug is about moving these things around, which might lead to some behavior changes. 1708066 1 webkit-bug-importer 2020-11-16 18:15:56 -0800 <rdar://problem/71468048> 1731474 2 gsnedders 2021-02-19 11:44:42 -0800 https://github.com/WebKit/WebKit/blob/51b6659009f49c33837e1ed10cddbd454315fb44/Source/WebCore/page/SecurityOrigin.cpp#L157 makes it look like we already treat localhost and loopback addresses as potentially trustworthy origins? 1731477 3 fred.wang 2021-02-19 11:48:09 -0800 (In reply to Sam Sneddon [:gsnedders] from comment #2) > https://github.com/WebKit/WebKit/blob/ > 51b6659009f49c33837e1ed10cddbd454315fb44/Source/WebCore/page/SecurityOrigin. > cpp#L157 makes it look like we already treat localhost and loopback > addresses as potentially trustworthy origins? IIRC, these functions are confusing since they are actually not used by MixedContentChecker::isMixedContent. See the patches I attached on bug 218623 and bug 218627 for where we would actually want to plug the new thing. 1731483 4 gsnedders 2021-02-19 11:55:46 -0800 Right, so there's the mixed content case, but also the… not-mixed content (lone content?) case for WebIDL's [SecureContext], for example. Not totally clear what this specific bug is meant to be for, given the title. Using the SecurityOrigin checks more widely? 1731502 5 fred.wang 2021-02-19 12:17:21 -0800 (In reply to Sam Sneddon [:gsnedders] from comment #4) > Right, so there's the mixed content case, but also the… not-mixed content > (lone content?) case for WebIDL's [SecureContext], for example. > > Not totally clear what this specific bug is meant to be for, given the > title. Using the SecurityOrigin checks more widely? Yes, so I think I opened this and other related issues in order to address bug 171934 reported by users, which was specifically about mixed content. I agree that in general it would be good to rely more on this "potentially trustworthy URL" concept when checking whether we are in a secure context. I think this is a bit a mess in browsers & spec currently, the call sites in Chromium are https://github.com/whatwg/html/issues/6369#issuecomment-779212659 1799332 6 gsnedders 2021-10-01 09:15:42 -0700 *** Bug 231035 has been marked as a duplicate of this bug. *** 1822596 7 fred.wang 2021-12-10 02:14:02 -0800 Removing myself from assignee since I'm not working on this anymore. 2007701 8 julian.fortune 2024-01-25 14:36:35 -0800 Got tripped up today by WebKit not accepting cookies with `Secure=true` from localhost, while gecko and chromium accepted them no problem. Would really like to see this fixed, thanks!