6 ms·

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 conver

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.

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.
    - erbbysam 13y ago
      removed - https://github.com/erbbysam/webRTCCopy/commit/c1f35404414d633ea211050ff5e1085fc8d92308 https://github.com/erbbysam/webRTCCopy/commit/c1f35404414d63...
      - zz1 13y ago
        Great!
      - Gnewt 13y ago
        Are you hosting the site through Github Pages?
        erbbysam 13y ago
        No, I currently just manually keep the site in sync with the repository. Not exactly the most professional system but it got the job done. I'm going to look into that(not sure exactly how it works, but I do need to keep a node.js server running as well for webrtc negotiation) , as well as potentially just installing git on the server and have it sync up to the repository.
    - mike-cardwell 13y ago
      Even if Google weren't currently sucking up this information, it would still have been a wise decision to remove it. They can change their JavaScript at any point without you noticing and start logging it. Malicious intent not required.
dmix 13y ago
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/oiigbmnaadbkfbmpbfijlflahbdbdgdf https://chrome.google.com/webstore/detail/scriptsafe/oiigbmn...
- sillysaurus2 13y ago
  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_ 13y ago
    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 13y ago
      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.
    - mike-cardwell 13y ago
      Script on a site like this should not be minified. It should be easily readable and well commented, so that people can audit it properly.
- mike-cardwell 13y ago
  I already use RequestPolicy and NoScript. My concern was that he made the security/privacy worse than it needed to be, for other people, by including Google Analytics on the page. He has now stated that he's seen that the room name is in fact being leaked to Google Analytics, and so has removed it. But even if he hadn't seen this, you still shouldn't include any third party hosted scripts on pages like these because you've no idea if/when they'll change in a manner which compromises security/privacy in future. No malicious intent required.
StavrosK 13y ago
I've been saying the same thing every time I encounter one of these articles (maybe I'll blog about it and just link people to it): The best way to do encrypted WebRTC transfers is to have the whole app in a single page, using as little code as possible (so it is easily auditable). NoScript/etc won't do much when you have to trust the author and can't audit it. People should be able to download the page from the GitHub repo (or wherever) and store it wherever they want. The page will generate a random URL that also contains a secret key (e.g. http://www.myservice.com/somerandomid/#98h9g78g2188t7231gy34t http://www.myservice.com/somerandomid/#98h9g78g2188t7231gy34...), which you can share with the receipient. Since the URL fragment is never transmitted to the server, it is private. The WebRTC service can encrypt the content appropriately and send it to the recipient, where it will be decrypted. Voila, encrypted p2p file transfers without having to download anything.
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.
  - erbbysam 13y ago
    removed - https://github.com/erbbysam/webRTCCopy/commit/c1f35404414d633ea211050ff5e1085fc8d92308 https://github.com/erbbysam/webRTCCopy/commit/c1f35404414d63...
    - zz1 13y ago
      Great!
    - Gnewt 13y ago
      Are you hosting the site through Github Pages?
      - erbbysam 13y ago
        No, I currently just manually keep the site in sync with the repository. Not exactly the most professional system but it got the job done. I'm going to look into that(not sure exactly how it works, but I do need to keep a node.js server running as well for webrtc negotiation) , as well as potentially just installing git on the server and have it sync up to the repository.
  - mike-cardwell 13y ago
    Even if Google weren't currently sucking up this information, it would still have been a wise decision to remove it. They can change their JavaScript at any point without you noticing and start logging it. Malicious intent not required.

dmix 13y ago

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/oiigbmnaadbkfbmpbfijlflahbdbdgdf https://chrome.google.com/webstore/detail/scriptsafe/oiigbmn...

sillysaurus2 13y ago
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_ 13y ago
  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 13y ago
    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.
  - mike-cardwell 13y ago
    Script on a site like this should not be minified. It should be easily readable and well commented, so that people can audit it properly.
mike-cardwell 13y ago
I already use RequestPolicy and NoScript. My concern was that he made the security/privacy worse than it needed to be, for other people, by including Google Analytics on the page. He has now stated that he's seen that the room name is in fact being leaked to Google Analytics, and so has removed it. But even if he hadn't seen this, you still shouldn't include any third party hosted scripts on pages like these because you've no idea if/when they'll change in a manner which compromises security/privacy in future. No malicious intent required.

StavrosK 13y ago

I've been saying the same thing every time I encounter one of these articles (maybe I'll blog about it and just link people to it): The best way to do encrypted WebRTC transfers is to have the whole app in a single page, using as little code as possible (so it is easily auditable). NoScript/etc won't do much when you have to trust the author and can't audit it. People should be able to download the page from the GitHub repo (or wherever) and store it wherever they want. The page will generate a random URL that also contains a secret key (e.g. http://www.myservice.com/somerandomid/#98h9g78g2188t7231gy34t http://www.myservice.com/somerandomid/#98h9g78g2188t7231gy34...), which you can share with the receipient. Since the URL fragment is never transmitted to the server, it is private. The WebRTC service can encrypt the content appropriately and send it to the recipient, where it will be decrypted. Voila, encrypted p2p file transfers without having to download anything.

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.