I haven't read Brian's note in the bug yet, but shipping item-URLs around without the knowledge of the user does occur to me like trading one security problem with another. Feels like a break in trust between Chandler and users. I'm not caught up on the list at the moment, my point may have been made already or may be obsolete, but just wanted to weigh in nontheless.
-Andre On Tue, 26 Feb 2008 10:45:17 -0800, "Mimi Yin" <[EMAIL PROTECTED]> said: > So the difference between shipping ticketed item-URLs around and > ticketed collection-URLs via email is that the user explicitly emails > the collection URLs to others whereas here, we're proposing that we > ship item-URLs around without the knowledge of the user. I don't see > a good way around this from a user workflow standpoint. > > We could essentially nix item-sharing via email edit/update and > change the UUID of the item on the recipient's end (if the the > recipient isn't sharing the item with the sender through a shared > collection) so that automatic updating of items via email stops > working. But I fear even that would be hard to get right. For > example, what if the recipient receives the emailed version of the > item in Chandler first, Chandler changes the UUID of the item and > then they syncs the shared collection. They will end up with dupes of > the same item. > > We could pop-up a warning (one that most users probably won't really > understand) with a '[x] Never show again.' option when users send > email from Chandler. > > We could flag this as an issue in release notes. > > Any other thoughts? > > Mimi > > On Feb 22, 2008, at 10:34 AM, Grant Baillie wrote: > > > (Redirecting to chandler-dev, since it seems to be a more product- > > general issue) > > > > On 21 Feb, 2008, at 13:42, Mimi Yin wrote: > > > >> Grant is going to investigate addressing 2 of the 4 issues > >> outlined here - http://lists.osafoundation.org/pipermail/cosmo-dev/ > >> 2008-February/005741.html, from the Desktop side. > >> > >> 1. In particular, he's going to ship read-write tickets around > >> with emailed items so that when users add items they've received > >> via email to collections that are on the Server, the Server will > >> accept those items. Otherwise, users might end up in situations > >> where they think they've added emailed items to published > >> collections, but other subscribers won't see them and they won't > >> see them if they check the collection on the web UI or on a > >> different machine. > >> > >> https://bugzilla.osafoundation.org/show_bug.cgi?id=11878 > >> ... > > > > In the bug, Brian Kirsch correctly points out that this could be a > > security issue; i.e. the emails can be easily sniffed for the read- > > write tickets we send. > > > > In somewhat more detail, the security threat here is that an > > eavesdropper would be able to monitor future changes to that item > > unbeknownst to the sharees, and could also cause troubles by > > changing the item on the server. I'd also note that we live with a > > similar (in fact more severe) threat when we send out read-write > > collections URLs. > > > > As I see it, we can address this by: > > > > 1. Convincing ourselves that we can live with the threat. In other > > words, we are OK given the combination of how rare we think said > > eavesdropping will be, and how severe the above consequences are. > > > > 2. Adding some kind of warning/confirmation UI (possibly tied to a > > preference) to the desktop client. > > > > 3. Designing and implementing something more secure here (probably > > out of scope, but if someone has a bright and easily implemented > > idea ...). > > > > 4. Living with the bug, i.e. not allowing users to add items they > > receive via email to new collections. > > > > Any thoughts here? > > > > --Grant > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > Open Source Applications Foundation "chandler-dev" mailing list > > http://lists.osafoundation.org/mailman/listinfo/chandler-dev > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "chandler-dev" mailing list > http://lists.osafoundation.org/mailman/listinfo/chandler-dev _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
