Re: [XHR] XMLHttpRequest specification lacks security considerations
Maciej Stachowiak wrote on 2/9/2010 4:13 AM: 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. Another threat is an attacker crafting a malicious payload in the Host header, hoping that it gets logged then viewed via a web browser. And some webapps conditionally show debugging information based on the host header, so that the production hostname has a generic error page and the staging hostname produces a full stack trace. Simply forging the host header allows an attacker to view the full debugging information. There are probably other threats too, such as a site using the Host header to craft links, etc. - Bil
Re: Notifications
On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I think the API for ambient notifications should be designed so that browsers can map all ambient notifications to Growl and NotifyOSD. As for notifications that require explicit acknowledgement, I think it would be worthwhile to collect use cases beyond calendar alarms first and not heading right away to generic HTML notifications. If it turns out that notifications that require explicit acknowledgements are virtually always calendar alarms or alarm clock notifications, it might make sense to design an API explicitly for those. For example, it could be desirable to allow a privileged calendar Web app to schedule such alarms to fire on a mobile device without having to keep a browsing context or a worker active at the notification time. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[widgets] LCWDs of XML Signature specs published
Last week the XML Security WG published LCWDs of two specs the Widget Digital Signature CR [Widget-DigSig] references: XML Signature Properties http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/ XML Signature Syntax and Processing Version 1.1 http://www.w3.org/TR/2010/WD-xmldsig-core1-20100204/ The comment deadline is March 18. Some additional details below. -Art Barstow [Widget-DigSig] http://www.w3.org/TR/2009/CR-widgets-digsig-20090625/ Last Call for Two XML Signature Drafts; Other Drafts Updated 04 February 2010 | Archive http://www.w3.org/News/2010#entry-8712 The XML Security Working Group published two Last Call Working Drafts: http://www.w3.org/2008/xmlsec/ * XML Signature Syntax and Processing 1.1, which specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content, including XML. * XML Signature Properties, which outlines proposed standard XML Signature Properties syntax and processing rules and an associated namespace for these properties. The intent is these can be composed with any version of XML Signature using the XML SignatureProperties element. The group welcomes Last Call comments through 18 March. The group also published several other drafts today: XML Security 1.1 Requirements and Design Considerations, XML Security RELAX NG Schemas, XML Security 2.0 Requirements and Design Considerations, XML Signature Transform Simplification: Requirements and Design, and XML Signature Best Practices. Learn more about XML Technology. http://www.w3.org/TR/2010/WD-xmlsec-reqs-20100204/ http://www.w3.org/TR/2010/WD-xmlsec-rngschema-20100204/ http://www.w3.org/TR/2010/WD-xmlsec-reqs2-20100204/ http://www.w3.org/TR/2010/NOTE-xmldsig-simplify-20100204/ http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100204 http://www.w3.org/standards/xml/
RE: [widgets] Draft Agenda for 11 February 2010 voice conf
Apologies in advance for this week and next. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 10 February 2010 13:30 To: public-webapps Subject: [widgets] Draft Agenda for 11 February 2010 voice conf Below is the draft agenda for the 11 February Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open and Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/04-wam-minutes.html Logistics below. -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. LC of XML Signatures spec published 4 Feb: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0531.html 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ CR Implementation Report: http://dev.w3.org/2006/waf/widgets/imp-report/ a. Important Test Suite Updates by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0485.html b. Action-486: Create ITS test case(s) for the PC test suite http://www.w3.org/2008/webapps/track/actions/486 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. API - openURL security considerations by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0501.html b. TWI: comments by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0479.html c. window object by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0476.html 5. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure to test the WARP spec http://www.w3.org/2008/webapps/track/actions/490 6. AOB a. Charter renewal - please send comments to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0493.html Comments from Scott Wilson: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0525.html Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Dear Mr. Barstow, As indicated in the mails about MPEG-U, I would like to request that the WG discusses the MPEG liaison regarding widgets. Could you add it to the agenda ? Best Regards, Cyril Concolato Le 10/02/2010 14:29, Arthur Barstow a écrit : Below is the draft agenda for the 11 February Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open and Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/04-wam-minutes.html Logistics below. -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. LC of XML Signatures spec published 4 Feb: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0531.html 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ CR Implementation Report: http://dev.w3.org/2006/waf/widgets/imp-report/ a. Important Test Suite Updates by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0485.html b. Action-486: Create ITS test case(s) for the PC test suite http://www.w3.org/2008/webapps/track/actions/486 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. API - openURL security considerations by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0501.html b. TWI: comments by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0479.html c. window object by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0476.html 5. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure to test the WARP spec http://www.w3.org/2008/webapps/track/actions/490 6. AOB a. Charter renewal - please send comments to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0493.html Comments from Scott Wilson: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0525.html Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public -- 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 HTTP method support, Re: XHR LC comments
Following up to an email from Feb 2009: Julian Reschke wrote: Following up to a mail from May 2008: Julian Reschke wrote: Sunava Dutta wrote: ... At this point, I'm not sure why we're bothering with XHR1 at all. It is *not* what the current implementations do anyway. [Sunava Dutta] I'm sorry, this statement is concerning and I'd like to understand it better. We haven’t had a chance to run the latest test suite yet but expect the test suite to be compliant with at least two existing implementations. Do you mean the XHR 1 draft is not interoperable with existing implementations? ... Absolutely. Everytime I check something that is of interest to me it turns out that there is no interop, and that only some or even none of the browsers works as specified. Examples: - Support for HTTP extension methods: IE violates the SHOULD level requirement to support extenstion methods. Opera silently (!!!) changes extension method names to POST. ... Just rechecked... IE8beta: no improvement -- only the methods in RFC2518 are are supported, the remaining methods (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-01.html), not to mention future methods, are unsupported. Opera 10: only a small improvement; unknown method names are now changed to GET (still silently!!!). Best regards, Julian I just checked Opera 10.5 beta (on Windows): unknown method names *still* are silently rewritten as GET. Oh my. Remind me: what's the purpose of the W3C working on an XHR spec if even well-documented bugs like this do not get fixed by implementers? Best regards, Julian
Re: XHR HTTP method support, Re: XHR LC comments
On Wed, 10 Feb 2010 16:49:18 +0100, Julian Reschke julian.resc...@gmx.de wrote: Remind me: what's the purpose of the W3C working on an XHR spec if even well-documented bugs like this do not get fixed by implementers? That it is clear this is in fact a bug and needs to be fixed. (I believe we fixed it actually, no idea when it will turn up in public builds.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Art, My regrets, but due to conflicts I will be unable to attend this VC, or next week's (assuming one is scheduled). S On 10 Feb 2010, at 13:29, Arthur Barstow wrote: Below is the draft agenda for the 11 February Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open and Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/04-wam-minutes.html Logistics below. -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. LC of XML Signatures spec published 4 Feb: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0531.html 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ CR Implementation Report: http://dev.w3.org/2006/waf/widgets/imp-report/ a. Important Test Suite Updates by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0485.html b. Action-486: Create ITS test case(s) for the PC test suite http://www.w3.org/2008/webapps/track/actions/486 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. API - openURL security considerations by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0501.html b. TWI: comments by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0479.html c. window object by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0476.html 5. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure to test the WARP spec http://www.w3.org/2008/webapps/track/actions/490 6. AOB a. Charter renewal - please send comments to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0493.html Comments from Scott Wilson: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0525.html Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public
Re: Notifications
On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I agree that this is a good distinction, but I think even considering ambient notifications there is a question of how much interaction should be supported. NotifyOSD, for example, does not allow the user to take any action in response to a notification. So a very simple use case: email web app wants to alert you have new mail outside the frame, and allow the user to click on that alert and be taken to the inbox page. This does not work on NotifyOSD, because they explicitly don't support that part of the D-bus notifications spec. However, Growl would support this. So this suggested approach reduces us to the least common denominator of these existing notification providers, which are far from ubiquitous (Growl is a separate install from the OS, and we haven't yet discussed what Windows users would see). Perhaps spec'ing HTML notifications is looking too far down one particular road, but I'm concerned about being completely restricted by the current set of frameworks, if that means we can't even rely on an onclick event. -John
Re: Notifications
We ran into this issue when mapping our own browser notifications to platform notification APIs. For ambient notifications, you can't rely on the user being able to click on the notification, because the notification might time out and disappear on its own before the user has had a chance to react, so there always has to be another way for the user to get the information and perform the action. So NotifyOSD not supporting actions is an issue of convenience, not functionality. So then, if the NotifyOSD designers think their users don't need that convenience, that's their call. A generic API can offer support for actions with the understanding that in some cases users won't be able to use them. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. I've had a few conversations about Growl and NotifyOSD, both on- and off-list, and I think it makes sense to discuss some of the underlying concerns. From these conversations, I've gotten the impression that some of the objections to HTML notifications are not entirely based in use cases (for example, it seems like the utility of being able to put markup such as bold text, or graphics, or links in a notification should be self-evident, even ignoring the various use cases around direct interaction with notifications). I haven't heard anyone claim that markup is bad - rather, the objections seem to boil down to a concern that somehow the mere existence of HTML notifications would undermine the adoption or use of Growl and NotifyOSD. I absolutely agree that Growl and NotifyOSD are important use cases to support, but I don't think they should be the tail that wags the dog (for example, I'm not sure that I agree with Henri that they should be treated as a more important use case than mobile phones, given the disparity in the size of the installed bases). And I also understand that for the users of these frameworks, having an application display notifications outside of the framework (possibly conflicting with those frameworks) would be a real problem. One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. I don't think it's in the best interest of developers or users to enforce a lowest-common-denominator approach to this API (especially since the currently dominant platform [Windows] doesn't have any native notification framework and would seem to derive great benefit from notifications with markup). Is the API change described above sufficient, or are there more things that we can do from an API standpoint to give UAs the flexibility to provide the desired user experience under Growl/NotifyOSD, without putting unnecessary restrictions on UAs running on other platforms? -atw So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I think the API for ambient notifications should be designed so that browsers can map all ambient notifications to Growl and NotifyOSD. As for notifications that require explicit acknowledgement, I think it would be worthwhile to collect use cases beyond calendar alarms first and not heading right away to generic HTML notifications. If it turns out that notifications that require explicit acknowledgements are virtually always calendar alarms or alarm clock notifications, it might make sense to design an API explicitly for those. For example, it could be desirable to allow a privileged calendar Web app to schedule such alarms to fire on a mobile device without having to keep a browsing context or a worker active at the notification time. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Notifications
On Thu, Feb 11, 2010 at 11:10 AM, Robert O'Callahan rob...@ocallahan.orgwrote: We ran into this issue when mapping our own browser notifications to platform notification APIs. For ambient notifications, you can't rely on the user being able to click on the notification, because the notification might time out and disappear on its own before the user has had a chance to react, so there always has to be another way for the user to get the information and perform the action. So NotifyOSD not supporting actions is an issue of convenience, not functionality. So then, if the NotifyOSD designers think their users don't need that convenience, that's their call. A generic API can offer support for actions with the understanding that in some cases users won't be able to use them. Er, ignore that entire message. Sorry! Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. You make the further point that application authors may intentionally *only* want to display HTML notifications, and would rather display nothing if HTML is not available (they pass in no message at all) - I'm not sure this is true, but if it is I'd say that's an argument in favor of supporting HTML in this API, not against it. I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Tue, Feb 9, 2010 at 2:50 PM, Maciej Stachowiak m...@apple.com wrote: 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 That link says this may not work reliably, or may not return the preferred hostname. *If* server implementers would be willing to have their servers refuse to work unless explicitly configured or the request host matches reverse DNS/OS hostname, then I agree as a web developer that that would be great. On Wed, Feb 10, 2010 at 4:37 AM, Bil Corry b...@corry.biz wrote: Another threat is an attacker crafting a malicious payload in the Host header, hoping that it gets logged then viewed via a web browser. That's just straight XSS. And some webapps conditionally show debugging information based on the host header, so that the production hostname has a generic error page and the staging hostname produces a full stack trace. Simply forging the host header allows an attacker to view the full debugging information. I'd be surprised if this were common enough to be worth worrying about.
Re: Notifications
On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. / Jonas
Re: Notifications
On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? If it supports, e.g., scripting, then you have to define what the relationship is between the browsing context for the notification and the browsing context for the opener. Can a notification document navigate itself using document.location = ...? At that point, this sounds like a specialized version of window.open. If that's your intent, maybe we should just add a flag to window.open? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 3:31 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? If it supports, e.g., scripting, then you have to define what the relationship is between the browsing context for the notification and the browsing context for the opener. Can a notification document navigate itself using document.location = ...? At that point, this sounds like a specialized version of window.open. If that's your intent, maybe we should just add a flag to window.open? I agree - the spec needs to define all of the implications of HTML support as well as any restrictions as to its use. On the bright side, from a security standpoint treating an HTML notification as its own browsing context ala window.open() is a well-understood model. As for using a specialized version of window.open() for notifications - that's an interesting suggestion. I think we'd still need to deal with the permission grant issue as well as having a good way to generate icon+header+body notifications from the HTML for compatibility with Growl/NotifyOSD/mobile platforms - I still think that having some way for the developer to explicitly specify a title/icon/body is superior to having the browser have to infer these pieces from a parsed DOM tree. But it's a good point that this starts to feel more like window.open(). Stepping back from the HTML issue, I note that one of the things in the NotifyOSD/DBUS API is the concept of a client-specified replace ID - the idea is that client applications can give their notifications a replace ID, and when that application displays a notification with that ID it replaces any currently displayed notification with that ID. I think that something like this would solve one of the core issues with the proposed notification API, which is avoiding duplicate notifications in the case where you have the same web page open in multiple windows. If we supported an optional replace ID parameter in createNotification(), then a page that wanted to have (say) a you have new mail notification could give that notification an ID of new_mail, so if any other page under the same origin tried to display a notification with a new_mail ID it would just replace the existing notification rather than displaying a duplicate notification. If we don't support this, apps have to jump through hoops using SharedWorkers or other methods to make sure they don't annoy the user with duplicate notifications. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [XHR] XMLHttpRequest specification lacks security considerations
Aryeh Gregor wrote on 2/10/2010 3:21 PM: On Wed, Feb 10, 2010 at 4:37 AM, Bil Corry b...@corry.biz wrote: Another threat is an attacker crafting a malicious payload in the Host header, hoping that it gets logged then viewed via a web browser. That's just straight XSS. I left it open-ended as I don't know what is being used to consume the log data (text editor, Java app, custom app, etc) and it could be someone is using regex or an xml tool to parse the log data. Given that, I envisioned the attack could extend beyond XSS to also include buffer overflows, recursive regex/xml poisoning, etc. The simple solution is to only accept the host headers you expect. And some webapps conditionally show debugging information based on the host header, so that the production hostname has a generic error page and the staging hostname produces a full stack trace. Simply forging the host header allows an attacker to view the full debugging information. I'd be surprised if this were common enough to be worth worrying about. I've seen it in both my work as a developer and my work as a pentester. It may not be common, but it does exist. On one site the net effect is the cookies expire in weeks instead of minutes, but on another site, the password reset token that is normally emailed to the user is instead displayed on the page (a debugging shortcut for QA). Not so good for a financial-sector website. - Bil
Re: Rechartering WebApp WG
On Wed, Feb 10, 2010 at 4:59 PM, Marcos Caceres marc...@opera.com wrote: I'm sooo totally for that. I want nothing more than to have more engagement and input from you guys. Our URI spec is in last call and so is the access request spec. The specs are really small. Please find a few hours and help us align if we haven't already. It's never too late to comment and help us fix stuff if it's borked. We are doing the best we can here, and certainly don't want to go against the web security model. It's funny that you say that, because last I commented on a widget spec was in relation to the signing spec. I then expressed dislike for the use of xml canonicalization and, IIRC, a few other non-trivial aspects of the spec. But was told that the spec was too far along and it was too late to change :-) That is correct. Many members working on widgets believed that the use cases were met by XML digsig (even with it's reliance on xml canonicalization) and I was led to believe that it is in fact implementable. I know of one implementation thus far, so the jury is still out. It's still too early for me to say if it was a mistake to take XML digsig over JAR signing. If it proves a mistake (I.e., no one implements), then it's logical to look for alternatives. I won't claim to understand the xml canonicalization issue, but people I talk to still tell me it won't be a problem. You want to add some tests to the test suite?:) I don't doubt that it's implementable. However I still think there are much simpler solutions that make things easier both for authors and browser implementors. See for example the way that mozilla signs XPI files. I don't disagree with you on the implementation side (and Im happy to hear that you think it can be implemented - I'll keep my fingers crossed). On the author side, I honestly don't know how much of a difference it will make. I'm sure someone will create a dead easy click once packager for widgets, if they haven't done so already. But is there something inherently wrong with our current technological choice that would not allow that? (if yes, please send to public-webapps, which is where we discuss widgets ;)) Ah, the old the tools will save us argument ;) Yes, tools can certainly help. But that doesn't remove from the fact that something that's simpler to author would be simpler for authors. What about situations when you want to dynamically generate widgets, say using PHP? Or if you don't speak the language(s) the tool is localized to. Or if a web-based tool happens to be down because of server upgrades? / Jonas
Re: Rechartering WebApp WG
On Feb 8, 2010, at 4:25 AM, 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 Some comments: - I would like to suggest the name Web Messaging for the postMessage / MessageChannel deliverable. - I think the Other Specifications section should be clear on the right process for adopting new deliverables without having to recharter. I think we want a process that is flexible but that retains transparency and accountability. I like the idea of writing requirements documents for these. Perhaps there should be some sort of review process for these requirements documents, in lieu of a full recharter cycle. - I think errata for the existing DOM specs should be stated as in- scope. I believe we are the right group to do this, but it's better to be explicit. I think this would include even DOM specs where we may not plan to publish a whole new version. - I think it's no longer necessary to cite the previous Web API and WAF charters. If we do cite a previous charter it should be the previous version of the Web Apps WG charter, It hink. Regards, Maciej
Re: Notifications
On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. I hear you. I'm not convinced that the web would be a better place without support for Javascript or Images though, despite the burden it might put on UA developers looking for wide compatibility. The nice thing about notifications is they are *clearly* an optional addition to the core functionality of a site (since the user has to grant permission to allow them to be displayed - they don't work by default anyway) so from an end user standpoint they can merely deny notification permission to web apps that do not display useful notifications. Your original objection about the existence of createHTMLNotification() was spot-on - UAs that do not provide this API would indeed break the web because application javascript code would throw undefined method exceptions in the middle of related operations. With a coalesced API that exists regardless of platform, it seems like this argument has less force. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. I'm assuming you aren't suggesting that this would happen because HTML notifications are so much better than non-HTML that developers just want to use HTML notifications :) I think our goal for optional support for HTML should not be that this would somehow enable desktop browsers to omit support for HTML notifications (keep in mind that NotifyOSD and Growl are far from ubiquitous on their relative platforms - browsers on Linux and the Mac will still need to be able to display notifications in the absence of these frameworks). Rather, providing a text + icon fallback for the HTML parameter enables this API to work on platforms that *cannot* support HTML notifications (a good example of a platform like this would be the Palm Pre, which has a dedicated text notification bar), similar to alt-text for img tags. A related goal is to support things like NotifyOSD and Growl gracefully, but IMO the expectation should not be that desktop browsers can/should just omit HTML notification support entirely. So I think the right question to ask isn't does this force all browsers to support HTML notifications? because I think that all browsers on platforms that can support them will need to do so anyway, but rather does the presence of widespread HTML notification support make it more likely that developers will neglect text+icon notifications, to the detriment of users that want them. Anyhow, my other concern with baking in lowest-common-denominator functionality into our APIs is that platform capabilities evolve over time. To make up a hypothetical example, it would not be unthinkable for another notification framework to supplant Growl over the next 5 years (for instance, if Apple added support for WebKit-based HTML notifications to the OS), or for Growl to add support for markup in its notifications, and yet UAs would be powerless to take advantage of these new capabilities if the APIs themselves lock in the lowest-common-denominator functionality. If we can future-proof the API, we should. / Jonas
Re: Rechartering WebApp WG
On Feb 11, 2010, at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 4:59 PM, Marcos Caceres marc...@opera.com wrote: I'm sooo totally for that. I want nothing more than to have more engagement and input from you guys. Our URI spec is in last call and so is the access request spec. The specs are really small. Please find a few hours and help us align if we haven't already. It's never too late to comment and help us fix stuff if it's borked. We are doing the best we can here, and certainly don't want to go against the web security model. It's funny that you say that, because last I commented on a widget spec was in relation to the signing spec. I then expressed dislike for the use of xml canonicalization and, IIRC, a few other non-trivial aspects of the spec. But was told that the spec was too far along and it was too late to change :-) That is correct. Many members working on widgets believed that the use cases were met by XML digsig (even with it's reliance on xml canonicalization) and I was led to believe that it is in fact implementable. I know of one implementation thus far, so the jury is still out. It's still too early for me to say if it was a mistake to take XML digsig over JAR signing. If it proves a mistake (I.e., no one implements), then it's logical to look for alternatives. I won't claim to understand the xml canonicalization issue, but people I talk to still tell me it won't be a problem. You want to add some tests to the test suite?:) I don't doubt that it's implementable. However I still think there are much simpler solutions that make things easier both for authors and browser implementors. See for example the way that mozilla signs XPI files. I don't disagree with you on the implementation side (and Im happy to hear that you think it can be implemented - I'll keep my fingers crossed). On the author side, I honestly don't know how much of a difference it will make. I'm sure someone will create a dead easy click once packager for widgets, if they haven't done so already. But is there something inherently wrong with our current technological choice that would not allow that? (if yes, please send to public-webapps, which is where we discuss widgets ;)) Ah, the old the tools will save us argument ;) Ooooh, snap!! walked straight into that one :D Yes, tools can certainly help. But that doesn't remove from the fact that something that's simpler to author would be simpler for authors. It's crypto: by definition, its really complicated; I don't know how much easier one could make it. And reading https://developer.mozilla.org/en/Signing_a_XPI I can see Mozilla's solution is far from easy to use. I was expecting point and click, but I see a lot of scary (for me) command line stuff. One even need a special zip tool because of the whole META/ inf thing? What about situations when you want to dynamically generate widgets, say using PHP? What about it? Won't a simple command line tool work? You could have a GUI version and a command line version. Like Zip. Or if you don't speak the language(s) the tool is localized to. I don't understand this one? I guess as above. Or if a web-based tool happens to be down because of server upgrades? I'm sorry, but i'm not really following as to what this has to do with our choice to use XML DigSig as the sig format? Despite my silly tools will save us mishap, my original question is still: is XML digsig limited in some way that all the above command/GUI/web interfaces could not be built on it (if they haven't already)? And what are the advantages of XPI signing over the current model? Is it the availability of tools to make sigs what makes it better or is it that the sig format simpler? I can't see it being too much simpler from an authors perspective. And once you implement it and get it running, won't the XML cononicalization problems go away?
Re: Notifications
On Wed, Feb 10, 2010 at 5:21 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. I hear you. I'm not convinced that the web would be a better place without support for Javascript or Images though, despite the burden it might put on UA developers looking for wide compatibility. Javascript and images has added *a lot* of value to the web platform though. I'm not convinced that HTML notifications add the similar amount of value over a simpler notification format. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. I'm assuming you aren't suggesting that this would happen because HTML notifications are so much better than non-HTML that developers just want to use HTML notifications :) It's enough that one or two high profile sites use it for every browser to need to implement it. I think our goal for optional support for HTML should not be that this would somehow enable desktop browsers to omit support for HTML notifications (keep in mind that NotifyOSD and Growl are far from ubiquitous on their relative platforms - browsers on Linux and the Mac will still need to be able to display notifications in the absence of these frameworks). Rather, providing a text + icon fallback for the HTML parameter enables this API to work on platforms that *cannot* support HTML notifications (a good example of a platform like this would be the Palm Pre, which has a dedicated text notification bar), similar to alt-text for img tags. However these types of fallback generally are used very rarely. I think Hixie might have run some actual numbers, but I would be surprised if even 1% of all images that need fallback content has a useful alt attribute. A related goal is to support things like NotifyOSD and Growl gracefully, but IMO the expectation should not be that desktop browsers can/should just omit HTML notification support entirely. So I think the right question to ask isn't does this force all browsers to support HTML notifications? because I think that all browsers on platforms that can support them will need to do so anyway, but rather does the presence of widespread HTML notification support make it more likely that developers will neglect text+icon notifications, to the detriment of users that want them. And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? / Jonas
Re: Rechartering WebApp WG
On Wed, Feb 10, 2010 at 5:42 PM, Marcos Caceres marc...@opera.com wrote: On Feb 11, 2010, at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 4:59 PM, Marcos Caceres marc...@opera.com wrote: I'm sooo totally for that. I want nothing more than to have more engagement and input from you guys. Our URI spec is in last call and so is the access request spec. The specs are really small. Please find a few hours and help us align if we haven't already. It's never too late to comment and help us fix stuff if it's borked. We are doing the best we can here, and certainly don't want to go against the web security model. It's funny that you say that, because last I commented on a widget spec was in relation to the signing spec. I then expressed dislike for the use of xml canonicalization and, IIRC, a few other non-trivial aspects of the spec. But was told that the spec was too far along and it was too late to change :-) That is correct. Many members working on widgets believed that the use cases were met by XML digsig (even with it's reliance on xml canonicalization) and I was led to believe that it is in fact implementable. I know of one implementation thus far, so the jury is still out. It's still too early for me to say if it was a mistake to take XML digsig over JAR signing. If it proves a mistake (I.e., no one implements), then it's logical to look for alternatives. I won't claim to understand the xml canonicalization issue, but people I talk to still tell me it won't be a problem. You want to add some tests to the test suite?:) I don't doubt that it's implementable. However I still think there are much simpler solutions that make things easier both for authors and browser implementors. See for example the way that mozilla signs XPI files. I don't disagree with you on the implementation side (and Im happy to hear that you think it can be implemented - I'll keep my fingers crossed). On the author side, I honestly don't know how much of a difference it will make. I'm sure someone will create a dead easy click once packager for widgets, if they haven't done so already. But is there something inherently wrong with our current technological choice that would not allow that? (if yes, please send to public-webapps, which is where we discuss widgets ;)) Ah, the old the tools will save us argument ;) Ooooh, snap!! walked straight into that one :D Yes, tools can certainly help. But that doesn't remove from the fact that something that's simpler to author would be simpler for authors. It's crypto: by definition, its really complicated; I don't know how much easier one could make it. And reading https://developer.mozilla.org/en/Signing_a_XPI I can see Mozilla's solution is far from easy to use. I was expecting point and click, but I see a lot of scary (for me) command line stuff. One even need a special zip tool because of the whole META/inf thing? What about situations when you want to dynamically generate widgets, say using PHP? What about it? Won't a simple command line tool work? You could have a GUI version and a command line version. Like Zip. Or if you don't speak the language(s) the tool is localized to. I don't understand this one? I guess as above. Or if a web-based tool happens to be down because of server upgrades? I'm sorry, but i'm not really following as to what this has to do with our choice to use XML DigSig as the sig format? Despite my silly tools will save us mishap, my original question is still: is XML digsig limited in some way that all the above command/GUI/web interfaces could not be built on it (if they haven't already)? And what are the advantages of XPI signing over the current model? Is it the availability of tools to make sigs what makes it better or is it that the sig format simpler? I can't see it being too much simpler from an authors perspective. I am admittedly far from an expert in how our XPI signing works. I'm told it's essentially like Suns signed JAR files, but we use a different crypto algorithm. My argument isn't that one is more or less feature full, it's all about solving enough of the relevant use cases as simply as possible. And it's definitely true that signing is always going to be hard. And once you implement it and get it running, won't the XML cononicalization problems go away? Code problems never go away. There's always some level of maintenance that needs to happen, fix security bugs, fix behavior bugs, fix spec bugs. And then there is of course the extra compile time for developers and download time for users. / Jonas
Re: Notifications
On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. The history of the web has generally been that good features spread to become ubiquitous, and if your concern is that HTML notifications will become one of those features, then I echo your concern :) I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I think we all have differing opinions over the importance of these varying goals - ideally we'd find an API that can satisfy all three, but I do agree that adding optional HTML support has a potentially negative impact on goal #1. However, that doesn't mean that we should pursue an API that *only* satisfies goal #1. I don't want to get completely focused on a single possible solution to this dilemma (i.e. supporting an optional HTML parameter), although I have to admit I personally think the idea of a fully-scriptable active notification is really compelling. Are there other solutions that would better meet those 3 goals? Maybe I'm off-base and goal #1 is the only one that matters in this case? -atw
Re: Rechartering WebApp WG
Hi, Maciej- Thanks for the feedback. Maciej Stachowiak wrote (on 2/10/10 8:10 PM): Some comments: - I would like to suggest the name Web Messaging for the postMessage / MessageChannel deliverable. Done. - I think the Other Specifications section should be clear on the right process for adopting new deliverables without having to recharter. I think we want a process that is flexible but that retains transparency and accountability. I like the idea of writing requirements documents for these. Perhaps there should be some sort of review process for these requirements documents, in lieu of a full recharter cycle. Sure, let's discuss this as a group to see what we are all comfortable with, and I will tighten up the language accordingly. Right now, I don't know exactly what else to say. - I think errata for the existing DOM specs should be stated as in-scope. I believe we are the right group to do this, but it's better to be explicit. I think this would include even DOM specs where we may not plan to publish a whole new version. Clarified. - I think it's no longer necessary to cite the previous Web API and WAF charters. If we do cite a previous charter it should be the previous version of the Web Apps WG charter, It hink. Corrected. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Rechartering WebApp WG
Hi, Folks- Scott Wilson wrote (on 2/9/10 10:32 AM): 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) Are these deliverables the Widgets folks are willing to take on? If so, are there clear use case requirements documents, and available editing resources? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Inconsistency in Web SQL Database Spec
On Wed, 10 Feb 2010 00:39:45 +0100, Eric Westenberger eric.westenber...@googlemail.com wrote: sorry, I am not able to follow this explanation.To which binding are you refering? See the bits about Web IDL. Specifically the getter keyword specified on the SQLResultSetRowList interface. 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. I guess there's a bug in WebKit then. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. Have you ever tried to browse the web with javascript or images turned off? It's not an experience most users would say is useful. I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I disagree with 2 and 3 being goals. Taking advantage of platform capabilities isn't a goal in and of itself, it's just a mean. Providing a better user experience is the goal IMHO. If users that want to use Growl can't get their browser notifications through growl because the browser was forced to use some other mechanism to implement HTML notifications, then we haven't improved that users experience. Even worse, if they don't get *any* notifications because the website didn't provide a non-html equivalent, then we certainly haven't helped that user. / Jonas
Re: Rechartering WebApp WG
On Thu, 11 Feb 2010 05:40:04 +0100, Doug Schepers schep...@w3.org wrote: Hi, Folks- Scott Wilson wrote (on 2/9/10 10:32 AM): 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) I find this item to be interesting and worth taking on, but I think we ought to also evaluate it in a wider context than widgets. Are these deliverables the Widgets folks are willing to take on? If so, are there clear use case requirements documents, and available editing resources? Scott - you've already implemented and deployed functionality like this in Wookie, right? -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Rechartering WebApp WG
On 11 Feb 2010, at 08:37, Arve Bersvendsen wrote: - inter-widget communication (both single-user and multi-user, e.g. collaboration) I find this item to be interesting and worth taking on, but I think we ought to also evaluate it in a wider context than widgets. +1 If this particular use case can be solved with postMessage, that would sound like a huge win.
