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

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sun Sep 7 13:28:58 CDT 2008


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.

Yes, but there's no need to limit this to install-time.

> At application launch, the trusted resolver creates the sockets, then
> passes them to the application. This doesn't constrain the traffic over
> sockets, only the addresses that are resolved.

Without constraining the traffic, the application has to have the
username/password in order to log into the account. The password is
likely to be reused between accounts (mine is, and I'm quite
security-conscious). So it's clearly more consistent with POLA to
grant access to logged-in sessions, and reserve the ability to
open an unconstrained socket to a given address/port as a fallback
for less common protocols.

-- 
David-Sarah Hopwood


More information about the cap-talk mailing list