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
