11 ms·

WebRTC Copy – OTR and fast file transfers over WebRTC

49 points by erbbysam 13y ago

morsch 13y ago
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 13y ago
  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 13y ago
    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).
mike-cardwell 13y ago
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.
- rektide 13y ago
  The problem with sites like this is that readers such as mike-cardwell are not cool enough to download the sources themselves and host it where they trust it.
  - mike-cardwell 13y ago
    I run my own federated XMPP server from my own trusted hardware in my own trusted building, with mandatory TLS and OTR. I wont be interested in running web based mail/chat clients until we get to a point where browsers have built in APIs that allow people to write trustable apps.
- erbbysam 13y ago
  Thanks for the feedback. In defense of this implementation - - The only external JS loaded on this site is google analytics. Feel free to block this using something like noscript :) - WebRTC datachannel connections on this site don't use just (optionally) OTR. They have DTLS enabled within the browser. OTR just adds an authentication layer that DLTS currently lacks. So that even if the OTR implementation here was completely compromised, the only possible attack would still be a MiTM on the DTLS channel. - It's open source (https://github.com/erbbysam/webRTCCopy https://github.com/erbbysam/webRTCCopy), so it's available to be hosted elsewhere and all of the libraries used could be re-downloaded. -Sam
  - mike-cardwell 13y ago
    Does Google now have a log that I visited: https://rtccopy.com/#csFXmvXW https://rtccopy.com/#csFXmvXW And if somebody else had visited that same room, would they have a log of that too?
    - erbbysam 13y ago
      It looks like this is leaking the room name to Google Analytics. After thinking about this more, I'm going to go ahead and remove that. I should be able to monitor the server itself to make sure it isn't getting overloaded.
comex 13y ago
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.
shmerl 13y ago
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 13y ago
  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-Session http://www.webrtc.org/reference/architecture#TOC-Transport-S...)
- pigubrco 13y ago
  I think this is a really nice overview for WebRTC: http://www.html5rocks.com/en/tutorials/webrtc/basics/ http://www.html5rocks.com/en/tutorials/webrtc/basics/ There is a section around standards and protocols.
taralx 13y ago
It would be lovely if it would explain what features it needs out of Chrome Canary.
- erbbysam 13y ago
  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!

49 points by erbbysam 13y ago

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 13y ago
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 13y ago
  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).

mike-cardwell 13y ago

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.

rektide 13y ago
The problem with sites like this is that readers such as mike-cardwell are not cool enough to download the sources themselves and host it where they trust it.
- mike-cardwell 13y ago
  I run my own federated XMPP server from my own trusted hardware in my own trusted building, with mandatory TLS and OTR. I wont be interested in running web based mail/chat clients until we get to a point where browsers have built in APIs that allow people to write trustable apps.
erbbysam 13y ago
Thanks for the feedback. In defense of this implementation - - The only external JS loaded on this site is google analytics. Feel free to block this using something like noscript :) - WebRTC datachannel connections on this site don't use just (optionally) OTR. They have DTLS enabled within the browser. OTR just adds an authentication layer that DLTS currently lacks. So that even if the OTR implementation here was completely compromised, the only possible attack would still be a MiTM on the DTLS channel. - It's open source (https://github.com/erbbysam/webRTCCopy https://github.com/erbbysam/webRTCCopy), so it's available to be hosted elsewhere and all of the libraries used could be re-downloaded. -Sam
- mike-cardwell 13y ago
  Does Google now have a log that I visited: https://rtccopy.com/#csFXmvXW https://rtccopy.com/#csFXmvXW And if somebody else had visited that same room, would they have a log of that too?
  - erbbysam 13y ago
    It looks like this is leaking the room name to Google Analytics. After thinking about this more, I'm going to go ahead and remove that. I should be able to monitor the server itself to make sure it isn't getting overloaded.

comex 13y ago

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.

shmerl 13y ago

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 13y ago
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-Session http://www.webrtc.org/reference/architecture#TOC-Transport-S...)
pigubrco 13y ago
I think this is a really nice overview for WebRTC: http://www.html5rocks.com/en/tutorials/webrtc/basics/ http://www.html5rocks.com/en/tutorials/webrtc/basics/ There is a section around standards and protocols.

taralx 13y ago

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

erbbysam 13y ago
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!