[cap-talk] Google Chrome - web browser with sandboxed rendering

Ben Laurie benl at google.com
Sat Sep 6 16:46:16 CDT 2008


On Sat, Sep 6, 2008 at 8:19 PM, Raoul Duke <raould at gmail.com> wrote:
>> The problem with this design, though, is that it relies on the user to
>> know that "aha, if an app wants to use the POP3 prototocol, then I
>> should insist that it uses the trusted POP3 component". Tying this to
>> port 110 is obviously not a great idea, so we're back to UI that is
>> going to confound most users, surely
>
> didactically, why should the have a choice to ever do anything that is
> not secure?
>
> decision making is complicated, and the more choices there are the
> more complicated it is. computer systems are entirely too configurable
> and thus nobody can make any hard and fast rules. thus nobody can make
> a system which gets it all right and doesn't have to involve a human
> decision maker somewhere along the way. which means the end user,
> which inevitably means trouble (even when the end user is somebody
> with a clue - we aren't able to make the right choice at all times of
> course).
>
> if we could present the user with a dialog box that says "do you want
> to the secure thing, or the insecure thing, with this POP connection?"
> [assuming they should know or care about what POP is] then we should
> not show that dialog box but instead just of course do the secure
> thing. such ability is empirically not accomplished with current
> systems.

How do we know it is a POP connection? If the application claims to
need to use some advanced version of POP your OS doesn't support, then
what?

> thought experiment: somebody comes up with a new alternative to the
> internet and to operating systems and user interfaces. the alternative
> is designed to not be so configurable to prevent confusion via choice;
> it is designed to require security measures before one can participate
> in the system. is such a thing possible? would the barrier to entry
> prevent anybody from using it? (a) people say they want security but
> often only after the fact; i dare say if security measures make things
> hard to use they'd rather skip them and get on with their task, so
> unless this alternative system is brilliant from a usability/ui
> perspective, it will not have clients. (b) even if you could make sure
> that yes we prevent all phishing, you'd still not be able to guarantee
> that the end-system is not compromised, or that the entire db of user
> information won't be left on a cd on the london tube for the taking.
>
> we need to figure out where and how choice should be allowed
> (essential choice vs. overcomplicated and wrong and confusing and
> therefore only going to all end in tears choice), and we need to be
> clear about what layer or aspect of security we are addressing, both
> when we think things through ourselves, but also when we talk with
> users.
>
> sincerely.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>


More information about the cap-talk mailing list