On 05/05/15 21:13, Jonas Sicking wrote:
> The problem is that even if we did what you propose above, it would
> still have security problems. Say that a user, Adam, who works at
> Bankers'r'Us, goes to the website evil.com
. At this point, evil.com
> could include the IMAP library and then connect to any IMAP server
> inside Bankers'r'Us corporate firewall.
I see. The problem is the bit in Anne's post where he explains that it's
not possible for the browser to know which hosts are internal and which
hosts are not. That is frustrating.
wouldn't get far on that IMAP server without IMAP login
credentials; making accesses in new contexts credentialless might help,
but wouldn't solve the entire problem. Some sensitive content inside
firewalls is credentialless.
We can't even check that the domain name is a public one (on the PSL)
because some sites use publicly-rooted names for their internal machines.
> But at this point that IMAP library has now become more of a web
> platform API, and less of a plain JS library. So why not just
> introduce a IMAP API? After all, we'd need to do as thorough audit of
> that IMAP JS library, as we'd do on the Gecko-implemented IMAP API.
Would we? Or would we only need to audit the part which made sure the
library wasn't able to make arbitrary TCP connections?
In a sense, I guess perhaps what I'm suggesting (for TCPSocket at least)
is a set of signed firewall rules that only permit safe connections for
a particular application - if that's even possible - because then, the
request message can be much better than "Do you want foo.com
to be able
to use TCPSocket", which no-one understands. It could be "Do you want
to be able to access the IMAP mail server at bar.com
", which is
much more understandable.