I didn't find it to be a good user experience. The GUI is OK, but when I talk about UX, I'm talking about more than that. I'm talking about what it feels like to visit the product's site for the first time with no clue what it is.
Go to the GPG Tools homepage. It's kind of a mess of links, without a dead-obvious path for the absolute beginner. Should I click "Quickstart tutorial" or "introduction?" Or should I just download the installer, which is my first step for 90% of applications? And the experience doesn't get less confusing when you get past the home page. If anything, it gets more so.
GPG Tools strikes me as a project that is by hackers, for hackers. Nothing wrong with that. But it's very different from what I envision. I want a UX that holds my hand. It should be like a teacher, patiently guiding me through everything I need to know to use GPG.
Fortunately, the mental model for how GPG works isn't actually that complicated. I think most people can understand, for example, what key signing is, if it's explained well.
Apologies to the maintainers of the GPG Tools. Their work is admirable and greatly exceeds the whole lot of nothing I've contributed. I'm hoping this will be interpreted as constructive criticism.
> However, it's still a minor pain to use for web-based email.
I don't see this problem being solved without something implemented in native code. See:
There have been proposals to add a crypto API to browsers, where such API would be implemented in native code. I.e. you could call the API from JS, but the algorithms would all run in native code. I don't know if any of these proposals will go anywhere.
Conceivably, one could also just up and write C modules for popular browsers. But then you'd have to get those accepted by the browser makers.
Either of these solutions is beyond the scope of what I envision, at least for now.
The W3C working group will eventually produce a crypto API standard, though whether that standard will meet the requirements you describe remains to be seen. In particular, it exposes primitives (the proposed API can definitely be called in unsound ways), which a whole lot of people think is a terrible idea but which the standard editor seems bound and determined to ship. It's very frustrating.
That's because W3C's goal in having a cryptography standard isn't security, but rather interoperability; they see encryption as another step towards making the web a first-class application development environment. Without it, they can't get Netflix to run on pure "open" web technology.
It's unfortunate, because we could use a secure browser crypto interface much more than we could use better browser interoperability with random non-web technology. But our industry is, of course, fundamentally unserious about security.
Go to the GPG Tools homepage. It's kind of a mess of links, without a dead-obvious path for the absolute beginner. Should I click "Quickstart tutorial" or "introduction?" Or should I just download the installer, which is my first step for 90% of applications? And the experience doesn't get less confusing when you get past the home page. If anything, it gets more so.
GPG Tools strikes me as a project that is by hackers, for hackers. Nothing wrong with that. But it's very different from what I envision. I want a UX that holds my hand. It should be like a teacher, patiently guiding me through everything I need to know to use GPG.
Fortunately, the mental model for how GPG works isn't actually that complicated. I think most people can understand, for example, what key signing is, if it's explained well.
Apologies to the maintainers of the GPG Tools. Their work is admirable and greatly exceeds the whole lot of nothing I've contributed. I'm hoping this will be interpreted as constructive criticism.
> However, it's still a minor pain to use for web-based email.
I don't see this problem being solved without something implemented in native code. See:
http://www.matasano.com/articles/javascript-cryptography/
There have been proposals to add a crypto API to browsers, where such API would be implemented in native code. I.e. you could call the API from JS, but the algorithms would all run in native code. I don't know if any of these proposals will go anywhere.
Conceivably, one could also just up and write C modules for popular browsers. But then you'd have to get those accepted by the browser makers.
Either of these solutions is beyond the scope of what I envision, at least for now.