N29: A way to obtain user consent for one-way media and data use cases #14
Conversation
|
I guess another nit is that this could be added to 1.0 but is currently in the no 1.0 support section. |
| @@ -141,6 +141,9 @@ <h3>File Sharing</h3> | |||
| be supported by servers as well as user agents. | |||
| N15 It must be possible to support data exchange | |||
| in a worker. | |||
| N29 The application must be able to request user consent | |||
| for one-way media and data only use cases in a | |||
There was a problem hiding this comment.
This section is "file sharing", so "one-way media" should be broken out in a separate use case.
There was a problem hiding this comment.
By that, do you mean add the requirement to "Video Conferencing with a Central Server" as well?
I'm also wondering if it's clear enough what "user consent" is referring to. What are your opinions?
| @@ -141,6 +141,9 @@ <h3>File Sharing</h3> | |||
| be supported by servers as well as user agents. | |||
| N15 It must be possible to support data exchange | |||
| in a worker. | |||
| N29 The application must be able to request user consent | |||
There was a problem hiding this comment.
"Request user consent" is an implementation, not a requirement. Please rephrase what the requirement is.
There was a problem hiding this comment.
Is it just the word "request"? What about replacing it with "obtain"?
|
@aboba Bernard, you mentioned another early-media use case that would benefit from being able to get user consent. Would that fit into "Video Conferencing with a Central Server"? |
|
Submitter action needed (no such label). |
| @@ -367,6 +370,9 @@ <h3>Requirements</h3> | |||
| rendered. | |||
| N28 TBD: restrictions on the application so as to | |||
| prevent unauthorized recording of the session. | |||
| N29 The application must be able to request user consent | |||
| for one-way media and data only use cases in a | |||
| non-discriminating way. | |||
There was a problem hiding this comment.
What does "non-discriminating way" mean?
There was a problem hiding this comment.
This can easily be misinterpreted as one-way media and data should not be allowed without user consent. This is about better connections (by exposing IP addresses), but it's not clear what the user is consenting to
There was a problem hiding this comment.
What does "non-discriminating way" mean?
The intent is to ensure that there is at least one use case neutral (thus, non-discriminating) way to request user consent. Maybe I should rephrase? Any suggestions?
There was a problem hiding this comment.
This can easily be misinterpreted as one-way media and data should not be allowed without user consent. This is about better connections (by exposing IP addresses), but it's not clear what the user is consenting to
I don't understand that. When we're talking about consent, it usually means the form of consent as described by the IP handling draft which is what this is targeting. Should I clarify this? Suggestions?
There was a problem hiding this comment.
Agree with @henbos, this needs to talk specifically about IP address enumeration, not the use cases (most of which don't need IP address enumeration)
There was a problem hiding this comment.
Okay, perfectly fine with that as it also points out more clearly what concrete use cases it targets. I'll /cc @steely-glint just in case. Justin, could you make a concrete proposal that would work for you? I'll happily update the PR with your framing.
There was a problem hiding this comment.
"N29: Support for one-way media and data applications between browsers inside the same LAN", which basically reduces to finding an alternative to mDNS for this environment.
You could also call out "NXX: Ability for one-way media and data applications to control the network interface used by ICE" as a separate requirement, which may point at a different solution. This particular problem largely reduces to a special case consideration to route real-time traffic directly when a VPN is in use, and may be solvable via its own targeted solution.
There was a problem hiding this comment.
I'm reasonably happy with "N29: Support for one-way media and data applications between browsers inside the same LAN" but I have 2 minor issues.
- I'd like to emphasize that the goal is the media should stay on that LAN, otherwise TURN fits the bill.
- LAN is a bit vague. We may be talking about anything from a local wifi to a whole corp network. (I'm thinking of the multisegment star network that traditionally covers the whole 4,400 acres of the burning man site - which isn't obviously a LAN, or the 15000 participant network that CCC spin up at congress.)
I don't agree with your framing of NXX as a VPN problem - it also addresses outages - so lets discuss that in a different issue.
There was a problem hiding this comment.
yea, or a corp network that uses MPLS and site-site VPN to make it all look like 1 big LAN. Is there a standard name for a "continuously virtual connected not NATed network" ?
There was a problem hiding this comment.
perhaps we could add 'p2p' to 1), e.g., "N29: Support for one-way media and data applications to connect P2P to other browsers inside the same LAN". Definition of what exactly is meant by LAN is probably better left as sub-bullets.
|
Ping @henbos and @alvestrand regarding in-line comments. |
| @@ -141,6 +141,9 @@ <h3>File Sharing</h3> | |||
| be supported by servers as well as user agents. | |||
| N15 It must be possible to support data exchange | |||
| in a worker. | |||
| N29 The application must be able to request user consent | |||
There was a problem hiding this comment.
We should also consider allowing the exposure of local IP not via user prompt but in "out-of-band" methods like browser Enterprise policy
|
So, how about this:
I mean, this is just the requirement for w3c/webrtc-pc#2175 conveyed to whatever API NV will ship. |
|
I've come across this in the wild and it is ugly. I have a 5g module in a smart camera in a race car - I am using webRTC to stream live low latency video to the pit crew. The 5g SIM gives the camera a routable IPV6 address. The browser in the pit also has a routable IPV6 address. Both sides have firewall apps protecting them from random incoming packets. This is because without asking for mic/camera permissions the browser's IPV6 address isn't sent as a candidate - except as an mdns address which is useless to the camera. So we have neatly undermined the whole point of IPV6. The current suggested fix is to pop a dialog that links to this issue and apologises for the microphone access request. |
The solution is to use an IPv6 stun server so that the User Agent identifies that the candidate is exposing a public IP address. In that case, it is allowed to bypass the mDNS protection, see https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-04#section-3.1.2.2. |
|
Thanks. That works. It is also horrible! It don't think it solves the problem for things like private 5g networks. |
Resolves #1
This could also be added to the Video Conferencing with a Central Server section.
@steely-glint: Is the wording solid enough to ensure that one really can get the same mode as can be achieved with
getUserMedia?