

WebRTC Copy – OTR and fast file transfers over WebRTC - erbbysam
https://rtccopy.com/

======
mike-cardwell
The problem with sites like these are that you have to trust the site owner to
not just add some javascript to the page which breaks the security of your
conversation.

Except this site is worse, because they also let their third party user
tracking provider run arbitrary script on every page too.

Nice as a demo of technology though.

~~~
dmix
If your concern is the security of 3rd party JS you should already be using
NoSript/ScriptSafe [1]. Keep same-domain policy as safe and 3rd party domains
blocked and opt-in only by default.

The day-to-day UX experience of browsing the web is only minimally affected
and significantly safer.

Better than adblock.

If your concern is the host operator, well obv can't circumvent that. Unless
you use OSS chrome plugins and client code verifications (ala CryptoCat). But
that's also an imperfect solution (cue tptacek).

[1]
[https://chrome.google.com/webstore/detail/scriptsafe/oiigbmn...](https://chrome.google.com/webstore/detail/scriptsafe/oiigbmnaadbkfbmpbfijlflahbdbdgdf)

~~~
sillysaurus2
_If your concern is the host operator, well obv can 't circumvent that._

Of course we can circumvent that. Make a plugin to alert the user whenever the
JS changes.

~~~
voltagex_
What do you base your initial known good JS on though? What is the user
supposed to do with the information that the JS has changed? A diff of
minified JS isn't that helpful.

~~~
sillysaurus2
The author would say "the current version is 0.6.4 and its JS hashes to this
SHA256 hash: xxx"

Open source already does this for binaries. Why not JS?

This assumes it's even possible to get a consistent hash of all javascript
executing on a page, though.

------
shmerl
Can anyone explain please, whether WebRTC is a protocol or not? After reading
this: [http://www.webrtc.org/faq#TOC-Why-should-I-use-
WebRTC-](http://www.webrtc.org/faq#TOC-Why-should-I-use-WebRTC-) I thought
it's just an API to enable other protocols (XMPP/Jingle, SIP etc.) to be built
through JavaScript. Or is it a protocol after all?

~~~
bemmu
I'm also a bit curious about the protocol part, found this tidbit on their
site "The session components are built by re-using components from libjingle,
without using or requiring the xmpp/jingle protocol."
([http://www.webrtc.org/reference/architecture#TOC-
Transport-S...](http://www.webrtc.org/reference/architecture#TOC-Transport-
Session))

------
comex
Security issues are one thing, but I've been using this site as a simple way
to transfer (nonsensitive) large files without having to wait for the file to
go through a third party server, sit through the ads required to pay for the
bandwidth for such a server, or require the recipient to download specialized
software for a P2P transfer. For this purpose it's very convenient.

------
morsch
You know what they say about javascript browser crypto, but for what it's
worth, it worked fine for transferring a file from my desktop to my phone
(Firefox on both ends).

I wonder: when using WebRTC between two devices on a single LAN, is my ISP
involved (possibly: beyond bootstrapping the process)?

~~~
nonane
1\. WebRTC is natively compiled into browsers. This app uses WebRTC's data
channel to transfer files and WebRTC guarantees that the data channel is
encrypted (via DTLS). So - tehcnically the crypto is not javascript based -
it's native code similar to crypto over HTTPS.

2\. WebRTC tries to create a P2P connection between the devices. The ISP is
only involved in the initial bootstrapping of the P2P connection - the actual
data packets travel over the LAN and not through your ISP. In the rare case a
P2P connection can't be established, a relay might be used (though this is
optional).

~~~
erbbysam
A minor note on 1. - rtccopy.com does use (optionally) OTR in javascript on
top of the DTLS channel in order guarantee identity (something not currently
guaranteed with the DTLS channel).

------
taralx
It would be lovely if it would explain what features it needs out of Chrome
Canary.

~~~
erbbysam
Chrome Canary is the only Chrome version that has working SCTP (reliable)
datachannel support at the moment. It's broken(undetectable also) in every
version before that (you can try, the website won't stop any version, just
display warnings).

I did have unreliable datachannel support initially, but as both Firefox &
Chrome now support reliable, I see no reason to keep that overhead/extra code
around. Hopefully working reliable datachannels in Chrome will reach the
primary version soon!

