- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 6 Feb 2006 14:50:42 -0800
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: public-cdf@w3.org
On Feb 6, 2006, at 4:30 AM, Charles McCathieNevile wrote: > Maciej, you wrote: > >> 2.5.3 >> "Currently, the common approach used is to restrict access across >> documents or network interfaces to material which comes from the >> same source as the code which tries to make that access." >> >> - This sentence is not grammatically correct English. > > It is grammatically correct english. It is not very clear, so we > will re-write it. We hope it will be clearer. It does seem grammatical now that I read more closely, but more confusing. >> - The claim made by the sentence is not correct. Access is based >> on the domain (and protocol and port) of the documents in the >> context of which the code is executing. It ignores where the code >> comes from, if the document happened to include code, such as >> JavaScript, from a site other than that which the document came from. > > This is correct, in detail. Broadly speaking, the practical upshot > is similar to the existing brief description. The practical upshot is actually not the same, because stylesheets, images, media resources, JavaScript, and documents from other domains can be included with current web technology. In the case of all of these but JavaScript, such access is provided in a secure way. The spec misleadingly makes it sound like you cannot transclude a document from another domain today, which you can, though with restricted scripting access. In any case, the spec should not say things that are false, even if they did have the same "practical upshot" as the actual fact of the matter. >> "This makes it difficult to re-use resources on the Web, by >> requiring a copy to be held in the domain of each application >> which uses that >> resource." >> >> - I don't see how this is true. JavaScript files, CSS files, >> images and html files can all be included from other sites. The >> difficulty only occurs when you wish to read the contents of such >> documents. There is no client-side technology that two sites could >> use to collaborate. > > Cross-document messaging, or simple DOM calls across a document > object are not restricted by spec to the same site. This is insecure by design. The spec should not in any wayencourage implementing cross-document DOM calls with no security restrictions. This can be used for phishing attacks or other information theft. I strongly disagree with the spec encouraging no security restrictions for the interfaces it defines. >> "This breaks cacheability, potentially reduces maintainability, >> and requires services to maintain the entire service rather than >> taking full advantage of specialised third-party providers." >> >> - I'm not buying these claims but ok - does this spec propose >> doing anything different in this regard? Does it propose that >> access to different documents *not* be restricted based on domain/ >> scheme/port as traditionally? > > The spec does not propose a security model, it points out that > there are potential security risks invovled in granting access to a > DOM from a different document (see your own message at @@). It > notes in passing that one common approach (cross-domain > restriction) while "good enough for many current uses" is neither a > particularly brilliant nor a brilliantly secure approach for the > Web at large, and so explicitly avoids mandating this approach. It is actually an approach that works well in practice. I do not think the spec should disparage the current de facto web security model without proposing an alternative. "No security restrictions on cross-document access" is not a viable alternative. > I hope this satisfies your concern. If not please let us know > within two weeks. It does not satisfy my concern. I believe you have left factually incorrect assertions in the spec and left it appearing to encourage a security model that is insecure by design. If you do not wish to mandate the current web security model for cross-site scripting restrictions, I would be fine with documenting it in an informative note, and saying implementations SHOULD implement some security model which does not have to be the one presented. Regards, Maciej
Received on Monday, 6 February 2006 22:51:32 UTC