[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

Irakli Gozalishvili <contact at gozala.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |contact at gozala.io

--- Comment #34 from Irakli Gozalishvili <contact at gozala.io> ---
(In reply to Alexey Proskuryakov from comment #25)
> I actually think that getting users trust a certificate is better for
> multiple reasons.
> 
> 1. It greatly reduces the impacted group, and makes it a less interesting
> target.
> 
> 2. It requires doing something that would be a deterrent to proceeding,
> which is good. One may decide to limit the hack to a VM, or use a less
> secure secondary browser just for this purpose, or make the vendor change
> their approach, or decide to not work with this vendor at all. All of those
> are better for security.
> 
> > I can partially agree on this but there should be an alternative.
> 
> I'm not sure why you are insisting that a web browser ever needs to talk to
> locally installed software and hardware at all. This is low benefit and high
> risk.
> 
> If we had to provide an opt-in, I would argue that it should be implemented
> in a way that discourages its use. Installing a trusted certificate doesn't
> sound so bad. Another alternative could be a Developer menu option that
> allows 127.0.0.1 access just for the currently open window. Or maybe one can
> take a clue from how NPAPI plug-ins are handled by each browser.
> 
> > If you have a concrete plan to start blocking all localhost content in the near future, then obviously this should be WONTFIX.
> 
> Good point, let's make it concrete in bug 186039.


Hi Alexey,

This thread got pretty toxic, threats of recommending other browsers is definitely not helping in driving arguments. I also understand your point that  allowing websites to talk to programs on the device does create additional security risks. However I would like to make an argument that not allowing them to talk to loopaback addresses does in fact create larger security risks:

Matter of the fact is that today due to this restriction applications are forced to do something that is much worse. They create DNS records like `local.myapp 127.0.0.1` and bundle TLS certificate + keys with an application.

Note that this does not require installing a trusted certificate root as you mentioned in the comment.


Additionally you could consider doing something along the lines of `document.requestStorageAccess` say `document.requestLoopbackAccess` and provide similar user consent prompt
https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/

Where instead of prompting user to give explicit access to site A when browsing site B, rephrase site A to "application A".

-- 
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/20190118/9ebd08d7/attachment.html>