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

Rob Meijer capibara at xs4all.nl
Sun Sep 7 17:29:24 CDT 2008


On Sun, September 7, 2008 16:46, Sandro Magi wrote:
> David-Sarah Hopwood wrote:
>> I don't actually see that having to specify an email protocol manually
>> (from, in practice, two alternatives -- POP3 and IMAP) is very high on
>> the list of things that are irritatingly complicated about current
>> computing systems.
>>
>> We definitely don't want to fix a single protocol. Competition between
>> protocols is good. In practice the user has to be instructed by their
>> ISP on how to fill in the server/account details, so one extra field
>> is neither here nor there. [...]
>
> It seems clear that as long as address resolution is in a trusted
> component, then an install-time configuration can endow any application
> with sockets the user specifies. The user has to specify SMTP,
> POP3(S)/IMAP(S) servers anyway to set up their accounts, so a standard
> powerbox interface for such TCP/IP endowments invoked at install-time
> seems workable to me.

You could also look at the POP/IMAP case as an example of decomposition of
authority, where it should be possible to shield this information from the
user. If the user has a bunch of services (ftp, secure shell, POP. IMAP,
VOIP) that her ISP offers her, you could probably think of some protocol
between powerbox and ISP that would allow the user to delegate proper
POP/IMAP access to the mail client without ever getting exposed to any of
the details. So the user logs in to some ISP abstraction, asks the ISP
abstraction for a thingy it can delegate to its mail client and than
delegates that thingy to the mail client.

Rob



More information about the cap-talk mailing list