croodle

croodle copied to clipboard

Some polls run for quite some time until evaluated. It would be great to have possibility to update votes for each user after having voted because things may have changed (made up once mind / got new appointment so croodle vote needs to be updated). I see two possibilities:

• every participant can edit every vote (easier to implement)
• every participant gets its own link for later editing only her own vote (harder to implement, people may find it to difficult to user [remember link...])

P.S.: Thanks for this great app!

Is related to #57. Both are definitely on my roadmap. I guess I will implement it in two steps:

First introduce an editable property for polls. If it's selected on creation every user knowing the encryption passphrase would be allowed to edit poll and votes.

Later I will add a moderated property. If a poll is editable and moderated only users knowing/having a secretes are allowed to edit poll and votes. I tend to a password entered at poll creation to handle authorization. It could be stored in locale storage, be part of a special moderator link or entered by user.

Allowing users of a moderated poll to edit only there own votes seems to be the hardest case from UX perspective. Not quite sure yet, how to handle this one best.

This is really pretty essential. We quite often run into people having a schedule change and needing to update their poll answers.

I would suggest creating an issue for this with a list of things that need to be done to implement this (actionable items), so that others can help get this done quicker. I'd definately invest time into this if I knew what your plan is and where to start or what's currently blocking this.

@dakira I agree that this feature is really needed and appreciate that your are willing to help. Before we can start to implement, we need to make some design decision. I'm not quite sure which way to got yet and will therefore outline some ideas.

I guess most important first step is to decide for an authentication and authorization strategy. Both isn't implemented yet. Since there isn't any possibility to edit or delete polls and participations it wasn't needed yet.

I think editing and deletion of polls and participations could be split up in two topics:

1. Edit and delete a poll.
2. Edit and delete a participation.

Authentication and authorization could therefore be implemented in three ways:

1. Allow everybody, who has the right to participate in a poll, to edit and delete it and all related participations. This could be called unmoderated.
2. Allow only some users to edit and delete a specific poll and all participations. Lets call this one moderated and the people who are allowed to do it moderators.
3. Allow people in a moderated poll to edit and delete only there own participation. Lets call this one owner only.

The first one seems to be the simplest case. We wouldn't need to authenticate a specific user and we already have a shared secret among all people having the right to participate in a poll: the encryption passphrase stored in URL.

Of course the user would have to proof his key knowledge against api without disclosing the key. There are different strategies we could use:

1. I guess the simplest approach would be another passphrase which is generated while creating a poll and is stored both encrypted and unencrypted by api. Api would only include the encrypted passphrase in response. A user would have to include the unencrypted passphrase in every edit / delete request and api would authorize action based on it. Croodle is using 256bit AES to encrypt the poll and that one is known to be safe against known plain text attacks. So the biggest pro would be not to mass around with the encryption.
2. We could split up encryption key derived from encryption passphrase by key derivation function (sjcl.encrypt uses PBKDF2). The first part could be used to encrypt the poll and the second part to proof key knowledge against api. In these case we couldn't rely encrypt and decrypt methods of Stanford Javascript Crypto Library which provide a well peer-reviewed default. This is the biggest disadvantage in my point of view. It would break backward compatibility also. But a pro might be that we could use it not only for editing and deleting but also for retrieving.

Giving only some people the right to edit / delete polls or participations (moderated or owner only) would add another level of complexity. User experience enters the game. We need a smooth way to authenticate a user. A user defined password? A special link like doodle does for moderated which contains a moderator secret? Just store it in browsers local storage? Or perhaps a combination of this ones? I'm absolutely not sure...

@jelhan I think Croodle should try to be a simple as possible (e.g. no real user accounts). So:

• for the beginning I would just go with the unmoderated poll and allow that as an option on poll-creation (I wouldn't allow for deleting the poll, though). Authorization does exist with the poll-id/encryption key combo.
• in the second case the owner-only model seems to add too much complexity for such an edge case so I would chose the moderated approach here.

Adding a second passphrase to authenticate edits seems like a reasonable approach. Your second suggestion goes beyond my expertise. ;)

We need a smooth way to authenticate a user.

Special links would be a simple way to go. I'm not sure if I like it, though. People lose these links. It might be more user-friendly to allow the moderator to set a passphrase. This passphrase could be stored the same way as the extra passphrase for an unmoderated poll, except it's not included in the encrypted data so that regular users don't have access to it.

I have very little javascript knowledge so I'll check out the API this weekend.

Adding to the above: Lets call the separate passphrase editToken and throw a deleteToken into the mix. Whether the moderator uses these by link or by password (which would have to generate the token) this would allow for a little more flexibility.

