Re: Access to localhost to be outlawed?

I understand the security concern but I feel the exception proposed in #32
should be valid, i.e.:

1. DNS alias to localhost
2. Valid SSL certificate for FQDN
3. Secure websocket server on localhost

Saying that a CA shouldn't be issuing a certificate for a FQDN that
resolves to 127.0.0.1 isn't really an answer is it?
(Especially when a later comment suggests that the CA that issued
dropboxlocalhost.com has verified that Dropbox have met the Baseline
requirements to get the cert).

A thought:
What if I have a web app at the FQDN www.myap.com and I setup the FQDN
localhost.myapp.com to resolve to 127.0.0.1 and both certificates are
signed by some common intermediary certificate or better yet use the same
certificate on both hosts which is either a widcard cert or is issued with
localhost.myapp.com as an alternate name?

Surely the browser can be confident that the local service and the webapp
can trust one another?

Are we getting to a point where the browser itself will need to listen on
some port for connections and service an API for native applications to
call directly into the browser?

I don't see how github, dorpbox, plex or any of the other major webapps
using this will find workarounds if this is disabled.
It definitely throws a spanner in the plans for a payments agent

On 17 March 2015 at 17:33, Randall Leeds <randall.leeds@gmail.com> wrote:

> Thanks. I understand the issue better now.
>
> On Tue, Mar 17, 2015, 11:07 Anders Rundgren <anders.rundgren.net@gmail.com>
> wrote:
>
>> On 2015-03-17 15:57, Randall Leeds wrote:
>> > I'm not sure I agree. The discussion seems to talk about user-initiated
>> actions in a way
>>  > that makes me think that clicking a link or button or otherwise taking
>> some action
>>  > that causes a subresource to be loaded from localhost is fine. What is
>> not fine is unsolicited attempts to access the local network.
>> >
>> > Are you sure this presents a problem for you?
>>
>> There's obviously something wrong when services like DropBox must issue
>> server-certificates
>> (mixing http/https is being outlawed) pointing to 127.0.0.1:
>> https://code.google.com/p/chromium/issues/detail?id=378566#c29
>>
>> The security folks may have gotten what they wanted, the market certainly
>> did not.
>>
>> There are no agreements between the browser-vendors on these topics
>> either.
>>
>> Anders
>>
>> >
>> > On Tue, Mar 17, 2015 at 7:53 AM Melvin Carvalho <
>> melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>> >
>> >     On 17 March 2015 at 15:48, Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>> >
>> >         On 2015-03-17 15:14, Randall Leeds wrote:
>> >
>> >             What's this got to do with payments? What do DropBox and
>> Spotify depend on that's relevant here?
>> >
>> >
>> >         DropBox and Spotify depend on browser bypass schemes using
>> localhost.
>> >
>> >         Payments may do that as well as David Nicol writes here:
>> >         https://lists.w3.org/Archives/__Public/public-webpayments/__
>> 2014Oct/0194.html <https://lists.w3.org/Archives/Public/public-
>> webpayments/2014Oct/0194.html>
>> >
>> >         GitHub use another browser bypass scheme:
>> >         github-windows://openRepo/http__s://github.com/
>> cyberphone/__webpkisuite-4-android <https://github.com/
>> cyberphone/webpkisuite-4-android>
>> >
>> >
>> >     Yes, I also use localhost for payments from the browser.
>> >
>> >     Added my +1 to the call for WONTFIX on this issue.
>> >
>> >     I locking down the browser in this way will hinder a lot of
>> legitimate use cases, and provide minimal incremental security.
>> >
>> >
>> >         Anders
>> >
>> >
>> >             On Tue, Mar 17, 2015 at 12:10 AM Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>
>> <mailto:anders.rundgren.net@__gmail.com <mailto:anders.rundgren.net@
>> gmail.com>>> wrote:
>> >
>> >             https://code.google.com/p/____
>> chromium/issues/detail?id=____378566 <https://code.google.com/p/__
>> chromium/issues/detail?id=__378566> <https://code.google.com/p/__
>> chromium/issues/detail?id=__378566 <https://code.google.com/p/
>> chromium/issues/detail?id=378566>>
>> >
>> >                  Since popular services like DropBox and Spotify depend
>> on this non-standardized
>> >                  way of bypassing the browser, I think this strengthens
>> my argument that we really
>> >                  need a standard way to do this.
>> >
>> >                  The time for that is now.
>> >
>> >                  Anders
>> >
>> >
>> >
>>
>>