[Last call] Re: [Chandler-dev] Shipping ticketed-URLs around for individual items via email

[Grant Baillie]

On 29 Feb, 2008, at 11:20, Mimi Yin wrote:

> Any thoughts about this? I'm inclined to just ship the tickets  
> around for now and re-address this security issue after 1.0 with a  
> more robust fix.

The only thing I could think of would be to include in the detail view  
something that looked like:

Include tickets: [ ] Read     [ ] Write      [?] What's this?

This would only be shown for mail items that had been shared by you, I  
guess.

--Grant

>
> On Feb 26, 2008, at 10:45 AM, Mimi Yin wrote:
>
>> 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