Re: [widgets] What does it mean to have an unavailable API
On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. Ah, so requestFeature() is a BONDI spec, not a widget spec? However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when requestFeature() is called. As it was described to me by Marcos earlier in this thread, feature was used so that a widget could statically declare which security sensitive features it desired to use. This added security because if the widget was hacked, it could never use more security sensitive functionality than what had been statically declared using feature. So for example a widget that displays the current time would not need to claim access to any security sensitive APIs like camera or network access. This way it wasn't such a big deal if someone managed to hack the camera widget and get malicious code to run in the widgets security context, since that malicious code would not have access to camera or network. But if the malicious code could simply call requestFeature to gain access to camera, the above description no longer holds true. / Jonas
Re: send data using the Web Socket and UCS-2
On Tue, Jun 2, 2009 at 1:23 PM, Jeff Walden jwal...@mit.edu wrote: The specification should say what happens when WebSocket.postMessage(data) is called where data is not structurally correct UTF-16 -- lone surrogates, backwards surrogates, and any similar structural errors I might have forgotten. The IETF protocol specification implicitly assumes the data can be encoded as UTF-8 when this may not be the case. I mentioned similar issues in #whatwg recently for DOM APIs in general[0], possibly to be handled by WebIDL. Since this instance of that problem explicitly requires interpretation of a bogus DOMString and can't be described as storing a sequence of opaque 16-bit numbers for later retrieval, I think it's worth raising this concern specially, and I would like precise behavior specified before this proceeds to a finalized state. Yes, I don't see how we could handle this in WebIDL, other than defining that all DOMStrings must be structurally correct UTF-16. However that would be prohibitively expensive since we would have to add checks in many many places. / Jonas
Re: [widgets] What does it mean to have an unavailable API
Security is on UC; another is resource use. If the UA only needs to inject the modules needed by a Widget this can have a positive impact on downloading and processing Widgets. For example, if you have a lot of optional features, each of which is another 12k of injected JS... well, you get the idea. You don't want to have those downloaded every time if they aren't needed. Also, if any of those modules do automatic polling then you only want to load them for Widget instances that really do need to use them. S On 4 Jun 2009, at 08:25, Jonas Sicking wrote: On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. Ah, so requestFeature() is a BONDI spec, not a widget spec? However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when requestFeature() is called. As it was described to me by Marcos earlier in this thread, feature was used so that a widget could statically declare which security sensitive features it desired to use. This added security because if the widget was hacked, it could never use more security sensitive functionality than what had been statically declared using feature. So for example a widget that displays the current time would not need to claim access to any security sensitive APIs like camera or network access. This way it wasn't such a big deal if someone managed to hack the camera widget and get malicious code to run in the widgets security context, since that malicious code would not have access to camera or network. But if the malicious code could simply call requestFeature to gain access to camera, the above description no longer holds true. / Jonas smime.p7s Description: S/MIME cryptographic signature
RE: [widgets] What does it mean to have an unavailable API
Yes, one of the differences between feature and requestFeature() is the time when the actual API gets available. What is the automatic polling? Do you assume that the loaded feature is initialized by a kind of onLoad method? Thanks. 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: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Thursday, June 04, 2009 10:58 AM To: Jonas Sicking Cc: Marcin Hanclik; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API Security is on UC; another is resource use. If the UA only needs to inject the modules needed by a Widget this can have a positive impact on downloading and processing Widgets. For example, if you have a lot of optional features, each of which is another 12k of injected JS... well, you get the idea. You don't want to have those downloaded every time if they aren't needed. Also, if any of those modules do automatic polling then you only want to load them for Widget instances that really do need to use them. S On 4 Jun 2009, at 08:25, Jonas Sicking wrote: On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. Ah, so requestFeature() is a BONDI spec, not a widget spec? However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when requestFeature() is called. As it was described to me by Marcos earlier in this thread, feature was used so that a widget could statically declare which security sensitive features it desired to use. This added security because if the widget was hacked, it could never use more security sensitive functionality than what had been statically declared using feature. So for example a widget that displays the current time would not need to claim access to any security sensitive APIs like camera or network access. This way it wasn't such a big deal if someone managed to hack the camera widget and get malicious code to run in the widgets security context, since that malicious code would not have access to camera or network. But if the malicious code could simply call requestFeature to gain access to camera, the above description no longer holds true. / Jonas 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.
[DOM3Events] Use cases for Mutation Events
Hi, For me it is not clear at all what are the use cases for DOM Mutations Events on web pages (so maybe simply dropping their implementation would be an option?). If the group could first identify the use cases for Mutation Events on the web pages, then: a) it would become clear to everyone whether the progress is needed b) creating proposals on progress would become easier, a proposal would have to satisfy these use case to prove its viability Other thoughts: 1) If I am the author to the scripts that modify document, then I am indeed aware of what gets changed. If I am not the author, I shall then not have been notified on the change. The use cases such as debugger do not count here - it would be possible to offer required APIs (such as DOM Mutation Events) to them only, without needing the API to populate on the page. And this is not a sucrifice to run page 50% slower caused by the Mutation Events turned on on behalf of a debugger, right? 2) I can see Mutation Events as the extension point that enables implementation of the technologies that are not available in the browser. However this is not a normal usecase that web browsers are here to face. Sergey/
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 3:56 AM, Robin Berjon ro...@berjon.com wrote: Hey Jonas, nice proposal, overall I like it a lot. On Jun 4, 2009, at 11:07 , Jonas Sicking wrote: 'AttributeChanged': Called when an attribute on the node is changed. This can be either a attribute addition, removal, or change in value. If setAttribute is called the 'AttributeChanged' listener is always called, even if the attribute is given the same value as it already had. This is because it may be expensive to compare if the old and new value was the same, if the value is internally stored in a parsed form. I take it in this case the Attr node is what's passed? Might give a reason for its sorry existence :) No, it'd be the element. The callback implementation would be responsible for going through the attributes it is interested in and take appropriate action based on their values. 'ChildlistChanged': Called if one or or mode children are added or removed to the node. So for example when innerHTML is set, replacing 10 existing nodes with 20 new ones, only one call is made to the 'ChildlistChanged' listeners on that node. 'SubtreeChanged': Same as 'ChildlistChanged', but called not just for children added/removed to the node, but also to any descendants of the node. If multiple nodes are changed at once, I'm guessing you call back with a DocumentFragment? No, you always call back with the node who had children added or removed to it. So if I do myNode.innerHTML = ihello/iworldb!/b; Then there would be only a single call to each callback with myNode passed as node. Even though 3 nodes are inserted, and all existing nodes were removed. For interoperability purposes, this would probably require a definition of what a single DOM operation is Indeed we should. I'm thinking we might need ChildElementsChanged and ElementsSubtreeChanged that would handle only elements as well. When would these be called? Why isn't ChildlistChanged enough? 'TextDataChanged': Called when the data in a Text, CDATASection or ProcessingInstruction, is changed on the node or any of its decendants. Hm. If I set the listener on a PI, then I might be interested in this event — in which case it should be available on comment nodes too. Ah, yes, I missed comment. Really it should be all CharacterData nodes and all PIs. But then again, it seems to imply that I wouldn't get notified of changes to the PI's target. Ah, yeah, we could fire it for changes to the target too. If on the other hand I listen to this on an element, I probably don't want to hear about changes made to PIs (or comments) in the subtree. I think PIs and comments are changed rarely enough that this isn't worth optimizing for. Unless you are worried about bugs somehow arising? I'm really trying to optimize for creating something simple and performant here. As the proposal stands now, for all mutations a minimal set of callbacks are fired. The only redundancy is that both node-specific and whole-subtree listeners are fired. As opposed to the DOM Mutation Events spec where for example a child insertion fires DOMNodeInserted, DOMSubtreeModified and DOMNodeInsertedIntoDocument, on the full parent chain. / Jonas
Re: Mutation events replacement
These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. The listeners are called as follows: I find this behavior limiting in some regards and makes mutation events less useful. You specify some functions which add listeners for sub tree modifications though. Why not keeping the DOM events model for sub tree modification cases, and optimize single node mutation listeners with the API you propose? Another possible way would be to extend DOM events to tell that one only wants a listener for the AT_TARGET phase. Currently, if the 3rd parameter is true then it's capturing phase, else if it's false it's at_target and bubbling. Why not extend this argument with another possible value, or overloading the function with an enumeration on the 3rd parameter ? 'AttributeChanged': Called when an attribute on the node is changed. This can be either a attribute addition, removal, or change in value. If setAttribute is called the 'AttributeChanged' listener is always called, even if the attribute is given the same value as it already had. This is because it may be expensive to compare if the old and new value was the same, if the value is internally stored in a parsed form. The overhead of comparing the previous with the new value inside the engine is a fragment of the overhead of calling an ecmascript callback and doing the same comparison in ecmascript. Doing so will also prevent the callback from being called way too many times. So I think it should only be called when the value actually changes. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [DOM3Events] Use cases for Mutation Events
Other thoughts: 1) If I am the author to the scripts that modify document, then I am indeed aware of what gets changed. If I am not the author, I shall then not have been notified on the change. The use cases such as debugger do not count here - it would be possible to offer required APIs (such as DOM Mutation Events) to them only, without needing the API to populate on the page. And this is not a sucrifice to run page 50% slower caused by the Mutation Events turned on on behalf of a debugger, right? Use cases: - user triggered input, like when using contentEditable/designMode - 3rd party libraries which want to know if the document mutates out of their context - 3rd party scripts (like ad scripts, or link to social networking or sharing sites) that change the document and the document wants to keep some sanity in it -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 4:15 AM, João Eiras jo...@opera.com wrote: These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. The listeners are called as follows: I find this behavior limiting in some regards and makes mutation events less useful. Less useful to do what? What's your use case? You specify some functions which add listeners for sub tree modifications though. Why not keeping the DOM events model for sub tree modification cases, and optimize single node mutation listeners with the API you propose? I'm not sure I follow what you are suggesting. Which DOM Events are you suggesting we keep? Another possible way would be to extend DOM events to tell that one only wants a listener for the AT_TARGET phase. Currently, if the 3rd parameter is true then it's capturing phase, else if it's false it's at_target and bubbling. Why not extend this argument with another possible value, or overloading the function with an enumeration on the 3rd parameter ? This is significantly more complicated to implement. In order to optimize and not build the parent chain we would have to know that there are no listeners on the parent chain that aren't AT_TARGET-only. 'AttributeChanged': Called when an attribute on the node is changed. This can be either a attribute addition, removal, or change in value. If setAttribute is called the 'AttributeChanged' listener is always called, even if the attribute is given the same value as it already had. This is because it may be expensive to compare if the old and new value was the same, if the value is internally stored in a parsed form. The overhead of comparing the previous with the new value inside the engine is a fragment of the overhead of calling an ecmascript callback and doing the same comparison in ecmascript. Doing so will also prevent the callback from being called way too many times. So I think it should only be called when the value actually changes. If we only call the callbacks when the value changes, this means that we have to check if the value changes on every call to setAttribute. Even though most likely 99.9% of the time the value will change (why did the page call setAttribute if not to change the value?). Like you say, we'd get a decent win in the case when the value doesn't change. But that is very rare. Compared to a small cost that we have to take every single time. / Jonas
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote:
Here's an API that might work:
The following methods are added to the Document, Element and
DocumentFragment interfaces:
addAttributeChangedListener(NodeDataCallback);
addSubtreeAttributeChangedListener(NodeDataCallback);
addChildlistChangedListener(NodeDataCallback);
addSubtreeChangedListener(NodeDataCallback);
I would go for
addSubtreeElementChangedListener for this one since a modification to an
attribute in the subtree does not trigger it
addTextDataChangedListener(NodeDataCallback);
removeAttributeChangedListener(NodeDataCallback);
removeSubtreeAttributeChangedListener(NodeDataCallback);
removeChildlistChangedListener(NodeDataCallback);
removeSubtreeChangedListener(NodeDataCallback);
and removeSubtreeElementChangedListener...
removeTextDataChangedListener(NodeDataCallback);
And add the following interface:
[CallBack=FunctionOnly, NoInterfaceObject]
interface NodeDataCallback {
void handleEvent(in Node node);
};
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes place. The listeners are called
as follows:
'AttributeChanged': Called when an attribute on the node is changed.
This can be either a attribute addition, removal, or change in value.
If setAttribute is called the 'AttributeChanged' listener is always
called, even if the attribute is given the same value as it already
had. This is because it may be expensive to compare if the old and new
value was the same, if the value is internally stored in a parsed
form.
'SubtreeAttributeChanged': As for 'AttributeChanged', but called not
just for attribute changes to the node, but also to any descendants of
the node.
'ChildlistChanged': Called if one or or mode children are added or
removed to the node. So for example when innerHTML is set, replacing
10 existing nodes with 20 new ones, only one call is made to the
'ChildlistChanged' listeners on that node.
'SubtreeChanged': Same as 'ChildlistChanged', but called not just for
children added/removed to the node, but also to any descendants of the
node.
'TextDataChanged': Called when the data in a Text, CDATASection or
ProcessingInstruction, is changed on the node or any of its
decendants.
The exact algorithm would go something like this:
The implementation contains a global list, pendingCallbacks. Each item
in pendingCallbacks is a tuple: callback, node.
The implementation also contains a flag, notifyingCallbacks, which
initially is set to false.
If an attribute is changed on node N, perform the following steps:
1. For each 'AttributeChanged' callback, C, registered on N, add an
item to the end of pendingCallbacks with the value C, N
2. For each 'SubtreeAttributeChanged' callback, C, registered on N,
add an item to the end of pendingCallbacks with the value C, N
3. Set N to N's parentNode.
4. If N is non-null, go to step 2.
5. If notifyingCallbacks is set to true, or pendingCallbacks is empty,
abort these steps.
6. Set notifyingCallbacks to true.
7. Remove the first tuple from pendingCallbacks.
8. Call the handleEvent function on the callback in the tuple, with
the 'node' argument set to the node from the tuple.
9. If pendingCallbacks is not empty, go to step 7.
10 Set notifyingCallbacks to false.
A similar algorithm is run when children are added and/or removed from
an element/document/document-fragment, just replace 'AttributeChanged'
with 'ChildlistChanged', and 'SubtreeAttributeChanged', with
'SubtreeChanged'.
And when Text/CDATASection/ProcessingInstruction
Please add Comment too
nodes have their
contents modified the same algorithm is run, but without step 1, and
with 'SubtreeAttributeChanged' replaced with 'TextDataChanged'.
There's a few of properties here that are desirable, and one that is
sub-optimal.
First of all no notifications are done until after the implementation
is done with the mutations. This significantly simplifies the
implementation since all critical work can be done without worrying
about script performing arbitrary operations in the middle.
Second, all callbacks are notified in the order mutations happen in
the tree, even when another callback performs further mutations. So if
a callback for 'ChildlistChanged' sets a attribute on the newly
inserted node, the other callbacks are still going to get first
notified about the node being inserted, and then about it having an
attribute set. This is thanks to the notifyingCallbacks flag.
Third, these notifications should be significantly faster. Since there
are no DOM Events, there is no need to build propagation chains.
There's also no need to recreated the old attribute value, or to fire
one event for each node if multiple nodes are added and
Re: [DOM3Events] Use cases for Mutation Events
On Thu, Jun 4, 2009 at 4:18 AM, João Eiras jo...@opera.com wrote: Other thoughts: 1) If I am the author to the scripts that modify document, then I am indeed aware of what gets changed. If I am not the author, I shall then not have been notified on the change. The use cases such as debugger do not count here - it would be possible to offer required APIs (such as DOM Mutation Events) to them only, without needing the API to populate on the page. And this is not a sucrifice to run page 50% slower caused by the Mutation Events turned on on behalf of a debugger, right? Use cases: - user triggered input, like when using contentEditable/designMode We should fix this by adding better events for user input into contentEditable/designMode. Using mutation events for this is both unnecessarily hard to use (I'd imagine), as well as unperformant (for sure). - 3rd party libraries which want to know if the document mutates out of their context - 3rd party scripts (like ad scripts, or link to social networking or sharing sites) that change the document and the document wants to keep some sanity in it Can you explain these more in detail? / Jonas
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 4:37 AM, mozer xmli...@gmail.com wrote: On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote: Here's an API that might work: The following methods are added to the Document, Element and DocumentFragment interfaces: addAttributeChangedListener(NodeDataCallback); addSubtreeAttributeChangedListener(NodeDataCallback); addChildlistChangedListener(NodeDataCallback); addSubtreeChangedListener(NodeDataCallback); I would go for addSubtreeElementChangedListener for this one since a modification to an attribute in the subtree does not trigger it the 'SubtreeAttributeChanged' callbacks are called whenever an attribute is the subtree below the node where the callback is registered is changed. Is that not what you need? I.e. in a DOM like body div p here's some text /p /div /body If I call div.addSubtreeAttributeChangedListener(doStuff); then doStuff is called if someone sets an attribute on the p element. And when Text/CDATASection/ProcessingInstruction Please add Comment too Yup. / Jonas
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 1:42 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jun 4, 2009 at 4:37 AM, mozer xmli...@gmail.com wrote: On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote: Here's an API that might work: The following methods are added to the Document, Element and DocumentFragment interfaces: addAttributeChangedListener(NodeDataCallback); addSubtreeAttributeChangedListener(NodeDataCallback); addChildlistChangedListener(NodeDataCallback); addSubtreeChangedListener(NodeDataCallback); I would go for addSubtreeElementChangedListener for this one since a modification to an attribute in the subtree does not trigger it the 'SubtreeAttributeChanged' callbacks are called whenever an attribute is the subtree below the node where the callback is registered is changed. Is that not what you need? I.e. in a DOM like body div p here's some text /p /div /body If I call div.addSubtreeAttributeChangedListener(doStuff); then doStuff is called if someone sets an attribute on the p element. We're in agreement here ! That's why I would go for a name stating explicitly that it is about ELEMENT in the subtree and not Whatever in the subtree And when Text/CDATASection/ProcessingInstruction Please add Comment too Yup. / Jonas Xmlizer
Re: [DOM3Events] Use cases for Mutation Events
Use cases: - user triggered input, like when using contentEditable/designMode We should fix this by adding better events for user input into contentEditable/designMode. Using mutation events for this is both unnecessarily hard to use (I'd imagine), as well as unperformant (for sure). I agree 100% that we need better events for user input in this regard, but we don't have them currently and Gecko and Webkit dispatch mutation events for user input on editable documents, and I know of a few high profile project that use them (although I can't disclose which). Can you explain these more in detail? Whether there are libraries that use them or not, I honestly can't tell. However there are scenarios where 3rd party libraries like jQuery or prototype might require to know if the document has mutated to update their internal data structures. For the 3rd party scripts, it's quite common for sites to deploy 3rd party scripts that embed links to social networking sites, bookmarking services, embedding ads, embedding videos, etc. If somehow the script breaks the main page's tree, a mutation event could help, although in these cases, probably the load events would be good enough.
RE: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
Hi Art, All, Vodafone has some late comments which it would like to provide to the group for consideration and apologise for supplying these after the deadline. We believe that all but one of the comments is editorial and so there inclusion or otherwise should not affect or delay the decision to go to CR status, which we support. In submitting these comments it is not our intention or desire to hold up this process, only to provide the comments for consideration. The only comment that doesn't fit into this category is a question that has been raised by one of our developers. My hope is that there is already an answer! Thanks, Mark --- Editorial Comments --- ---[Definition of file entry]--- Section: 1.2 A file entry is the compressed (or Stored [ZIP]) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification. In Widgets 1.0: Packaging and Configuration [2] the file entry definition is different. A file entry is the data held by a local file header, file data, and (optional) data descriptor, as defined in the [ZIP] specification, for each physical file contained in a Zip archive. Comment - the inclusion of folder in the definition in [1] has caused one reviewer to ask if there should be a reference element for folders? I believe this is not the case and or folder could be removed from the definition. ---[Requirements accuracy]--- Section: 2 R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1, DSA-SHA-256 and RSA-SHA-256. Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should probably be removed as they are not required algorithms. ECDSA-SHA-256 could be added. [Conflict between mandatory statements] A user agent MAY support additional signature algorithms. (Section: 6.1) A user agent MAY support additional digest methods. (Section: 6.2) A user agent MAY support additional XML canonicalization methods. (Section: 6.3) Section: 7.1 The Algorithm attribute of the ds:digestMethod MUST be one of the digest algorithms. The Algorithm attribute of the ds:CanonicalizationMethod element MUST be one of the canonicalization algorithms. The ds:SignatureMethod algorithm used in the ds:SignatureValue element MUST be one of the signature algorithms. Comment - If in section 6 we say A user agent MAY support additional XXX algorithms, which seems to be in conflict with section 7 that states the algorithm used must be one of algorithms listed in section 6. This seems to be an open ended requirement. Suggestion - Remove the statements in section 7.1. It is down to the signer to choose the algorithm to use. If they choose to use a non-recommended algorithm they should understand that user agent support cannot be guaranteed. --- Question / non-editorial --- ---[Support for certificate chains]--- Typically more than one X509 certificate will need to be included in the signature in order to construct a certificate chain to an installed root certificate. Ideally the widget user agent would be given an indication of how to re-construct the certificate chain. This could be done my recommending that X509Certificate elements be included in certificate chain order or by including an attribute to the element, e.g. X509Data X509Certificate order=1.../X509Certificate X509Certificate order=2.../X509Certificate X509Certificate order=3.../X509Certificate /X509Data Maybe this is already solved with other uses of XML Digital Signatures? [1] http://dev.w3.org/2006/waf/widgets-digsig/ [2] http://www.w3.org/TR/widgets/#definitions -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 21 May 2009 18:23 To: public-webapps; public-xml...@w3.org Subject: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1 Hi All - a friendly reminder June 1 is the end of the comment period for the April 30 Widgets 1.0: Digital Signatures Last Call Working Draft: http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ Please send all comments by June 1. -Regards, Art Barstow On May 1, 2009, at 10:48 AM, Barstow Art (Nokia-CIC/Boston) wrote: On April 30 the WebApps WG published a LCWD of the Widgets 1.0 Digital Signatures spec: [[ http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ Introduction This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Widget authors and distributors can digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and to confirm the signing key(s). This document specifies conformance requirements on
RE: [widgets] Moving Widgets 1.0: Digital Signature spec to Candidate Recommendation
Hi Art, Vodafone supports this proposal. I have submitted some late (sorry!) editorial comments (see separate email) but do not believe any other comments were received or that the comments I submitted should hold up this process. Thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 02 June 2009 14:02 To: public-webapps Subject: [widgets] Moving Widgets 1.0: Digital Signature spec to Candidate Recommendation The comment period for the 30 April 2009 Widgets Digital Signature LCWD [1] ended 1 June 2009. It appears the only changes between the latest ED [2] and the LCWD are Editorial. It also appears no formal comments were submitted. Editors - please confirm this. One of the next steps to move this spec to CR is to agree on the CR's Exit Criteria. A strawman proposal (based on the Element Traversal CR) follows: [[ This is the DD MMM 2009 Candidate Recommendation of the Widgets 1.0: Digital Signature specification. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. The Web Applications (WebApps) Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has developed a comprehensive Widgets 1.0: Digital Signature test suite, and demonstrated at least two interoperable implementations for each test. The WebApps Working Group expects to show these implementations by September 2009. The Working Group does not plan to request to advance to Proposed Recommendation prior to 01 September 2009. ]] An agenda topic for the June 4 widgets voice conference will be a proposal to advance this spec to Candidate Recommendation. If you cannot attend that meeting and object to such a proposal, please clearly state your reason(s) for objecting before that meeting starts (June 4 @ 15:00 Paris time). -Regards, Art Barstow [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ [2] http://dev.w3.org/2006/waf/widgets-digsig/
Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
XML Signature 1.1 notes that the order of certificates in X.509Data is not specified. http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-X509Data Is this really expected to be an issue, with long cert chains? regards, Frederick Frederick Hirsch Nokia On Jun 4, 2009, at 8:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Vodafone has some late comments which it would like to provide to the group for consideration and apologise for supplying these after the deadline. We believe that all but one of the comments is editorial and so there inclusion or otherwise should not affect or delay the decision to go to CR status, which we support. In submitting these comments it is not our intention or desire to hold up this process, only to provide the comments for consideration. The only comment that doesn't fit into this category is a question that has been raised by one of our developers. My hope is that there is already an answer! Thanks, Mark --- Editorial Comments --- ---[Definition of file entry]--- Section: 1.2 A file entry is the compressed (or Stored [ZIP]) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification. In Widgets 1.0: Packaging and Configuration [2] the file entry definition is different. A file entry is the data held by a local file header, file data, and (optional) data descriptor, as defined in the [ZIP] specification, for each physical file contained in a Zip archive. Comment - the inclusion of folder in the definition in [1] has caused one reviewer to ask if there should be a reference element for folders? I believe this is not the case and or folder could be removed from the definition. ---[Requirements accuracy]--- Section: 2 R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1, DSA-SHA-256 and RSA-SHA-256. Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should probably be removed as they are not required algorithms. ECDSA-SHA-256 could be added. [Conflict between mandatory statements] A user agent MAY support additional signature algorithms. (Section: 6.1) A user agent MAY support additional digest methods. (Section: 6.2) A user agent MAY support additional XML canonicalization methods. (Section: 6.3) Section: 7.1 The Algorithm attribute of the ds:digestMethod MUST be one of the digest algorithms. The Algorithm attribute of the ds:CanonicalizationMethod element MUST be one of the canonicalization algorithms. The ds:SignatureMethod algorithm used in the ds:SignatureValue element MUST be one of the signature algorithms. Comment - If in section 6 we say A user agent MAY support additional XXX algorithms, which seems to be in conflict with section 7 that states the algorithm used must be one of algorithms listed in section 6. This seems to be an open ended requirement. Suggestion - Remove the statements in section 7.1. It is down to the signer to choose the algorithm to use. If they choose to use a non-recommended algorithm they should understand that user agent support cannot be guaranteed. --- Question / non-editorial --- ---[Support for certificate chains]--- Typically more than one X509 certificate will need to be included in the signature in order to construct a certificate chain to an installed root certificate. Ideally the widget user agent would be given an indication of how to re-construct the certificate chain. This could be done my recommending that X509Certificate elements be included in certificate chain order or by including an attribute to the element, e.g. X509Data X509Certificate order=1.../X509Certificate X509Certificate order=2.../X509Certificate X509Certificate order=3.../X509Certificate /X509Data Maybe this is already solved with other uses of XML Digital Signatures? [1] http://dev.w3.org/2006/waf/widgets-digsig/ [2] http://www.w3.org/TR/widgets/#definitions -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 21 May 2009 18:23 To: public-webapps; public-xml...@w3.org Subject: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1 Hi All - a friendly reminder June 1 is the end of the comment period for the April 30 Widgets 1.0: Digital Signatures Last Call Working Draft: http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ Please send all comments by June 1. -Regards, Art Barstow On May 1, 2009, at 10:48 AM, Barstow Art (Nokia-CIC/Boston) wrote: On April 30 the WebApps WG published a LCWD of the Widgets 1.0 Digital Signatures spec: [[ http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ Introduction This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a
Re: [DOM3Events] Use cases for Mutation Events
Whether there are libraries that use them or not, I honestly can't tell. However there are scenarios where 3rd party libraries like jQuery or prototype might require to know if the document has mutated to update their internal data structures. They do not know now if document is mutated (generally speaking), and the developers who use those libraries got used to that? Also, if I am not mistaken, Webapps group is here to eliminate the very need in such libraries by standardazing and pushing the consistent API to the browsers world. For the 3rd party scripts, it's quite common for sites to deploy 3rd party scripts that embed links to social networking sites, bookmarking services, embedding ads, embedding videos, etc. If somehow the script breaks the main page's tree, a mutation event could help, although in these cases, probably the load events would be good enough. 3rd party libraries should rather provide an API to their functionality, than letting developers to discover effect they caused from the view (HTML/SVG). Sergey/
Re: [DOM3Events] Use cases for Mutation Events
On Jun 4, 2009, at 12:17 , Jonas Sicking wrote: I generally agree, and I think that had mutation events never been implemented (I'm looking at you Hyatt) the world would probably not have missed them very much. More to the point, if browsers would give us XBL2 mutation events would be a whole lot less needed. (Yes Jonas, you know at whom I'm looking). One thing that mutation events were used a lot for back in the old days of ASV (that supported them early on, IIRC in v3) was to add behaviour through decoration. Basically you could add a foo:draggable=true on an element and know that a JS library would detect that change and make your element draggable. It's the poor man's XBL really. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Widgets 1.0: Digital Signatures
Hi, apologies for the late comments. I hope all of my comments are of an editorial nature. The only one that might not be is the last one which is a question. http://dev.w3.org/2006/waf/widgets-digsig/ - I'm aware this is non normative: 1.4 Example CanonicalizationMethod Algorithm=http://www.w3.org/2006/12/xml-c14n11/ SignatureMethod Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256; / but..do we want to be consistent about trailing spaces before / ? - there are tabs here, which is inconsistent with the rest of the example: KeyInfo X509Data X509Certificate.../X509Certificate /X509Data /KeyInfo - 4 Locating and Processing Digital Signatures for the Widget 3. If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc). In Safari 4 beta, the paragraph has a blank paragraph between it and the 3. number, this differs from 6. - If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc). change xml etc to xml, etc. - 7.1 Common Constraints for Signature Generation and Validation 4. Every Signature Property required by this specification MUST be incorporated into the signature as follows: b. A widget signature MUST include a ds:Object element within the ds:Signature element. This ds:Object element MUST have an Id attribute that is referenced by a ds:Reference element within the signature ds:SignedInfo element. Why is Id written in mixed case? -
Re: Mutation events replacement
On Jun 4, 2009, at 12:14 , Jonas Sicking wrote: On Thu, Jun 4, 2009 at 3:56 AM, Robin Berjon ro...@berjon.com wrote: On Jun 4, 2009, at 11:07 , Jonas Sicking wrote: 'AttributeChanged': Called when an attribute on the node is changed. This can be either a attribute addition, removal, or change in value. If setAttribute is called the 'AttributeChanged' listener is always called, even if the attribute is given the same value as it already had. This is because it may be expensive to compare if the old and new value was the same, if the value is internally stored in a parsed form. I take it in this case the Attr node is what's passed? Might give a reason for its sorry existence :) No, it'd be the element. The callback implementation would be responsible for going through the attributes it is interested in and take appropriate action based on their values. That's annoying. I'm guessing that creating an Attr node just for this purpose is overhead we can live without given that they're never used, but it would be cheap (and dead useful) to include at least the attribute's name (ns/ln pair). 'ChildlistChanged': Called if one or or mode children are added or removed to the node. So for example when innerHTML is set, replacing 10 existing nodes with 20 new ones, only one call is made to the 'ChildlistChanged' listeners on that node. 'SubtreeChanged': Same as 'ChildlistChanged', but called not just for children added/removed to the node, but also to any descendants of the node. If multiple nodes are changed at once, I'm guessing you call back with a DocumentFragment? No, you always call back with the node who had children added or removed to it. So if I do myNode.innerHTML = ihello/iworldb!/b; Then there would be only a single call to each callback with myNode passed as node. Even though 3 nodes are inserted, and all existing nodes were removed. So if I'm myNode's great-great-great-grand-mother and am watching SubtreeChanged do I get called with myNode or myself? I hope it's myNode, otherwise it's a bit useless. I'm thinking we might need ChildElementsChanged and ElementsSubtreeChanged that would handle only elements as well. When would these be called? Why isn't ChildlistChanged enough? I don't feel strongly about it — but it seems that every time we do something that's generic to nodes people come back and ask for an elements only variant, because that's what they actually use. 'TextDataChanged': Called when the data in a Text, CDATASection or ProcessingInstruction, is changed on the node or any of its decendants. Hm. If I set the listener on a PI, then I might be interested in this event — in which case it should be available on comment nodes too. Ah, yes, I missed comment. Really it should be all CharacterData nodes and all PIs. I'm not sure, see below. But then again, it seems to imply that I wouldn't get notified of changes to the PI's target. Ah, yeah, we could fire it for changes to the target too. Well, if you're firing on PIs it could be useful :) If on the other hand I listen to this on an element, I probably don't want to hear about changes made to PIs (or comments) in the subtree. I think PIs and comments are changed rarely enough that this isn't worth optimizing for. Unless you are worried about bugs somehow arising? Precisely because they're rare, I'm worried about bugs when all of a sudden they're triggered. I think that there's a distinction (in authors' minds) between content — which includes text — and the other stuff — like PIs and comments. I think we should mirror that understanding, as it's rather sensible. It'd be a shame if 99.99% of code had to start with if (node.nodeType == PROCESSING_INSTRUCTION_NODE || node.nodeType == COMMENT_NODE) return; and half of it forgot to. I'm really trying to optimize for creating something simple and performant here. I'm all for that, but it should also be useful and simple to use :) -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Mutation events replacement
2009/6/4 Jonas Sicking jo...@sicking.cc: On Thu, Jun 4, 2009 at 4:46 AM, mozer xmli...@gmail.com wrote: On Thu, Jun 4, 2009 at 1:42 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jun 4, 2009 at 4:37 AM, mozer xmli...@gmail.com wrote: On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote: Here's an API that might work: The following methods are added to the Document, Element and DocumentFragment interfaces: addAttributeChangedListener(NodeDataCallback); addSubtreeAttributeChangedListener(NodeDataCallback); addChildlistChangedListener(NodeDataCallback); addSubtreeChangedListener(NodeDataCallback); I would go for addSubtreeElementChangedListener for this one since a modification to an attribute in the subtree does not trigger it the 'SubtreeAttributeChanged' callbacks are called whenever an attribute is the subtree below the node where the callback is registered is changed. Is that not what you need? I.e. in a DOM like body div p here's some text /p /div /body If I call div.addSubtreeAttributeChangedListener(doStuff); then doStuff is called if someone sets an attribute on the p element. We're in agreement here ! That's why I would go for a name stating explicitly that it is about ELEMENT in the subtree and not Whatever in the subtree Ah, now I understand what you're suggesting. I think ElementChanged could mean more than attribute changes though, such as children added or removed. I'll leave debates for things like names for later though, until there's agreement that this is the general API we want to go for. / Jonas What about the simpler: void addModificationListener(in DOMString type,in NodeDataCallback handler, in boolean subtree); void removeModificationListener(in DOMString type,in NodeDataCallback handler, in boolean subtree); with a string for the modification type (ElementAdded, ChildListChanged, ElementRemoved, AnyNodeAdded, etc.), the handler as a NodeDataCallback and a boolean indicating if we want to track all the subtree or only the current node. Possibly, the first argument may be an integer (an enumeration), the first function may return an opaque identifier to be used in removeModificationListener instead of those three arguments, because handler may be lost between addML and removeML, and NodeDataCallback may be extended to include a NodeList of nodes involved in the modification. This way we don't have to create a function for every node type (any, attribute, element, chardata), multiplied by every node operation (add, remove, change), multiplied by 2 (current node only or all subtree) and again by 2 (add and remove handler) and thus we disambiguate between different dom operations in fast native code, rather than in the slow JS interpreter. Lastly, you could use the event queue mechanism used by HTML5 for asynchronous events (modifications callbacks are just events that are not captured and neither bubble), instead of defining your own. Giovanni
Re: Widgets 1.0: Digital Signatures
4. Every Signature Property required by this specification MUST be incorporated into the signature as follows: b. A widget signature MUST include a ds:Object element within the ds:Signature element. This ds:Object element MUST have an Id attribute that is referenced by a ds:Reference element within the signature ds:SignedInfo element. Why is Id written in mixed case? That's a choice that was made in the original version of the XML Signature spec 7 years ago.
Re: [widgets] What does it mean to have an unavailable API
We inject JS into the head of the Widget HTML, including the Widget API object, before sending it to the client browser; it automatically initializes itself. If a Widget requires shared state and participant features (e.g. Google Wave), then we inject our reverse-AJAX JS, which triggers either polling, comet, or piggyback synching (depending on server configuration). So we wouldn't want to do this for every widget, especially when many of them are single-user/ single-state and don't need it. I can imagine other features implemented by Widget UAs that might have resource implications if not selectively applied using feature. For this reason alone the feature element gets a +1 from me :-) S On 4 Jun 2009, at 10:30, Marcin Hanclik wrote: Yes, one of the differences between feature and requestFeature() is the time when the actual API gets available. What is the automatic polling? Do you assume that the loaded feature is initialized by a kind of onLoad method? Thanks. 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: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Thursday, June 04, 2009 10:58 AM To: Jonas Sicking Cc: Marcin Hanclik; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API Security is on UC; another is resource use. If the UA only needs to inject the modules needed by a Widget this can have a positive impact on downloading and processing Widgets. For example, if you have a lot of optional features, each of which is another 12k of injected JS... well, you get the idea. You don't want to have those downloaded every time if they aren't needed. Also, if any of those modules do automatic polling then you only want to load them for Widget instances that really do need to use them. S On 4 Jun 2009, at 08:25, Jonas Sicking wrote: On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. Ah, so requestFeature() is a BONDI spec, not a widget spec? However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when requestFeature() is called. As it was described to me by Marcos earlier in this thread, feature was used so that a widget could statically declare which security sensitive features it desired to use. This added security because if the widget was hacked, it could never use more security sensitive functionality than what had been statically declared using feature. So for example a widget that displays the current time would not need to claim access to any security sensitive APIs like camera or network access. This way it wasn't such a big deal if someone managed to hack the camera widget and get malicious code to run in the widgets security context, since that malicious code would not have access to camera or network. But if the malicious code could simply call requestFeature to gain access to camera, the above description no longer holds true. / Jonas 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. smime.p7s Description: S/MIME cryptographic signature
[widgets] Draft Minutes from 4 June 2009 Voice Conference
The draft minutes from the May 28 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/06/04-wam-minutes.html#item08 WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 18 June 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conf 04 Jun 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0728.html See also: [3]IRC log [3] http://www.w3.org/2009/06/04-wam-irc Attendees Present Art, Robin, Thomas, Arve, Marcos, Josh, Jere, David, Frederick, Mark Regrets Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]DigSig LCWD comments by Vodafone 4. [8]Widgets Dig Sig spec: agree on candidate exit criteria: 5. [9]Widgets Dig Sig spec: Dependency on XML Sig 1.1 6. [10]Widgets Digital Signature spec: Proposal to publish Candidate Recommendation 7. [11]WAR spec: UCs and requirements 8. [12]Prepare for June 9-11 f2f meeting Draft agenda: comments, priorities, etc.: 9. [13]Open Actions 10. [14]AOB * [15]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 4 June 2009 arve Zakim: P2 is me Review and tweak agenda AB: I posted the agenda on June 3 ([16]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0 728.html). The only change I propose is to change the order of 3.b and 3.c. Any change requests? [16] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0728.html). TR: move f2f preps to end of meeting AB: OK; we will do that ... add Mark's latest email re DigSig to the agenda ... Robin, will you represent Mark on this call? darobin mpriestl: can you get on the call? RB: no, not really Announcements AB: I have one short announcement: for those of you following the Draft DAP WG Charter () discussions, Frederick has been designated as a Chair (along with Robin) DR: what is the Chair selection process? TR: it is mostly opaque ... and Team driven DR: if you would direct me to the Proc Doc; I'm not clear on it TR: sure, I can do that ... I think the only relevant text is the Director will appoint the Chair AB: any other announcements? [ None ] DigSig LCWD comments by Vodafone AB: Mark submitted comments this morning which is 3 days too late ... my recommendation is to postpone the handling of those comments until after the CR is published ... comments on my proposal? MP: that is fine for VF ... I am sorry those comments were late ... I don't think any of the comments will affect Candidate ... one may be a bit problematic AB: want to emphasize we will always accept comments ... we do have to be careful though about moving the target date ... proposed Resolution: we will handle VF's LCWD comments of June 4 during CR ... any objections? [ None ] RESOLUTION: we will handle VF's LCWD comments of June 4 during CR Widgets Dig Sig spec: agree on candidate exit criteria: AB: a few days ago I proposed some text for the WidDigSig's Candidate exit criteria ([17]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0 700.html). Any comments about that proposal? [17] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0700.html). Marcos_ +a AB: any objections to the proposed Exit Criteria? [ None ] Widgets Dig Sig spec: Dependency on XML Sig 1.1 AB: one issue we need to discuss before resolving to publish a DigSig CR is how far can this spec go in the Recommendation track with a normative dependency on a WD of XML Digital Signatures 1.1?. My understanding is PR but no further. Thomas or Mike, would you please clarify? TR: I believe your understanding is correct ... but I'll check ... I think the doc is well hidden AB: XBL2 has a precedence of this TR: let's proceed as if this won't be an issue and we can deal with it later if we need to MS: +1 to TR AB: we then proceed as planned Widgets Digital Signature spec: Proposal to publish Candidate Recommendation AB: the WidDigSig spec is ready to be published as a Candidate Recommendation. Any objections to that? MC: I have concerns about the cannoicalization aspects ... have they been resolved? TR: are these general issues or ones that can be dealt with during CR Zakim MikeSmith, you wanted to say that we have not hard-and-fast
Re: Widgets 1.0: Digital Signatures
Thanks for the review Josh. These all look editorial to me and I assume we can handle them during CR. regards, Frederick Frederick Hirsch Nokia On Jun 4, 2009, at 9:30 AM, ext timeless wrote: Hi, apologies for the late comments. I hope all of my comments are of an editorial nature. The only one that might not be is the last one which is a question. http://dev.w3.org/2006/waf/widgets-digsig/ - I'm aware this is non normative: 1.4 Example CanonicalizationMethod Algorithm=http://www.w3.org/2006/12/xml-c14n11/ SignatureMethod Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256; / but..do we want to be consistent about trailing spaces before / ? - there are tabs here, which is inconsistent with the rest of the example: KeyInfo X509Data X509Certificate.../X509Certificate /X509Data /KeyInfo - 4 Locating and Processing Digital Signatures for the Widget 3. If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc). In Safari 4 beta, the paragraph has a blank paragraph between it and the 3. number, this differs from 6. - If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc). change xml etc to xml, etc. - 7.1 Common Constraints for Signature Generation and Validation 4. Every Signature Property required by this specification MUST be incorporated into the signature as follows: b. A widget signature MUST include a ds:Object element within the ds:Signature element. This ds:Object element MUST have an Id attribute that is referenced by a ds:Reference element within the signature ds:SignedInfo element. Why is Id written in mixed case? -
RE: [widgets] PC Last Call comments, zip-rel-path ABNF
Hi Marcos, Great thanks for all the fixes! I have seen also the further changes in the draft. One more comment to this chunk: Authors need to keep path lengths below 250 bytes. Unicode code points can require more than one byte to encode a character, which can result in a path whose length is less than 250 characters. The second sentence is actually not needed in this form. I would drop it or change it as follows: Authors need to keep path lengths below 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters to be represented in more than 250 bytes. 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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Monday, June 01, 2009 9:20 PM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [widgets] PC Last Call comments, zip-rel-path ABNF On Mon, Jun 1, 2009 at 12:44 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Error in ABNF: localized-folder vs. locale-folder Fixed. Error with ABNF utf8-chars = safe-chars / U+0080 and beyond and beyond does not fit here right. What should be there is: utf-8-chars = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF / %x1-1FFFD / %x2-2FFFD / %x3-3FFFD / %x4-4FFFD / %x5-5FFFD / %x6-6FFFD / %x7-7FFFD / %x8-8FFFD / %x9-9FFFD / %xA-AFFFD / %xB-BFFFD / %xC-CFFFD / %xD-DFFFD / %xE1000-EFFFD Section 2. of RFC2279 shows that all UTF-8 characters above U+0080 are encoded with byte values over 0x80. So utf-8 production equals to cp437 production on the byte level within the context that is important for us. Correct, I think. So both productions can be equalized and removed, since allowed-char may be used. right. I think the problem is similar to this one about encoding (I just had a brief look on it): http://lists.w3.org/Archives/Public/public-html/2009May/0643.html Yes, they are just byte ranges. Error with ABNF cp437-chars = safe-chars / x80-FF should be according to RFC2234: cp437-chars = safe-chars / %x80-FF Right, but safe chars does not cover the whole CP437 range. Due to many issues I would rewrite the whole ABNF as follows. ABNF issues, additionally to the above, are: 1. plural form used for just one-of value Where? 2. the zip-rel-path may have problems with existence, since all productions are optional. The below format seems equal and is shorter See below. 3. the production of file-name is wrongly specified, since there file-extension could appear up to 254 times in a file name yes, that is wrong. 4. I am not sure whether the file extension could be more than 3 chars or not in the existing ABNF? Yes, it's at least 1 to many. It's not restricted to 3 and I'm not sure why you are saying we should restrict it to 3? If so, the actual file name shall match 2 rules simultaneously, e.g.: file-name1 = 1*allowed-char [ . 1*allowed-char ] file-name2 = 1*254 ( allowed-char ) Matching of those 2 rules is not expressible in ABNF, so prose would be needed. New ABNF (problem of file extension length as above still remains): ** A valid Zip relative path is one that case-insensitively matches the production of Zip-rel-path in the following [ABNF] that operates on bytes, not on characters, i.e. after any encoding (CP437 or UTF-8) has been applied: zip-rel-path = [ locale-folder ] [ *folder-name ] [ file-name ] Everything in the above is optional too... so it's the same problem... locale-folder= locales / Language-Tag / folder-name = file-name / file-name= base-name [ file-extension ] file-extension = . 1*3 ( allowed-char ) base-name= 1*250( allowed-char ) allowed-char = safe-char / %x80-FF safe-char= ALPHA / DIGIT / SP / $ / % / ' / - / _ / @ / ~ / ( / ) / / + / , / . / = / [ / ] ** Here is another crack at it, taking the bugs your found into consideration. I also dropped the length restriction: zip-rel-path = [ *folder-name ] file-name / [ locale-folder ] 1*folder-name / locale-folder [ *folder-name ] file-name locale-folder = locales / Language-Tag / folder-name = file-name / file-name = base-name [ file-extension ] base-name = 1*allowed-char file-extension = . 1*allowed-char allowed-char = safe-char / utf8-char safe-char = ALPHA / DIGIT / SP / $ / % / ' / - / _ / @ / ~ / ( / ) / / + / , / . / = / [ /
RE: [widgets] What does it mean to have an unavailable API
We inject JS into the head of the Widget HTML, including the Widget API object, before sending it to the client browser; it automatically initializes itself. As for me this is just one of the possible implementations and the spec should not mandate how the additional API is made available. The client browser term should be replaced by rendering engine in this context, IMHO. Browser is something bigger for me. As for your other comments, I have to grasp it deeper first. Thanks. 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: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Thursday, June 04, 2009 3:50 PM To: Marcin Hanclik Cc: Jonas Sicking; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API We inject JS into the head of the Widget HTML, including the Widget API object, before sending it to the client browser; it automatically initializes itself. If a Widget requires shared state and participant features (e.g. Google Wave), then we inject our reverse-AJAX JS, which triggers either polling, comet, or piggyback synching (depending on server configuration). So we wouldn't want to do this for every widget, especially when many of them are single-user/ single-state and don't need it. I can imagine other features implemented by Widget UAs that might have resource implications if not selectively applied using feature. For this reason alone the feature element gets a +1 from me :-) S On 4 Jun 2009, at 10:30, Marcin Hanclik wrote: Yes, one of the differences between feature and requestFeature() is the time when the actual API gets available. What is the automatic polling? Do you assume that the loaded feature is initialized by a kind of onLoad method? Thanks. 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: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Thursday, June 04, 2009 10:58 AM To: Jonas Sicking Cc: Marcin Hanclik; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API Security is on UC; another is resource use. If the UA only needs to inject the modules needed by a Widget this can have a positive impact on downloading and processing Widgets. For example, if you have a lot of optional features, each of which is another 12k of injected JS... well, you get the idea. You don't want to have those downloaded every time if they aren't needed. Also, if any of those modules do automatic polling then you only want to load them for Widget instances that really do need to use them. S On 4 Jun 2009, at 08:25, Jonas Sicking wrote: On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. Ah, so requestFeature() is a BONDI spec, not a widget spec? However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when requestFeature() is called. As it was described to me by Marcos earlier in this thread, feature was used so that a widget could statically declare which security sensitive features it desired to use. This added security because if the widget was hacked, it could never use more security sensitive functionality than what had been statically declared using feature. So for example a widget that displays the current time would not need to claim access to any security sensitive APIs like camera or network access. This way it wasn't such a big deal if someone managed to hack the camera widget and get malicious code to run in the widgets security context, since that malicious code would not have access to camera or network. But if the malicious code could simply call requestFeature to gain access to camera, the above description no longer holds true. / Jonas 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
Automated API specification generation
Hi All, This is FYI. To accelerate the API standardization process we can use some tools. As you know BONDI uses widl format (WebIDL + doxygen). http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#dox It has its problems, but it helped us a lot. We could discuss first the patterns and document format, e.g. XML-based. This is planned already for BONDI. In ACCESS I prepared a tool that helped me ensure some quality aspect of the BONDI specs. It is known as API database approach, since one of the intermediate format is a database that enables SQL queries to the spec. The output is e.g. here: http://bondi01.obe.access-company.com/1_0_3309_41/ The tool enables me to prepare specification checkers, one of them is here: http://bondi01.obe.access-company.com/1_0_3309_41/checker_versions.html (it checks whether version of the widl file was specified correctly) Another nice aspect are the statistics: http://bondi01.obe.access-company.com/1_0_3309_41/stats.html I assume a tool, format, etc. could help the group concentrate on the real problems and the syntactical issue could be spotted more easily. 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 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 1.0: Digital Signatures
Why is Id written in mixed case? On Thu, Jun 4, 2009 at 4:44 PM, Thomas Roessler t...@w3.org wrote: That's a choice that was made in the original version of the XML Signature spec 7 years ago. gah. thanks, and i think i've actually asked about this before. oops. ok, retracted. sorry :) although, would it be unreasonable to add a note reminding people that it is mixed case and why? :)
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 6:31 AM, Robin Berjon ro...@berjon.com wrote: On Jun 4, 2009, at 12:14 , Jonas Sicking wrote: On Thu, Jun 4, 2009 at 3:56 AM, Robin Berjon ro...@berjon.com wrote: On Jun 4, 2009, at 11:07 , Jonas Sicking wrote: 'AttributeChanged': Called when an attribute on the node is changed. This can be either a attribute addition, removal, or change in value. If setAttribute is called the 'AttributeChanged' listener is always called, even if the attribute is given the same value as it already had. This is because it may be expensive to compare if the old and new value was the same, if the value is internally stored in a parsed form. I take it in this case the Attr node is what's passed? Might give a reason for its sorry existence :) No, it'd be the element. The callback implementation would be responsible for going through the attributes it is interested in and take appropriate action based on their values. That's annoying. I'm guessing that creating an Attr node just for this purpose is overhead we can live without given that they're never used, but it would be cheap (and dead useful) to include at least the attribute's name (ns/ln pair). Yeah, I definitely don't want to fore Attr nodes to be created just for this. The reason for not supplying the ns/ln pair is that this way we can fire the callback just once even if multiple attributes were changed during a DOM operation. 'ChildlistChanged': Called if one or or mode children are added or removed to the node. So for example when innerHTML is set, replacing 10 existing nodes with 20 new ones, only one call is made to the 'ChildlistChanged' listeners on that node. 'SubtreeChanged': Same as 'ChildlistChanged', but called not just for children added/removed to the node, but also to any descendants of the node. If multiple nodes are changed at once, I'm guessing you call back with a DocumentFragment? No, you always call back with the node who had children added or removed to it. So if I do myNode.innerHTML = ihello/iworldb!/b; Then there would be only a single call to each callback with myNode passed as node. Even though 3 nodes are inserted, and all existing nodes were removed. So if I'm myNode's great-great-great-grand-mother and am watching SubtreeChanged do I get called with myNode or myself? It's called with myNode. I actually got this wrong in the algorithm in my initial proposal. Here is a fixed version: When one or more attributes change on N: 1. For each 'AttributeChanged' callback, C, registered on N, add an item to the end of pendingCallbacks with the value C, N 2. Set P to N. 3. For each 'SubtreeAttributeChanged' callback, C, registered on P, add an item to the end of pendingCallbacks with the value C, N 4. Set P to P's parentNode. 5. If P is non-null, go to step 3. 6. If notifyingCallbacks is set to true, or pendingCallbacks is empty, abort these steps. 7. Set notifyingCallbacks to true. 8. Remove the first tuple from pendingCallbacks. 9. Call the handleEvent function on the callback in the tuple, with the 'node' argument set to the node from the tuple. 10. If pendingCallbacks is not empty, go to step 8. 11. Set notifyingCallbacks to false. (For childlist changes, run the above with 'ChildlistChanged' instead of 'AttributeChanged', and 'SubtreeChanged' instead of 'SubtreeAttributeChanged') I'm thinking we might need ChildElementsChanged and ElementsSubtreeChanged that would handle only elements as well. When would these be called? Why isn't ChildlistChanged enough? I don't feel strongly about it — but it seems that every time we do something that's generic to nodes people come back and ask for an elements only variant, because that's what they actually use. The only advantage I can see with this is that listeners that that only care about the element tree, would avoid getting notified when only non-element nodes were added or removed. The code in the listener would be exactly the same. So it's strictly a performance optimization. On the flip side, for something like the innerHTML setter, the UA will have to keep track of if the childlist used to contain any elements, and then check if the new childlist contains any element. I'm not convinced that this is worth it simply for a performance optimization. At least not in the initial revision of this API. But then again, it seems to imply that I wouldn't get notified of changes to the PI's target. Ah, yeah, we could fire it for changes to the target too. Well, if you're firing on PIs it could be useful :) Actually, target is readonly. If on the other hand I listen to this on an element, I probably don't want to hear about changes made to PIs (or comments) in the subtree. I think PIs and comments are changed rarely enough that this isn't worth optimizing for. Unless you are worried about bugs somehow arising? Precisely because they're rare, I'm worried about bugs when all of a sudden they're triggered. I
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 6:33 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: What about the simpler: void addModificationListener(in DOMString type,in NodeDataCallback handler, in boolean subtree); void removeModificationListener(in DOMString type,in NodeDataCallback handler, in boolean subtree); with a string for the modification type (ElementAdded, ChildListChanged, ElementRemoved, AnyNodeAdded, etc.), the handler as a NodeDataCallback and a boolean indicating if we want to track all the subtree or only the current node. Possibly, the first argument may be an integer (an enumeration), the first function may return an opaque identifier to be used in removeModificationListener instead of those three arguments, because handler may be lost between addML and removeML, and NodeDataCallback may be extended to include a NodeList of nodes involved in the modification. Why would it be easier to keep track of the opaque identifier than to keep track of the callback. In fact, couldn't you use the callback as a opac identifier? This way we don't have to create a function for every node type (any, attribute, element, chardata), multiplied by every node operation (add, remove, change), multiplied by 2 (current node only or all subtree) and again by 2 (add and remove handler) and thus we disambiguate between different dom operations in fast native code, rather than in the slow JS interpreter. I'm not quite following you here. Can you provide an example of a use case and code pattern that would be problematic? Lastly, you could use the event queue mechanism used by HTML5 for asynchronous events (modifications callbacks are just events that are not captured and neither bubble), instead of defining your own. I think we want the notifications to fire by the time that the function that caused the DOM mutation returned. So in code like myNode.innerHTML = bhello world!/b; doStuff(); by the time doStuff is called all the notifactions have fired and updated whatever state that they need to update. / Jonas
Re: review of AE
On Fri, 24 Apr 2009, Robin Berjon wrote: On Apr 24, 2009, at 11:12 , Marcos Caceres wrote: Also note that a scheme doesn't necessarily uniquely map to a protocol, so it should probably say scheme handler. Right. I thought the same thing. I used protocol handler to be consistent with HTML5. Ah, well before we use different terminology we should have a chat with someone who knows where that wording comes from in HTML5 and see if there's a reason to keep it. I've corrected HTML5's terminology. (The word protocol is still used in the API, for consistency with other parts of the Web API, e.g. the location.protocol attribute.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
