4 ms·

You must always trust something. In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their co

by 3JPLW 13y ago

You must always trust something. In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a trivial task. [0]. https://spideroak.com/faq/questions/35/why_isnt_spideroak_open_source_yet_when_will_it_be/ https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...

gcommer 13y ago
The point anon1385 is trying to make about JavaScript clients is that they can be changed at any time by the web service provider, where as open source clients can be 'verified' once by the open source community and then can't be easily changed by the service provider (unless they have an auto updater, which Tarsnap does not)
- 3JPLW 13y ago
  Ah, very good point. And the provider can send uniquely compromised versions to individuals to reduce their chance of detection, as well.
  - marshray 13y ago
    Hushmail.
    - sneak 13y ago
      It's almost like a punchline these days, innit?
      - marshray 13y ago
        Converting a weak encryption scenario into a Hushmail scenario seems, in a perverse way, an indication of progress.
anon1385 13y ago
Yes one must always trust something[1], but the impression I get is that people seem to want to use JS crypto specifically so that users don't need to trust the server with their data. But crypto in a js webapp can't provide that assurance. I struggle to see what the point of it is[2]. You are already (hopefully) sending all the user data securely over the wire. In a current app the user needs to trust the server with their plain text data. With a js crypto app the users needs to trust the server to provide the crypto code to encrypt their plain text. Either way the user has to trust the server and once the server is compromised their data is trivially retrievable. At best it would prevent your data being seen until you login. If all you are interested in is data storage that is secure because nobody ever retrieves the data then I can offer you a great price on such a service. [1] http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html [2] other than attempts to provide plausible deniability for legal reasons
- bigiain 13y ago
  I've got an odd use-case where JS crypto _might_ be a sensible choice… A piece of hardware, with an embedded linux machine and wifi capabilities – intended as a piece of consumer electronics(1) – with the main user interface being an HTML5 webapp intended to run on a phone(/tablet/computer). The hardware will either boot up and establish a wifi access point that you connect your phone to, or you'll be able to configure it to connect to your home(/office/shop/venue) wifi network where it'll (typically) live behind your NAT gateway on a 10...* or 192.168.. network. In either of those two configurations, it's difficult to ensure TLS secured communication between the phone and the hardware – where by "difficult" I mean "without big scarey 'YOURE ABOUT TO CONNECT TO AN UNTRUSTED SERVER' warnings baked into browsers when they hit TLS certs without proper root-CA-trusted signatures, for a bit of inexpensive consumer electronics aimed at your Mom or grandparents - accepting self-signed certs or installing self generated trusted keys is a difficult UX problem, and buying real trusted-CA-signed certs for production runs of 10,000 is expensive (and it's impossible to then secure those private keys against anyone with a screwdriver). I'm currently deciding between relying on WPA2 encryption and forbidding access to things requiring sensitive data (passwords) if the wifi isn't encrypted, or using a modified version of OAuth2 and relying on a cloud service that I can TLS secure with a CA-signed cert (OAuth2 assumes you'll TLS secure all the redirects, but I can't use TLS for the phone/hardware segment as described above. I've got an "I hope not too screwball" workaround involving generating public/private keys on the hardware, sending the public key to the cloud server, doing the OAuth there, and instead of sending the auth token back over a TLS secured channel, encrypt it to the public key first then send it over regular old http). I'm now wondering is JS crypto might solve that part of my problem… (1) in my case, intelligent Christmas tree lights – http://holiday.moorescloud.com http://holiday.moorescloud.com for the curious, and http://dev.moorescloud.com http://dev.moorescloud.com for the (open sourced) hardware and software details.

by 3JPLW 13y ago

gcommer 13y ago

The point anon1385 is trying to make about JavaScript clients is that they can be changed at any time by the web service provider, where as open source clients can be 'verified' once by the open source community and then can't be easily changed by the service provider (unless they have an auto updater, which Tarsnap does not)

3JPLW 13y ago
Ah, very good point. And the provider can send uniquely compromised versions to individuals to reduce their chance of detection, as well.
- marshray 13y ago
  Hushmail.
  - sneak 13y ago
    It's almost like a punchline these days, innit?
    - marshray 13y ago
      Converting a weak encryption scenario into a Hushmail scenario seems, in a perverse way, an indication of progress.

anon1385 13y ago

Yes one must always trust something[1], but the impression I get is that people seem to want to use JS crypto specifically so that users don't need to trust the server with their data. But crypto in a js webapp can't provide that assurance. I struggle to see what the point of it is[2]. You are already (hopefully) sending all the user data securely over the wire. In a current app the user needs to trust the server with their plain text data. With a js crypto app the users needs to trust the server to provide the crypto code to encrypt their plain text. Either way the user has to trust the server and once the server is compromised their data is trivially retrievable. At best it would prevent your data being seen until you login. If all you are interested in is data storage that is secure because nobody ever retrieves the data then I can offer you a great price on such a service. [1] http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html [2] other than attempts to provide plausible deniability for legal reasons

bigiain 13y ago
I've got an odd use-case where JS crypto _might_ be a sensible choice… A piece of hardware, with an embedded linux machine and wifi capabilities – intended as a piece of consumer electronics(1) – with the main user interface being an HTML5 webapp intended to run on a phone(/tablet/computer). The hardware will either boot up and establish a wifi access point that you connect your phone to, or you'll be able to configure it to connect to your home(/office/shop/venue) wifi network where it'll (typically) live behind your NAT gateway on a 10...* or 192.168.. network. In either of those two configurations, it's difficult to ensure TLS secured communication between the phone and the hardware – where by "difficult" I mean "without big scarey 'YOURE ABOUT TO CONNECT TO AN UNTRUSTED SERVER' warnings baked into browsers when they hit TLS certs without proper root-CA-trusted signatures, for a bit of inexpensive consumer electronics aimed at your Mom or grandparents - accepting self-signed certs or installing self generated trusted keys is a difficult UX problem, and buying real trusted-CA-signed certs for production runs of 10,000 is expensive (and it's impossible to then secure those private keys against anyone with a screwdriver). I'm currently deciding between relying on WPA2 encryption and forbidding access to things requiring sensitive data (passwords) if the wifi isn't encrypted, or using a modified version of OAuth2 and relying on a cloud service that I can TLS secure with a CA-signed cert (OAuth2 assumes you'll TLS secure all the redirects, but I can't use TLS for the phone/hardware segment as described above. I've got an "I hope not too screwball" workaround involving generating public/private keys on the hardware, sending the public key to the cloud server, doing the OAuth there, and instead of sending the auth token back over a TLS secured channel, encrypt it to the public key first then send it over regular old http). I'm now wondering is JS crypto might solve that part of my problem… (1) in my case, intelligent Christmas tree lights – http://holiday.moorescloud.com http://holiday.moorescloud.com for the curious, and http://dev.moorescloud.com http://dev.moorescloud.com for the (open sourced) hardware and software details.