On Thu, 04 Nov 2010 23:11:30 +0100, Nic Jansma <njansma@microsoft.com>
wrote:
> Hi everyone,
>
> We have several options for how we can define same-origin for the
> purposes of the NavigationTiming interface. I have listed out 4 of
> these options, along with their advantages/disadvantages and examples
> below.
Thanks for the nice overview.
I agree that both 2 (document.domain) and 4 (CORS) are complex to
implement (which will mean lots of bugs, and differences in how browsers
behave), and both are affecting the security of things unrelated to Timing
(which will mean lots of obscure security holes in sites). Further #4
(CORS) needs to add network headers to measure the performance, thus
changing the performance by measuring it, which might not be what web
developers want.
For the sake of completeness, #2 (document.domain) have the exact same
caveats as #3 (private domain) when it comes to the correctness of the
implementation, as document.domain will/should throw a security exception
if attempting to set it to a public suffix: "Current public suffix list
implementations are either heuristics or based on maintained lists, which
cannot be quickly updated, and are not perfect."
I think the best solution is to go for #3 (private domain), if not #1
(fqdn) as the other option. I am not in favour of either document.domain
or CORS. To comment on the listed disadvantages for #3.
> Loosest definition of same-origin.
For Web developers this is good.
For users, in the case of no shared domain: No effect
For users, in the case of shared domains: This is point three below
I'd be tempted to put this as an advantage instead ;)
> Current public suffix list implementations are either heuristics or
> based on maintained lists, which cannot be quickly updated, and are not
> perfect.
Current public suffix list implementations are what browsers use for
cookies today. Though not theoretically perfect, they are already in heavy
use, absolutely essential for for every single user, and working
flawlessly.
> Would allow different-owner sites of subdomains such as a.blogspot.com
> to get data about b.blogspot.com, with no way for b.blogspot.com to
> restrict access.
I claim that this is not an issue in practice. I also claim that we will
not be able to find any sites for which this is a real issue, even if we
look hard. For blogspot.com, it is not an issue.
* Such sites have much worse cookie problems already, as the cookies may
be shared[1]
* High profile sites (which are the typical target sites of attacks) do
not share their domain with someone else.
* Such sites tend to fall into one of two categories:
** Shared login (as for blogspot), scripting disabled (if scripting is
enabled, timing attacks are not the concern)
** Completely different sites (as for dyndns.org), low profile, few
users[2], not sensitive data (except for possibly private data behind a
login form[3])
* The potential privacy leak for the user is small, both in data, and
possible places it can leak to
* Sites which think this might be an issue, can do something about it, by
getting their own private domain or by getting an entry on the pubsuffix
list (as for operaunite.com).
[1] Which, though being much worse, has never been an issue, I'd be
surprised if anyone could even point to a writeup on the Web about the
issues and how to work around them.
[2] Timing attacks are mostly useless if directed at particular users, in
order to direct it, one needs to know more about the user than one would
obtain.
[3] Private data behind a login form would typically suffer from the much
worse cookie problems
--
SigbjÃžrn Vik
Quality Assurance
Opera Software