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