3 ms·

Until a user provides their pin, and you decrypt their private key. Then you have the private key, although you may choose not to remember it. This doesn't so

Until a user provides their pin, and you decrypt their private key. Then you have the private key, although you may choose not to remember it. This doesn't solve the privacy issues such as with Facebook and other centralized servers, where you distrust the host as much as hackers or other users. EDIT: You may want to read this: http://wiki.appleseedproject.org/doku.php?id=future:encryption:client-side_encryption http://wiki.appleseedproject.org/doku.php?id=future:encrypti...

privachi123 15y ago
The decryption of private key happens in the user's browser, not on the server. We still don't know user's decrypted private key on the server. Thanks for the link.
- michaelchisari 15y ago
  So you're doing the data encryption/decryption through a browser plugin, then? Is the source available? If it occurs in the browser, why are the (encrypted) private keys stored on the server? Why not store them in the browser?
- privachi123 15y ago
  Nope. No plugin involved. Encryption/decryption carried out in JS. Storing it on a particular browser will limit user's access to the service from any other browser :)
  - michaelchisari 15y ago
    Hmmm, again, that assumes trust of the host serving up the Javascript. I know it may seem nit-picky, but it's not a concern that can be easily dismissed.
    - yid 15y ago
      At some point, you're going to have to trust software that someone else has written. I understand that you see Appleseed as the solution, but it really doesn't solve the problem of 99% of users downloading a binary that they blindly run. When you're at that level, a Javascript file is as transparent (if not more) than an Appleseed binary.
      - michaelchisari 15y ago
        I think you're missing the point, though. When you have a centralized site, one of the problems that we've seen with Facebook is the issue of being "host-safe". There's too much financial incentive to do something with that data, and no other viable business model has been proposed. A site which promises to solve Facebook's privacy issues can't make those promises while serving up Javascript decryption code. It's too easy for the host to inject a simple line of code which pulls the pin number and sends it back to the host, which can then decrypt everything. They could do this with a single page load, and then never do it again, so that you would have to catch the malfeasance that one time. It's a case of misplaced trust, simply because things are "encrypted". They could get around this via an open source browser plugin so that it can be peer-reviewed, or (more desirably) the functionality can be integrated into browsers via the HTML5 spec. There's no such thing as an Appleseed binary, btw, it's written in a scripted language.
        yid 15y ago
        Your issue applies to any system that can pull executable code from the web and dynamically execute it, including almost every scripting language. You could pull the password before it hits the browser plugin. There is no remedy to this under the circumstances -- not open source, not peer review, not SSL, not distributed systems. You'd have to use a signed binary whose source you had examined yourself, at the least. So even the distributed FOSS argument is snake oil. BTW, I'm not trying to imply that these guys have solved the problem -- there are numerous problems, as you pointed out.
        michaelchisari 15y ago

privachi123 15y ago

The decryption of private key happens in the user's browser, not on the server. We still don't know user's decrypted private key on the server. Thanks for the link.

michaelchisari 15y ago
So you're doing the data encryption/decryption through a browser plugin, then? Is the source available? If it occurs in the browser, why are the (encrypted) private keys stored on the server? Why not store them in the browser?
privachi123 15y ago
Nope. No plugin involved. Encryption/decryption carried out in JS. Storing it on a particular browser will limit user's access to the service from any other browser :)
- michaelchisari 15y ago
  Hmmm, again, that assumes trust of the host serving up the Javascript. I know it may seem nit-picky, but it's not a concern that can be easily dismissed.
  - yid 15y ago
    At some point, you're going to have to trust software that someone else has written. I understand that you see Appleseed as the solution, but it really doesn't solve the problem of 99% of users downloading a binary that they blindly run. When you're at that level, a Javascript file is as transparent (if not more) than an Appleseed binary.
    - michaelchisari 15y ago
      I think you're missing the point, though. When you have a centralized site, one of the problems that we've seen with Facebook is the issue of being "host-safe". There's too much financial incentive to do something with that data, and no other viable business model has been proposed. A site which promises to solve Facebook's privacy issues can't make those promises while serving up Javascript decryption code. It's too easy for the host to inject a simple line of code which pulls the pin number and sends it back to the host, which can then decrypt everything. They could do this with a single page load, and then never do it again, so that you would have to catch the malfeasance that one time. It's a case of misplaced trust, simply because things are "encrypted". They could get around this via an open source browser plugin so that it can be peer-reviewed, or (more desirably) the functionality can be integrated into browsers via the HTML5 spec. There's no such thing as an Appleseed binary, btw, it's written in a scripted language.
      - yid 15y ago
        Your issue applies to any system that can pull executable code from the web and dynamically execute it, including almost every scripting language. You could pull the password before it hits the browser plugin. There is no remedy to this under the circumstances -- not open source, not peer review, not SSL, not distributed systems. You'd have to use a signed binary whose source you had examined yourself, at the least. So even the distributed FOSS argument is snake oil. BTW, I'm not trying to imply that these guys have solved the problem -- there are numerous problems, as you pointed out.
        michaelchisari 15y ago