[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

Dustin Nielson <dustin.nielson at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dustin.nielson at gmail.com

--- Comment #69 from Dustin Nielson <dustin.nielson at gmail.com> ---
These are just a few comments and observations about this bug.

First there have been several discussions about localhost vs loopback that are outside the scope of this bug so let’s just not address that issue here as it’s going to involve OS level changes before the level of validation comes to the level that it can be trusted to be the exact same as loopback.

The actual bug:

Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content

I think a more appropriate description would be something like:

“Safari mixed content handling does not comply with web specifications. “ 

As this more closely describes the actual issue and in my opinion is a critical bug as any change that doesn’t follow specifications is potentially a breaking bug as in this case.

There is talk of needing to put restrictions in place before this fix can be implemented.  I’m here to argue that fixes for this should not be a Safari specific implementation as it does not solve the potentially described problems for any other browser.  My recommendation is those types of changes should be addressed at the application level with entitlements etc… So the fix is universal in nature and solves any potential issues for all browsers.

Lastly let's examine the goal that the changed behaviour from spec was trying to address which was to potentially increase security.

The actual outcome of this implementation is that web sites are having to recommend using essentially any other browser other than Safari and most likely posting something like this on the page:

“We see you’re trying to access this page from Safari.  Unfortunately Safari is currently out of web specifications and has limited our ability to support Safari.  Please download (list of any other browser) to use this site as intended.”

Leading the user to use another browser and bypassing the intended goal this bug was trying to resolve and bypassing all the other great features that Safari does support.

This has led to references of Safari being the Internet Explorer of the modern age.  In fact Internet Explorer extended web specifications and didn’t break them.  It just added proprietary functionality that when implemented by web sites broke other browsers from being able to access the site but allowed I.E. to render (for the most part) any web spec compliant web site.

I would love to see this bug resolved asap as I’m close to releasing an application that requires this functionality and I’d much rather push people to upgrade outdated Safari to one that has become spec compliant again vs telling my users they need to just use another browser.

-- 
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/20200611/3a24a89e/attachment.htm>