From: [...] Daniel Vainsencher First, we don't represent the board, so we don't make their impression, they do.
No; we are merely constructing an artifact, partially on their behalf.
But I agree with what you say - we don't want to create artificial delays in the progress on the security front, because it determines when the system starts being a real tool for the community.
On the other hand, you don't at all address my reason for keeping security out - it is complicated. And for a system to succeed, nothing is more important than that it be simple in the beginning. Simple so implementation gets finished, simple so people get it enough to see why its useful.
"Everything should be as simple as possible, but not simpler than that." -- Einstein
For a system to succeed, in my experience, it has to be sufficiently useful to its target audience that the members of that audience are each willing to invest the effort required to make the system work. Typically they are willing to invest that time because there is benefit to themselves.
Let's try a different artifact. Most 'mildly-secure' systems consist of the following:
- Registration with username and password;
- A request for an email address;
- A challenge to that email address to check that someone there sent the request;
- An admonition not to publish the password;
- A requirement to log in with username and password in order to make use of the secured resource.
This is absolutely not hacker-proof - I could compromise it in many different ways. Yet, for voting, it probably wouldn't be worth my while. So let's consider that our target for a 'mildly-secure' system for a moment and see how much of it we already have:
- SqP already asks for username/password/email;
- SqP does not validate the email address;
- SqP already requires secured access in order to make use of the secured resource;
- SqP already has things on which one can register an opinion, namely people and projects.
OK, so how about adding 'referenda' as a new kind of thing on which opinions can be registered, giving people the option to validate their email address, and calling that system our 'version 1' voting system? Yes, I accept that we still have to construct our initial set of voters; but I suspect that is going to be the case with any system, and I note that it is conceptually independent of any existing ranking system on SqP.
Doing security right requires more time and expertise than I can muster, so we need someone else to do/push that one. Do you want to?
Within the time I have available, and with the understanding that I am paranoid, have worked on security in the past, but cannot be considered a security expert... I'm willing to do so.
I will update the spec to allow the voters to be specified as a simple string, with 'dvf danielv@tx.technion.ac.il 123456 ls lex@lexspoon.org 654321 ?? Peter@ozzard.org 346098' as the initial value.
Agreed?
Not yet - I'd like some clarification. What are the values here? The first set appear to be initials, and may correspond to an account on SqP (although my usename on SqP is not my initials). The second is an email address. The third?
- Peter
Peter Crowther wrote:
Let's try a different artifact. Most 'mildly-secure' systems consist of the following:
[snip] You're right. That kind of security is probably doable without killing the project. It might not be good enough for money handling or legally binding stuff, but it probably is for all kinds of decisions the community is trying to make now.
This is absolutely not hacker-proof - I could compromise it in many different ways. Yet, for voting, it probably wouldn't be worth my while. So let's consider that our target for a 'mildly-secure' system for a moment
On this we agree. Do you mind updating the minnow page to reflect these requirements? I propose to place it with the non-functional requirements, rather than mess up the functional workflow description.
and see how much of it we already have:
[stuff SqP does]
OK, so how about adding 'referenda' as a new kind of thing on which opinions can be registered, giving people the option to validate their email address, and calling that system our 'version 1' voting system? Yes, I accept that we still have to construct our initial set of voters; but I suspect that is going to be the case with any system, and I note that it is conceptually independent of any existing ranking system on SqP.
Here I don't quite understand your intention. Do you mean to extend SqP itself? note that it is not Squeak, so some Squeakers won't hack it directly. Anyhow, Cees has built several systems based on an interface to SqP that exposes some of its objects, including the trust and users. I haven't looked at that interface to see what it exposes exactly yet.
Anyway, I think the first thing is to make sure we can live with the initial requirements list, and then let move to implementation. For that I was going to ask on the Squeak list for volunteers, unless one of you wants to tackle it yourselves. In the case where someone else is doing it, there's no point in making too many implementation decisions now.
Within the time I have available, and with the understanding that I am paranoid, have worked on security in the past, but cannot be considered a security expert... I'm willing to do so.
Great!
I will update the spec to allow the voters to be specified as a simple string, with 'dvf danielv@tx.technion.ac.il 123456 ls lex@lexspoon.org 654321 ?? Peter@ozzard.org 346098' as the initial value.
Agreed?
Not yet - I'd like some clarification. What are the values here? The first set appear to be initials, and may correspond to an account on SqP (although my usename on SqP is not my initials). The second is an email address. The third?
I meant it to be an initial mock password, useful for our testing the 0.5 version. But its your call now... :-)
Daniel
On Sun, 2006-01-01 at 21:42 +0200, Daniel Vainsencher wrote:
Do you mean to extend SqP itself? note that it is not Squeak, so some Squeakers won't hack it directly. Anyhow, Cees has built several systems based on an interface to SqP that exposes some of its objects, including the trust and users. I haven't looked at that interface to see what it exposes exactly yet.
Terminus
http://map.squeak.org/package/67ff1f57-94f6-4db6-baed-5ff080727179
Ken
"Peter Crowther" Peter@ozzard.org wrote:
OK, so how about adding 'referenda' as a new kind of thing on which opinions can be registered, giving people the option to validate their email address, and calling that system our 'version 1' voting system? Yes, I accept that we still have to construct our initial set of voters; but I suspect that is going to be the case with any system, and I note that it is conceptually independent of any existing ranking system on SqP.
That sounds like a great way to run votes if the manpower is available to make it happen. I would actually feel comfortable using a wiki page (with history logged) to get started, but running votes on Squeak People, using SqP accounts, sounds even better.
In the long run, it would seem even nicer to use public key cryptography. That would allow other services to use aunthetication without requiring Squeak People to support the feature itself. But that's a long term idea, at least 6 months off, probably more like a year.
Peter's detailed analysis and suggestions from the email seem great to me....
I'll toss out that it would also be dandy to record membership and application archives on Squeak People, regardless of the specific membership system we choose. Again, a wiki page would be enough, but a few choice web services could make it all work really smoothly.
-Lex
elections@lists.squeakfoundation.org
-
Daniel Vainsencher -
Ken Causey -
Lex Spoon -
Peter Crowther