Re: [w3ctag/design-reviews] Private Network Access (aka CORS-RFC1918) (#572)

> > > Making sure I understand your concern correctly:
> > > 
> > > 1. Certain devices will not be able to update and support CORS preflights, for example old printers
> > > 2. There should be a way for websites to request access to such devices that bypasses PNA restrictions
> > 
> > 
> > Well, not really bypass restrictions, as the goal would not to let them be available through http, but as an attached device.
> 
> Do you propose to introduce a new API for loading websites that does not use http, then? Or a new scheme perhaps? Though that would not prevent CSRF, so I think I am missing your point. Could you explain how you envision a user agent would interact with a pseudo-device?

Not really, my point was to make it seen (if allowed) as a peripheral directly attached to the computer, with the browser deciding which device can be seen or not. That would solve the use case of legacy devices like printers, scanners, cameras, etc... But how it can be done, or even would it be the best solution for enabling those legacy devices is out of scope of this review.
 
> > > If I've understood correctly, then I can certainly see your point. I have two reservations, however:
> > > 
> > > 1. This mechanism would significantly reduce the incentive for devices to implement PNA proper. In other words, it seems advantageous for device maintainers (and disadvantageous for user security) to classify _all_ services as pseudo-devices.
> > 
> > 
> > I don't think so, as not all services can be seen as a pseudo device, router configuration is definitely not in that range. I think more about devices sitting on the local network where the function can be identified easily.
> 
> Who makes that call, and how is it made? I think this is a crucial question with such an approach.
> 
> Either the user agent has some list of acceptable pseudo-devices, or the target service must be trusted to self-identify, in which case we are back to solution relatively similar to the current proposal.
> 
> In the former case, it seems that the only recourse we have is to ask either the host OS or the user for help determining what are acceptable pseudo-devices to communicate with. I have shied away from asking users for input on the theory that most will be unable to make an educated decision on the risks involved with allowing a random website to probe at a private network device. As a defense-in-depth measure, I am not opposed to it. However, I believe relying on user consent alone would significantly weaken the protections afforded by the preflight protocol envisioned in the current spec.

Decisions in that case shouldn't be on the user, to avoid permission fatigue.

> > > 2. It begs the question: how do you identify a pseudo-device? IP address alone works to an extent, but is hardly fool-proof. mDNS names are not authenticated either, though one could argue that on the private network they should be relatively stable.
> > 
> > 
> > mDNS is probably the most reliable way to identify an ipp or roap device, for example, but it is just a possibility.
> > > > On the second point, I think there is a difference between the local network and the private networks you can reach, like corporate private networks. The pseudo-device use case makes sense only for local networks, not for corporate private networks, for example.
> > > 
> > > 
> > > Oh, so you propose allowing the pseudo-device attachment only work within the currently subnet(s)?
> > 
> > 
> > Yes, on remote private network, you can imagine that gateways to implement PNA would be in place to access devices that can't be directly upgraded.
> 
> That makes sense.

We discussed this again during our F2F, and decided that it looks good enough to close it.
Thanks!



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/572#issuecomment-989636372