[Proposal] Allow querying permissions for specific URL

[lukas-w]

Moving from #71 (comment):

Proposal

I propose a client API to allow querying for permission state for a specific URL. It could take the following form:

navigator.permissions.query({name: "local-network-access", url: "http://<host>:<port>"})

Assuming no other changes to the specification, this would:

1. return granted if a request to url is not a local network request, meaning it would not fall under LNA restrictions and wouldn't trigger a prompt
2. in all other cases, be equivalent to a query to local-network or loopback-network if the IP url resolves to is in local or loopback address space respectively

Use-case

To provide a good and streamlined user experience, developers need to be able to have their UI accurately guide the user through the permission process.

To do this, it's essential to be able to detect if an intended network request has or needs permission from the user. This avoids

• confusing the user with info about an upcoming permission prompt that may not actually appear
• increased permission denial rates, when a permission prompt is shown without the site informing the user beforehand
• bothering the user with connection re-attempts and error messages when it's not detected that the connection is failing because the user has denied the network request.

This helps contain the increased user frustration and support workload that's inevitably caused by the LNA rollout.

As an additional benefit, browsers could limit the permissions' scope to the requested address while still following the spec, and in the respective prompt, help the user form a decision by (where available) displaying information about the device that the site is trying to access.

Rationale

The current draft & implementation puts developers in a bit of a pickle when it's not known before runtime which address space a connection attempt's target and/or origin lives in (because e.g. the address is user-provided):

• They can't determine whether the request falls under LNA restrictions beforehand
• Even if they know that LNA restrictions apply, since the new permission split into local-network and loopback-network (since #87), they can't find out which one of the two permissions is needed (see discussion starting at #17 (comment)).
• Therefore after a failed connection, they can't reliably detect whether it was denied or failed for other reasons (#69)
  • This feature is clearly intended to be available, otherwise the Permissions API integration would be pointless in this situation
  • This used to be possible before #87, at least in situations where it is known if LNA restrictions apply at all

Relationship to other proposals

This proposal could potentially supersede

• the request for an API to determine whether a given URL falls under LNA restrictions (#71). While this proposal doesn't provide the ability to differentiate between a granted permission and a non-needed permission, I can't think of a use-case that needs that distinction. This avoids exposing necessary information while integrating well into an existing API.
• the requests for per-device permissions (#72), per-port permissions and (#92), which could leave this as an implementation detail, simplifying the spec
• the newly split local-network and loopback-network permissions (initially proposed in #17), unless it's specifically the aim of the LNA spec to allow acquiring permission for accessing the entire local or loopback network which at least from a security perspective seems highly unlikely