3 ms·

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 bro

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
        You could pull the password, but you couldn't pull the private key from the browser (or plugin). Encryption/decryption is done in the browser, and the host server acts purely as a data store, incapable of doing anything with that (encrypted) data. The trust question then gets moved from the host to the browser. Have you read the link I posted about how you could approach encryption at the browser level? Far from not solving the situation, I think they fall into the category of "half-way encryption is worse than no encryption at all", and they don't seem to understand the social concept of trust. As Jon Callas says, "Encryption is not magic pixie dust that makes everything okay."

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
      You could pull the password, but you couldn't pull the private key from the browser (or plugin). Encryption/decryption is done in the browser, and the host server acts purely as a data store, incapable of doing anything with that (encrypted) data. The trust question then gets moved from the host to the browser. Have you read the link I posted about how you could approach encryption at the browser level? Far from not solving the situation, I think they fall into the category of "half-way encryption is worse than no encryption at all", and they don't seem to understand the social concept of trust. As Jon Callas says, "Encryption is not magic pixie dust that makes everything okay."