I’m a little surprised and disappointed by your tone.
I don’t want to go into a detailed description correcting what, in my opionion, sounds like an attempt to diminish the work that we do here at PassPack.
Right now I’m not peased, so I’m going to limit myself to saying that I find your analysis is imprecise, borderline incorrect. We can address these issues in due time (we’re working on a developers center that should see the light in September sometime). I will, however touch on some key points below:
1. “Zero Knowledge Methodology” is not a recognized industry standard.
It’s your invention, and as far as I know, there is no public or community accepted definition of it’s rules, principals or standards anywhere. PassPack is not, nor does it strive to be, a Zero Knowledge Application. We do strive to protect our users privacy and security, but we do not pretend that we can do this without any knowledge.
Let me ask you a question. Your web server is based in Colorado. What happens if the US government decides to search through your provider’s logs? You can’t do a thing to stop them, you’re under their legislation, and your provider is required by law to comply. They’ll find the IP addresses of all of your users, and easily use this data to arrive at them - know who they are, when they connected, how data much (in kb) they transfered, and from where. Is that Zero Knowledge?
Just because you don’t know anything about your users, doesn’t meant that no one does. Where is the “zero knowledge” line drawn? Zero knowledge, while a respectable ideal, is unfortunately an unattainable utopia. At PassPack we work very hard to find a real world balance between flexibility, privacy, usability and security - that’s attainable.
2. PassPack’s primary objective is Privacy.
All of our choices are made with the highest regards to user privacy and data protection. Any insinuation to contrary is not only incorrect, but offensive as well.
In particular, I’ll briefly point out that:
The links stored in the auto-login database to not necessarily point to any given user. Many (about 1/3) have been inserted by us to facilitate the proccess.
Teaching websites is optional. No usernames or emails are stored in the autologin database. A Client Code is, and this is to protect the security of the entire community in the event of an attempted abuse of the system.
The “bridgelet key” can be regenerated on the installation screen.
The PassPack It! button has been amply tested for various types of attacks. A number of security measures are in place which we’ll happily discuss as soon as we get the developer center up and running. Regardless the tool is optional and is not even activated by default (should a user wait to learn more first).
Yes, the auto-login is centralized through PassPack. This helps to avoid “every user for himself” scenarios, and lets users benefit from those who came before them, as well as from the efforts of PassPack in pre-training some important websites.
The advantages to our approach are many. It allows us to constantly fine-tune the tool in a way that is completely transparent to the users. We can, and have, added the ability to login to many more types if sites. It’s a continual evolution. In a worst case scenario, they’ll have to update their button, but certainly not recreate their entire lists of captured logins. It’s feasible that a year from now, few new PassPack users will have to do any “teaching” at all.
In general, I can say this of PassPack’s auto-login tool: Our goal is to obtain a user experience similar to using a browser plugin - but without the plugin. We’ve just this morning released a 1 click version which achieves just that: http://tinyurl.com/2bpxgx
This plugin-type approach allows users to login to the large majority of HTML based forms, including far more than Clipperz direct login can handle. Try this: make a list of sites that wont’ work with your direct login and try them on PassPack. You’ll be surprised at the results.
Regards to you and Giulio Cesare. Perhaps when you get back to Rome we can talk about it over a glass of wine. And after this stunt… you’re buying [wink].
A little surprised and disappointed
Hi Marco,
I’m a little surprised and disappointed by your tone.
I don’t want to go into a detailed description correcting what, in my opionion, sounds like an attempt to diminish the work that we do here at PassPack.
Right now I’m not peased, so I’m going to limit myself to saying that I find your analysis is imprecise, borderline incorrect. We can address these issues in due time (we’re working on a developers center that should see the light in September sometime). I will, however touch on some key points below:
1. “Zero Knowledge Methodology” is not a recognized industry standard.
It’s your invention, and as far as I know, there is no public or community accepted definition of it’s rules, principals or standards anywhere. PassPack is not, nor does it strive to be, a Zero Knowledge Application. We do strive to protect our users privacy and security, but we do not pretend that we can do this without any knowledge.
Let me ask you a question. Your web server is based in Colorado. What happens if the US government decides to search through your provider’s logs? You can’t do a thing to stop them, you’re under their legislation, and your provider is required by law to comply. They’ll find the IP addresses of all of your users, and easily use this data to arrive at them - know who they are, when they connected, how data much (in kb) they transfered, and from where. Is that Zero Knowledge?
Just because you don’t know anything about your users, doesn’t meant that no one does. Where is the “zero knowledge” line drawn? Zero knowledge, while a respectable ideal, is unfortunately an unattainable utopia. At PassPack we work very hard to find a real world balance between flexibility, privacy, usability and security - that’s attainable.
2. PassPack’s primary objective is Privacy.
All of our choices are made with the highest regards to user privacy and data protection. Any insinuation to contrary is not only incorrect, but offensive as well.
In particular, I’ll briefly point out that:
The advantages to our approach are many. It allows us to constantly fine-tune the tool in a way that is completely transparent to the users. We can, and have, added the ability to login to many more types if sites. It’s a continual evolution. In a worst case scenario, they’ll have to update their button, but certainly not recreate their entire lists of captured logins. It’s feasible that a year from now, few new PassPack users will have to do any “teaching” at all.
In general, I can say this of PassPack’s auto-login tool: Our goal is to obtain a user experience similar to using a browser plugin - but without the plugin. We’ve just this morning released a 1 click version which achieves just that: http://tinyurl.com/2bpxgx
This plugin-type approach allows users to login to the large majority of HTML based forms, including far more than Clipperz direct login can handle. Try this: make a list of sites that wont’ work with your direct login and try them on PassPack. You’ll be surprised at the results.
Regards to you and Giulio Cesare. Perhaps when you get back to Rome we can talk about it over a glass of wine. And after this stunt… you’re buying [wink].
Tara