- From: Brian <netdemonz@yahoo.com>
- Date: Wed, 6 Jun 2001 16:51:54 -0400
- To: <plh@w3.org>
- Cc: <www-dom@w3.org>
Oh yeah, I almost forgot, in respect to number 4. This is really a killer as I have learned with Mozilla. There are certain things on the page you really need to access, such as the URL. frame.src doesn't change (which I personally think is an errata in the DOM and HTML specs) when you change pages in the frame unlike images, which change. So say you wanted to have a fake browser by putting a form and an iframe. There would be no way to know when someone clicks on a link in the iframe which page they went to. There are two ways to solve this: allow certain parts of a document in the frame to be accessed (such as the title and the URL). The other way is to fix the obvious errata in the specs. I think both should be undertaken. Now, the second issue is document.domain - Although it is good start to allowing cross-domain access in frames, it is not without problems. Problem 1: Example is two pages on geocities. If you allow domain-based access to frames in security, that gives two sites on geocities access to each other, which is probably no problem because they have nothing that needs to be secure, but its just an example. Problem 2: You have your site strewn across many domains. Setting them all to the same document.domain would give any site on that domain access to all the documents. ***Solution: create document.friends which would be a linked list of domstrings which are directories, ips, domains, or files anywhere on the web that have access to this document. The strings could also have wildcards in them. for instance, say you wanted to do *.netscape.com or http://www.netscape.com/blah/de/dah* Addressing this soon would make some of your fellow dom experts which I know from Netscape (and make me look clueless about the dom :) probably very happy since they are constantly harassed about the security model breaking sites that have frames. Thanks for your time. -----Original Message----- From: plh@w3.org [mailto:plh@w3.org] Sent: Tuesday, June 05, 2001 14:01 To: Brian Cc: www-dom@w3.org Subject: Re: Security recommendation for DOM? Brian wrote: > > Mozilla/Netscape 6 has a security model that makes a lot of the DOM not > work. Although this is ok, there are some lines that get blurred - i.e. > which parts of the contentDocument of a frame can one domain access of the > site in the frame? Obviously the title can't hurt anything, and it would be > good if there was a security recommendation to make problems not occur > because of differing security models in browsers. Not addressed by DOM 1, 2 or 3. Our issue list still has this item but again, not sure about its future yet. [[[ 1.9. Security, Validity and Privacy [After Level 1] Security, validity, and privacy considerations are interrelated and entwined. DOM will initially provide simple "sandbox" security; subsequent levels are expected to incorporate more sophisticated mechanisms. 1.Each object must be responsible for maintaining its own internal consistency. 2.It must be safe to have multiple threads operating on the same object. 3.Object locking must be incorporated to ensure consistent results. 4.It must be possible to prevent scripts on one page from accessing another page. 5.Firewall boundaries must be respected. 6.It must be possible to restrict access and navigation to specific elements. 7.An external security API will be provided. ]]] -- Document Object Model Requirements http://www.w3.org/TR/1998/WD-DOM-19980416/requirements Mon, 13 Mar 2000 14:38:57 GMT Philippe _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Received on Wednesday, 6 June 2001 16:51:52 UTC