[Last call] Re: [Chandler-dev] Shipping ticketed-URLs around for
individual items via email
Grant Baillie
grant at osafoundation.org
Fri Mar 7 16:09:30 PST 2008
Hi, Mimi
I concur somewhat with Brian Kirsch's reply that the "something
radical" below would simplify a lot of the sharing interactions, but
also don't have much sense how important non-shared peer-to-peer Edit/
Update usage is. (It certainly is a rare case amongst us hub-centric
users).
If we did implement this, as I think Brian pointed out, we could avoid
sending eimml attachments with emails. On the other hand, it would
make POP accounts completely useless, since it sounds as if you're
proposing having Chandler not download any incoming email at all.
Also ... individual item sharing. Sounds yummy :D, but probably not by
1.0 I'm guessing.
--Grant
On 5 Mar, 2008, at 14:00, Mimi Yin wrote:
> Hi Grant,
>
> I started on a rather elaborate proposal for how users could share
> items via email read-write or read-only. But I'm now pulling back
> and wondering if this is really the mental model we want to present
> to users.
>
> I think Edit/Update today is usable because you don't really know
> too much about how it might or might not.
>
> For example:
> + Users may too casually restrict access to an item not realizing
> the workflows they'll miss out on. Recipients won't be able to edit
> and update the agenda to the same event, recipients won't be able to
> make local edits to the emailed item etc.
>
> + Recipients won't necessarily understand how to make it so that
> they're sharing the item unless we also implement a way for Chandler
> Desktop to automatically subscribe to items that arrive via email
> with sharing URLs embedded in them.
>
> No matter what we do, we still have the problem of: What happens if
> an user sends an item before it's shared. And then puts it on the
> server? OR, what happens if the recipient is the first one to put it
> on the server, thereby locking the original sender out of adding the
> item to the server?
>
> Here's something radical:
>
> - What if we 'turned off' pulling down email from other Chandler
> Desktop clients?
> - You can still receive emails from Chandler Desktop in your email
> client of choice
> - If you want to share individual items with others, you do it by
> putting it into a shared collection; OR
>
> - We make it all very explicit with the new item-sharing workflows
> where users can:
> + Publish individual items to the server
> + Send individual items to others with View-and-Edit or View-only
> sharing URLs
> + Recipients can click on the URLs and view them on Hub in a
> standalone detail view
>
> ...Eventually recipients will be able to subscribe to individual
> items with their Hub accounts and/or Chandler Desktop
>
> Open Issue:
> + What if you drag an email sent from another Chandler Desktop
> client into your Chandler via IMAP folders?
>
> I think the only use case that this breaks is Chandler Desktop User
> A wanting to share an item with Chandler Desktop User B via Email-
> Edit/Update-only, no shared collections. I think today, this is an
> edge case. The likelihood of someone running into another Chandler
> Desktop user out in the world via Chandler email is for better or
> worse, low. Meaning, most of the time, Edit/Update is being used by
> users who are also sharing collections as a way to 'PING' sharees
> about already shared items and/or a way to get information out to
> non-Chandler users.
>
> I believe this means we can get around having to ship tickets with
> individual email messages without mucking up sharing workflows
> (assuming we can work through the IMAP folder case).
>
> Mimi
>
> On Mar 4, 2008, at 7:11 AM, Grant Baillie wrote:
>
>>
>> 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
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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
More information about the chandler-dev
mailing list