[Webkit-unassigned] [Bug 171934] Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=171934

--- Comment #21 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Luca Cipriani from comment #18)
> Hello, Arduino officially speaking here.
> 
> We do have a system that HAS to interact with a local server:
> https://github.com/arduino/arduino-create-agent
> 
> This agent is installed already in a couple hundred thousand devices. Due to
> the blocking of 127.0.0.1 by webkit we are forced to create a Certificate
> Autority for Localhost and install it in the certificate chain, this is much
> worse than just allowing http://127.0.0.1/ (then obviously we remove the CA
> key permanently)

It seems like a pretty good argument in favor of reopening this issue and adopting the Firefox/Chrome behavior. Creating a certificate for 127.0.0.1 is surely worse than the alternative. And there really isn't much value in performing mixed content checks on localhost content.

(In reply to Brent Fulgham from comment #14)
> I do not support this requested change in behavior. Allowing HTTP from
> localhost to be included in a secure page is a terrible idea for a few
> reasons

I'm pretty much satisfied by the responses to this above.

(In reply to Alexey Proskuryakov from comment #20)
> Having web pages access (or enumerate) local devices would have to come with
> a meaningful permission model, which is unlikely to exist. Asking the user
> anything along the lines of "www.arduino.corp.trusted.myphishingpage.cc
> would like to access 127.0.0.1:23764 for an unknown reason with unknown
> consequences, Allow/Block" wouldn't make any security sense.

This makes more sense to me, but the problem is that such access is already allowed from http:// websites, right? Surely mixed content blocking is not the right way to enforce restrictions on accessing local content. Looking at https://bugs.chromium.org/p/chromium/issues/detail?id=607878, it looks like the mixed content spec developers have spent a lot of time thinking about this, including the link to https://mikewest.github.io/cors-rfc1918/ in comment 6.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180523/893a920c/attachment.html>