Re: XBL2
Ian, It's good news that you have re-opened the XBL2 effort. We still don't have a reasonable component model for HTML, and XBL1 has proven its value for 10 + years in the Mozilla world. My first question is how to deal with the chicken-and-egg problem where developers won't touch it until 95% of deployed browser support this feature, and browser teams won't touch it until developers show strong interest. Is the idea that if the features goes into the HTML5 spec and one or two browsers implement it right away, then maybe the other browsers will follow? One other option for dealing with the chicken-and-egg problem is to make sure that the XBL2 spec is implementable in JavaScript. If a good JavaScript library existed and the browser teams agreed that native support for XBL2 will be offered as a native feature for HTML5 in the future, then developers could use XBL2 right away in current browsers and then find improved performance in future browsers. Jon PS - I still have a nervous tick from our efforts on sXBL From: Ian Hickson i...@hixie.ch To: public-webapps@w3.org Cc: hy...@apple.com Date: 09/02/2010 06:24 PM Subject:XBL2 Sent by:public-webapps-requ...@w3.org Since XBL2 wasn't getting much traction, I've taken an axe to the spec and made a number of changes to the spec based on some discussions with some browser vendors: http://dev.w3.org/2006/xbl2/Overview.html The main changes are simplification: I've dropped namespace support, made it part of HTML rather than its own language, dropped style and script in favour of HTML equivalents, dropped all the handler syntactic sugar (and redirected event forwarding to internal object instead), dropped preload, dropped mentions of XForms and XML Events, and so on. I've updated all the examples to use the new syntax, so if you're curious about the differences, comparing the examples in the spec above to those in the TR version is probably a good way to get an idea of what I did. If this ends up being more successful than the previous work on this specification, I'll have to merge it with the HTML spec to more properly define how it works. Right now it leaves a lot of the detail a bit vague (e.g. integration with the event loop, the parser, authoring conformance definitions, etc). If this happens, I don't yet know how much this will lend itself to being extracted back out into a separate module (for publication by this working group), versus being just published as a core part of the HTML spec, but I will be happy to update the group on this matter as it becomes clearer. I don't think the draft above would be suitable for publication as a TR/ draft, because of the aforementioned rough edges. I mostly just wanted to provide this for discussion, to see whether people considered this a move in a good direction or a significant step backwards. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' inline: graycol.gifinline: ecblank.gif
Re: [cors] unaddressed security concerns
Hi Jonathan, I was one of the people who complained a long time ago about the dangers of sending cookies with cross-site requests, but the WG responded to my concerns and now I'm satisfied with the spec as it stands today. CORS requires servers to explicitly add a new HTTP header (Access-Control-Allow-Credentials:true) to the response before credentials (cookies) to be sent from browser to a (cross-site) server. If this header is not included, then CORS-conformant browsers will not send cookies. This approach helps to minimize the chance that unsophisticated server developers (who are uninformed about CSRF protection) might introduce new vulnerabilities as they open up their sites to cross-site requests because the default is that credentials are not sent. While the Access-Control-Allow-Credential header helps to minimize CSRF vulnerabilities in the face of CORS, it doesn't represent a complete solution to CSRF problems. Servers that enable cross-site requests with credentials around sensitive information should include appropriate CSRF bulletproofing, such as using random session-specific tokens (not stored in cookies) to ensure that cross-site requests are coming from properly authenticated users who are involved in properly managed sessions. While it is impossible to be certain about the security implications of CORS, which represents a major enhancement to the Web communications, it looks to me that the potential CSRF problems have been addressed in an adequate manner, at least to the same level as existing same-site XHR requests. Servers have to opt-in for credentials to be sent. Once they opt-in, then the same CSRF bulletproofing techniques that are required for same-site XHR requests could be used to safeguard cross-site XHR requests. Jon | | From: | | -| |Jonathan Rees j...@creativecommons.org | -| | | To:| | -| |Doug Schepers schep...@w3.org | -| | | Cc:| | -| |Maciej Stachowiak m...@apple.com, Mark S. Miller erig...@google.com, Adam Barth w...@adambarth.com, Anne van Kesteren | |ann...@opera.com, Henry S. Thompson h...@inf.ed.ac.uk, Jonas Sicking jo...@sicking.cc, Arthur Barstow art.bars...@nokia.com, | |public-webapps public-webapps@w3.org | -| | | Date: | | -| |10/23/2009 02:06 PM | -| | | Subject: | | -| |Re: [cors] unaddressed security concerns | -| | | Sent by: | | -| |public-webapps-requ...@w3.org | -| Comments below On Thu, Oct 22, 2009 at 6:12 PM, Doug Schepers schep...@w3.org wrote: Let's take it a step further, and
Re: [Widgets] Widget Gallery RSS like sharing format
(A little slow on my response) Hi Robin, I was pointing to the *response* part of OpenSearch. The URL below shows the RSS and Atom formats that they use to reflect the list of things found from the search query. Over in OpenAjax Alliance, we are working with various players in the industry to establish widget repositories. We have been using OpenSearch for both the search query and the response. If you go to: http://www.openajax.org/2008_InteropFest/mashupapp/gadgets/samples/newmashup.php and click at the top left on the hour glass icon, a list of widgets will appear. That list of widgets is built from an OpenSearch response. We find it works quite well. Jon Robin Berjon ro...@berjon.com To Jon Ferraiolo/Menlo Park/i...@ibmus 03/11/2009 10:16 cc AMSUZANNE Benoit RD-SIRP-ISS benoit.suza...@orange-ftgroup.com , public-webapps@w3.org, public-webapps-requ...@w3.org Subject Re: [Widgets] Widget Gallery RSS like sharing format On Mar 11, 2009, at 16:44 , Jon Ferraiolo wrote: How about adopting OpenSearch response? http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_response_elements In fact, how about simply adopting OpenSearch in its entirety? Well my understanding of the use case is that it's about sharing the content of a widget gallery, which isn't really a search, but if the idea is to support discoverable repositories or that sort of stuff, it might be something worth looking at. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/ inline: graycol.gifinline: pic14041.gifinline: ecblank.gif
Re: ACTION-315: Widget URI scheme thoughts
My opinion is that having a widget URI scheme is not worth all of this complexity. I propose that the W3C ship Widgets 1.0 as quickly as possible with less flexibility on URI addressing. I think it is acceptable for a 1.0 release if all assets in the ZIP can only be addressed by relative addressing without allowing / at the front of the relative URL. In my experience a few years ago at Adobe which used ZIP packaging for its Digital Editions products (based on IDPF standards) and its Mars technology (PDF in XML/ZIP), people were able to deal with the restriction that relative addressed could not start with /. I definitely know that OpenAjax Widgets get by without a widget URI scheme, and I'll 99% sure that Google/OpenSocial Gadgets doesn't have such a mechanism. Jon Thomas Roessler t...@w3.org Sent by: To public-webapps-re Thomas Roessler t...@w3.org qu...@w3.org cc public-webapps@w3.org WG public-webapps@w3.org, 02/26/2009 04:54 public-pkg-uri-sch...@w3.org AMSubject Re: ACTION-315: Widget URI scheme thoughts As a follow-up from trashing this through with Josh, the one open issue is navigation of iframes: Assume a widget frames a resource that is retrieved from the Web. Would navigation of that iframe have to go through the manifest based indirection or not? The sense in our conversation was that it should *not* go through that indirection, but that that would probably have the potential to cause some surprises. The basic behavior would be that the manifest is only used for resolution of URI references that have the widget instance's unique origin; anything else would bypass the manifest mechanism. The other point would be HTTP POST (from forms): The manifest mechanism is right now scoped to the *retrieval* of resources. Form posts, XMLHttpRequest and other mechanisms are out of scope, therefore, standard HTML behavior (e.g., going out on the network) would apply. The synthetic origin approach seems to lead to the intended results in terms of security policy as far as the discussion between Josh and myself was concerned; I understand that Josh has some ideas about writing POST-like handlers in JavaScript, but that would be another extension. -- Thomas Roessler, W3C t...@w3.org: On 26 Feb 2009, at 13:23, Thomas Roessler wrote: Getting back to the URI scheme discussion, here's a strawman proposal that's inspired by the Widget case, where scripting and navigation add a few more complexities. I'll be interested in seeing Marcos, Arve and Josh shoot this one down. :) Specifically, we need to say: - how to dereference a URI reference that occurs within a widget resource, and for which the identified resource is included within the widget package - what the base URI property is for any DOM created from a resource within a widget package - what the origin is for any DOM created by the Widget. (e.g., for cross-frame scripting) The critically important point here is that we separate the Origin consideration from the identification and retrieval of resources in the package. Design assumptions: - we can synthesize origins to be globally unique identifiers (as HTML5 does) - we have unique identifiers resources within the package. Typically, these will look filesystem path like, but for the purposes of this proposal, they're opaque identifiers, and totally depend on the package format. Proposal: 1. The manifest is turned into a generic indirection tool that can aim inside the widget. For each resource (identified by absolute URI), the following properties are defined: - Content-Type - Parameters for said Content-Type - identifier for the packaged file that includes a representation of this resource E.g.: Resource Identifier=http://www.w3.org/;
Re: [widgets] OAuth and openID
Hi Marcos, I'll take a crack at this. OpenID is a technology that authenticates your identity. The cool thing about OpenID is that multiple web sites can share the same identity system, which makes it so that there can be a single mar...@myopenidwhatever.com instead of dozens of separate IDs for you (mar...@google.com, mar...@yahoo.com, etc.). A competitor to OpenID is a login/password screen served by a single web site. With W3C Widgets, you might use OpenID if you have to establish an identity before a widget can be installed; for example, you might have to login to the Apple AppStore (or some other store) before you downloaded a widget from there, and maybe the store supports OpenID. After installation, while a widget runs, the widget (or its server) might periodically need to ask you to enter a login/password to confirm who you are. The login/password software might use OpenID. This might be where Dan sees a problem - OpenID requires browser redirects to do its magic. You might need a list of allowed domains (i.e., at least 2) to support OpenID for this sort of repeated server login. OAuth is a technology that authorizes someone to do something. For example, an OAuth server might authorize you to cast a vote in an election. Regarding authorization, in the most common case of W3C Widgets, you would most likely use something like an OMTP/BONDI policy file or some sort of platform-specific (maybe implicit) policy to control authorization instead of OAuth. My thinking is that you can ignore OAuth for now. If I were on the committee, I would push to finish Widgets 1.0 as quickly as possible, and then put OpenID and OAuth on the list for things to consider for Widgets 1.1. Jon Marcos Caceres marc...@opera.co m To Sent by: public-webapps@w3.org public-webapps-re public-webapps@w3.org qu...@w3.org cc Dan Brickley dan...@danbri.org Subject 02/22/2009 07:11 [widgets] OAuth and openID AM Please respond to marc...@opera.com Hi, I recently spoke to Dan Brickley who raised concerns wrt to using OAuth authentication flows and support open ID. I've only had very limited exposure to these technologies, so I am not the best to comment about how they would work with widgets, but I'm starting this thread so we can discuss ideas. Dan, it would be great if you could outline the problem as you see it? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au inline: graycol.gifinline: pic14024.gifinline: ecblank.gif
Re: Required support for SVG in widgets
The Web Apps WG should create yet another (short) widget spec, which would be an Open Web profile spec that simply provides a checklist for two interoperability levels for conformance. In both profiles, the user agent would be required to implement all of the various Widgets spec. One interoperability profile would require support for the vague notion of HTML (defacto standard HTML, not XHTML) and the other profile would require support for SVG Tiny 1.2. Both profiles should mandate OMTP BONDI. To me, such a spec would help promote open, interoperability technologies in the widget space. This spec could be on a delayed timeline (i.e. approved after the other widget specs), particularly to allow BONDI to reach completion, but just having drafts out there would show the community what the interoperability target is. Jon Robin Berjon ro...@berjon.com To Sent by: Marcos Caceres public-webapps-re marcosscace...@gmail.com qu...@w3.org cc public-webapps@w3.org Subject 02/04/2009 03:29 Re: Required support for SVG in AMwidgets On Feb 4, 2009, at 02:20 , Marcos Caceres wrote: On Tue, Feb 3, 2009 at 11:22 PM, Jonas Sicking jo...@sicking.cc wrote: Is there a reason to require any formats? In very few places we do this. For example the HTML and CSS specs don't require support for JPEG, GIF or PNG. Neither HTML or SVG require support for javascript. Is there a reason for the widget spec to be different? I guess it's not really about mandating that the widget user agent support SVG, just that it look for SVG as a default start file. My request actually covered both. But apparently you've now removed the requirement to support HTML, so maybe I can withdraw that part of my objection. I would prefer if HTML and SVG were both required because it makes widgets more useful when you know what you can rely on, but I can live with nothing specific being required. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/ inline: graycol.gifinline: pic04476.gifinline: ecblank.gif
Re: ISSUE-80: Runtime localization model for widgets [Widgets]
I am all in favor of *not* having to replicate many files in the widget distribution just so you can create localized versions of a single image. One more thing I'll add. One of the URL techniques in the Widgets spec, using / as the first character in a relative address, works OK in widget workflows where the content is always wrapped in a ZIP, but in various Web Widget workflows, the widget contents are often exploded into a file system where the root of the widget is not the root of the file system or the root of the Web site. In those scenarios, you can't use / as the first character in a relative address, which means the entire set of files would have to be duplicated for each locale. Hardly ideal. Jon Web Applications Working Group Issue Tracker To sysbot public-webapps@w3.org +trac...@w3.org cc Sent by: public-webapps-re Subject qu...@w3.org ISSUE-80: Runtime localization model for widgets [Widgets] 02/02/2009 03:51 PM Please respond to Web Applications Working Group WG public-weba...@w 3.org ISSUE-80: Runtime localization model for widgets [Widgets] http://www.w3.org/2008/webapps/track/issues/80 Raised by: Josh Soref On product: Widgets Below is a discussion I had with Josh about the localization model for widgets. Josh identifies an issue that may affect localization at runtime that may be overcome by having the widget engines dynamically change folders when it can't find resources. timeless.b...@gmail.com: how do localized folders work anyway? Sent at 12:01 AM on Sunday timeless.b...@gmail.com: oh, it's hidden in base folder me: you put folders that follow the lang-place pattern into a folder called locale. The UA looks for a folder that matches the user's locale prefs timeless.b...@gmail.com: i'm not quite sure i understand or like that imagine i have 100 images and only want to localize 2 if base-folder means that i have to copy the whole set, i'm unhappy me: no, just make all your refs absolute. it's no problem timeless.b...@gmail.com: no, definitely bad that means i have to know in advance if i need to localize a path instead of just having 1 locale that needs to localize a file me: yes. But it supports multiple models of localization. So the model is quite flexible. timeless.b...@gmail.com: supporting a virtual mapping would have been better :( me: we can always change it if you have a better proposal timeless.b...@gmail.com: i guess the simplest question is would you ever have a localized file foo.bar and want access to the original unlocalized file timeless.b...@gmail.com: i claim no me: no, you wouldn't the idea is that you only localize what you want. timeless.b...@gmail.com: yeah so, in my model, instead of 'base folder' a localized file i18n/en-GB/index.html appears as /index.html if the UA selects en-GB me: I'm sure we are thinking of the same thing here, but now I'm worried I've done this wrong. timeless.b...@gmail.com: (so searches go first to i18n/en-GB/ and then to /) if index.html has img src=flag.png me: flag.png gets resolved to i18n/en-GB/flag.png timeless.b...@gmail.com: then whether it's /index.html, or /i18n/fr-FR/index.html if the UA locale is fr-FR, it first looks in /i18n/fr-FR/flag.png and then /flag.png yeah, but that's not what i want it's a disaster me: no, it only goes to one location timeless.b...@gmail.com: yeah, that sucks. you end up w/ millions of included files in dozens of locales because only one needed an override or you have to fork each html file just to make something happy me: hmmm I'm not convinced... I thought I had sorted this out I need to do some tests timeless.b...@gmail.com: we have a VFS, and our UA has a cache, which
Re: Required support for SVG in widgets
Hi Marcos, *IF* the WG decides to somehow promote SVG into a required format for some features in the widgets spec, then either the spec or implementations have to figure out how to deal with time-based behaviors (e.g., animations) and interactive behaviors (e.g., hyperlinks, onload, onclick, other JavaScript) for the scenarios where SVG is used. One thing to remember about SVG is that there is well-defined rendering behavior when time-based behaviors and interactive behaviors are turned off, which is to render the SVG content as if the animation elements and all interactive features were removed from the file. This is what we sometimes call static SVG. It is pretty much the same as a PNG, except the graphics are defined via vector graphic commands instead of colored bits. Jon Marcos Caceres marcosscace...@g mail.com To Sent by: Robin Berjon ro...@berjon.com public-webapps-re cc qu...@w3.org public-webapps@w3.org Subject Re: Required support for SVG in 02/03/2009 11:54 widgets AM Hi Robin, On Tue, Feb 3, 2009 at 5:54 PM, Robin Berjon ro...@berjon.com wrote: Hi, I'm sorry if this was discussed earlier, but I have no recollection of it being brought up and I can't seem to dig up a reference to this issue from the archives of the public lists of this WG or its previous incarnations. Then again, I have a pretty poor memory and am not so good with computers. Is there any specific reason not to require SVG support in widgets? The draft has everything defined in terms of how it would work, but has it optional both for icons and for the start page. Given the implementations that we're likely to see, I doubt that there would be any problem getting out of CR with SVG being required, even on mobile devices. Making it required has all the usual advantages of reassuring authors that they can indeed use it. If there is no overarching concern with requiring SVG (or if there was when the spec was started, but it's now gone) I would kindly urge the working group to require SVG and add an index.svg default start file. Ok, I've added SVG as a default start file type to the editor's draft (I'll commit it to CVS later today). However, as this is a significant addition, the Working Group will have to reach a resolution on this (or raise objections here, ASAP). If WebApps agrees (which I'm confident sure they will), could we ask in return that someone from the SVG WG do a review of the Widget PC spec to make sure that all the right bits are in place to make SVG work. We are currently in the middle of responding to LC comments, so we would ask that the SVG review is done in the Second Last Call period (one month from now). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au, inline: graycol.gifinline: pic21269.gifinline: ecblank.gif
Re: [widgets] Version string
We came up with an approach at OpenAjax Alliance for version strings where the string must begin with N.N (or N.N.N or N.N.N.N) but can contain arbitrary alpha text after the number value. Then we defined how to do numeric comparisons between the leading numeric parts of two different version strings. * http://www.openajax.org/member/wiki/OpenAjax_Hub_1.0_Specification_Libraries Jon Thomas Roessler [EMAIL PROTECTED] Sent by: To public-webapps-re Marcos Caceres [EMAIL PROTECTED] [EMAIL PROTECTED] cc public-webapps 10/27/2008 11:13 public-webapps@w3.org AMSubject Re: [widgets] Version string You'll want to define what it means for one version string to be greater than another one. -- Thomas Roessler, W3C [EMAIL PROTECTED] On 27 Oct 2008, at 17:27, Marcos Caceres wrote: Hi All, I would like to relax a valid version string to be any string. The reason I want to do this is to make it easier to parse a version string without requiring any special processing (any string will do). We will still recommend the MIDlet Suite Versioning where Version numbers have the format Major.Minor[.Micro] (X.X[.X]). This affects the widget element's version attribute and parts of the Updates spec in a minor way. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au inline: graycol.gifinline: pic20792.gifinline: ecblank.gif
Re: Opting in to cookies - proposal
Maciej Stachowiak wrote: On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote: ...snip... I mean, I guess it's possible people will do this, but people could add Access-Control-Allow-Credentials site-wide too. And if we add Access-Control-Allow-Credentials-I-Really-Mean-It, they'll add even more. Yes, this is certainly a possibility. But my hope is that this will happen to a smaller extent. I share the hope smaller extent hope with Jonas, and his latest proposals look good to me. My assumption is that 99% of all cross-site XHR usage will not require credentials/cookies. Therefore, what makes sense is a simple way that server developers can opt-in to credential-free cross-site XHR which tells the browser to allow cross-site credential-free XHR to their site. Then, in an advanced section of the AC spec, talk about how some workflows might want credentials to be sent, and here is the extra header to enable credentials (Access-Control-Allow-Credentials), but this section of the spec should include SHOUTING TEXT about potential dangers and instruct the developer that he should not enable transmission of credentials unless he is sure that he needs it and he is sure that he knows what he is doing (such as understanding what a CSRF attack is). I realize that some developers won't read the spec carefully or notice the shouting text, but I expect most tutorials and examples on the Web will follow the lead from the spec and help to teach people steer clear of the Access-Control-Allow-Credentials header unless they know what they are doing. Jon
