[RTW] Criteria for what one can do in Javascript vs what one has to do inside the browser
Harald Alvestrand
harald at alvestrand.no
Thu Feb 17 18:05:41 CET 2011
Trying to sort out thoughts in my own head.... I've run a few
experiments, and thought a few thoughts.
There are a couple of things that should NOT be permitted from
Javascript in an RTC-Web enabled application, and there are a couple of
things that just can't be done at the present stage of our codebase.
Things that should not be permitted:
- Sending an UDP packet with script-specified content to a
script-specified destination. This has far too much potential for havoc
(imagine them being fired at business critical systems, DNS servers or
SNMP monitoring ports).
- Setting up a TCP connection to a script-specified destination and
sending script-specified data down it. Same issues as above.
The traditional defense against the second type is the "same origin
policy", policed by browsers in their implementation of XmlHttpGet,
WebSockets and similar interfaces, which also limits requests to
more-or-less valid HTTP (but see
http://www.alvestrand.no/ietf/http-traps.html for some fun abuses that
used to work...)
So far, we have assumed that the STUN handshake is our defense against
the first one, and that it's OK to send out a moderate amount of
STUN-formatted UDP packets to ports and IP addresses chosen by the
script, believing that the STUN format prevents them from being parsed
as valid packets by other protocols.
(Query: What other operations need to be protected against?)
Things that can't be done:
- Anything that requires timing of events within 20-100 ms of each other
- Anything that depends on multithreading behaviour in the browser
In both cases, Javascript just doesn't work that way.
I think the TCP constraint + the UDP constraint means that we can't
implement SIP or XMPP in Javascript without a gateway that talks
SIP-over-HTTP - you just can't get around the security features.
I think the timing constraint means that if you implement ICE in
Javascript, you're going to need to have seriously relaxed timing
constraints - the standard specifies that you should try candidates at
<complicated expression that usually turns out to be 20 ms>.
What else are serious limitations on what we can or cannot do?
What are the consequences?
Harald
More information about the RTC-Web
mailing list