Re: Widgets 1.0 Packaging and Configuration: I18N comments...
hey, both of your messages were marked by gmail as phishing (they claim the sender isn't who it appeared to be). Is this normal? Is it because of the mailing list? This means that people like me might not have seen either message.
Re: [cors] security issue with XMLHttpRequest API compatibility
On 8 Apr 2009, at 02:29, Jonas Sicking wrote: But it's for a limited time. In a few years hopefully all browsers supports cross site XHR. And if you can already today follow the advice that you should not rely on XHR not honoring your request just because it's a cross site URI. You are proposing a model where there's two types of XHR objects. One where we specifically tell users that you can rely on the request won't be sent cross site, and one where you can't. Put differently: Current web applications have a contract with the underlying browser that prevents cross-site requests from happening when XMLHttpRequest is used. That's a contract that software authors might very well rely on. The proposal within the working group (which is implemented by a number of browser vendors) is to abolish this guarantee. The approach that's implemented by IE8 (with a separate XDomainRequest) matches Tyler's requirement, and preserves the existing contract for XHR. While I can see how a single API would be a useful thing to have, I can also follow Tyler's argument; the trade-off here is indeed between following the principle of least surprise for existing Web Applications and a certain sense of simplicity for future applications. Incidentally, just framing this as XHR vs XDR is a bit simplistic: E.g., one could imagine a method enableCrossSiteRequests (or something like that) which needs to be invoked before XHR can do cross site requests.
[widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider
The XML Security WG would like to refine the question about the suitability of elliptic curve as a mandatory to implement algorithm for XML Signature 1.1 by highlighting that the scope of elliptic curve is greatly limited in what is proposed to be mandatory in XML Signature 1.1. As T-Mobile pointed out previously in their comments [1], the specific curve being used in an instance of ECDSA is important and there are a few sets of well-known (named) curves that have been standardized. The P-256, P-384 and P-521 curves are three of the five NIST-defined prime curves. Since the publication of the First Public Working Draft of XML Signature 1.1, the following clarifying text was added by the XML Security WG to the end of section 6.4.3 of XML Signature 1.1 [2]: This specification REQUIRES implementations to support the ECDSAwithSHA256 signature algorithm, which is ECDSA over the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS186-3] (and using the SHA-256 hash algorithm). It is further RECOMMENDED that implementations also support ECDSA over the P-384 and P-521 prime curves; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively. It is important to realize that by reducing the scope of the requirement to a specific curve that this should simplify evaluation of whether it is desirable to make this mandatory to implement. The XML Security WG would also like to note the importance of this algorithm to US Government customers, as evidenced by their adoption of Suite B [3]. This is reflected in the XML Security WG Use Cases and Requirements document in section 3.5.2.3 [4]. These considerations can also apply to the decision of which algorithms should be required in Widget Signature. Please share this additional information in your organization and indicate if it would cause any change in position regarding the mandatory to implement algorithms. Thank you regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0842.html [2] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-SignatureAlg [3] Fact Sheet NSA Suite B Cryptography, http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml [4] http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/#algorithm-suiteb
Re: [widgets] dropping Asynchronous HTTP Requests and Storage
On Apr 6, 2009, at 6:46 AM, ext Marcos Caceres wrote: I had a discussion with Anne on IRC about using the Storage interface and XHR [1]. He recommended that we recommend support for Storage only on user agents that support HTML5. With regards to XHR, the same applies: it would be a property of the underlying document technology. So, proposal are: drop Asynchronous HTTP Requests requirement [2] and remove its support from Widgets 1.0: AE. For Storage, specify that only HTML-aware UAs support Storage interface. Regarding the Storage proposal, we've debated this before. I support the existing text and its adoption/reuse of HTML5's Storage interface. As Jonas indicated, the Storage interface has been moved from HTML5 to a separate Web Storage spec [1] that WebApps will publish soon (perhaps as early as next week). -Regards, Art Barstow [1] http://dev.w3.org/cvsweb/html5/webstorage/Overview.html
Re: [widgets] Zip endian issue?
On Fri, Apr 3, 2009 at 11:17 AM, jere.kapy...@nokia.com wrote: Well, the ZIP file specification does say that all values are stored in little-endian byte order unless otherwise specified. The local file header signature is the four bytes 50 4B 03 04, in this order, always. Endianness is not even an issue, if you read and compare individual bytes. How could the ZIP file “be entirely transposed on media”? It is a binary file; if some entity is “transposing” it, it’s not the same file anymore. A practical example of where and how this would be happening is needed. I guess that unless we come up with a realistic scenario, this is a non-issue. Josh? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
Hi Rainer, On Mon, Mar 2, 2009 at 2:56 PM, Hillebrand, Rainer rainer.hillebr...@t-mobile.net wrote: RH: I would recommend not to standardize a base security policy for all markets on the world. It would take too long. However, we might want to discuss for Widgets 2.0 whether we would try agreeing on a security framework defining what needs to be protected, how a security policy is defined (i.e. format, vocabulary) and how security policies could be provisioned or managed. Ok, this seems like a reasonable way forward. Not specifying the default security policy is inline with what is currently specified in the PC spec. I have added your suggestion for V2.0 to the wiki: http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R -- Marcos Caceres http://datadriven.com.au
Re: Do we need to rename the Origin header?
Adam Barth wrote on 4/7/2009 4:36 PM: HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step Barth: http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt These two, at least, are the same. We separated the XXX-Origin bit from the HTML 5 spec because folks from the IETF were interested in reviewing it separately from HTML 5. Is draft-abarth-origin-00.txt entirely compatible now with CORS-Origin? - Bil
Re: Do we need to rename the Origin header?
On Wed, Apr 8, 2009 at 10:34 AM, Bil Corry b...@corry.biz wrote: Is draft-abarth-origin-00.txt entirely compatible now with CORS-Origin? Yes, as far as I know. If you find any incompatibility, please let me know and I'll fix it. Adam
Re: [cors] security issue with XMLHttpRequest API compatibility
On Wed, Apr 8, 2009 at 2:23 AM, Thomas Roessler t...@w3.org wrote: Incidentally, just framing this as XHR vs XDR is a bit simplistic: E.g., one could imagine a method enableCrossSiteRequests (or something like that) which needs to be invoked before XHR can do cross site requests. Oh, indeed. I didn't mean to frame it as an XHR vs XDR thing. There's certainly other ways of doing it. Tyler also proposed adding an argument to the XHR constructor. / Jonas
Web Storage SQL
(I originally blogged this at http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/, but Hixie rightfully pointed out that I should post it here for discussion -- doing so! Blog post is copied pretty much verbatim below, so apologies if it sounds more blog-y than post-y.) There's been a lot of interest around the Web Storage spec (formerly part of whatwg HTML5), which exposes a SQL database to web applications to use for data storage, both for online and offline use. It presents a simple API designed for executing SQL statements and reading result rows. But there's an interesting problem with this; unlike the rest of the HtML5, this section defines a core piece of functionality in terms of an undefined chunk referenced as SQL. The initial implementations of Web Storage are both based on SQLite, and expose the dialect of SQL understood by SQLite to web content. I'm actually a big fan of SQLite, and was one of the advocates for pulling it into the Gecko platform. However, SQLite implements a variant of SQL, with a number of deviations from other SQL engines, especially in terms of the types of data that can be placed in columns. Web content that is created to use database storage with SQLite as the backing is unlikely to work with any other backend database. Similarly, if another database was chosen as a browser's backing implementation, web content that works with it is unlikely to work with anything else. This is a serious interop problem, the root of which is that there really isn't a useful core SQL standard. SQL92 is generally taken as a base, but is often extended or altered by implementations. Even beyond the parser issues (which could be resolved by defining a strict syntax to be used by Web Storage), the underlying implementation details will affect results. So, the only option is for the Web Storage portion of the spec to state do what SQLite does. This isn't specified in sufficient detail anywhere to be able to reimplement it from the documents, so it would be even worse — do what this exact version of SQLite does, because there are no guarantees that SQLite won't make any incompatible changes. For example, a future SQLite 4 may introduce some changes or some new syntax which wouldn't be supported by earlier versions. Thus, it requires every single browser developer to accept SQLite as part of their platform. This may not be possible for any number of reasons, not the least of which is it essentially means that every web browser is on the hook for potential security issues within SQLite. Instead of all of this, I think it's worth stepping back and consider exactly what functionality web developers actually want. It's certainly much easier to say well, server developers are used to working with SQL, so let's just put SQL into the client, but it's certainly not ideal — most people working with SQL tend to end up writing wrappers to map their database into a saner object API. So, I would propose stepping back from Web Storage as written and looking at the core pieces that we need to bring to web developers. I believe that the solution needs to have a few characteristics. First, it should be able to handle large data sets efficiently; in particular, it should not require that the entire data set fit into memory at one time. Second, it should be able to execute queries over the entire dataset. Finally, it should integrate well with the web, and in particular with JavaScript. With these needs in mind, I think there are other options that should be considered, even beyond a subset of SQL; for example, an object-oriented database approach might serve those needs better. A good prototype example of what such a system could look like is jLINQ, which implements client-side querying on JavaScript objects and arrays. As such, a basic implementation is simple; more complex ones can have browser support for efficient indexing, triggers, rapid serialization to and deserialization from disk, etc. An implementation could even map all of this on top of an underlying SQL engine. Another option is something like CouchDB. I was also just pointed at Persevere, which looks quite cool; much in the same way as CouchDB, the same API could be implemented both client-side and server-side, for efficient online/offline switching. An approach such as one of these could well serve the web better than just throwing a SQL dialect over the web content fence. This is a conversation that I think is worth having, both to figure out what could be done about the issues with directly exposing SQL/SQLite, and also to step back and explore alternate approaches to getting the same functionality in web developers' hands. - Vlad
Re: Do we need to rename the Origin header?
Adam Barth wrote on 4/9/2009 12:21 AM: On Wed, Apr 8, 2009 at 10:09 PM, Bil Corry b...@corry.biz wrote: Using the above scenario, if Origin was populated and sent for all same-origin requests (including GET), the website could simply redirect any request for any protected resource that isn't same-origin. Then no one could link to the site. Virtually every site is going to have some page that both wants to be world-linkable and has different time characteristics for logged in / not logged in. The Origin header is useful for many things but not for defeating timing attacks. The site could redirect externally-driven requests to a login page, and once the user logs in again, redirect the user back to the original source. It really depends on the site and what it is trying to accomplish. For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. - Bil
