Re: [whatwg] Location object identity and navigation behavior

On Tue, 20 Nov 2012, Boris Zbarsky wrote:
> On 11/20/12 2:38 AM, Ian Hickson wrote:
> > IMHO there's no point us trying to keep things locked down when you 
> > set document.domain.
> 
> I believe sites actually rely on a certain amount of lockdown in 
> situations like this...  Adam can fill you in, I'm sure.

I would certainly be interested in concrete examples of this. I would be 
shocked if such sites weren't already vulnerable to something or other.


> But in general, as people work more and more on Widgety and Appy stuff 
> in HTML, with various expanded privileges, granted permissions, etc, the 
> assumption that the security model is completely symmetric just becomes 
> false. I'd rather we didn't paint ourselves into a corner by assuming 
> otherwise here and requiring behavior that UAs would simply refuse to 
> implement because they view it as insecure.

Given the way JavaScript works, I just don't see a sane way to make a 
non-symmetric model work. JS just allows too much introspection. Any time 
you pass a string from one to the other, you're also passing a way for the 
callee to call back into the caller, for example (via the string's 
methods). Passing any sort of structured objects similarly means passing 
mehods. Callbacks are also a very widely used pattern.

We have mechanisms for safe passing of data from one context to another, 
such as postMessage(). Doing it by having one-way glass in JS just seems 
like asking for trouble.


> Say I'm implementing a debugger in a web browser, and I implement my UI in
> HTML+JS as browsers are tending to do now.  When I examine properties with
> scripted getters in this debugger, what should happen?  I will bet money that
> the debugger is not, generally, running with the permissions of the page,
> because it needs to be able to do things that web pages aren't allowed to do.

Yeah, like running getters with the ability to abort them if they don't 
return promptly.


> However the getters in question had better run with the permissions of 
> the page; otherwise you open up the debugger to attacks from the web 
> page.  This problem is not solvable using the "separate worlds" 
> approaches browsers use to provide extensions with an unmodified view of 
> the DOM, since the debugger really does want to see what's going on in 
> the web page itself; it just doesn't want to allow the page to escalate 
> permissions.
> 
> Now I know there are several possible objections to this use case, so 
> let me just pre-address some:
> 
> 1)  "It's not the web, so we don't have to specify it."  That's true, 
> sure. 

I'd go even further. Debuggers are a rare exception, IMHO, which can't be 
fully specified because the whole point is that they want to examine 
everything that _is_ specified. I have no problem leaving the specific 
case of debuggers, profilers, and similar development tools out of what we 
need to specify to get interoperability.

But your underlying point, that we can't rely on the entry script and the 
real origin, is sound. In particular, anything that's to be affected by 
document.domain has to use the calling script, not the entry script, and 
has to use the effective origin, not the real origin. It would be useful 
if someone (other than me) were to review the spec's uses of the term 
"entry script" and "origin" and verify that the checks all make sense.


Anyway, we're kind of getting away from the original topic here, which 
isn't fully resolved; Location.

In thinking about this further last night, it struck me that while the 
proposed proxy mechanism was IMHO overly complex, there might be a simpler 
mechanism that still gets all the compatibility needs, and works for 
Mozilla, and isn't quite so crazy. I'm not a huge fan of this, but I'd be 
interested in what Adam thinks of it.

Right now, as specced, each Document gets a Location object, but they all 
act the same: they all work on the active document and they all do 
security checks based on the active document, not the Location's Document. 

But what if, instead, we had one Location per Document, and it worked on 
that Document (not the active document), with the security policy being 
like Window, specific to its Document's effective origin, but instead of 
ever getting references to it, you only got references to a proxy that 
acted on the active document's Location?

Then you wouldn't need to do anything with properties added by the author, 
either, they'd just work normally (like on Window).

I'm not a big fan of this, but if this simplified model works for WebKit, 
maybe it's worth it?

It's still less intuitive than just having unique Location objects, 
though.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 20 November 2012 21:21:29 UTC