Rechartering WebApp WG
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
Re: [widgets] TWI: comments
On Feb 4, 2010, at 22:19 , Cyril Concolato wrote:
* A user agent whose start file implements [HTML5]'s Window interface MUST
...
The start file does not implement anything. The user agent implements. I
suggest to change it to something like:
User agent implementing the [HTML5]'s Window interface MUST ...
You're mostly right, but I see where the original comes from. The UA may
support Window but not expose it for all start files — e.g. it won't be there
for a SWF start file. The resulting sentence is going to be clumsy no matter
what :)
* The step 1 in the initialization of the preference attribute algorithm
which says Establish the instance of a widget for this widget and create a
storage area that is unique for the origin. should probably say unique for
the origin and for that instance.
I'm not sure what you mean? The preference storage should remain available
across instantiations of the widget. This could probably be rephrased though.
*In case two instances of the same widget package are loaded, modified (e.g.
weather in Paris and in New York) and then closed, how does the UA retrieve
the associated storage area when one is reloaded ? I don't think it can be
specified but I think you should probably add a note saying that it is
implementation specific, for example by asking the user what previous
instance it want to start first.
This is a lifecycle issue. It's not clear that two instances of the same widget
package loaded inside of the same UA is something that can even be described
with the current specifications (though it can be implemented).
We've talked about a lifecycle spec that would flesh these things out, but
there hasn't been much support (in terms of actually doing it).
Beyond that, I would expect it to work like loading the same page in two tabs.
* What happens to the storage event fired by the setItem or removeItem
methods when the UA does not implement the window object ?
I guess nothing!
* 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.
What you quote is in an i.e., i.e. it's a clarification for the reader. The
normative statement that it clarifies is the user agent must act as if the
method had not been invoked.
* 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.
Return the Storage object associated with that widget instance's
preferences attribute. but that's not really explicit.
Implement the Storage interface on the storage area, and make the
preferences attribute a pointer to that storage area. but this isn't as
clear as The UA MUST support the Storage interface on the preferences
attribute or similar...
I suggest that you add an additional sentence.
Why? The WebIDL is normative, and we certainly don't want to reproduce all of
the constraints it expresses in prose!
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 ?
That's really up to the Web Storage specification (and WebIDL).
--
Robin Berjon - http://berjon.com/
Re: [widgets-twi] window object
On Feb 5, 2010, at 16:18 , Marcos Caceres wrote: On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolato cyril.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. -- Robin Berjon - http://berjon.com/
Re: [widgets-twi] window object
Robin Berjon wrote: 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. As much as I dislike it, I'm also not that inclined to define what to do for non-Window-based implementations (beyond what we currently have in the spec; which, I admit, is not much). It is, non-the-less, kinda bad that we don't have a spec that defines Window independently of HTML but I understand why that is: because Window is a foul intertwined incestuous mess... However, as Window is an integral part of the Web platform, we might just have to live with that :( Also, the main use cases we are dealing with all rely on Window being there (HTML and, as Robin points out, SVG). If UAs start to emerge that are windowless (e.g., daemon or headless widgets), then we should formally define how this binds to some top-level context. WDYT? Kind regards, Marcos
Re: [widgets] TWI: comments
On Thu, Feb 4, 2010 at 10:19 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, While trying to implement the widget interface spec [1], I found two typos: - a user agent can to support = a user agent can support - missing closing parenthese in conjunction to the preferences attribute). fixed I have also some remarks/questions: * A user agent whose start file implements [HTML5]'s Window interface MUST ... The start file does not implement anything. The user agent implements. I suggest to change it to something like: User agent implementing the [HTML5]'s Window interface MUST ... Fixed * Section 5. is called Widget Interface but it starts by saying The widget object provides It think it should say Objects implementing the widget interface provide ... Fixed * The step 1 in the initialization of the preference attribute algorithm which says Establish the instance of a widget for this widget and create a storage area that is unique for the origin. should probably say unique for the origin and for that instance. Right, fixed. * 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? *In case two instances of the same widget package are loaded, modified (e.g. weather in Paris and in New York) and then closed, how does the UA retrieve the associated storage area when one is reloaded ? I don't think it can be specified but I think you should probably add a note saying that it is implementation specific, for example by asking the user what previous instance it want to start first. I personally think this is too implementation specific to comment on and there are just too many ways to solve this problem (e.g., order closed = order open, user prompting, etc.). * What happens to the storage event fired by the setItem or removeItem methods when the UA does not implement the window object ? ... 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 :( * 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. * 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]. Return the Storage object associated with that widget instance's preferences attribute. but that's not really explicit. Right. Given the clarification above, this should now make more sense. Implement the Storage interface on the storage area, and make the preferences attribute a pointer to that storage area. but this isn't as clear as The UA MUST support the Storage interface on the preferences attribute or similar... Given the redefinition of the preference attribute, it's a statement of fact that the preference attribute supports the Storage interface. The conformance requirements around that fact are tested through the various algorithms and behavior imposed by the specification. I suggest that you add an additional sentence. Also, the given example is not really clear because it
Re: XHR LC comment: header encoding
On Fri, 05 Feb 2010 23:42:09 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/31/10 7:38 AM, Anne van Kesteren wrote: Specifically search for inflate and deflate throughout the drafts: To deflate a DOMString into an byte sequence means to remove from each code point in the DOMString the higher-order byte and let the resulting byte (all the lower-order bytes) be the byte sequence. How about: To deflate a DOMString into a byte sequence means to create a sequence of bytes such the n-th byte of the sequence is equal to the low-order byte of the n-th code point in the original DOMString. To inflate an byte sequence into a DOMString means to create a code point for each byte of which the higher-order byte is 0x00 and the lower-order byte is the byte. The resulting code point sequence is the DOMString. To inflate a byte sequence into a DOMString means to create a DOMString such that the n-th codepoint has 0x00 as the high-order byte and the n-th byte of the byte sequence as the low-order byte. Other than that looks ok, though I still worry about changing behavior here... Thanks, fixed. Hopefully it all works out, and if not we will have to change the specification again. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets-twi] window object
On Feb 8, 2010, at 13:51 , Marcos Caceres wrote: As much as I dislike it, I'm also not that inclined to define what to do for non-Window-based implementations (beyond what we currently have in the spec; which, I admit, is not much). I don't think that we could even if we wanted to. Presumably, any technology that embeds Javascript will have to have defined a global object of some form or other (I don't see how it works otherwise) but the exact details will either 1) be copied from HTML or 2) be something different that we can't predict. So for (1) it'll be obvious what to do, for (2) it's obvious that we can't do anything to help. It is, non-the-less, kinda bad that we don't have a spec that defines Window independently of HTML but I understand why that is: because Window is a foul intertwined incestuous mess... Actually, the reason is because we don't have an editor for it. If we did, Window could get split out of HTML (as it used to be). Also, the main use cases we are dealing with all rely on Window being there (HTML and, as Robin points out, SVG). If UAs start to emerge that are windowless (e.g., daemon or headless widgets), then we should formally define how this binds to some top-level context. WDYT? Yeah, but we can cross that bridge if and when we get there. -- Robin Berjon - http://berjon.com/
Re: [widgets-twi] window object
Robin Berjon wrote: On Feb 8, 2010, at 13:51 , Marcos Caceres wrote: As much as I dislike it, I'm also not that inclined to define what to do for non-Window-based implementations (beyond what we currently have in the spec; which, I admit, is not much). I don't think that we could even if we wanted to. Presumably, any technology that embeds Javascript will have to have defined a global object of some form or other (I don't see how it works otherwise) but the exact details will either 1) be copied from HTML or 2) be something different that we can't predict. So for (1) it'll be obvious what to do, for (2) it's obvious that we can't do anything to help. Agreed. It is, non-the-less, kinda bad that we don't have a spec that defines Window independently of HTML but I understand why that is: because Window is a foul intertwined incestuous mess... Actually, the reason is because we don't have an editor for it. If we did, Window could get split out of HTML (as it used to be). No, I don't mean split in editorial terms. I mean in the way it interweaves its slimy windowy tentacles into everything else and how everything relies on it being there. Like Storage firing events on it, etc. They should have called it the BlackHole interface, as there is no escape:) Also, the main use cases we are dealing with all rely on Window being there (HTML and, as Robin points out, SVG). If UAs start to emerge that are windowless (e.g., daemon or headless widgets), then we should formally define how this binds to some top-level context. WDYT? Yeah, but we can cross that bridge if and when we get there. Agreed.
[widgets] API - openURL security considerations
At Opera we've been discussing some of the security implications around
the openURL method in the widgets API spec. We think the spec might
benefit if we were to add a non-normative security consideration section
for openURL.
We are basically concerned about protecting against a simple attack such as:
while(true){
openURL(http://...;);
}
The following text, which I did not write, can serve as a basis for the
note - we are presenting it here for discussion, and you'll note it uses
different terminology than the one found in the spec. In other words,
please don't consider the following to be spec text, it needs a fair
amount of editing but tries to get to the heart of the problem:
[[
APIs to open external programs, such as opening a URL in a browser,
SHOULD only be allowed automatically if the widget has focus. Opening
such an external program, SHOULD result in the widget losing focus, for
the purpose of opening more external programs. User interaction with the
widget may restore the focus to the widget. Widget Managers MAY offer a
dialog for other attempts to open external programs, or MAY fail the
operation. User agents MAY also offer an override for users to allow a
widget to open external programs automatically, even when minimized in
the background.
Security considerations: Widgets may have managed run-time constraints,
for instance on memory usage or domain access, and opening multiple
instances of external programs may easily exceed those constraints.
External programs may present dialogs to perform harmful actions, e.g.
download dialogs, and multiple new windows in a short time span may
allow for interaction flooding attacks or may lead to warning fatigue.
This security measure ensures that users get a reasonable chance to
manage the run-time constraints, and ensures that only one external
program and/or dialog can be opened at a time.
See http://www.w3.org/TR/wsc-ui/#popups for more details.
]]
We would appreciate any feedback people have about the proposed text.
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Thu, 04 Feb 2010 17:22:16 +0100, Thomas Roessler t...@w3.org wrote: On 31 Jan 2010, at 14:23, Anne van Kesteren wrote: On Tue, 19 Jan 2010 08:01:12 +0100, Thomas Roessler t...@w3.org wrote: With apologies for the belated Last Call comment -- the XMLHttpRequest specification http://www.w3.org/TR/XMLHttpRequest/ ... doesn't have meaningful security considerations. I actually removed that section altogether in the editors draft. Strikes me as a step in the wrong direction. Well, as you said, it didn't amount to much anyway. - 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? - 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. - 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 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? So, without going into semantics of what define the policy means, I suggest calling out that this spec sets the security policy for XHR, what that policy is, how the different pieces that are relevant to it tie together, and what the risks are. To be honest, I'm not quite sure what I should write down with respect to this. I guess if someone has text that is accurate we could opt into using it. For security reasons, these steps should be terminated if header is an ASCII case-insensitive match for one of the following headers: ... Early on we agreed that all security-relevant conformance clauses should be SHOULD and not MUST so that implementors could ignore them in specific contexts. E.g. extensions. I would personally be fine with making these MUST. I'd be significantly more comfortable with a MUST, and wonder whether the extension considerations have changed over time. *If* we stick to SHOULD, some analysis of the combined effects of different choices would be in order. Changed to MUST. (Considering the discussion around cross-origin XHR over the past two or three years, I suspect that we've had a (partial) change of attitude around playing with different security models for the API. Hence, I'd like us to reconsider that particular decision.) I'm not sure what you're saying here. Is this a reference to the UM/CORS discussion? What do we need to reconsider in addition to what is already under discussion? -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] XMLHttpRequest specification lacks security considerations
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 ;-). ... 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. ... 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. ... Best regards, Julian
Re: [XHR] XMLHttpRequest specification lacks security considerations
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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] API - openURL security considerations
What about being about to link to file:// URLs? You probably want to
ban that. Also, have you considered what happens if you put a
JavaScript URL or a Data URL into openURL?
Adam
On Mon, Feb 8, 2010 at 8:36 AM, Marcos Caceres marc...@opera.com wrote:
At Opera we've been discussing some of the security implications around the
openURL method in the widgets API spec. We think the spec might benefit if
we were to add a non-normative security consideration section for openURL.
We are basically concerned about protecting against a simple attack such as:
while(true){
openURL(http://...;);
}
The following text, which I did not write, can serve as a basis for the note
- we are presenting it here for discussion, and you'll note it uses
different terminology than the one found in the spec. In other words, please
don't consider the following to be spec text, it needs a fair amount of
editing but tries to get to the heart of the problem:
[[
APIs to open external programs, such as opening a URL in a browser, SHOULD
only be allowed automatically if the widget has focus. Opening such an
external program, SHOULD result in the widget losing focus, for the purpose
of opening more external programs. User interaction with the widget may
restore the focus to the widget. Widget Managers MAY offer a dialog for
other attempts to open external programs, or MAY fail the operation. User
agents MAY also offer an override for users to allow a widget to open
external programs automatically, even when minimized in the background.
Security considerations: Widgets may have managed run-time constraints, for
instance on memory usage or domain access, and opening multiple instances of
external programs may easily exceed those constraints. External programs may
present dialogs to perform harmful actions, e.g. download dialogs, and
multiple new windows in a short time span may allow for interaction flooding
attacks or may lead to warning fatigue. This security measure ensures that
users get a reasonable chance to manage the run-time constraints, and
ensures that only one external program and/or dialog can be opened at a
time.
See http://www.w3.org/TR/wsc-ui/#popups for more details.
]]
We would appreciate any feedback people have about the proposed text.
