Relax mixed-content for `private -> private`, `private -> local` and `local -> private`

[softworkz]

The explainer states:

Note that private -> private is not a private network request, as well as local -> anything

How is that supposed to work then? Is there a different mechanism?

Thanks

[johnathan79717]

They should work just like public to public requests.

[softworkz]

But this is creating a weird situation!

Assuming I want to access http://192.168.1.10/iot_device_endpoint

Then - with this new mechanism - I will be able to access the above (private network) URL from a public site like https://mysite.com but not from https://localhost or not from https://privatehost.local.

So we'll be forced to serve via http instead, which wouldn't have been a problem in earlier times, but as you are cutting off all new features from http,

It can't be that a publicly served site has more access privileges in my local network than something I'm serving in my local network only...?!

[softworkz]

Can you please re-open?

[johnathan79717]

I don't understand. Why can't you access the above URL from https://localhost or https://privatehost.local? I meant the spec doesn't block any private -> private or local -> anything requests.

[softworkz]

[johnathan79717]

I see your point. Indeed, mixed content would block those requests. It is a little weird that public websites can get around mixed content but private and local can't.

[softworkz]

Thanks for re-opening!

With all the cloud-centric hype these days, it should not be forgotten that the most secure systems are those where no public network communication is happening or required at all, and such solutions must not be disregarded.

[letitz]

Thanks for the feedback! It seems to me we can just remove the assertions that the target IP address space is less public than the client's, both in the spec and in Chromium. Then https://localhost should be able to make requests that bypass mixed content, but only to the private network.

[softworkz]

Sounds good. I've changed the title accordingly.

How about private => local ? Will the implementation be smart enough to detect whether an IP address is a local one? Or does it just look for localhost and 127.0.0.1?

[johnathan79717]

How about private => local ? Will the implementation be smart enough to detect whether an IP address is a local one? Or does it just look for localhost and 127.0.0.1?

https://wicg.github.io/private-network-access/#non-public-ip-address-blocks listed IP address ranges that are considered local.

[softworkz]

Yes, I've read that. But will it work?

Assuming the web site is served from the local network - let's say 192.168.1.99 (www.local) and my machine is 192.168.1.11 (mymachine.local).

So in the browser, I'm opening https://www.local. And this web app shall connect to a service on my machine. Which of those urls would work and which won't? (assuming the required mechanisms are implemented)

• http://localhost
• http://127.0.0.1
• http://127.0.0.2
• http://192.168.1.11
• http://mymachine.local

[johnathan79717]

According to step 4 of https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy, the first 3 are trustworthy and shouldn't be blocked as mixed content as Chrome is today.

The 4th and 5th shall be relaxed once Chrome implements what @letitz mentioned in https://github.com/WICG/private-network-access/issues/109#issuecomment-1630384393

[softworkz]

Excellent! I've updated the title.

Thanks

[CSiggers77]

I am new. Can anyone help me as far as what to do from the initial start?

[johnathan79717]

I am new. Can anyone help me as far as what to do from the initial start?

@CSiggers77 What do you hope to achieve?