Permission prompt spec

[johnathan79717]

Don't forget to replace all "private network" with "local network" too.

[yelhouti]

In section 6.2 it is mentioned that:

The CORS restrictions added by the proposal in this document do not obviate mixed content checks [MIXED-CONTENT-2]. Device consent obtained through a CORS preflight request is necessary but not sufficient.

I have a use case where a legacy hardware device (payment terminal) is in my private network. I would like my public webapp to be able to communicate with it using websocket but it doesn't support wss:// . What I do today is run a proxy locally that forwards request back and fort, this is not ideal as you need to manually install the proxy on the device. Ideally the prompt should take priority over CORS here.

[letitz]

@yelhouti thanks for the feedback! This is actually the point of the prompt: we want to allow secure websites to bypass mixed content restrictions given user permission. The device would still have to respond to preflight requests with new headers, but it would not need to be served over HTTPS. Would that satisfy your use case?

[yelhouti]

The device would still have to respond to preflight requests with new headers, but it would not need to be served over HTTPS.

@letitz Maybe I wasn't clear, but I have no control over the payment terminal or it's firmware. So it won't be able to answer the preflight request as expected.

[letitz]

Ah, that's unfortunate. PNA as currently envisioned does not allow for such accesses, as they are indistinguishable from attacks.

Browsers are free to introduce mechanisms allowing users to disable PNA selectively on certain websites, though. Maybe that's enough of an escape hatch for your purposes?

[yelhouti]

PNA as currently envisioned does not allow for such accesses, as they are indistinguishable from attacks.

Well I disagree. The app running in the client could prompt for a permission to access a specific device on the network.

Browsers are free to introduce mechanisms allowing users to disable PNA selectively on certain websites, though. Maybe that's enough of an escape hatch for your purposes?

That is too big of an escape hatch/risk. as a user I would want the app to be able to talk to only one device but not my router...

[letitz]

PNA as currently envisioned does not allow for such accesses, as they are indistinguishable from attacks.

Well I disagree. The app running in the client could prompt for a permission to access a specific device on the network.

Right, but one design principle we've held fast to in PNA is that users are ill-positioned to make that kind of judgment call. In other words, we do not believe that only introducing a prompt would meaningfully protect users from attacks.

Browsers are free to introduce mechanisms allowing users to disable PNA selectively on certain websites, though. Maybe that's enough of an escape hatch for your purposes?

That is too big of an escape hatch/risk. as a user I would want the app to be able to talk to only one device but not my router...

That's true! I think the way we're seeing this is that the device should allow the fetch, in that case.

[yelhouti]

Right, but one design principle we've held fast to in PNA is that users are ill-positioned to make that kind of judgment call. In other words, we do not believe that only introducing a prompt would meaningfully protect users from attacks.

@letitz thanks for the clarification, I kind of agree with the statement. The threat model here if I understand it correctly is that the webapp is malicious or compromised right ?

Maybe I compromise could to prompte the user and ask to manually enter the IP he wants to allow instead of just clicking allow. Maybe doing all this in a different page (ex: chrome://pna-allow-list ) with a clear warning:

That's true! I think the way we're seeing this is that the device should allow the fetch, in that case.

End users do not have control over the firmware of all their devices, specially the ones built/designed in the pre-cloud era.