Okay, lets put it together.

Key knowledge

We add another property which is used to proof key knowledge. This one is stored encrypted and unencrypted in api. The encrypted one is send to client which decrypts it and includes it in edit / delete action to proof key knowledge. If a poll is unmoderated key knowledge is used to authorize edit and delete actions.

Note that there is already a property which value is stored encrypted and unencrypted: expirationDate and serverExpirationDate.

Proof of key knowledge could also be used to authorize poll participations. Currently an attacker is able to participate in a poll even without knowing polls encryption passphrase. That's not a big deal since wrongly encrypted participations are simply ignored, but adding a proof of key knowledge would add another layer of security.

editToken and deleteToken

We add an editToken and a deleteToken to apis poll model. They are used to authorize edit and delete actions in a moderated poll. They are generated on client-side by a password and never included in a response. They maybe stored in local storage of client.

Note that we could also add editToken and deleteToken to apis user model, which would allow a owner only strategy for editing / deleting participations.

Generating tokens from password should include password hashing on client-side. Since we shouldn't overwhelm weak clients (e.g. smartphone) we can't make it really strong. Therefore api should hash it again.

I don't think we have to care about reply attacks since croodle should only be served over https.

I would appreciate if you help with api implementation and would try to implement it on client as soon as possible.

Great, I'll have to read through the souce a bit more and will submit a WIP pull request soon.

Any progress on this?

Any progress on this?

Unfortunately not. :disappointed: I know that is one of the most missed features but my current focus is stabilizing and improving the existing feature set - especially from an UX perspective. PRs are very welcome! I'm happy to have a detailed chat on the design with anybody who is willing to work on this feature. :telephone_receiver:

Editing polls is not planed for the foreseeable future. Planing to provide a clone/fork feature instead, which allows to create a new poll reusing the settings of another one. Please have a look at #57 for details.

it is such a pitty, as the whole tool is more or less useless without this feature! i am sure this feature would be much more important to be implemented than stabilizing or improving anything. nobody will ever need that more stabil or improved thing as long as the whole tool is simply not useable!

i am sure this feature would be much more important to be implemented than stabilizing or improving anything. nobody will ever need that more stabil or improved thing as long as the whole tool is simply not useable!

I understand your frustration. It would be awesome if we could get this shipped quicker. Please let me know if you could help with the implementation. Having people that are willing to work on this project without getting paid is critical to get this and other features shipped.

Please understand that the roadmap has to be done by the maintainers of the project. Especially if it comes to technical debts and maintainability concerns. Shipping new features without addressing technical debts won't work out in the long term. At least that's my experience. No one likes to work on a messy code base - especially not in their free time. And if one is willing a lot of time will be lost in getting familiar with the code.

Having that said any PR implementing the edit functionality is very welcome. Please reach out to me if you are willing to work. Send me a direct message on Twitter or write me on Ember Community Discord.

sorry, i wrote a polling-system - filling my needs - already myself.

i implemented it this way (maybe it helps): when the creator of a poll adds a user (email) to it, he sees a link, he can press. pressing the link opens a 'mailto:..' including subject and body and in the body there is a unique link to the poll. so there is not only unique id for poll and unique key for encryption but additionally a unique key for user. this user-key is stored together with the poll at the server, so server knows, if the user is allowed to participate by crawling the url called...

Am 19.12.2019 um 20:26 schrieb Jeldrik Hanschke [email protected]:

i am sure this feature would be much more important to be implemented than stabilizing or improving anything. nobody will ever need that more stabil or improved thing as long as the whole tool is simply not useable!

I understand your frustration. It would be awesome if we could get this shipped quicker. Please let me know if you could help with the implementation. Having people that are willing to work on this project without getting paid is critical to get this and other features shipped.

Please understand that the roadmap has to be done by the maintainers of the project. Especially if it comes to technical debts and maintainability concerns. Shipping new features without addressing technical debts won't work out in the long term. At least that's my experience. No one likes to work on a messy code base - especially not in their free time. And if one is willing a lot of time will be lost in getting familiar with the code.

Having that said any PR implementing the edit functionality is very welcome. Please reach out to me if you are willing to work. Send me a direct message on Twitter https://twitter.com/jelhan1 or write me on Ember Community Discord https://discord.gg/emberjs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jelhan/croodle/issues/98?email_source=notifications&email_token=AOCTZMX6M7JXJ45DFGYKWLDQZPDGJA5CNFSM4CF3HMAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHKVGXI#issuecomment-567628637, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCTZMU4LSH53QZWHWWSZATQZPDGJANCNFSM4CF3HMAA.