Re: Google Docs as capabilities as data

Dirk Pranke <[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <CAEoffTA5AZQkvSLuDoMHX0yCdcXKykD5Oe5xK+jtdaHkET0+=Q@mail.gmail.com>
On Mon, Jan 27, 2014 at 4:30 PM, David Barbour <[email protected]> wrote:

>
> On Mon, Jan 27, 2014 at 6:09 PM, Dirk Pranke <[email protected]> wrote:
>
>>
>> Perhaps this is because once you actually have to add the UI to manage
>> revocation (and the UI to manage individuals, groups, and all that other
>> fun stuff), the advantages of webkeys (and other easily transferable caps)
>> don't seem to great (at least from a user experience point of view)?
>>
>
> This hypothesis seems unlikely. Visibility and revocability are central
> principles of usable security. And the UI for revocation or independent
> distribution doesn't need to be obtrusive.
>
>
Perhaps I should elucidate further. Non-webkey-based access control looks
something like:

1) Figure out ACLs desired for my quarterly earnings report
2) Figure out where I want to store the report (e.g.
https://example.com/financials/2014_q1.xls)
3) Ensure .htaccess is set up so that the right people have access.
4) Stage the doc there.
5) Send out email containing link to 2014_q1.xls
6) Click on link
7) Check ACLs
8) Return the file

In a web-key world, you have:

1) Figure out ACLs
2) Figure out where to store the report
3) Ensure .htaccess is set up right
4) Ensure that that is locked down so that no one can access this w/o a
webkey.
5) Stage the doc
6) Figure out how to generate the right webkeys
7) send out *multiple* emails w/ the right web keys
8) Click on link
9) Check to ensure link is still valid and redirect to underlying document
10) Send return file

Note that steps 6) and 7) are new, and there is still a check at access
time to ensure that access is still permitted.

On the other hand, if you only have a single web key, the whole flow is:

1) Figure out where to store the report
2) Stage the doc
3) Send out the email
4) Click on link
5) Return the file.

Which is substantially easier than *either* of the other flows. In other
words, the single-webkey flow has clear UX benefits over the
non-webkit-flow (no ACL screen), but the multiple-webkey-revocation screen
does not.

Obviously, adding ACLs adds complexity and that part is unavoidable. And,
it's certainly possible to implement tools and infrastructure that makes
both of the first two flows roughly have the same UI.

However, it's not immediately clear in this scenario that you're really
getting much for your buck by using webkeys in addition to ACLs. Thinking
purely from the "lazy developer" standpoint, you can understand why someone
implementing a new system would implement either the single-web-key flow or
the commonplace flow first, then maybe the other, and never quite get to
the "use webkeys for everything" flow, I think.

-- Dirk

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.