Re: [rtcweb] Let's define the purpose of WebRTC

[Eric Rescorla <[e-mail]>]

On Thu, Nov 10, 2011 at 5:15 PM, Hadriel Kaplan <[e-mail]> wrote:
>
> On Nov 10, 2011, at 4:34 PM, Eric Rescorla wrote:
>
>> This isn't my point: Roman offered a set of use cases he claimed didn't
>> require confidentiality. But in fact, many such cases do. The fact that
>> there are also overlapping cases which do not is an argument for erring
>> on the side of confidentiality, not the other way around.
>
> But the argument isn't about a generic "game-app" or generic "greeting card" WebRTC use-case - it's about a specific "game-app" or "greeting card" application instance.  In other words, of course for a "game-app" use-case we can imagine games which involve money that need media security; but there are "Farmville" and Scrabble and so on games as well, and those are the specific applications that're being proposed don't need it and may not want it.

I get that that's the argument you're offering, but my point is that people's
intuitions about what's needed are generally wrong. To take the specific
examples you've chosen, why do you think Scrabble doesn't require
security? If people are playing a scrabble tournament, then certainly
there is something riding on the outcome and so security is appropriate.
(This is, for instance, an issue for first person shooters, where tournaments
can have high stakes).


> The subtle difference, I think, is that you're viewing it like WebRTC is a generic application that can be used by different hosting sites for different purposes, whereas I view WebRTC as a toolkit to build different applications - like a library included with my OS or compiler.  So saying "well since someone could use WebRTC for something sensitive we have to assume the worst case" sounds rather odd to me - it's like a compiler removing a library because some programs made for sensitive data could be accidentally using it. No?

I would say a better analogy is a system declining to offer APIS which are known
to be extremely dangerous (since we are building a new system it's not really
a question of removing.) And indeed this is good practice. Imagine all the
security vulnerabilities which could have been avoided if the C standard library
had not included strcpy().

-Ekr