Re: Offline Web Applications status
Louis-Rémi, We are working on a large-size HTML5 web application and are using appcache successfully. For a large-size webapp being delivered off of a slow network, appcache provides a huge (arguably essential) performance gain because the client doesn't have to do a server request for everything that is put into the appcache, whereas you still need to ping the server for old-style cached files. (Therefore, we are using appcache today mostly for network performance advantages versus old-style browser caching. We aren't doing "offline" at this point. However, we are looking at taking the next step to offline down the road.) We found it was difficult to get working on a cross-browser basis due to incomplete specs and browser quirks. I vote for improving what exists today, particularly hammering out detailed spec issues and creating a comprehensive test suite. Jon Ferraiolo, IBM From: louis-rémi BABE To: public-webapps@w3.org Date: 03/23/2011 08:58 AM Subject:Offline Web Applications status Sent by:public-webapps-requ...@w3.org Hello Webapps working group, I'm an intern at Mozilla Developers Engagement team and I'm currently working on promoting Offline Web Applications. My first task is to understand what did go wrong with the App Cache mechanism... ## Maybe Web devs don't use App Cache because they don't understand what it is... ## The possibility of using Webapps offline has a great potential but its adoption by developers didn't reach our expectations. We asked Web developers some time ago what were their feelings regarding application cache (see http://hacks.mozilla.org/2010/05/revitalizing-caching/ ) and it appeared that the name was misleading, as they expected it to be more of an auxiliary cache than an offline mechanism. You can find evidences of this confusion on StackOverflow, where some people struggle to use the application cache as a mean to boost performances of their Websites. ## Can you see other reasons? ## Before going back to developers or writing yet another App Cache documentation, I wanted to have *your* feelings about this mechanism. You might have a different impression about its adoption and be aware of successful real-world use-cases. You might have asked developers yourself and received a different feedback. Maybe you feel that Web advocates are not doing a good enough job at documenting this feature, producing demos and clarifying its nature. Maybe you think that the problem has to do with the specification itself. Maybe there is an evolution of the specification underway that I am not aware of. ## Two naive questions ## After reading a large amount of documentation, I have to admit that I am myself confused about app cache: Do you think it *can* be used as an auxiliary cache mechanism, and what would be the limitations? The main problem I see is that there is no way to white-list the referring document (e.g. index.html). Currently, I would advocate *against* using it as an auxiliary cache. Why isn't there any DOM API allowing a fine-grained control of the application cache? applicationCache.cache.add( URI ); applicationCache.cache.remove( URI ); Thank you in advance, Louis-Rémi Babé <><>
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 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
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 | >-| |> | To:| |> >-| |Doug Schepers | >-| |> | Cc:| |> >-| |Maciej Stachowiak , "Mark S. Miller" , Adam Barth , Anne van Kesteren | |, "Henry S. Thompson" , Jonas Sicking , Arthur Barstow , | |public-webapps | >-| |> | 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 wrote: > Let's take it a step further, and propose a worst-case scenario. Say that > some undetected hypothetical vulnerability in CORS is discovered some years > from now, with a degree of severity akin to C
Re: Request for Review: Cross-Origin Resource Sharing
Hi Doug, OpenAjax Alliance is highly interested in the security aspects of the CORS spec, but AFAIK, there isn't anyone doing careful monitoring of spec changes or email list discussion. Sounds like it is time for me to solicit input from our security committee on the most recent spec. Jon Doug Schepers Sent by: To public-webapps-re ietf-http...@w3.org, qu...@w3.org "public-webapps@w3.org" cc 04/03/2009 04:12 PMSubject Request for Review: Cross-Origin Resource Sharing Hi- The W3C Web Applications WG is actively seeking review for the Cross-Origin Resource Sharing (CORS) specification [1] from parties interested in Web security. This specification currently depends upon the proposed Origin header, which started within the CORS specification but has been split out as an IETF draft, The HTTP Origin Header [2]. It should be noted that the Origin header has received some criticism, and the WebApps WG is discussing whether it may be sufficient for use with the use cases covered by CORS. The CORS specification is currently being implemented by major browsers, including at least Internet Explorer 8, beta versions of Firefox 3.5, and beta versions of Safari 4. Therefore, it is of particular importance and urgency that we receive formal review of CORS. A previous request for review [1] (when this specification was known as "Access Control for Cross-Site Requests") did not result in sufficient technical response during the last year and a half. It is difficult for the WebApps WG to determine if this was due to lack of interest, lack of perceived problems, or belief that review of the Origin header draft was sufficient. Explicit review will help us assess how to move forward with this work in a way that is mindful of Web security architecture. We would appreciate this call for review being forwarded to any lists or people that should be aware of it. [1] http://www.w3.org/TR/cors/ [2] http://tools.ietf.org/html/draft-abarth-origin-00 [3] http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0298.html Best Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs <><><>
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 To Jon Ferraiolo/Menlo Park/i...@ibmus 03/11/2009 10:16 cc AMSUZANNE Benoit RD-SIRP-ISS , 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/ <><><>
Re: [Widgets] Widget Gallery RSS like sharing format
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? Jon Robin Berjon To Sent by: SUZANNE Benoit RD-SIRP-ISS public-webapps-re qu...@w3.org cc Subject 03/11/2009 08:10 Re: [Widgets] Widget Gallery RSS AMlike sharing format On Mar 11, 2009, at 14:14 , SUZANNE Benoit RD-SIRP-ISS wrote: > I do not consider the following as a formal format proposition but > as an input to open the discussion as it should probably be written > in atom instead of RSS. Yes, and it should introduce as few new elements as possible. Off the top of my head: http://www.w3.org/2005/Atom"; xml:lang="en"> Cool Widgets For Your Phone http://example.org/widgets/feed"; rel="self"/> http://example.org/widgets/"/> 1997-03-15T00:05:42Z Kjetil Dahut k...@example.com urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6 W3C LC Comment Generator http://example.org/1997/03/15/ lcgen.wgt" type='application/widget'/> http://example.org/1997/03/15/about-lcgen.html "/> http://w3.org/rel/screenshot"; href=" http://example.org/1997/03/15/lcgen01.jpg. "/> http://example.org/1997/03/15/lcgen.wgt 1997-03-15T00:05:42Z To make handling those pesky groups easier. BjörnH Of note: - the only extension to the base format is minting a new rel IRI for screenshots; - I don't think we want anything describing the platform, this is for W3C Widgets (and platform description would need something more powerful than just a string anyway); - category as a number is meaningless to users, using a tag plus a label is probably better; - I don't see the use case for including a version here (that's for the Update spec); - I'm not convinced that there is strong value in supporting download statistics and ratings; - there is probably some variant on the @rel that might have better semantics; - language has to be an ISO code. -- Robin Berjon - http://berjon.com/: Feel like hiring me? Go to http://robineko.com/ <><><>
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 Sent by: To public-webapps-re Thomas Roessler qu...@w3.org cc "public-webapps@w3.org WG" , 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 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.: http://www.w3.org/";> iso-8859-1 bar /www.w
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 To Sent by: "public-webapps@w3.org" public-webapps-re qu...@w3.org cc Dan Brickley 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 <><><>
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 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 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 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 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 means having it try two paths won't hurt (and it's a readonly VFS, so if i do and my locale doesn't have /i18n/fr-FR/images/, then the UA can skip the check for the file there and go stra
Re: Required support for SVG in widgets
Hi Charles, Just because the OMTP is "pay-to-play" doesn't mean their efforts are wrong. (Isn't W3C "pay-to-play" also?) My understanding is that all of the BONDI technologies will be RF and published as open standards, and that they are working in good faith with the W3C and WebApps WG to make sure their technologies fit in with what the W3C is doing. My perception is that BONDI (with all of its mobile operator members) is focused on driving industry support for W3C Widgets, which is a very good thing for the W3C. If I'm wrong with these assumptions, I'd like to know about it. But off course, W3C needs to study the BONDI specs before giving a thumbs up, so it would be premature to reference BONDI at this point. Jon "Charles McCathieNevile" wrote on 02/04/2009 10:21:52 AM: > On Wed, 04 Feb 2009 15:42:08 +0100, Jon Ferraiolo > wrote: > > > 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. > > Err, why exactly should this group mandate a spec that has so far been > developed in secret among a consortium of pay-to-play members? It might > make sense for BONDI to be submitted here, and I hope that it is as good > as it will need to be, but I don't see any reason to simply take it on > trust that it is perfect when we haven't even seen it. > > > 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)... > > but just having drafts out there would show the community what the > > interoperability target is. > > Yes, it makes sense in practice to say what kind of baselines are > generally supported (I don't know that this needs to be a recommendation - > it would make a fairly useful note just as a rough table). > > Doing this as an occasionaly working group note would mean it is quite > easy process wise, and that might be the best approach. > > cheers > > Chaals > > -- > Charles McCathieNevile Opera Software, Standards Group > je parle français -- hablo español -- jeg lærer norsk > http://my.opera.com/chaals Try Opera: http://www.opera.com
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 To Sent by: Marcos Caceres public-webapps-re 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 > 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/ <><><>
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 To Sent by: Robin Berjon 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 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 P&C 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, <><><>
Re: [widgets] Widget modes
Hi everyone, It would be good if the Widgets spec was careful to study potential conflicts with similar attributes in Google/OpenSocial Gadgets and OpenAjax Metadata. Google Gadgets has: OpenSocial/Google Gadgets: * http://code.google.com/apis/gadgets/docs/ui.html#views * http://code.google.com/apis/gadgets/docs/reference/#gadgets.views.ViewType OpenAjax: * http://www.openajax.org/member/wiki/OpenAjax_Mashable_Widgets#view_attribute Over at OpenAjax Alliance, we are in the process of examining our spec for web widgets to align better with Google Gadgets. There is a good chance we will change our 'view' attribute to re-use the same keywords as OpenSocial/Google Gadgets when used for the same purpose. The W3C doesn't have to do that since there are different namespaces for the different XML vocabularies anyway, but at least it makes sense to spend a little time studying what's happening at OpenSocial and OpenAjax to see if it makes sense to attempt to share the same markup. Jon SUZANNE Benoit RD-SIRP-ISS Sent by: cc public-webapps-re qu...@w3.org Subject [widgets] Widget modes 01/29/2009 08:34 AM Hi all, about the widget windows modes, I wanted to share the following points: *** Wording *** In the wordings of the modes, I think that the wording used in some of the modes are too specific to existing platforms, therefore I propose the following names: Icon: I’m not sure this one is really a mode as it is already dealt with in the rest of the spec in the right manner with a static image format Iconized: this mode will allow to define an icon that can be adapted to the content status, for example a weather icon will display the right cloud or sun based on the real time information. This is possible using the svg, but I believe this is one of the modes of displaying information in a widget. Expanded: this is the reference to the existing floating mode in the spec or the undocked mode for vista Minimized: this is the reference to the existing docked mode in the spec but is too restrictive in the wordings Full screen: now for this one my worry is more the fact that there are other attributes that should be available for this mode as the display can be specific to the orientation (landscape or portrait) and to the size of the screen’s device (vga, qvga, ...) Hidden: I like the proposition from mark to allow a widget to run as a background task that can awaken an action, so you would probably need to add this as a mode as well. Settings: I would also like to add the settings of the widget as a specific mode as this will largely simplify the coding of the widget where all the various screens to display will all be defined as modes. ***Context*** The way I see this implemented is that based on the platform actions (drag on a widget bar for example) the platform would switch from one view to the other. Or based on a code input in the hidden mode, a widget would be able to call it’s Minimized mode through the code. In this context the one thing that needs to be included is how to pass parameters from one mode to the other, but that could be resolved using some kind of parametered declaration. ***Usage*** I do not see the mode as an element, but as an item of the content element, see examples below. ***Code example*** In the format to use the modes I propose the following as a bases for discussions: What do you think? Best Regards, Benoit Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 benoit.suza...@orange-ftgroup.com. <><><><><>
Re: [widgets] Version string
We didn't attempt to provide algorithms for numeric comparison for anything
after the numeric part. Therefore, with our approach, we cannot determine
if "1.1Beta1" is greater than or less than "1.1Beta2".
The only thing we did to address alpha/beta releases was to *suggest* that
the numeric part include a build number. That way, if 1.1Beta1 is build
2045 and 1.1Beta2 is build 2387, then numeric comparison would work if the
version numbers were expressed as "1.1.0.2045 Beta1" and "1.1.0.2387
Beta2".
We certainly could have tried to force the community to always include the
build number (or some other technique that would ensure version number
comparisons would be accurate), but given our target audience (i.e., Ajax
libraries developers), who aren't always good at following rules, we felt
that we would be lucky if we could get them to include any sort of useful
version string, and therefore we tried to formulate rules that would tend
to match the version strings that they were using today (e.g., "1.1Beta1").
Jon
"Arve
Bersvendsen"
<[EMAIL PROTECTED]> To
Jon Ferraiolo/Menlo Park/[EMAIL
PROTECTED],
10/27/2008 02:09 public-webapps
PM
cc
"Marcos Caceres"
<[EMAIL PROTECTED]>, "Thomas
Roessler" <[EMAIL PROTECTED]>
Subject
Re: [widgets] Version string
On Mon, 27 Oct 2008 20:11:20 +0100, Jon Ferraiolo <[EMAIL PROTECTED]>
wrote:
> 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.
So, you are allowing something like
2.6.27.4-foo3
and
2.6.27.4-foo4
or
1.2.3.gcc4.qt3
1.2.3.gcc4.qt4
Is any judgment whether one version in these cases is newer than the
other? If so, which is newer of the following?
1.2.☺
1.2.☻
--
Arve Bersvendsen
Developer, Opera Software ASA, http://www.opera.com/
<><><>
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 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 > <><><>
Re: Cross-Site Requests, Users, UI (and What We're Trying to Fix)
Hi Arun, This looks like a promising direction to me. At OpenAjax Alliance, there is a lot of interest from security-minded folks for something like this ([1]). On our wiki, various people made suggestions about how to address these sorts of issues, but each of the previous proposals did not seem to address the problem at a more fundamental level. The Mozilla approach looks much better than the others, although I'll bet there are lots of issues to work through. One question that comes up right away: Is there a reason why the whitelist information is available only via HTTP headers (versus markup)? So that the info doesn't appear in View Source? (But wouldn't it still be viewable via Firebug?) Jon [1] http://www.openajax.org/runtime/wiki/Better_Security_for_Cross-site_Scripts Arun Ranganathan <[EMAIL PROTECTED] > To Sent by: public-webapps@w3.org, public-webapps-re [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] cc 07/03/08 12:49 PM Subject Cross-Site Requests, Users, UI (and What We're Trying to Fix) Please respond to [EMAIL PROTECTED] All, At the recent F2F discussions in Redmond covering XMLHttpRequest (Level 2) and Access Control, the question of user involvement came up more than once. This discussion raised issues about whether or not the user should be informed by a user interface mechanism in the browser that a cross-site request was taking place. In general, discussion about *notifying the user* is part of a larger discussion about enabling sites to exchange *user-private data* via browser-based APIs such as postMessage and XMLHttpRequest with Access Control. Within Mozilla, we had several discussions about private data exchanges and the pros and cons of a user notification mechanism. Opinions within Mozilla vary. Often, given the nature of our open community and open participation model, we have to agree to disagree. Some hold the opinion that obtaining private data through a cross-site transaction, even with a mitigation mechanism such as Access Control, creates security or privacy scenarios that are unfavorable to end users. These same parties hold that at the very least, the user should have a user interface mechanism to stop the transaction. Others, including myself, hold the opinion that it is better to fundamentally *improve* existing cross-site access mechanisms, which certainly do not inform the user today [1], and to encourage developers to use safer APIs to build applications that engage in cross-site transactions. Moreover, it is desirable to introduce a mechanism that allows for "stricter" script inclusion, including inline scripts and maintaining lists of domains that are safe to script scr="" from [2]. The way forward might be to: 1. introduce new mechanisms to do what developers do already[1], but allow them to be done safer, and to 2. "clean up" unsafe legacy mechanisms[2] as best as possible. While user interface mechanisms may help to generally inform the user and customize their web experience (e.g. stopping third party Cookies, etc.), "STOP | CONTINUE" type messages affiliated with APIs such as XMLHttpRequest (with AC) may be misleading in this context, since sites that wish to exchange data can use any number of mechanisms[1] on the web today and not inform the user. Of course, it is generally good behavior for sites that store user-private data to have privacy policies and inform the user about any sharing with other sites. -- A* [1] A (Not Exhaustive) Listing of Cross Site Mechanisms: http://www.arunranga.com/articles/browser-cross-site.html [2] Straw Person Proposal for Site Security Policy: http://people.mozilla.com/~bsterne/site-security-policy/ <><><>
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
