- From: timeless <timeless@gmail.com>
- Date: Fri, 20 Jun 2008 13:25:04 +0300
- To: "Arve Bersvendsen" <arveb@opera.com>
- Cc: "Marcos Caceres" <marcosscaceres@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Jun 20, 2008 at 11:08 AM, Arve Bersvendsen <arveb@opera.com> wrote: > The security policy proposed by Opera (and mostly implemented already) > allows you to XHR any content stored within the package archive itself, just > as it would allow you to include the contents of a package through <script > src>, <img src> et al. I guess I've failed to explain myself. (Please keep in mind that this is a comment on the meta requirements spec. I haven't had time to review much else, although I do want to.) As long as the code actively uses XHR (or something else) to retrieve data, I have no objection. What I don't want is something where a property (of the settings object!) is automatically resolved to the result of its pointer location. If a property "icon" has value "http://example.org/favicon.ico", then i would want retrieval of "icon" to yield "http://example.org/favicon.ico" and not the _data_ that is at the location <http://example.org/favicon.ico>. I'm perfectly fine with the widget then using an XHR or whatever to retrieve the data for the referenced location. I just don't want a property lookup to resolve an indirection. > This happens through treating a widget: protocol > URI where the identifier-portion matches the instance ID of the widget as > being same-origin. Thus, allowing XHR is an (intended) side-effect, so you > can read other content from the widget (configuration data stored in an XML > file or template snippets used throughout the application, for instance), > and I don't think a specification will need to mention or reference XHR > specifically, except perhaps informatively. that's fine.
Received on Friday, 20 June 2008 10:25:45 UTC