Re: Window: rewrite Navigation section, added History

"Maciej Stachowiak" <mjs@apple.com>
> Anyway, comments welcome even though there are still a handful of  pieces 
> missing. Let me know especially if the text is hard to  understand or 
> appears to overconstrain implementations.

Looking good, but a few comments:

location.reload()  do we not want to list location.reload(true) too?

| Should define which objects are replaced on a navigation and which aren't.
| Window is not replaced,

Not sure that this means, but in that Window is also the global script 
object, care needs to be taken.

Is DocumentWindow really necessary?  It's a relatively new kid on the block, 
and redundant with Window.location

| A normative requirement that UAs implement some security policy
| that is in line with some general principles of cross-site scripting 
security,
| with exemptions allowed for "trusted" content.

I don't think it should be a requirement that any particular security 
mechanism is required, it's perfectly reasonable to implement the object in 
a wholely trusted environment, and there's no reason to make them.

| Specific cases where access and navigation must be allowed, 
notwithstanding
| any additional security restrictions (anything from the same origin).

There should be no cases where a client MUST do something due to security, 
it's got to be down to the UA (mainly because a UA is going to do whatever 
it needs to to be secure, so it will ignore the MUST anyway)

| Normative restrictions on what may be considered "trusted" content (MUST
| be from a specific known location, MUST NOT be transmitted over a network
| via an insecure protocol -- so you can't just say "my UA considers all 
content
| to be trusted" or "my company's homepage sent over non-SSL http is 
trusted".

There's absolutely no reason why I should not be able to choose that a non 
SSL page supplied only within the VPN of my system is trusted, nor any 
reason why SSL would automatically make a site more able to be trusted, 
again the restriction is too extreme.  (Basically I'd prefer everything was 
examples of existing security models, but whatever you do make sure it's 
secure type wording, rather than any specific requirements)

The other thing is some language to deal with clashes of names, you say you 
need a unique name, but currently there is no restriction on uniqueness of 
names.

Cheers,

Jim.

Received on Monday, 1 May 2006 15:20:53 UTC