Re: Handling too few arguments in method calls
On Thu, Jun 25, 2009 at 6:13 PM, Cameron McCormackc...@mcc.id.au wrote: Darin Adler: What about too many arguments, and ignoring extra ones? Is that settled? It seems consistent with current implementations to ignore extra arguments. That approach might go against the desire to maximise the freedom API designers have to add additional overloaded operations later, though. Yeah, ideally I would want to treat too many arguments the same as too few. However I'm more concerned about breaking existing content here if all commonly used UAs consistently ignore them. I would be willing to give it a try though, or at least once I've checked with the appropriate people that that is easily testable in gecko. / Jonas
Re: Points of order on this WG
On Jun 26, 2009, at 07:49 , Maciej Stachowiak wrote: It's also not clear to me if a BDB-level API is sufficient for developer needs. That's something that we should nail down early this time around. I tend to think that sufficient for developer needs means good enough that one can implement something like Persevere / MongoDB / KiokuDB on top of it, and several others have made similar comments. I'm unsure as to how exactly that translates into requirements without tying us to the implementation strategy of a couple products. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Points of order on this WG
On Fri, 26 Jun 2009 01:20:43 +0200, Maciej Stachowiak m...@apple.com wrote: I strongly agree on these points. I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. I also think Nikunj's proposal should be yet a third separate orthogonal draft. FWIW, Opera is implementing SQL storage too. -- Anne van Kesteren http://annevankesteren.nl/
Berkeley DB (was: Points of order on this WG)
Hi, Maciej- Maciej Stachowiak wrote (on 6/26/09 1:49 AM): As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. I wonder if Oracle would be willing to back the Berkeley DB option by changing the license? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Berkeley DB (was: Points of order on this WG)
On Fri, Jun 26, 2009 at 12:58 AM, Doug Schepersschep...@w3.org wrote: Hi, Maciej- Maciej Stachowiak wrote (on 6/26/09 1:49 AM): As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. I wonder if Oracle would be willing to back the Berkeley DB option by changing the license? I don't think we should tie a web API to a specific library. Just as I think specifying a SQL storage to exactly follow a given version of SQLite, I would think it's a bad idea to follow a given version of Berkeley DB. The idea isn't to use BDB specifically. The idea is to provide the type of data structures that SQL databases use to implement their tables. Berkeley DB used to be available as a backend to MySQL, so clearly it is possible to implement SQL on top of BDB. However it appears that MySQL no longer is able to run on top of BDB, so there is probably a reason for that too. / Jonas
RE: Points of order on this WG
+1 Stable specification moving faster in the standards track will definitely bring more implementations. Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Anne van Kesteren Sent: Friday, June 26, 2009 9:23 AM To: Maciej Stachowiak; Ian Hickson Cc: Doug Schepers; Nikunj R. Mehta; public-webapps WG; Charles McCathieNevile; Arthur Barstow; Jeff Mischkinsky Subject: Re: Points of order on this WG On Fri, 26 Jun 2009 01:20:43 +0200, Maciej Stachowiak m...@apple.com wrote: I strongly agree on these points. I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. I also think Nikunj's proposal should be yet a third separate orthogonal draft. FWIW, Opera is implementing SQL storage too. -- Anne van Kesteren http://annevankesteren.nl/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Points of order on this WG
On Fri, 26 Jun 2009, Doug Schepers wrote: The plan of record would be to split out the SQL Storage section into its own spec, with an alternate spec edited by Nikunj, and to publish an updated draft of Web Storage that points to both those other drafts. This way, all parts of the web storage deliverable are put on a level playing field to be judged on their individual merits, and subject to being edited and updated individually. I've added split the Web Storage spec to my list of things to do and will hopefully get to that within the next few weeks. It shouldn't be much work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Cameron,
Thank for your comments.
It is clear now.
I’ll probably loosen the IDL grammar to allow
sequences of square-bracketed extended attributes instead of requiring
them to be all in one, but for now you do need to have them all in one,
comma separated.
As for me it is not necessary to loosen the IDL grammar.
Listing the extended attributes separately was my problem within the example
and I am sorry for that.
Stability of the spec seems important.
Thanks.
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
Sent: Friday, June 26, 2009 2:51 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Marcin Hanclik:
Following our conversation on the geolocation ML
http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0173.html
I have the following clarification request related to the Web IDL spec.
In the geolocation spec we have now:
[NoInterfaceObject]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Proposed and agreed in our mail discussion:
[Callback]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Our intentions are:
1) Not to instantiate the interface object with new PositionOptions();
This is handled by not specifying [Constructor] extended attribute.
2) Not to have PositionOptions on the ES global object.
This shall be handled by specifying [NoInterfaceObject]. But it
seems to have to be removed.
3) Use PositionOptions interface to specify properties of the object
passed to e.g. getCurrentPosition() method.
This is handled by specifying [Callback].
4) Resulting from the above, use the PositionOptions as follows:
navigator.geolocation.getCurrentPosition(successCallback,
errorCallback,
{maximumAge:60});
Right.
Questions:
a) What is the PropertyOnly argument/identifier for?
It seems unclear from the Web IDL spec.
Does it specify that the interface has one attribute only and ES
binding just one property?
Or does it specify that the interface includes only attributes?
Or does it signify only the opposite to FunctionOnly?
I’ll try to clear up the wording in
http://dev.w3.org/2006/webapi/WebIDL/#native-objects.
The intended meaning of [Callback=PropertyOnly] is that if the interface
has one or more operations with the same name (but no others) and no
attributes, then an ECMAScript Function object’s [[Call]] will not be
considered to be the implementation of those operations. Instead, the
[[Call]] of the object returned from invoking [[Get]] with the operation
identifier as the property name will be.
So for example with these interfaces:
interface Target {
void registerListener(in Listener x);
};
[Callback]
interface Listener {
void f();
};
this would work:
getTarget().registerListener(function() { … })
as would:
getTarget().registerListener({ f: function() { … } });
If [Callback=FunctionOnly] was specified, then only the former would
work (passing a Function object), while if [Callback=PropertyOnly] was
specified, then only the latter would work.
Web IDL really should make IDL fragments non-conforming to use
FunctionOnly or PropertyOnly when the interface has operations of
different names or when it has attributes.
b)
Shouldn't we have the PositionOptions specified as follows?
[NoInterfaceObject]
[Callback=PropertyOnly]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
It should be:
[NoInterfaceObject, Callback]
interface PositionOptions {
…
};
as far as I can tell. (I’ll probably loosen the IDL grammar to allow
sequences of square-bracketed extended attributes instead of requiring
them to be all in one, but for now you do need to have them all in one,
comma separated.)
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by
responding to this e-mail. Thank you.
Re: Points of order on this WG
On Jun 26, 2009, at 12:23 AM, Anne van Kesteren wrote: On Fri, 26 Jun 2009 01:20:43 +0200, Maciej Stachowiak m...@apple.com wrote: I strongly agree on these points. I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. I also think Nikunj's proposal should be yet a third separate orthogonal draft. FWIW, Opera is implementing SQL storage too. That's great news! Having multiple independent implementations will, I hope, provide more reason to advance the spec. However, I still think SQL storage should be split from LocalStorage/ SessionStorage, since there is no technical reason for them to be tied together, and they enjoy different levels of consensus and implementor support. Regards, Maciej
Re: Points of order on this WG
On Jun 26, 2009, at 10:54 , Maciej Stachowiak wrote: I don't think the Web Storage draft (I assume by this you mean the remaining draft that would define LocalStorage and SessionStorage) needs to link to either of the other drafts. It is customary, when something is split out of a draft, to link to it so that people can find it using their old bookmarks. I think that's all that Doug meant here — not linking in the normative sense. I should add that I still think SQL Storage is a good technical solution to the problem of structured client-side storage. Web developers who are specifically targeting mobile devices, or in particular iPhone, have given extremely positive feedback about both LocalStorage and SQL Storage, as well as the HTML5 Application Cache. On general-purpose Web sites, of course, uptake is limited by the lack of other implementations so far. But Web developers seem positive about it as a technology, based on feedback from presentations. All of this makes me doubt that a fundamentally different model for structured storage is needed or would be significantly better. Well, the advantage of SQL is that developers know it, and have been wanting something like that on the client for ages (I know I have). There are non-negligible issues however in defining it interoperably. Also, I think there's a possibility that it's popular with developers simply because it's the only option. That's why ideally I'd like to give us the leeway to experiment a little around various options before committing completely to SQL. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Points of order on this WG
On Fri, 26 Jun 2009 10:43:10 +0200, Maciej Stachowiak m...@apple.com wrote: On Jun 26, 2009, at 12:23 AM, Anne van Kesteren wrote: FWIW, Opera is implementing SQL storage too. That's great news! Having multiple independent implementations will, I hope, provide more reason to advance the spec. However, I still think SQL storage should be split from LocalStorage/ SessionStorage, since there is no technical reason for them to be tied together, and they enjoy different levels of consensus and implementor support. Yeah, that seems fine. That way localStorage/sessionStorage can move ahead while Web SQL is properly defined. -- Anne van Kesteren http://annevankesteren.nl/
Re: Points of order on this WG
On Fri, 26 Jun 2009 10:09:43 +0200, Marcin Hanclik marcin.hanc...@access-company.com wrote: +1 Stable specification moving faster in the standards track will definitely bring more implementations. To be clear, when we decided to implement this feature it was still part of the HTML5 specification. Where it is specified did not really have an impact on whether we would do it or not. I would also be somewhat hesitant to say that separate drafts necessarily move faster. -- Anne van Kesteren http://annevankesteren.nl/
RE: Points of order on this WG
Where it is specified did not really have an impact on whether we would do it or not. Agreed. The place does not matter. Stability does, IMHO. I would also be somewhat hesitant to say that separate drafts necessarily move faster. At least there is a chance. It seems more feasible to implement a set of interfaces one by one - if they are independent - then to do it all at once. Separation on the spec level may also result in better specs, since the interface interdependencies would be avoided for practical reasons. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Friday, June 26, 2009 11:57 AM To: Marcin Hanclik; Maciej Stachowiak; Ian Hickson Cc: Doug Schepers; Nikunj R. Mehta; public-webapps WG; Charles McCathieNevile; Arthur Barstow; Jeff Mischkinsky Subject: Re: Points of order on this WG On Fri, 26 Jun 2009 10:09:43 +0200, Marcin Hanclik marcin.hanc...@access-company.com wrote: +1 Stable specification moving faster in the standards track will definitely bring more implementations. To be clear, when we decided to implement this feature it was still part of the HTML5 specification. Where it is specified did not really have an impact on whether we would do it or not. I would also be somewhat hesitant to say that separate drafts necessarily move faster. -- Anne van Kesteren http://annevankesteren.nl/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] dig sig RelaxNG schema
Woops. The validator error messages go away when the ... are removed from the DigestValues. http://www.w3.org/TR/widgets-digsig/#example Attached is a signature1.xml template which validates to http://www.w3.org/2007/xmlsec/Drafts/xmldsig-rngschema/ with rnv for me at least. :) ?xml version=1.0 encoding=UTF-8? Signature xmlns=http://www.w3.org/2000/09/xmldsig#; Id=DistributorASignature SignedInfo CanonicalizationMethod Algorithm=http://www.w3.org/2006/12/xml-c14n11/ SignatureMethod Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256/ Reference URI=config.xml DigestMethod Algorithm=http://www.w3.org/2001/04/xmlenc#sha256/ DigestValue/DigestValue /Reference Reference URI=index.html DigestMethod Algorithm=http://www.w3.org/2001/04/xmlenc#sha256/ DigestValue/DigestValue /Reference Reference URI=icon.png DigestMethod Algorithm=http://www.w3.org/2001/04/xmlenc#sha256/ DigestValue/DigestValue /Reference Reference URI=#prop DigestMethod Algorithm=http://www.w3.org/2001/04/xmlenc#sha256/ DigestValue/DigestValue /Reference /SignedInfo SignatureValue/SignatureValue KeyInfo X509Data X509Certificate/X509Certificate /X509Data /KeyInfo Object Id=prop SignatureProperties xmlns:dsp=http://www.w3.org/2009/xmldsig-properties; SignatureProperty Id=profile Target=#DistributorASignature dsp:Profile URI=http://www.w3.org/ns/widgets-digsig#profile/ /SignatureProperty SignatureProperty Id=role Target=#DistributorASignature dsp:Role URI=http://www.w3.org/ns/widgets-digsig#role-distributor/ /SignatureProperty SignatureProperty Id=identifier Target=#DistributorASignature dsp:Identifier07425f59c544b9cebff04ab367e8854a/dsp:Identifier /SignatureProperty /SignatureProperties /Object /Signature
Re: Points of order on this WG
Please don't skimp on due diligence before making such strong statements. It creates unnecessary friction. More details below. On Jun 25, 2009, at 10:49 PM, Maciej Stachowiak wrote: On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote: On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I have proposed to Mozilla a solution that provides access to an organized key-value database such as that provided in the (open source) Berkeley DB. In essence, a database is a simple B-tree - it keeps keys sorted and permits duplicate keys. It is able to find a key or a key prefix, which enables efficient searching through a very large number of items. If we are ambitious (i.e., need more functionality), we can add indexes and joins to this spec. There is unlikely to be an interoperability nightmare, such as that which is the most likely outcome with SQL, it does not mandate the use of any query language, and there is at least 40 years of experience with it, including in highly resource-constrained environments. (There are 200 million copies of Berkeley DB in deployment [1]). This is what so far seems like the best solution to me. I.e. something that is more backend-ish than what a SQL API would be. I'd love to see something that allows you to implement a SQL API on top of. But that also allows you to implement something like MungoDB very effectively. I doubt you can efficiently or correctly implement SQL on top of a Berkeley-DB-style API. If you are worrying, that's great; we can address your worries. Just take a look at the top two hits for MySQL Berkeley DB. The first one talks about MySQL with the BDB storage engine - so yes, you can correctly implement SQL on top of Berkeley DB [1]. The second one talks about MySQL discontinuing BDB support due to extra-technical reasons, so there are no efficiency reasons either [2]. As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. Huh? what? I hope you had read Oracle's BDB license document [3] and open source FAQ [4]. IANAL, but I can get answers for your specific concerns in the context of open source Berkeley DB. AFAICT, someone like Mozilla would not face any trouble with the open source license of Berkeley DB. YMMV. It's also not clear to me if a BDB-level API is sufficient for developer needs. As I understand it, it's basically a giant dictionary with unstructured keys and values. So it's not providing much over LocalStorage, except for prefix matching and the ability to hold large amounts of records or records that are individually large. There's no way to efficiently query by one of several fields, as I understand it. I trust that you are relatively new to storing data with B-trees. They are at the heart of Oracle's indices so efficiency is out of question. If you are wondering how can people store complex data items with multiple fields and repeating values, look at Berkeley DB Java Edition, which supports the EJB 3 persistence model [5]. FYI, there is no significant difference between the APIs of BDB Java Edition and the original BDB. They also have identical licensing requirements. [1] http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html [2] http://www.linux.com/archive/articles/56835 [3] http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html [4] http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html [5] http://www.oracle.com/technology/products/berkeley-db/je/index.html
Re: Points of order on this WG
On Jun 25, 2009, at 4:25 PM, Maciej Stachowiak wrote: On Jun 25, 2009, at 12:42 PM, Nikunj R. Mehta wrote: I think Nikunj's proposal definitely is worthy of being persued, just like the working group is persuing dozens of other proposals like XHR, CORS, Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't believe it really fits into the Web Storage spec (if anything, I think we should split Web Storage into two further specs, not add a third wholly independent feature to it). However, I would definitely support an FPWD publication of Nikunj's proposal, as I have for other proposals. That is encouraging. I will be glad to edit an FPWD that includes B- tree, interception, and programmable cache, if the WG so prefers. It seems to me that Berkley DB style database storage, and request interception / programmable cache are orthogonal ideas and should arguably be separate drafts. I would assume request interception and programmable cache are usable regardless of what client-side storage APIs are available, much as HTML5 Application Cache is independent of these APIs. If anything, it seems more closely related to AppCache than to any proposed storage solution. I don't have a preference either way. Request interception and programmable cache belong in a single spec. We could put Structured storage in a separate spec on its own. Regards, Maciej
Re: Points of order on this WG
On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote: On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I have proposed to Mozilla a solution that provides access to an organized key-value database such as that provided in the (open source) Berkeley DB. In essence, a database is a simple B-tree - it keeps keys sorted and permits duplicate keys. It is able to find a key or a key prefix, which enables efficient searching through a very large number of items. If we are ambitious (i.e., need more functionality), we can add indexes and joins to this spec. There is unlikely to be an interoperability nightmare, such as that which is the most likely outcome with SQL, it does not mandate the use of any query language, and there is at least 40 years of experience with it, including in highly resource-constrained environments. (There are 200 million copies of Berkeley DB in deployment [1]). This is what so far seems like the best solution to me. I.e. something that is more backend-ish than what a SQL API would be. I'd love to see something that allows you to implement a SQL API on top of. But that also allows you to implement something like MungoDB very effectively. You could implement SQL API on top of Berkeley DB as some have in the past. I am not super confident that the whole thing can work out with JavaScript overhead, but that may be just my perception of JS. This may be one of those conclusions that can only be made after a painful implementation exercise.
Re: Points of order on this WG
On Jun 26, 2009, at 12:15 AM, Robin Berjon wrote: On Jun 26, 2009, at 07:49 , Maciej Stachowiak wrote: It's also not clear to me if a BDB-level API is sufficient for developer needs. That's something that we should nail down early this time around. I tend to think that sufficient for developer needs means good enough that one can implement something like Persevere / MongoDB / KiokuDB on top of it, and several others have made similar comments. I'm unsure as to how exactly that translates into requirements without tying us to the implementation strategy of a couple products. I agree. This is why I am making an attempt to write down requirements ahead of time. I would suggest formally publishing and taking comments on the requirements, so we can avoid trouble. Nikunj http://o-micron.blogspot.com
Re: Points of order on this WG
On Jun 26, 2009, at 12:56 AM, Doug Schepers wrote: Hi, Folks- Maciej Stachowiak wrote (on 6/25/09 7:20 PM): On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I think Nikunj's proposal definitely is worthy of being persued, just like the working group is persuing dozens of other proposals like XHR, CORS, Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't believe it really fits into the Web Storage spec (if anything, I think we should split Web Storage into two further specs, not add a third wholly independent feature to it). However, I would definitely support an FPWD publication of Nikunj's proposal, as I have for other proposals. I strongly agree on these points. I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. I also think Nikunj's proposal should be yet a third separate orthogonal draft. Art, Chaals, Mike, and I discussed this yesterday, and we agreed that this seems like the best solution. Like the Widgets work, a deliverable doesn't necessarily have to be in a single spec, so we believe there is sufficient justification for this in the charter. The plan of record would be to split out the SQL Storage section into its own spec, with an alternate spec edited by Nikunj, and to publish an updated draft of Web Storage that points to both those other drafts. This way, all parts of the web storage deliverable are put on a level playing field to be judged on their individual merits, and subject to being edited and updated individually. Nikunj, would this suit you? Does anyone else have any thoughts? I would be pleased to edit an alternate spec for structured storage. After the charter snafu earlier in April, we discussed the need for WG's charter to state a desire to standardize structured storage (as opposed to limiting to SQL storage). Still it would be good if the charter clarifies this. Secondly, Oracle proposes adding request interception and programmable http cache to the WG's charter. Oracle will provide resources for editing and reviewing proposals for all three deliverables. That being said, I am really glad that the WG was able to arrive at a swift and positive conclusion on this matter. I want to take a moment and appreciate the help of all those who weighed in on Oracle's concerns and look forward to working together and constructively to remove the concerns. Best regards, Nikunj http://o-micron.blogspot.com
Re: Berkeley DB (was: Points of order on this WG)
On Jun 26, 2009, at 1:07 AM, Jonas Sicking wrote: On Fri, Jun 26, 2009 at 12:58 AM, Doug Schepersschep...@w3.org wrote: Hi, Maciej- Maciej Stachowiak wrote (on 6/26/09 1:49 AM): As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. I wonder if Oracle would be willing to back the Berkeley DB option by changing the license? I don't think we should tie a web API to a specific library. Just as I think specifying a SQL storage to exactly follow a given version of SQLite, I would think it's a bad idea to follow a given version of Berkeley DB. I agree with the principle of not tying the API to a specific library. To the extent that this WG provides feedback, I would be inclined to keep the API independent of Berkeley DB. That said, there is inherent benefit to starting with an API which could be easily implemented and be mature enough from the beginning. Therefore, my approach would be to use a subset of Berkeley DB's API that is justified based on the requirements considered appropriate by this WG. The idea isn't to use BDB specifically. The idea is to provide the type of data structures that SQL databases use to implement their tables. You got it right. Berkeley DB used to be available as a backend to MySQL, so clearly it is possible to implement SQL on top of BDB. However it appears that MySQL no longer is able to run on top of BDB, so there is probably a reason for that too. To be precise, MySQL has deprecated support for BDB as a storage engine starting with v5.1.12. Who know what will happen in the future though? Nikunj http://o-micron.blogspot.com
Re: Points of order on this WG
On Jun 26, 2009, at 10:56 AM, Jeremy Orlow wrote: On Fri, Jun 26, 2009 at 10:26 AM, Nikunj R. Mehta nikunj.me...@oracle.com wrote: Please don't skimp on due diligence before making such strong statements. It creates unnecessary friction. More details below. Similarly, I'd ask you to make your points clearer and to read what others say more closely. You didn't address Maciej's points very well, and I think they're definitely worth addressing. I understand your point, even though I don't think I missed anything in Maciej's comments, unless you want me to give sentence by sentence and word by word clarifications. Still, I can try one more time. If I miss this time, it is not intentional, and you can just ask me to clarify. On Jun 25, 2009, at 10:49 PM, Maciej Stachowiak wrote: On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote: On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I have proposed to Mozilla a solution that provides access to an organized key-value database such as that provided in the (open source) Berkeley DB. In essence, a database is a simple B-tree - it keeps keys sorted and permits duplicate keys. It is able to find a key or a key prefix, which enables efficient searching through a very large number of items. If we are ambitious (i.e., need more functionality), we can add indexes and joins to this spec. There is unlikely to be an interoperability nightmare, such as that which is the most likely outcome with SQL, it does not mandate the use of any query language, and there is at least 40 years of experience with it, including in highly resource-constrained environments. (There are 200 million copies of Berkeley DB in deployment [1]). This is what so far seems like the best solution to me. I.e. something that is more backend-ish than what a SQL API would be. I'd love to see something that allows you to implement a SQL API on top of. But that also allows you to implement something like MungoDB very effectively. I doubt you can efficiently or correctly implement SQL on top of a Berkeley-DB-style API. If you are worrying, that's great; we can address your worries. Just take a look at the top two hits for MySQL Berkeley DB. The first one talks about MySQL with the BDB storage engine - so yes, you can correctly implement SQL on top of Berkeley DB [1]. The second one talks about MySQL discontinuing BDB support due to extra- technical reasons, so there are no efficiency reasons either [2]. As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. Huh? what? I hope you had read Oracle's BDB license document [3] and open source FAQ [4]. This is the type of thing I'd expect you to say had those links clearly stated GPL, LGPL, etc compatibility. Am I missing it? Because I don't see anything that makes it clear. Oracle's license is what it is. I don't see why I should commit to offering it under GPL or LGPL. IANAL, but I can get answers for your specific concerns in the context of open source Berkeley DB. AFAICT, someone like Mozilla would not face any trouble with the open source license of Berkeley DB. YMMV. What do you mean by your mileage may vary? Are you saying that perhaps it is exactly as Maciej said? If you have a closed source browser then Berkeley DB will require commercial licensing. If your product is open source, then Berkeley DB is free for you. If you are somewhere in between, then you need to ask your lawyers. If you need something from Oracle, then by all means I can help you with that. Before believing Maciej, you might do well to read the links I sent in my previous email, or ask your lawyers to review the license. I understand that it is more work for you, but Oracle's at least helping to the extent it can. It's also not clear to me if a BDB-level API is sufficient for developer needs. As I understand it, it's basically a giant dictionary with unstructured keys and values. So it's not providing much over LocalStorage, except for prefix matching and the ability to hold large amounts of records or records that are individually large. There's no way to efficiently query by one of several fields, as I understand it. I trust that you are relatively new to storing data with B-trees. They are at the heart of Oracle's indices so efficiency is out of question. If you are wondering how can people store complex data items with multiple fields and repeating values, look at
Re: Points of order on this WG
On Fri, Jun 26, 2009 at 11:16 AM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. Huh? what? I hope you had read Oracle's BDB license document [3] and open source FAQ [4]. This is the type of thing I'd expect you to say had those links clearly stated GPL, LGPL, etc compatibility. Am I missing it? Because I don't see anything that makes it clear. Oracle's license is what it is. I don't see why I should commit to offering it under GPL or LGPL. Note that mozilla has since long made a commitment not to ship code that is not compatible with all of GPL, LGPL *and* MPL. So unless the BDB license is compatible with all those three we couldn't use BDB. That is what Maciej was saying, and it seems you are confirming that? Open sources licenses are complicated. / Jonas
Re: Points of order on this WG
On Friday 2009-06-26 11:27 -0700, Jonas Sicking wrote: Note that mozilla has since long made a commitment not to ship code that is not compatible with all of GPL, LGPL *and* MPL. So unless the BDB license is compatible with all those three we couldn't use BDB. I think our (Mozilla's) requirement is actually slightly stronger than license compatibility, at least as defined by http://en.wikipedia.org/wiki/License_compatibility . Rather, I think we require that the licenses don't impose any restrictions in addition to those imposed by the MPL, the LGPL, or the GPL. (In other words, that the license is less restrictive than *each* of those licenses.) For what it's worth, the license document in question, located at http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html appears to suggest that the files in the source code are covered under three different licenses (although it's not entirely clear to me what is meant by the concatenation of three licenses, my initial guess is that it means different parts are covered under different licenses). The second and third given appear to me to be the three-part BSD license (varying by whether the copyright holder is the UC Regents or Harvard University). If my quick glance is correct and this is identical to the three-part BSD license, then I suspect the second and third licenses are unlikely to be a problem for Mozilla; we already include code licensed under the three-part BSD license (see http://opensource.org/licenses/bsd-license.php ). The first license, on the other hand, appears to be a modified version of the BSD license, with the third claused replaced by an entirely different one. I don't recognize this clause, and I suspect it would require legal analysis to determine whether it's less restrictive than the MPL, LGPL, and GPL. (Though the part that says For an executable file, complete source code means the source code for all modules it contains. seems pretty restrictive to my untrained eyes.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Points of order on this WG
On Jun 26, 2009, at 10:26 AM, Nikunj R. Mehta wrote: As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. Huh? what? I hope you had read Oracle's BDB license document [3] and open source FAQ [4]. IANAL, but I can get answers for your specific concerns in the context of open source Berkeley DB. AFAICT, someone like Mozilla would not face any trouble with the open source license of Berkeley DB. YMMV. I read the license. By my reading, it imposes requirements that go beyond WebKit's LGPL license or Gecko's BSD/GPL/LGPL tri-license: http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html . Specifically clause 3 of the license. It's also not clear to me if a BDB-level API is sufficient for developer needs. As I understand it, it's basically a giant dictionary with unstructured keys and values. So it's not providing much over LocalStorage, except for prefix matching and the ability to hold large amounts of records or records that are individually large. There's no way to efficiently query by one of several fields, as I understand it. I trust that you are relatively new to storing data with B-trees. They are at the heart of Oracle's indices so efficiency is out of question. If you are wondering how can people store complex data items with multiple fields and repeating values, look at Berkeley DB Java Edition, which supports the EJB 3 persistence model [5]. FYI, there is no significant difference between the APIs of BDB Java Edition and the original BDB. They also have identical licensing requirements. Your references do not appear to explain on a technical level how one stores data with multiple fields in a way that you can query efficiently by more than one of them. I would appreciate a brief explanation. Regards, Maciej P.S. I would appreciate if you could discuss technical matters without mock incredulity or condescension.
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Thu, Jun 18, 2009 at 12:32 AM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 17 Jun 2009, Mark S. Miller wrote:
I don't really understand what we're trying to prevent here.
Confused deputies such as XSRF problems. Original paper is at
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. It's well worth
rereading. Much deeper than it at first appears.
Could you describe a concrete attack that you are concerned about? I don't
really see how the article you cite applies here.
Perhaps my own srl.cs.jhu.edu/pubs/SRL2003-02.pdf may help.
The threads and links already cited should make the connection with
browser security clear.
Maybe I'm just too stupid for this job, but I don't understand the
connection at a concrete level. I mean, I think understand the kind of
threats we're talking about, but as far as I can tell, CORS takes care of
them all.
The problem with redirects that is still outstanding against CORS is a
concrete example of the general Confused Deputy issues with CORS. A
redirect is just one way for a site to pass an identifier to code from
another site. Confused Deputy vulnerabilities will occur in CORS
whenever an identifier (such as a URI) is passed from one site to
another. For example...
I'm not really sure what more to explain. Perhaps you could ask a more
specific question?
Could you show some sample code maybe that shows the specific threat you
are concerned about?
Consider two web-applications: photo.example.com, a photo manager; and
printer.example.net, a photo printer. Both of these web-apps use
storage provided by storage.example.org. We're going to print a photo
stored at: https://storage.example.org/photo123
1. A page from photo.example.com makes request:
POST /newprintjob HTTP/1.0
Host: printer.example.net
Origin: photo.example.com
HTTP/1.0 201 Created
Content-Type: application/json
{ @ : https://storage.example.org/job123; }
2. To respond to the above request, the server side code at
printer.example.net set up a new printer spool file at
storage.example.org and gave photo.example.com write access to the
file.
3. The same page from photo.example.com then makes request:
POST /copydocument HTTP/1.0
Host: storage.example.org
Origin: photo.example.com
Content-Type: application/json
{
from : { @ : https://storage.example.org/photo123; },
to: { @ : https://storage.example.org/job123; }
}
HTTP/1.0 204 Ok
That's the expected scenario. Now, what happens if in step 1,
printer.example.net responds with URL
https://storage.example.org/photo456, another photo belonging to
photo.example.com. The POST in step 3 now looks like:
POST /copydocument HTTP/1.0
Host: storage.example.org
Origin: photo.example.com
Content-Type: application/json
{
from : { @ : https://storage.example.org/photo123; },
to: { @ : https://storage.example.org/photo456; }
}
HTTP/1.0 204 Ok
Consequently, one of the user's existing photos is overwritten with a
different photo.
The general point exemplified by the above scenario is that a site
cannot safely make a request that includes an identifier received from
a third-party, when access-control is based on the origin of a
request. The point of CORS is to enable sites to exchange messages.
These messages will include identifiers. When an identifier is taken
from a response and put into a request, a Confused Deputy
vulnerability is created by CORS. The redirect example is just an
automated way of doing this transfer of an identifier from a response
to a request. CORS could prevent such vulnerabilities by not
identifying the origin of requests.
--Tyler
--
Waterken News: Capability security on the Web
http://waterken.sourceforge.net/recent.html
Berkeley DB license (was Re: Points of order on this WG)
Maciej, David, Jeremy, Doug, others, I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. I have asked our legal team to clarify what they mean by the last para of the 3rd clause of the first license. As I understand it, it is the following text that appears problematic: For an executable file, complete source code means the source code for all modules it contains. Although it might be ideal, at this time, I cannot commit to having Berkeley DB be offered under a third (besides commercial and its current open source) license. I can only suggest that we move forward one step at a time. I will try my best to get this issue clarified in the quickest possible time. I also reaffirm the approach that it should not be necessary to use Berkeley DB to implement the structured storage API Oracle is proposing. I hope this helps. Feel free to suggest other licensing terms that appear problematic. Nikunj http://o-micron.blogspot.com On Jun 26, 2009, at 12:42 PM, L. David Baron wrote: On Friday 2009-06-26 11:27 -0700, Jonas Sicking wrote: Note that mozilla has since long made a commitment not to ship code that is not compatible with all of GPL, LGPL *and* MPL. So unless the BDB license is compatible with all those three we couldn't use BDB. I think our (Mozilla's) requirement is actually slightly stronger than license compatibility, at least as defined by http://en.wikipedia.org/wiki/License_compatibility . Rather, I think we require that the licenses don't impose any restrictions in addition to those imposed by the MPL, the LGPL, or the GPL. (In other words, that the license is less restrictive than *each* of those licenses.) For what it's worth, the license document in question, located at http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html appears to suggest that the files in the source code are covered under three different licenses (although it's not entirely clear to me what is meant by the concatenation of three licenses, my initial guess is that it means different parts are covered under different licenses). The second and third given appear to me to be the three-part BSD license (varying by whether the copyright holder is the UC Regents or Harvard University). If my quick glance is correct and this is identical to the three-part BSD license, then I suspect the second and third licenses are unlikely to be a problem for Mozilla; we already include code licensed under the three-part BSD license (see http://opensource.org/licenses/bsd-license.php ). The first license, on the other hand, appears to be a modified version of the BSD license, with the third claused replaced by an entirely different one. I don't recognize this clause, and I suspect it would require legal analysis to determine whether it's less restrictive than the MPL, LGPL, and GPL. (Though the part that says For an executable file, complete source code means the source code for all modules it contains. seems pretty restrictive to my untrained eyes.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Points of order on this WG
I have a tutorial available to understand how one can use Berkeley DB to store data with multiple fields [1]. If you are only interested in understanding how to do look up by one or more of them, please skip to slide 51. If this doesn't help, I can write up another explanation for the issues that are outstanding. Hope this helps. Nikunj http://o-micron.blogspot.com [1] http://www.oracle.com/technology/products/berkeley-db/tutorial-berkeleydb-ds.html On Jun 26, 2009, at 1:13 PM, Maciej Stachowiak wrote: It's also not clear to me if a BDB-level API is sufficient for developer needs. As I understand it, it's basically a giant dictionary with unstructured keys and values. So it's not providing much over LocalStorage, except for prefix matching and the ability to hold large amounts of records or records that are individually large. There's no way to efficiently query by one of several fields, as I understand it. I trust that you are relatively new to storing data with B-trees. They are at the heart of Oracle's indices so efficiency is out of question. If you are wondering how can people store complex data items with multiple fields and repeating values, look at Berkeley DB Java Edition, which supports the EJB 3 persistence model [5]. FYI, there is no significant difference between the APIs of BDB Java Edition and the original BDB. They also have identical licensing requirements. Your references do not appear to explain on a technical level how one stores data with multiple fields in a way that you can query efficiently by more than one of them. I would appreciate a brief explanation.
Re: Berkeley DB license (was Re: Points of order on this WG)
On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Fri, 26 Jun 2009, Tyler Close wrote:
Consider two web-applications: photo.example.com, a photo manager; and
printer.example.net, a photo printer. Both of these web-apps use storage
provided by storage.example.org. We're going to print a photo stored at:
https://storage.example.org/photo123
1. A page from photo.example.com makes request:
POST /newprintjob HTTP/1.0
Host: printer.example.net
Origin: photo.example.com
HTTP/1.0 201 Created
Content-Type: application/json
{ @ : https://storage.example.org/job123; }
2. To respond to the above request, the server side code at
printer.example.net set up a new printer spool file at
storage.example.org and gave photo.example.com write access to the
file.
3. The same page from photo.example.com then makes request:
POST /copydocument HTTP/1.0
Host: storage.example.org
Origin: photo.example.com
Content-Type: application/json
{
from : { @ : https://storage.example.org/photo123; },
to: { @ : https://storage.example.org/job123; }
}
HTTP/1.0 204 Ok
That's the expected scenario. Now, what happens if in step 1,
printer.example.net responds with URL
https://storage.example.org/photo456, another photo belonging to
photo.example.com. The POST in step 3 now looks like:
POST /copydocument HTTP/1.0
Host: storage.example.org
Origin: photo.example.com
Content-Type: application/json
{
from : { @ : https://storage.example.org/photo123; },
to: { @ : https://storage.example.org/photo456; }
}
HTTP/1.0 204 Ok
Consequently, one of the user's existing photos is overwritten with a
different photo.
The general point exemplified by the above scenario is that a site
cannot safely make a request that includes an identifier received from a
third-party, when access-control is based on the origin of a request.
I don't understand why photo.example.com would trust the identifier from
printer.example.net if the latter could be in the same namespace as the
namespace photo.example.com uses for its own data. The problem there is
simply one of trusting potentially hostile external input.
The point of CORS is to enable sites to exchange messages. These
messages will include identifiers. When an identifier is taken from a
response and put into a request, a Confused Deputy vulnerability is
created by CORS. The redirect example is just an automated way of doing
this transfer of an identifier from a response to a request. CORS could
prevent such vulnerabilities by not identifying the origin of requests.
I don't understand why this is any different in sandboxed iframes than
anywhere else. I don't disagree that redirects complicate matters mildly,
but that is the case regardless of whether there is a sandboxed iframe or
not as far as I can tell. My point was that without the user credentials
in the sandboxed origin, it would be impossible for the page to even get
to the original photo data, let alone contact the printing site or the
storage site and get them to print a photo.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Berkeley DB license (was Re: Points of order on this WG)
On Fri, Jun 26, 2009 at 3:46 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: FWIW, I came across two pieces about Oracle's open source licensing of Berkeley DB that might help clear the air around the licensing issues. First, Oracle's license [1] is word-for-word identical to the erstwhile SleepyCat license [2]. Secondly, SleepyCat license qualifies as a free software license, and is compatible with the GNU General Public License. [3]. Thirdly, the license is OSI approved [4]. I am not sure if this resolves issues. It would help if you had comments on the above so that I can keep that in my context while discussing with our legal staff. Unfortunately this does not resolve the issue. OSI approved is entirely different from compatible with any specific license (GPL, LGPL, MPL or anything else). Also, I'm not sure it's entirely fair to simply exclude non open-source browsers. We want the browser space to be competative, both for open source browsers and for proprietary browsers. If the API we come up with is prohibitively complex to implement without either releasing the browser as open source, or by licensing software from Oracle or any other party, then I think we haven't designed a good API. / Jonas
Re: Berkeley DB license (was Re: Points of order on this WG)
On Jun 26, 2009, at 3:40 PM, L. David Baron wrote: On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) That's roughly our position for WebKit as well. I did not mean to raise the license issue as a showstopper, merely to point out the following: - If we propose an API modeled on Berkeley DB, it likely could not be implemented by the popular open source browser engines using Berkeley DB itself. - If we propose an API modeled on Berkeley DB, it likely could not be implemented by proprietary browser engines using Berkeley DB itself, unless the developers paid licensing fees to oracle. - Therefore, if we design such an API, we need to be clear and detailed enough that it can be implemented interoperably from scratch. - We also need to be clear that the implementation cost for any browser will likely involve implementation from scratch, not just plugging in an existing library. (If Oracle changed the license terms, things would be different, but I'm not asking for that and I don't think it's appropriate to ask at this early stage.) Regards, Maciej
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
Response inline below, so keep scrolling...
On Fri, Jun 26, 2009 at 3:41 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 26 Jun 2009, Tyler Close wrote:
Consider two web-applications: photo.example.com, a photo manager; and
printer.example.net, a photo printer. Both of these web-apps use storage
provided by storage.example.org. We're going to print a photo stored at:
https://storage.example.org/photo123
1. A page from photo.example.com makes request:
POST /newprintjob HTTP/1.0
Host: printer.example.net
Origin: photo.example.com
HTTP/1.0 201 Created
Content-Type: application/json
{ @ : https://storage.example.org/job123; }
2. To respond to the above request, the server side code at
printer.example.net set up a new printer spool file at
storage.example.org and gave photo.example.com write access to the
file.
3. The same page from photo.example.com then makes request:
POST /copydocument HTTP/1.0
Host: storage.example.org
Origin: photo.example.com
Content-Type: application/json
{
from : { @ : https://storage.example.org/photo123; },
to: { @ : https://storage.example.org/job123; }
}
HTTP/1.0 204 Ok
That's the expected scenario. Now, what happens if in step 1,
printer.example.net responds with URL
https://storage.example.org/photo456, another photo belonging to
photo.example.com. The POST in step 3 now looks like:
POST /copydocument HTTP/1.0
Host: storage.example.org
Origin: photo.example.com
Content-Type: application/json
{
from : { @ : https://storage.example.org/photo123; },
to: { @ : https://storage.example.org/photo456; }
}
HTTP/1.0 204 Ok
Consequently, one of the user's existing photos is overwritten with a
different photo.
The general point exemplified by the above scenario is that a site
cannot safely make a request that includes an identifier received from a
third-party, when access-control is based on the origin of a request.
I don't understand why photo.example.com would trust the identifier from
printer.example.net if the latter could be in the same namespace as the
namespace photo.example.com uses for its own data.
Are you saying the two web-apps should not be allowed to use
storage.example.org?
The problem there is
simply one of trusting potentially hostile external input.
What input validation should photo.example.com have done?
Your above claim basically means a site cannot accept identifiers from
potentially hostile sites. That is true when using the ACL model (ie:
doing access control based on the origin of a request). I'm suggesting
we not use the ACL model, since it is broken in multi-party scenarios
like CORS.
I leave it as a simple exercise for the reader to redo the above
example using web-keys http://waterken.sf.net/web-key. The exchanged
messages have exactly the same format and there is no additional input
validation required. That's because the capability model actually
provides access control in multi-party scenarios.
The point of CORS is to enable sites to exchange messages. These
messages will include identifiers. When an identifier is taken from a
response and put into a request, a Confused Deputy vulnerability is
created by CORS. The redirect example is just an automated way of doing
this transfer of an identifier from a response to a request. CORS could
prevent such vulnerabilities by not identifying the origin of requests.
I don't understand why this is any different in sandboxed iframes than
anywhere else. I don't disagree that redirects complicate matters mildly,
but that is the case regardless of whether there is a sandboxed iframe or
not as far as I can tell. My point was that without the user credentials
in the sandboxed origin, it would be impossible for the page to even get
to the original photo data, let alone contact the printing site or the
storage site and get them to print a photo.
There are no sandboxed iframes in this example. It's just a simple web
page from a single origin, using CORS for cross-origin resource
sharing. And it doesn't work. The scenario is not impossible to
implement. It is simple using web-keys. It is only impossible to
safely implement it using the CORS security model.
--Tyler
--
Waterken News: Capability security on the Web
http://waterken.sourceforge.net/recent.html
Re: Berkeley DB license (was Re: Points of order on this WG)
On Jun 26, 2009, at 4:06 PM, Maciej Stachowiak wrote: On Jun 26, 2009, at 3:40 PM, L. David Baron wrote: On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) That's roughly our position for WebKit as well. I did not mean to raise the license issue as a showstopper, merely to point out the following: I agree with Maciej - we have gotten far ahead of ourselves here on licensing terms. - If we propose an API modeled on Berkeley DB, it likely could not be implemented by the popular open source browser engines using Berkeley DB itself. I don't buy this but... - If we propose an API modeled on Berkeley DB, it likely could not be implemented by proprietary browser engines using Berkeley DB itself, unless the developers paid licensing fees to oracle. there is no free lunch for commercial browsers, at least not one that's catered by Oracle, - Therefore, if we design such an API, we need to be clear and detailed enough that it can be implemented interoperably from scratch. and, regardless of Berkeley DB, this should be the design goal. We have all been burned by SQLite and SQL storage, and I am not going to lead another train down the same path. I was quite clear in my very first message on this topic that we are talking about a B-tree based database and not a W3C stamp of approval for Berkeley DB to be embedded in browsers. - We also need to be clear that the implementation cost for any browser will likely involve implementation from scratch, not just plugging in an existing library. This is not correct. You and I can disagree, but really we should let our lawyers examine the matter. (If Oracle changed the license terms, things would be different, but I'm not asking for that and I don't think it's appropriate to ask at this early stage.) Regards, Maciej
Re: Berkeley DB license (was Re: Points of order on this WG)
On Jun 26, 2009, at 3:46 PM, Nikunj R. Mehta wrote: FWIW, I came across two pieces about Oracle's open source licensing of Berkeley DB that might help clear the air around the licensing issues. First, Oracle's license [1] is word-for-word identical to the erstwhile SleepyCat license [2]. Secondly, SleepyCat license qualifies as a free software license, and is compatible with the GNU General Public License. [3]. Thirdly, the license is OSI approved [4]. I am not sure if this resolves issues. It would help if you had comments on the above so that I can keep that in my context while discussing with our legal staff. The issue I see with using Berkeley DB for implementation (which I think is only a side issue to design of the spec itself) is as follows: Clause 3 of the first license (the one with the Oracle copyright notice) appears to have stricter source release requirements than LGPL. It's not clear to me what exactly the scope of the requirement is, but it doesn't seem to have the dynamic linking or relinkable object file exceptions of LGPL. That would be a problem for projects like WebKit or Gecko that don't want to impost any constraints that go beyond the LGPL in their license terms. I don't want to start a huge debate over this, I just wanted to clarify the issue I see. Regards, Maciej
Re: Points of order on this WG
On Jun 26, 2009, at 10:51 AM, Nikunj R. Mehta wrote: Secondly, Oracle proposes adding request interception and programmable http cache to the WG's charter. Oracle will provide resources for editing and reviewing proposals for all three deliverables. We already have a broad charter and quite a few deliverables. Before we add more to the charter, I'd like to understand the degree of interest in request interception and programmable http cache. Is anyone besides Oracle interested in pursuing this technology? Are any implementors interested in implementing it? Regards, Maciej
Re: Points of order on this WG
On Jun 26, 2009, at 3:33 PM, Nikunj R. Mehta wrote: I have a tutorial available to understand how one can use Berkeley DB to store data with multiple fields [1]. If you are only interested in understanding how to do look up by one or more of them, please skip to slide 51. If this doesn't help, I can write up another explanation for the issues that are outstanding. It sounds like the answer is to make multiple tables with additional tables allowing secondary keys to map to the master key. Did I understand that correctly? (I'm not sure I got the right idea from the pictures). Can you clarify how a Berkley DB style API would differ from LocalStorage in interface or capabilities? What would it be able to do that LocalStorage can't? Regards, Maciej
Re: Handling too few arguments in method calls
Jonas Sicking: Yeah, ideally I would want to treat too many arguments the same as too few. However I'm more concerned about breaking existing content here if all commonly used UAs consistently ignore them. I would be willing to give it a try though, or at least once I've checked with the appropriate people that that is easily testable in gecko. That’d be great. I’d much rather make an informed decision here than just guess. -- Cameron McCormack ≝ http://mcc.id.au/
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Fri, 26 Jun 2009, Tyler Close wrote: I don't understand why photo.example.com would trust the identifier from printer.example.net if the latter could be in the same namespace as the namespace photo.example.com uses for its own data. Are you saying the two web-apps should not be allowed to use storage.example.org? I'm saying that they should use different namespaces for their autogenerated file names. For example, the printing app should use http://storage.example.com/printing.example.net/spool123 and the photo app should use http://storage.example.com/photo.example.com/photo123. Even better would be for the storage site to use keys in addition to the identifiers, so that printer.example.net can give photo.example.com access to specific files which photo.example.com can then access, but photo.example.com can then do so in a manner that tells the storage site that it only wants to be able to access printer.example.net's storage area. So then the storage server knows who is accessing the data, which decides what the credentials that site needs to present are; it knows the file that the site wants to access, and it knows who the file is being accessed on behalf of, along with a key to prove that this is being done with that site's permission. But this still doesn't seem to have anything to do with sandboxed iframes. The problem there is simply one of trusting potentially hostile external input. What input validation should photo.example.com have done? Is this identifier a file that is definitely owned by printing.example.net? I don't understand why this is any different in sandboxed iframes than anywhere else. I don't disagree that redirects complicate matters mildly, but that is the case regardless of whether there is a sandboxed iframe or not as far as I can tell. My point was that without the user credentials in the sandboxed origin, it would be impossible for the page to even get to the original photo data, let alone contact the printing site or the storage site and get them to print a photo. There are no sandboxed iframes in this example. It's just a simple web page from a single origin, using CORS for cross-origin resource sharing. Oh. Then that isn't what I was talking about. This thread is specifically about the use of Origin and Referer and user credentials in the context of a sandboxed iframe. And it doesn't work. The scenario is not impossible to implement. It is simple using web-keys. It is only impossible to safely implement it using the CORS security model. That's like saying that it is impossible to secure a beach with a padlock. Is anyone saying that CORS is what you would use in this scenario? If so, then I agree, they are wrong. The Origin header just tells the server who sent the request. If you use it to let other sites do stuff on your behalf without checking what they are doing, then game over. It's not going to protect against that. It similarly won't protect against script src= blocks importing scripts from untrusted domains. That doesn't mean Origin doesn't solve some specific problems, such as in particular allowing a site to access user-specific information from a third-party site (e.g. Google Finance giving the user's financial information to a mashup). You have to use the right tool for the job. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebIDL] module in ECMAScript
Marcin Hanclik: A correction / question to what I stated below: window.bondi – “namespace object” for ::bondi In BONDI we did not foresee that. We would like bondi to be the root. Which of the following do you foresee to exist: 1. window.bondi.* only 2. bondi.* only 3. both from the above? Both would exist. The bondi property would be on the global object (which is the same object that window evaluates to, usually). I’ve specified this now, using the name [NamespaceObject] instead. http://dev.w3.org/2006/webapi/WebIDL/#NamespaceObject http://dev.w3.org/2006/webapi/WebIDL/#es-modules I haven’t done anything with [Prefix] for the moment. -- Cameron McCormack ≝ http://mcc.id.au/
