Re: [widgets-twi] window object
Le 08/02/2010 13:29, Robin Berjon a écrit : On Feb 5, 2010, at 16:18 , Marcos Caceres wrote: On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr wrote: So I'm wondering how should the widget object be implemented in a UA that does not support the window object ? Yeah, that's a tough one... the spec says: For a widget instance, a user agent MUST expose a unique object that implements the widget interface to author scripts. It does not give any guidance as to how the interface must be exposed. But then again, SVG supports the Window object (minimally defined in http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a widget field there ought to be straightforward. My mistake. I had not realized that. But again, the question is why put the widget object on the window object, apart from it being a black hole. Why not put it in the global object. What's wrong with that? It would easier to specify. What's the benefit of using the window object? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] TWI: comments
Hi Marcos,
Le 08/02/2010 16:56, Marcos Caceres a écrit :
On Thu, Feb 4, 2010 at 10:19 PM, Cyril Concolato
* The spec says:
When an object implementing the Widget interface is instantiated, if a user
agent has not previously associated a storage area with the instance of a
widget, then the user agent must initialize the preferences attribute.
What happens if the UA has already associated a storage area ? It should
probably say that no initialization of the preferences attribute is made but
the associated storage area can be used using the Storage interface, no ?
Right, I've adapted your text to read:
When an object implementing the Widget interface is instantiated, if
a user agent has not previously associated a storage area with the
instance of a widget, then the user agent must initialize the
preferences attribute.
If a user agent has previously associated a storage area with a widget
instance, the user agent must not re-initialize the preferences
attribute unless explicitly requested to do so by the end-user or for
security reasons. Instead, the previously associated storage area (or
an equivalent clone) can be accessed using the Storage interface.
Does that make any sense?
Yes it does.
... hmm... seems that Storage is tied to Window... bah. This goes back
to my previous email [1] about the window object. I think we need to
just bite the bullet and just put the Window dependency in :(
See my answer to Robin, I'm not sure to understand the benefits of that choice.
* What is the return value for the openURL method when there is a scheme
handler associate to the IRI ? When there is none, the text says the method
returns void. I think it also returns void so I wonder what's the point of
the paragraph.
Right. This whole openURL section needs a minor clean-up: there is a
bit or redundancy there. Let me work on that an get back to the WG.
Thanks.
* The IDL spec indicates that the preference attribute implements the
Storage interface, but I can't find a 'real' sentence saying it. I find:
Note: A user agent can support the Storage interface on DOM attributes
other than the preferences attribute (e.g., a user agent can to support the
[WebStorage] specification's localStorage attribute of the window object in
conjunction to the preferences attribute) but this is a note, hence not
normative.
Well spotted! The definition of preference now reads:
The preferences allows authors to manipulate a storage area that is
unique for the instance of a widget. It does this by implementing the
Storage interface specified in [WebStorage].
Good.
I suggest that you add an additional sentence. Also, the given example is
not really clear because it does not show the relationship between a
config.xml document with preference elements and the associated script and
storage.
That's a good point. I've added another example to the spec. Can you
please take a look?
Finally, can you clarify if the usage of getItem / setItem such as in
widget.preferences.getItem('foo'); and widget.preferences.setItem('foo',
'dahut'); is allowed or if only the brackets notation
(widget.preferences['foo']) is allowed. Maybe by adding an example ?
As of WebIDL , I believe the notations are equivalent. Regardless, I
have added an example. Please see the spec.
Can you point me to the right place because I can't find the new examples in:
http://dev.w3.org/2006/waf/widgets-api/
Regards,
Cyril
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/
Re: [widgets-twi] window object
On Tue, Feb 9, 2010 at 9:54 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Le 08/02/2010 13:29, Robin Berjon a écrit : On Feb 5, 2010, at 16:18 , Marcos Caceres wrote: On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr wrote: So I'm wondering how should the widget object be implemented in a UA that does not support the window object ? Yeah, that's a tough one... the spec says: For a widget instance, a user agent MUST expose a unique object that implements the widget interface to author scripts. It does not give any guidance as to how the interface must be exposed. But then again, SVG supports the Window object (minimally defined in http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a widget field there ought to be straightforward. My mistake. I had not realized that. But again, the question is why put the widget object on the window object, apart from it being a black hole. Why not put it in the global object. What's wrong with that? It would easier to specify. What's the benefit of using the window object? I don't think there is a way around this. Everything lives in the window: it is the top level scope. This is evident by running scriptalert(this)/script, which returns [object Window] or [object DOMWindow]. Changing this to have Widget as the top or as a shared top level scope would break code expecting to window object to be there. Also, it might not even be possible to have two objects be at the level scope at the same time. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] TWI: comments
On Tue, Feb 9, 2010 at 10:14 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi Marcos, Le 08/02/2010 16:56, Marcos Caceres a écrit : On Thu, Feb 4, 2010 at 10:19 PM, Cyril Concolato As of WebIDL , I believe the notations are equivalent. Regardless, I have added an example. Please see the spec. Can you point me to the right place because I can't find the new examples in: http://dev.w3.org/2006/waf/widgets-api/ My apologies, I thought I've checked them in! Here they are: http://dev.w3.org/2006/waf/widgets-api/#usage-example-getting-and-setting-prefer http://dev.w3.org/2006/waf/widgets-api/#usage-example-interacting-with-the-prefe -- Marcos Caceres http://datadriven.com.au
Re: [XHR] XMLHttpRequest specification lacks security considerations
On 8 Feb 2010, at 17:50, Anne van Kesteren wrote: - Somewhat detailed considerations around CONNECT, TRACE, and TRACK (flagged in the text of the specification, but not called out in the security section; 4.6.1). What is the reason for duplicating this information? It will be useful for implementers and reviewers of this specification to find a brief summary of the relevant issues within the spec itself. That doesn't imply that you simply need to duplicate information. Well, I didn't mean it literally, but that's what it would come down to, no? Again, please explain within the spec what the security reasons are for this specific profile of HTTP. It'll help people understand the spec a few years down the road. - Considerations around DNS rebinding. Why would these be specific to XMLHttpRequest? These indeed apply to just about any specification that uses a same-origin policy. But that's not a justification for ignoring them here. DNS rebinding has been both obvious and overlooked for some 10-15 years, so reminding reviewers and implementers of both the security risk and the countermeasures would seem appropriate. But you could e.g. do this kind of attack using img or form as well. It seems this problem should be pointed out in the HTTP specification. img or form permit you to place HTTP requests cross-origin anyway. The point here is that, if the server doesn't check host headers, then DNS rebinding lets you place requests to some other server that you're not supposed to be able to place. That's worth pointing out here. - Some explanation for the security reasons that are mentioned in section 4.6.2 (setRequestHeader). Maybe removing security reasons would be better? No. It's worth explaining why (a) we have a specific blacklist, and (b) what the impact of not having that blacklist is -- this is effectively profiling of the protocol elements that are accessible to applications; if I've seen a design decision that deserves a rationale in the spec, then this qualifies. There is already a note that explains why we have this list. I removed security reasons therefore. The above headers are not allowed to be set as they are better controlled by the user agent as it knows best what value they ought to have. That's hardly an explanation. - The rationale for the handling of HTTP redirects in section 4.6.4. I agree that this should be clarified, though I do not see why it should be mentioned in a separate section as well. It sounds useful to tell a single, consistent story about the security model around redirects, DNS rebinding, and same-origin policies, instead of scattering rationales through the spec. Therefore, I'm in favor of covering these topics in a single security considerations section. - The fact that this specification normatively defines the same-origin policy as it applies to network access within browsers (section 4.6.1; though that mostly refers to HTML5 these days) It does not define the policy. It just uses it. It does not define what same-origin means. That would be a bug in HTML5. It *is* the place that explains what policy applies to XMLHttpRequest, and the redirect section is one example where the policy needs to be refined for the specific case. What do you mean with refined? I think we have a case of too many its here. HTML5 explains when two origins are the same. That comparison gets applied in a number of policies: - navigation policy - same-origin policy for cross-frame scripting - XMLHttpRequest It's reasonable for the XMLHttpRequest specification to define the same-origin policy when it's applied to placing HTTP requests; it's also reasonable to explain in the XMLHttpRequest specification how an HTTP client should behave with respect to redirects when it's operating under that policy. It's not clear to me that this kind of material would actually belong in HTML5. However, please write up a coherent story that says (roughly) we're defining the application of this policy to HTTP, the critical pieces where it shows up in this specification are the following, and here are the specific security considerations we thought about when we wrote this down. On 8 Feb 2010, at 18:14, Anne van Kesteren wrote: On Mon, 08 Feb 2010 18:01:18 +0100, Julian Reschke julian.resc...@gmx.de wrote: Is re-binding == spoofing? Does http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.15.3 help, or does nit need to be updated (Thomas; HTTPbis will gladly accept your input ;-). As far as I can tell DNS rebinding is possible because clients observe TTL and can be prevented by servers carefully checking the Host header. The solutions clients can employ have potential drawbacks: http://en.wikipedia.org/wiki/DNS_rebinding I.e. it seems to be something different. correct HTML5 defines when two origins are the same, but it's remarkably silent about
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Feb 8, 2010, at 9:01 AM, Julian Reschke wrote: Anne van Kesteren wrote: - Considerations around DNS rebinding. Why would these be specific to XMLHttpRequest? These indeed apply to just about any specification that uses a same-origin policy. But that's not a justification for ignoring them here. DNS rebinding has been both obvious and overlooked for some 10-15 years, so reminding reviewers and implementers of both the security risk and the countermeasures would seem appropriate. But you could e.g. do this kind of attack using img or form as well. It seems this problem should be pointed out in the HTTP specification. ... Is re-binding == spoofing? Does http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.15.3 help, or does nit need to be updated (Thomas; HTTPbis will gladly accept your input ;-). DNS rebinding is a different type of attack than DNS spoofing. DNS spoofing typically involves binding the hostname of the victim to the IP of the attacker. This is done by fully controlling DNS on the local network or via DNS cache poisoning. DNS rebinding is almost the reverse - the attacker's domain name is bound to the victim's IP. This is used for an attack like so: 1) User loads a page from the attacker's domain. 2) Attacker serves his own DNS record with a very short TTL. 3) Attacker changes his DNS record to point to victim IP. 4) Script in the attackers page loads fresh resources on a short timeout - they are now coming from the victim's IP, but because they are labeled with the attacker's domain name, they are accessible due to the same-origin policy. This won't allow access to resources protected by cookies, but it *does* allow attackers to read arbitrary resources from firewall-protected internets, where being inside the firewall is the only access restriction. What the section you cited says actually increases the risk of DNS rebinding attacks. It says that If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they must observe the TTL information reported by DNS. Clients that follow this advice will be at greater risk than if they give cached DNS lookup results a floor on time-to-live, or keep a DNS resolution result pinned so long as any resource from that domain is active. DNS rebinding can also be defended against with complete effectiveness if servers always check the Host header. A server attacked via DNS rebinding will get an unexpected value in the Host header - the attackers hostname instead of any of its own. HTTPbis should address this threat in the security considerations section, and should strongly consider making it a MUST-level requirement for servers to check that the Host header is a host they serve. If HTTP had that requirement and all servers followed it, then the risk of DNS rebinding attacks would be eliminated. Meanwhile clients can only do partially effective or inordinately complex mitigations to protect against this attack, and client-side protections can risk breaking completely valid DNS round-robin load balancing setups. Regards, Maciej
Re: MPEG-U
Hi Cyril, On Feb 9, 2010, at 10:20 , Cyril Concolato wrote: Le 04/02/2010 13:35, Robin Berjon a écrit : It would be a lot simpler if the secretariat would just send an email to this list! I agree with you it would be much simpler, but that's not my choice. Well, you could vote with your feet ;-) Apparentyl, the attachement has been removed by a W3C member. I don't understand the reasons. Anyway, the WG should be able to process it. Can I request that this topic be discussed at the next conference of the WG? We certainly can, but our minutes are public — do we have to discuss it unrecorded? -- Robin Berjon - http://berjon.com/
Re: [widgets-twi] window object
On Feb 9, 2010, at 09:54 , Cyril Concolato wrote: My mistake. I had not realized that. But again, the question is why put the widget object on the window object, apart from it being a black hole. Why not put it in the global object. What's wrong with that? It would easier to specify. What's the benefit of using the window object? The Window object is the global object. Except it gets a little bit more complicated around WindowProxy. -- Robin Berjon - http://berjon.com/
Re: [widgets] TWI: comments
Hi Cyril, On Feb 9, 2010, at 09:52 , Cyril Concolato wrote: Le 08/02/2010 13:26, Robin Berjon a écrit : I'm not sure what you mean? The preference storage should remain available across instantiations of the widget. This could probably be rephrased though. I think that maybe there should be two separate words instead of 'instance' for the two notions: a) a widget package instantiated twice at the same time b) a widget package instantiated twice at different times. In a) you have 2 different storage areas. In b) you have only one. I don't think that that is something which you can infer from any of the specification we have published? Implementations may perform what you do by assigning different authorities in the widget URIs for your (a) and (b) but essentially that is equivalent to have two widget packages (that happen to have the same content). If it really is one and only one widget package, then I'd expect it to have the same widget URI any time it is launched, and therefore if it has multiple copies running in parallel those would share the storage. -- Robin Berjon - http://berjon.com/
Re: MPEG-U
Robin, Le 09/02/2010 13:41, Robin Berjon a écrit : Hi Cyril, On Feb 9, 2010, at 10:20 , Cyril Concolato wrote: Le 04/02/2010 13:35, Robin Berjon a écrit : It would be a lot simpler if the secretariat would just send an email to this list! I agree with you it would be much simpler, but that's not my choice. Well, you could vote with your feet ;-) Apparentyl, the attachement has been removed by a W3C member. I don't understand the reasons. Anyway, the WG should be able to process it. Can I request that this topic be discussed at the next conference of the WG? We certainly can, but our minutes are public — do we have to discuss it unrecorded? I don't think so. All the documents related to MPEG-U (unfortunately, except for liaisons) being public documents [1] this shouldn't be a problem. Cyril [1] http://mpeg.chiariglione.org/working_documents.htm#MPEG-U -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Tue, 09 Feb 2010 12:13:49 +0100, Thomas Roessler t...@w3.org wrote: On 8 Feb 2010, at 17:50, Anne van Kesteren wrote: Well, I didn't mean it literally, but that's what it would come down to, no? Again, please explain within the spec what the security reasons are for this specific profile of HTTP. It'll help people understand the spec a few years down the road. I'm not an expert on the reasons so I'd prefer not to. I believe I already mentioned that if someone writes text it could be taken in. But you could e.g. do this kind of attack using img or form as well. It seems this problem should be pointed out in the HTTP specification. img or form permit you to place HTTP requests cross-origin anyway. Well yes, but with this attack you can also read the response, at least with form and an iframe. Unless I'm missing something. The point here is that, if the server doesn't check host headers, then DNS rebinding lets you place requests to some other server that you're not supposed to be able to place. That's worth pointing out here. It is a general problem and not at all specific to XMLHttpRequest. There is already a note that explains why we have this list. I removed security reasons therefore. The above headers are not allowed to be set as they are better controlled by the user agent as it knows best what value they ought to have. That's hardly an explanation. When I added that I requested a better note but so far I have not gotten anything. It *is* the place that explains what policy applies to XMLHttpRequest, and the redirect section is one example where the policy needs to be refined for the specific case. What do you mean with refined? I think we have a case of too many its here. HTML5 explains when two origins are the same. That comparison gets applied in a number of policies: - navigation policy - same-origin policy for cross-frame scripting - XMLHttpRequest It's reasonable for the XMLHttpRequest specification to define the same-origin policy when it's applied to placing HTTP requests; it's also reasonable to explain in the XMLHttpRequest specification how an HTTP client should behave with respect to redirects when it's operating under that policy. It's not clear to me that this kind of material would actually belong in HTML5. XMLHttpRequest already explains how a client should behave in face of redirects or normal requests. However, please write up a coherent story that says (roughly) we're defining the application of this policy to HTTP, the critical pieces where it shows up in this specification are the following, and here are the specific security considerations we thought about when we wrote this down. The security stuff is based on what implementations did or advice from people who do research in this area. If anything needs to be said in the specification I would probably not be the right person to do it. HTML5 defines when two origins are the same, but it's remarkably silent about the so-called same-origin policy. The information may be there, but it#s not obvious where it is. I think you are right in that it does not actually explain what it is. You filed a bug on the matter so hopefully it gets resolved in due course. See above. The same-origin policy consists of a sufficient number of building blocks that it might be reasonable to keep some of them in a spec like XMLHttpRequest. I'm not convinced, e.g. EventSource faces exactly the same issues. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] XMLHttpRequest specification lacks security considerations
On 9 Feb 2010, at 14:30, Anne van Kesteren wrote: Again, please explain within the spec what the security reasons are for this specific profile of HTTP. It'll help people understand the spec a few years down the road. I'm not an expert on the reasons so I'd prefer not to. I believe I already mentioned that if someone writes text it could be taken in. So let's identify the instances where we think more material is needed and look for volunteers. But you could e.g. do this kind of attack using img or form as well. It seems this problem should be pointed out in the HTTP specification. img or form permit you to place HTTP requests cross-origin anyway. Well yes, but with this attack you can also read the response, at least with form and an iframe. Unless I'm missing something. You're right about that attack. The point here is that, if the server doesn't check host headers, then DNS rebinding lets you place requests to some other server that you're not supposed to be able to place. That's worth pointing out here. It is a general problem and not at all specific to XMLHttpRequest. It's highly relevant to XHR, though, and therefore worth calling out. Could we agree on that? There is already a note that explains why we have this list. I removed security reasons therefore. The above headers are not allowed to be set as they are better controlled by the user agent as it knows best what value they ought to have. That's hardly an explanation. When I added that I requested a better note but so far I have not gotten anything. So that's another open point that we need to find a volunteer for. It *is* the place that explains what policy applies to XMLHttpRequest, and the redirect section is one example where the policy needs to be refined for the specific case. What do you mean with refined? I think we have a case of too many its here. HTML5 explains when two origins are the same. That comparison gets applied in a number of policies: - navigation policy - same-origin policy for cross-frame scripting - XMLHttpRequest It's reasonable for the XMLHttpRequest specification to define the same-origin policy when it's applied to placing HTTP requests; it's also reasonable to explain in the XMLHttpRequest specification how an HTTP client should behave with respect to redirects when it's operating under that policy. It's not clear to me that this kind of material would actually belong in HTML5. XMLHttpRequest already explains how a client should behave in face of redirects or normal requests. Yes, of course. My request was for a security considerations section that explains the interaction and says where what policy is defined. However, please write up a coherent story that says (roughly) we're defining the application of this policy to HTTP, the critical pieces where it shows up in this specification are the following, and here are the specific security considerations we thought about when we wrote this down. The security stuff is based on what implementations did or advice from people who do research in this area. If anything needs to be said in the specification I would probably not be the right person to do it. HTML5 defines when two origins are the same, but it's remarkably silent about the so-called same-origin policy. The information may be there, but it#s not obvious where it is. I think you are right in that it does not actually explain what it is. You filed a bug on the matter so hopefully it gets resolved in due course. See above. The same-origin policy consists of a sufficient number of building blocks that it might be reasonable to keep some of them in a spec like XMLHttpRequest. I'm not convinced, e.g. EventSource faces exactly the same issues. Are they documented for EventSource? And if there's a common policy here, should this be a separate document?
Re: Rechartering WebApp WG
Doug, All, On Feb 8, 2010, at 7:25 AM, ext Doug Schepers wrote: We are interested in comments to refine the charter before submitting it to the Advisory Committee and W3C management for review. [1] http://www.w3.org/2010/webapps/charter/Overview.html The changes from the current [Charter] look good Doug! Some additional changes I propose, using [PubStatus] as a guide for some of the comments: 3.1 - a straight diff on the draft and [Charter] shows a relatively significant set of changes. However, there are really just 3 additions: Alternate Input Device Events, PostMessage + MessageChannel and Web Notifications. Perhaps it would be useful if these three additions were marked up such that these additions were easily identified. 3.1 - it would be convenient if all of the specs included pointers to their EDs (links are missing for Clipboard, DOM, File API, Progress Events, PostMessage/MessageChannel, Selectors L1 and L2, Web Notifications, XBL2, XHR L1 and L2). 3.1 - CORS is included as a 1st-level bullet and a sub-bullet of Secure Cross-Domain Scriptiong. I would delete CORS' 1st-level bullet. 3.1 - Widgets specs: we have already started to remove the Widgets 1.0: prefix for the spec names and this draft charter should do the same (e.g. change Widgets 1.0: Updates to Widget Updates). 3.1 - re Widgets View Modes - there are actually two related EDs so I would change this to Widgets View Mode: a media feature and API related to presentation mode. 3.3 - I think you can delete the Notes: line 4.1 - besides XHR, at least one of the widget specs (TWI) has a dependency on the HTML5 spec. 4.2 - re CSS WG, change the text to To collaborate on the Selectors API and widget media feature specifications 2., 3.1 and 4.2 all refer to the Canvas Graphics API. What is this API and would it make sense to consolidate this info in one or two places in the charter? 4.2 - Security Group? - it's not clear what this is about. Is this the informal security IG (public-web-security) or the XML Security WG or something else? 4.2 - re the MAWG, given WebApps' history with Media related spec work, perhaps the text should be a bit more specific e.g To integrate consistent APIs for multimedia functionality e.g. MAWG's a href=http://www.w3.org/TR/mediaont-api-1.0/;API for Media Resource 1.0/a. 4.3. - the Web Sockets protocol is in scope for IETF's HyBi (not their HTTP WG) and it should be explicitly identified. I think this can be addressed by using ... keep pace with the IETF's HTTP and a href=http://www.ietf.org/dyn/wg/charter/hybi-charter.html;HyBi/a groups' work 9. Given WAF and Device API WGs closed almost two years ago, I would delete the Please also see ... sentence. Lastly, 4 specs are listed in [PubStatus] and not included in the draft charter. Above I propose a way to reflect our interest in what [Charter] calls Media Object, but re the other three: a. Element Traversal - it seems like this should be explicitly included in the charter with a caveat that no work will be done except errata handling if the need arises. b. File Upload - does the group now consider this work taken over by the File API and File System spec or is there something here we want to explicitly include in the draft? c. Window object - given the wording in 3.1 re HTML5 split out, I presume it's OK for the draft to not explicitly include this spec since this wording would permit WebApps to take it (given an Editor, etc.). -Art Barstow [Charter] http://www.w3.org/2008/webapps/charter/ [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
Inconsistency in Web SQL Database Spec
Hello,
I noticed a slight inconsistency in the Web SQL Database Spec on
http://dev.w3.org/html5/webdatabase/Overview.html (version Feb 04, 2010)
The example in section 1 does not match to the API description in the
following sections.
E.g. consider the lines
db.readTransaction(function (t) {
t.executeSql('SELECT COUNT(*) AS c FROM docids', [], function (t, r) {
span.textContent = r.rows[0].c;
However, in Section 4.5 the API specifies that the rows are addressed via
r.rows.item(i)
Best regards,
Eric Westenberger
Re: Inconsistency in Web SQL Database Spec
On Tue, 09 Feb 2010 02:37:01 +0100, Eric Westenberger
eric.westenber...@googlemail.com wrote:
I noticed a slight inconsistency in the Web SQL Database Spec on
http://dev.w3.org/html5/webdatabase/Overview.html (version Feb 04, 2010)
The example in section 1 does not match to the API description in the
following sections.
E.g. consider the lines
db.readTransaction(function (t) {
t.executeSql('SELECT COUNT(*) AS c FROM docids', [], function (t, r)
{
span.textContent = r.rows[0].c;
However, in Section 4.5 the API specifies that the rows are addressed via
r.rows.item(i)
Because of the binding defined both will work.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [widgets-twi] window object
On 9 Feb 2010, at 09:22, Marcos Caceres wrote: On Tue, Feb 9, 2010 at 9:54 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Le 08/02/2010 13:29, Robin Berjon a écrit : On Feb 5, 2010, at 16:18 , Marcos Caceres wrote: On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr wrote: So I'm wondering how should the widget object be implemented in a UA that does not support the window object ? Yeah, that's a tough one... the spec says: For a widget instance, a user agent MUST expose a unique object that implements the widget interface to author scripts. It does not give any guidance as to how the interface must be exposed. But then again, SVG supports the Window object (minimally defined in http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a widget field there ought to be straightforward. My mistake. I had not realized that. But again, the question is why put the widget object on the window object, apart from it being a black hole. Why not put it in the global object. What's wrong with that? It would easier to specify. What's the benefit of using the window object? I don't think there is a way around this. Everything lives in the window: it is the top level scope. This is evident by running scriptalert(this)/script, which returns [object Window] or [object DOMWindow]. Changing this to have Widget as the top or as a shared top level scope would break code expecting to window object to be there. Also, it might not even be possible to have two objects be at the level scope at the same time. In Wookie we just create the widget object in the global scope, and then add it as an attribute to the window object. Author scripts can access it either by window.widget or just plain widget. I wonder though - for authors what should we recommend if they want their widget to run unmodified in the most UAs? S smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] TWI: comments
On 9 Feb 2010, at 12:49, Robin Berjon wrote: Hi Cyril, On Feb 9, 2010, at 09:52 , Cyril Concolato wrote: Le 08/02/2010 13:26, Robin Berjon a écrit : I'm not sure what you mean? The preference storage should remain available across instantiations of the widget. This could probably be rephrased though. I think that maybe there should be two separate words instead of 'instance' for the two notions: a) a widget package instantiated twice at the same time b) a widget package instantiated twice at different times. In a) you have 2 different storage areas. In b) you have only one. I don't think that that is something which you can infer from any of the specification we have published? Implementations may perform what you do by assigning different authorities in the widget URIs for your (a) and (b) but essentially that is equivalent to have two widget packages (that happen to have the same content). If it really is one and only one widget package, then I'd expect it to have the same widget URI any time it is launched, and therefore if it has multiple copies running in parallel those would share the storage. Its up to implementations how they decide what rules they apply to determine what makes a widget instance. For example in our implementation this is decided by the process of requesting the widget - if its the same user, the same context, and the same widget package, then its the same instance and shares a storage area. Otherwise its a new instance with a new URI (by adding an instance id). But that's our implementation, and it relies on protocols that are outside the scope of TWI. I suggest looking at it from the user's perspective - given how the UA works, would they expect the storage to be shared or be separate? smime.p7s Description: S/MIME cryptographic signature
Re: Rechartering WebApp WG
Hi Doug, There are a couple of additional areas it would be useful to consider for future work in the Widgets space, specifically: - inter-widget communication (both single-user and multi-user, e.g. collaboration) - social web APIs for widgets (e.g. friends, friends-of) The latter is a topic for a call next month with the Social Web IG, and would involve co-ordination with DAP as it may share some characteristics with the Contacts API. It would also be useful to have a liaison with the OpenSocial foundation. S On 8 Feb 2010, at 12:25, Doug Schepers wrote: Hi, Folks- As you know, we will be up for rechartering on 30 June 2010. However, we have a few new deliverables, and we've been specifically advised that though they are arguably in scope, it would be better transparency if e.g. postMessage and MessageChannel were explicitly added to the charter. Thus, I have started a rough draft of the new WebApps charter [1], taking into account the feedback received so far on the WebApps member list. We are interested in comments to refine the charter before submitting it to the Advisory Committee and W3C management for review. [1] http://www.w3.org/2010/webapps/charter/Overview.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs /-/-/-/-/-/ Scott Wilson Apache Wookie: http://incubator.apache.org/projects/wookie.html scott.bradley.wil...@gmail.com http://www.cetis.ac.uk/members/scott smime.p7s Description: S/MIME cryptographic signature
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Tue, Feb 9, 2010 at 7:13 AM, Maciej Stachowiak m...@apple.com wrote: HTTPbis should address this threat in the security considerations section, and should strongly consider making it a MUST-level requirement for servers to check that the Host header is a host they serve. If HTTP had that requirement and all servers followed it, then the risk of DNS rebinding attacks would be eliminated. Servers don't always know what domains they're expected to serve -- if I sudo apt-get install lighttpd and already have a domain name pointing to the server, I expect that domain name to work with no additional configuration. And this is how all the web servers I've used actually work. So, I imagine this requirement is infeasible.
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Feb 9, 2010, at 11:46 AM, Aryeh Gregor wrote: On Tue, Feb 9, 2010 at 7:13 AM, Maciej Stachowiak m...@apple.com wrote: HTTPbis should address this threat in the security considerations section, and should strongly consider making it a MUST-level requirement for servers to check that the Host header is a host they serve. If HTTP had that requirement and all servers followed it, then the risk of DNS rebinding attacks would be eliminated. Servers don't always know what domains they're expected to serve -- if I sudo apt-get install lighttpd and already have a domain name pointing to the server, I expect that domain name to work with no additional configuration. And this is how all the web servers I've used actually work. So, I imagine this requirement is infeasible. A sever can generally determine the domain name of the host it is running on from the operating system, if it wants to run with zero configuration. That is apparently what Apache does: http://httpd.apache.org/docs/1.3/mod/core.html#servername Regards, Maciej
Re: Inconsistency in Web SQL Database Spec
2010/2/9 Anne van Kesteren ann...@opera.com
On Tue, 09 Feb 2010 02:37:01 +0100, Eric Westenberger
eric.westenber...@googlemail.com wrote:
I noticed a slight inconsistency in the Web SQL Database Spec on
http://dev.w3.org/html5/webdatabase/Overview.html (version Feb 04, 2010)
The example in section 1 does not match to the API description in the
following sections.
E.g. consider the lines
db.readTransaction(function (t) {
t.executeSql('SELECT COUNT(*) AS c FROM docids', [], function (t, r) {
span.textContent = r.rows[0].c;
However, in Section 4.5 the API specifies that the rows are addressed via
r.rows.item(i)
Because of the binding defined both will work.
--
Anne van Kesteren
http://annevankesteren.nl/
Hi,
sorry, I am not able to follow this explanation.To which binding are you
refering?
I came across this problem when trying to build a Chromium extension using
the newly provided HTML5 APIs.
I tried to follow the example in the introduction of the Spec and it did not
work. But using the API as specified
in Section 4.5 it worked fine.
Either both APIs are required to work by the Spec (and then there is a bug
in WebKit or Chrome plus the Spec should make this more explicit),
or the introduction section should be changed in my opinion.
Best regards,
Eric
