Re: [Widgets] URI Scheme revisited.... again
On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. Mark.
Re: [access-control] Origin: null versus Origin:
On Thu, 09 Oct 2008 03:05:20 +0200, Adam Barth [EMAIL PROTECTED] wrote: In some cases, XHR+AC will send an Origin header whose value is the empty string. This asks server operators to distinguish between a request that lacks an Origin header (like a same-site request) and a request with an empty Origin header (say from a data URL), which might be tricky in various languages like mod_security. Also, some proxies might normalize empty headers away if they represent the non-existence of a header with the empty string (as, for example, XMLHttpRequest does). Actually, XMLHttpRequest distinguishes between the two. (Empty string versus null, though not all browsers have implemented that feature yet.) A previous version of the spec sent the literal string null in these cases. It seems like this behavior is preferable. If we want to have the same behavior as postMessage, we might be able to change its origin property to use the string null in these cases too. If HTML5 were to change Access Control would also automatically change. However, browsers are already deploying this. Then again, I haven't actually tested if any browser does Origin correctly yet. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[Widgets] BONDI update from Austin
Dear all, At the last conference call I promised to give you an update on the main points from our BONDI Architecture Security meeting which relate to W3C. As I have already said on previous calls, BONDI would like to be in-line with W3C. Specifically, at a high level: * BONDI will require widgets to be packaged as defined by the W3C Widgets 1.0: Packing and Configuration specification * BONDI will specify the use of the W3C Widgets 1.0: Digital Signature for the signing of widgets These agreements were made on the current working drafts of the W3C work and also with the understanding that the W3C specifications will be completed within the timescales required. We will continue to actively contribute to this work to help this happen. We are planning the next public release of BONDI documents soon which will reflect the points above. I will inform you all when these are online and available to download. If you have any comments or questions, please feel free to contact me. Thanks, David. David Rogers OMTP Director of External Relations
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. I see what you mean, the Hoffman draft above reads more like a here is a list of what is wrong with file: rather than a spec. And rfc1738 has been obsoleted. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. We use both relative and absolute URI references, and the base is derived from the i18n model we have introduced. The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). Personally, the solution I keep coming to is something like : widget-uri = http://; widget-engine [: instance-id] / package-name path-absolute [# fragment] Where widget-engine is something akin to using, say, localhost, but uses some arbitrary string that identifies the engine (e.g. theFooEngine). The optional instance-id would be a string that uniquely identifies a widget instance for the purpose of cross-widget communication. However, I can foresee that there may be problems with thieving http's port semantics to uniquely identify an instance (so we leave this out until version 2). The scheme would only support GET requests. For example, http://theFooEngine/barWidget.wgt/index.html#welcome Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] Minutes from 9 October 2008 Voice Conference
The minutes from the October 9 Widgets f2f meeting are available at the following and copied below: http://www.w3.org/2008/10/09-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before October 16 (next Widgets voice conference); otherwise these minutes will be considered approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Web Applications Working Group Teleconference 09 Oct 2008 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2008OctDec/0051.html See also: [3]IRC log [3] http://www.w3.org/2008/10/09-wam-irc Attendees Present Art, Arve, Benoit, Mark, Marcos, Thomas, Claudio Regrets DavidR Chair Art Scribe Art Contents * [4]Topics 1. [5]Agenda Tweaking 2. [6]Annoucements 3. [7]API and Events spec 4. [8]DigSig spec 5. [9]I18N issue 6. [10]widget URI scheme aka Issue #16 7. [11]Widget Testing 8. [12]Requirement doc - Req #21 - New req Feature Access Declarations 9. [13]Requirements LC #2 10. [14]AOB * [15]Summary of Action Items _ Agenda Tweaking AB: any change requests for the agenda? [None] Annoucements AB: any annoucements? [None] API and Events spec AB: Arve, what's the status? Arve: I think we are ready to publish ... I haven't done much since last week except to remove prefs API ... I need some help getting it pub ready scribe ACTION: Barstow talk to Mike about helping Arve getting the API and Events spec pub ready [recorded in [16]http://www.w3.org/2008/10/09-wam-minutes.html#action01] trackbot Created ACTION-254 - Talk to Mike about helping Arve getting the API and Events spec \pub ready\ [on Arthur Barstow - due 2008-10-16]. MikeSmith hai MikeSmith I can deal with that of course Arve: HTML5 defines a similar API ... but the semantics and UCs are a bit diff ... e.g. showNotification scribe ACTION: Barstow submit FPWD request for API and Events spec [recorded in [17]http://www.w3.org/2008/10/09-wam-minutes.html#action02] trackbot Created ACTION-255 - Submit FPWD request for API and Events spec [on Arthur Barstow - due 2008-10-16]. DigSig spec AB: what's the status Mark and Marcos? MC: we haven't done any work in the last week AB: where is this in your priorities Mark and Marcos? MC: my priority is the PC spec ... but I can help Mark MP: from the VF and BONDI point of view, we want to use the DigSig spec ... it is important to progress it ... I hope to do some work on it next week ... it is a priority for us MC: the PC spec is being update to include multiple signatures ... If Mark could start a dialog with XMLSec WG that could help AB: it would be good to get more specific on the agenda for our joint meeting MC: I have some questions for them re our model tlr +1 to having specific issues. However, note that I won't have much bandwidth available between now and TPAC. AB: I would like MC and MP to be prepared to drive the discussion with XML Sec WG ... we want specific questions, in advance if possible ... what is the status of the latest ED [18]http://dev.w3.org/2006/waf/widgets-digsig/ - says May 27 ... do you have a copy that reflects discussions in Turin [18] http://dev.w3.org/2006/waf/widgets-digsig/ MC: we have done some brainstorming but haven't put those ideas into CVS AB: will there be an update before the f2f meeting? MC: yes; at a min we will add some UC data ... I will need Mark's help I18N issue AB: have you Marcos and Felix converged on a solution? MC: Felix provided some good feedback re ITS ... I added optional support for ITS to the ED ... Felix says my latest changes are OK ... he recommended some minor changes in the Relax NG schema and I've added those AB: can we now close this issue i.e. ISSUE #46? ... [19]http://www.w3.org/2008/webapps/track/issues/46 [19] http://www.w3.org/2008/webapps/track/issues/46 MC: no I don't think we can close this yet ... want to make sure I18N WG is OK with our solution widget URI scheme aka Issue #16 AB: we will meet with some TAG members on Monday Oct 20 14:00-15:00 to discuss this issue MC: I have been responding to Mark Baker's comments marcos widget-uri = http://; widget-engine [: instance-id] /package-name path-absolute [# fragment] Arve: this seems like a breakage with HTTP ... I think using this is a locator issue ... I think file: has lots of problems ... e.g. not interoperable in current browsers ... as well as no formal definition ... it is also
Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32
Arthur Barstow wrote: The following issues were created during the July 1-2 f2f meeting (minutes at [1], [2], respectively). Would someone that attended that meeting please elaborate these issues? In particular, has the Issue been addressed and thus can be proposed to be Closed? -Regards, Art Barstow [1] http://www.w3.org/2008/07/01-wam-minutes.html [2] http://www.w3.org/2008/07/02-wam-minutes.html * ISSUE-25 - Revocation of cached access grants http://www.w3.org/2008/webapps/track/issues/25 The issue was the ability for a server to revoke a cached preflight result. Or ensuring that if you are MITMed in a cafe or some such that the cached result doesn't linger too long. I *think* this one is resolved since the cache is cleared if access is ever denied (haven't implemented this part of spec yet so not 100% sure). We decided that implementations should be allowed to clear the cache at any point if they so desire, which means that implementations are allowed to limit the cache time to 24 hours or some such (something that firefox will do). Hmm.. though looking at the spec I can't find where it says that clearing items out of the cache at any point. * ISSUE-26 Wildcarding is currently possible together with cookies which could result in exploitable servers. http://www.w3.org/2008/webapps/track/issues/26 This is about not allowing the '*' syntax when fetching private data. This has been address as this is no longer allowed per spec. * ISSUE-29 Should Access-control allow DNS binding defense? http://www.w3.org/2008/webapps/track/issues/29 This should again be addressed by the spec allowing the implementation the clear the cache at any point. * ISSUE-30 Should spec have wording to recognise that User Agents may implement further security beyond the spec? http://www.w3.org/2008/webapps/track/issues/30 I guess this is the part that needs to be addressed by adding wording to the spec to say that the cache can be cleared/ignored at any point. I wrote up a list at some point and I think sent it to the public list about security measures that Firefox was going to take beyond the spec. * ISSUE-31 Allow POST without a preflight with headers in a whitelist http://www.w3.org/2008/webapps/track/issues/31 This is addressed in the spec. POST is now allowed when the content-type is text/plain. * ISSUE-32 Each redirect step needs to opt in to AC in order to avoid data leaking http://www.w3.org/2008/webapps/track/issues/32 I think this is addressed in the spec. So all in all it seems like once ISSUE-30 is fixed all of the above can be closed. / Jonas
