Re: [SPAM] Re: [SPAM] Re: Joins on capabilities that have passed through different membranes
Sandro Magi <[email protected]> Wed, 20 Jan 2016 10:11:33 -0500
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
--===============8683840138655450761==
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 20/01/2016 12:14 AM, Kenton Varda
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOP=3D4wiuCAEyD5jk9s=3DwQHUVSH62B3u6MTMp5DHnmUzrwGRxQw@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">I don't think "If people understand email
attachments they can understand caps" is a good argument.</div>
</blockquote>
<br>
No one made this argument. The argument made was specifically about
the usability of the UI pattern of opening a document in read-only
mode because it was opened with another person's authority. The fact
that this pattern has existed for over 10 years and few have
clamoured for this default to change should be evidence that it's
usable enough, contrary to the original claim that it would be
confusing.<br>
<br>
<blockquote
cite=3D"mid:CAOP=3D4wiuCAEyD5jk9s=3DwQHUVSH62B3u6MTMp5DHnmUzrwGRxQw@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>Email attachments have significantly higher cognitive
overhead than Google Docs does today. Yes, a lot of people get
it, but at a mental cost, and some people (probably, people
that people like us rarely interact with) could never handle
it at all. Google Docs is widely considered to be a huge
improvement over that world.</div>
</div>
</blockquote>
<br>
If Google Docs truly had *significantly* lower cognitive overhead,
then everyone would be using it, and there would be plenty of clones
of it competing for this influx of users. I've seen no such
evidence. Microsoft has its own online office suite, but still
boasts brisk sales of offline Office software.<br>
<br>
Having personally used Google docs many times, I will merely say
that it has advantages and disadvantages, but that local office
suites and e-mail isn't going anywhere anytime soon. It's still the
default at every one of my clients, in fact.<br>
<br>
I have no real opinion on the viability of capability merge, but I
will say that users misuse their authority on behalf of others all
the time. I've dealt with many situations in which they mistakenly
gave customers discounts they shouldn't have, approved purchases
beyond what they reasonably should have, and plenty more. And these
weren't uncommon either, to the extent that clients wanted mandatory
controls to prevent most such mistakes.<br>
<br>
I would not be surprised at all if users were susceptible to
confused deputies, but I certainly think it's a worthy experiment
because of the potential usability benefits.<br>
<br>
Sandro<br>
<br>
<blockquote
cite=3D"mid:CAOP=3D4wiuCAEyD5jk9s=3DwQHUVSH62B3u6MTMp5DHnmUzrwGRxQw@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">And IMO, there really isn't a good reason. If we'r=
e
going to argue that humans are susceptible to confused deputy,
we need examples, but I've never heard of one. (This is in stark
contrast to computers, where we have an endless list of
examples.)
<div><br>
</div>
<div>If we fight battles where we don't have strong evidence to
back our case, people will stop taking us seriously.</div>
<div><br>
</div>
<div>So, I choose to concede this one.</div>
<div><br>
</div>
<div>With that said, if someone did come up with real evidence
that confused deputy is a problem for humans, it would not be
hard to adjust Sandstorm to work differently. Our model is
primarily capability-based under the hood, with automatic
merging built on top as a feature.</div>
<div><br>
</div>
<div>-Kenton</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Sun, Jan 17, 2016 at 12:42 PM, Mike
Stay <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]" target=3D"_blank">stay@goog=
le.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_default"
style=3D"font-family:arial,helvetica,sans-serif">I have
issues with their claim as well; in particular, I don't
think they ever tried making it a coherent caps-based
system, but tried to use some caps-like ideas in their
existing system.</div>
</div>
<div class=3D"gmail_extra">
<div>
<div class=3D"h5"><br>
<div class=3D"gmail_quote">On Fri, Jan 15, 2016 at 6:44
PM, Sandro Magi <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:[email protected]"
target=3D"_blank"><a class=3D"moz-txt-link-abbrev=
iated" href=3D"mailto:[email protected]">[email protected]</a><=
/a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I=
'm
skeptical of this UI claim. This behaviour is
exactly what happens when people open Word
attachments directly from some e-mail clients. An
additional strip at the top says you're in
read-only mode, and provides a button to begin
editing. This pattern has clearly existed for many
years already, and persists to this day, so it
can't be so confusing as to be unusable.<span><font
color=3D"#888888"><br>
<br>
Sandro</font></span><span><br>
<br>
On 05/01/2016 2:46 PM, Mike Stay wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin=
:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp
<<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]"
target=3D"_blank">[email protected]</a>>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
Marc Stiegler came up with a clever UI
affordance to make all this clear.<br>
If Ihab views the document with Kenton's
capability, Ihab sees a ro view.<br>
If Ihab opens it with his own, he sees a rw
view.=A0 In either case, he see<br>
the same document, which reduces any
possible confusion.=A0 Since Ihab does<br>
have write permission, his UI has an Edit
button (actually a tab in<br>
Stiegler's UI).<br>
</blockquote>
Google's UI researchers claimed to us that
people would get a<br>
read-only view from somewhere and then be
confused when they couldn't<br>
edit it, even when there was an edit button.=A0
People don't look for<br>
controls they don't expect to need.<br>
</blockquote>
<br>
<br>
</span>
<div>
<div>
_______________________________________________<br>
cap-talk mailing list<br>
<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]"
target=3D"_blank">[email protected]</=
a><br>
<a moz-do-not-send=3D"true"
href=3D"http://www.eros-os.org/mailman/listin=
fo/cap-talk"
rel=3D"noreferrer" target=3D"_blank">http://w=
ww.eros-os.org/mailman/listinfo/cap-talk</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<div><br>
</div>
</div>
</div>
<span class=3D"HOEnZb"><font color=3D"#888888">-- <br>
<div>Mike Stay<br>
<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]" target=3D"_blank">s=
[email protected]</a></div>
</font></span></div>
<br>
_______________________________________________<br>
cap-talk mailing list<br>
<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]">[email protected]=
s-os.org</a><br>
<a moz-do-not-send=3D"true"
href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk"
rel=3D"noreferrer" target=3D"_blank">http://www.eros-os.org=
/mailman/listinfo/cap-talk</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
cap-talk mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]=
s.org">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.eros-os.org/mailman=
/listinfo/cap-talk">http://www.eros-os.org/mailman/listinfo/cap-talk</a>
</pre>
</blockquote>
<br>
</body>
</html>
--===============8683840138655450761==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
--===============8683840138655450761==--