Question Re: Private Network Access: Secure Context Restriction

[Mark Rullo]

Hello,

 

Please forgive me if this is not the appropriate avenue to ask questions about this matter.  I’m just learning about this particular deprecation and trying to understand it’s impacts on our application.  

 

This is the deprecation I’m speaking about:

Restrict "private network requests" for subresources to secure contexts. - Chrome Platform Status (chromestatus.com)

 

We serve up our application from an internal web server and make a separate connection to a local service (using SignalR) for barcode scanner and scale data.  The server connection is via HTTPS, but the localhost:8080 connection is not.  If I understand this deprecation properly, this scenario will be disallowed going forward.  What I don’t have a grasp on is how I can fix this on our end, or what can be done to work around this scenario.  Will there be a flag to enable/work around this?  Would implementing a certificate on the localhost service solve the matter?  This is a critical workflow for us.

 

Any help you could provide would be greatly appreciated.  I have to admit a lot of the documentation on the matter (that I’ve found) is out of my depth.

 

Cheers,

 

Mark

[Chris Thompson]

I believe that your use case should continue to be okay, as localhost is special-cased as a secure context in Chrome (we can check that it points to the loopback address and thus does not traverse the network). This is called out under the "Activation Risks" section in the chromestatus entry you linked, but is easy to miss.

Hope that helps!

- Chris

[Titouan Rigoudy]

Hi Mark,

Private Network Access dev here, sorry I missed this email in my inbox.

Chris is correct: this deprecation in itself only requires that the initiating website be served over HTTPS, not the target website. This is already the case for you, so you should have nothing to worry about.

The requirement on the target website comes from Mixed Content, which has shipped for a while in Chromium. Mixed Content prevents secure websites from making insecure fetches in most cases, but not when talking to localhost. This carveout is intended to be permanent.

You will probably be interested in the next steps for Private Network Access, however, where we will start sending CORS preflight requests to the target of the fetch. See this short blurb [1] for a quick overview. There will be a few threads on blink-dev@ and a corresponding chromestatus entry notifying you of that upcoming change, of course. I'm happy to discuss this further over email too.

Cheers,

Titouan

[1] https://developer.chrome.com/blog/private-network-access-update/#cors-preflight-requests

--
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Mark Rullo]

Titouan,

 

I can’t express how much I appreciate this team responding to my questions.  Thank you so much for adding that additional detail.  I’ll add a ticket on our side to keep an eye out for the CORS preflight. 

 

I’m so grateful that that you all have taken the time to respond.  Your assurances have been really relieving.

 

Regarding CORS, I have some reading up to do as I’ve never been good with implementing it properly.  I’ll have to check on some .Net docs on how to do this right.

 

Cheers,

 

Mark

 

Sent from Mail for Windows 10