FW: tag: uri scheme
Hi All, WebApps-WG recently asked Tim Kindberg, editor of the TAG URI scheme, if could make some comments about the widgets' requirements for a URI scheme. Below, Tim agrees that tag: is probably suitable for widgets, but raises some concerns about i18n and having a resolution algorithm to go from a tag: to a resource inside a widget. Kind regards, Marcos -- Forwarded Message From: Tim Kindberg timo...@hpl.hp.com Date: Wed, 17 Dec 2008 09:15:48 + To: Arthur Barstow art.bars...@nokia.com Cc: Argh marcosscace...@gmail.com, www-arch...@w3.org www-arch...@w3.org Subject: Re: Fwd: tag: uri scheme Hi Art, I've had a quick look through the resources you referenced. It does seem that tag: is a good candidate for your needs (although I have a couple of questions below). You need an id scheme that isn't quite matched by http etc., and it's better to avoid an entirely new scheme. My points are: (1) Don't you say you want internationalised ids? We (I) gave up on IRI-compatible tags some time ago. It's do-able but I got mired in the mud and ran out of time. (2) Somewhere I saw a reference to using a fixed date, 2008, for 'security reasons. Well that's OK as long as any domain name (or email address) that comes before it was indeed assigned to the minter of the tag on 2008-01-01. (3) From my glance at your documents, it seems that you need a resolution algorithm, to go from a tag: to a resource inside a widget. That's OK by the tag spec: there is no default resolution mechanism but any tag usage protocol can define its own. AFAIK, Atom 'id' elements (the biggest user of tag URIs) are chosen to be resolvable internally to feed generators. I hope that that is of some help, even though I've only had a little time to look at your requirements. I'm actually on leave until January now but may be able to respond occasionally in the meantime. Cheers, Tim. Arthur Barstow wrote: Hi Tim, I am a Chair of the W3C's Web Applications WG [WebApps] and in the context of our Widgets spec [Widgets], particularly Requirements #6 [Req-6] and #37 [Reg-37], we are interested in the tag: scheme. Marcos Caceres, the Editor of our Widgets spec, asked me to contact to you re this scheme. For a bit of context, please see his email below as well as a summary of the Widget scheme issue in [Widget- scheme]. If you have any info to share, we would greatly appreciate it. Here is one the latest discussion threads we've had on this scheme: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 0299.html -Regards, Art Barstow [WebApps] http://www.w3.org/2008/webapps/wiki/Main_Page [Widgets] http://dev.w3.org/2006/waf/widgets-reqs/ [Req-6] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing [Req-37] http://dev.w3.org/2006/waf/widgets-reqs/#r37.- [Widget-scheme] http://tinyurl.com/69yegh Begin forwarded message: From: ext Marcos Caceres marcosscace...@gmail.com Date: December 6, 2008 11:56:24 AM EST To: Arthur Barstow art.bars...@nokia.com Subject: tag: uri scheme Hi Art, I'm wondering if you could do me a huge favor. In light of the tag: uri scheme potentially meeting our needs in regards to a widget uri, I was wondering if you could take the time to contact Tim Kindberg (timo...@hpl.hp.com), who created the tag: scheme, and possibly ask him to weight in on the discussion on the packaging list, web apps list, and the TAG list. It would be great if you could point him to our requirements R6 and R37 and maybe some of the relevant emails. It would also be a big help if you could also ask him if he managed to resolve i18n issues with tag:; And if no, what would need to be done. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au -- Tim Kindberg hewlett-packard laboratories filton road stoke gifford bristol bs34 8qz uk purl.org/net/TimKindberg timo...@hpl.hp.com voice +44 (0)117 312 9920 fax +44 (0)117 312 8003 -- End of Forwarded Message
Re: Comments on Widgets 1.0 Security requirements
Requirements related to widgets should be clearly stated, even if mechanisms can be used beyond widgets. Thus if widgets need expiration then we should be able to articulate both the use case and the requirement. Thanks for updating the requirements document for the other items. regards, Frederick Frederick Hirsch Nokia On Jan 19, 2009, at 7:48 AM, ext Marcos Caceres wrote: Hi Frederick, I've updated the requirements document wrt the suggestions you have made. However, I have not yet included the new requirements as I need to consider them a bit more before I do so. Naturally, if we find that things like expiration and policy association are applicable beyond widgets, I'm wondering if they should become requirements for XML Dig Sig 2.0? Inline comments below... On 1/5/09 10:21 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: I have some comments on requirements section 4.6, Security and DIgital Signatures, editors draft [1], and some concrete suggestions for changes: (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.- This requirement is unclear. Is the intent to say that a signature associated with a widget package might be extracted and served to a client independently of the package, allowing the package to be delivered without the signature inside of it? Or is it saying that the certificate chain and/or revocation information should be able to be accessed independently of the package? In general it might not make sense to validate a signature without access the widget content, since that is not meaningful unless it is possible to validate the content hashes used to generate and validate the signature. Simplified the requirement (see my response to Art). (2) R45 http://dev.w3.org/2006/waf/widgets-reqs/#r45.- It would be useful to add a sentence as to why SHA-1 is still required, e.g. Continued SHA-1 support is recommended to enable backward compatibility and interoperability. I've added the text above to the rationale. On the other hand if the widget specification has not yet been adopted, is there a reason not to require SHA-256 (and make SHA-1 optional), given the known potential weaknesses with SHA-1? Suggestion: replace MUST strongly recommend the use of SHA-256 to MUST recommend SHA-256 for new signature generation and must recommend SHA-1 and SHA-256 for signature verification (or explicitly note that SHA-1 is optional) strongly recommend is not a normative phrase according to RFC 2119. I reworded the requirement using your recommended text. (3) R46 http://dev.w3.org/2006/waf/widgets-reqs/#r46.- Change and to or in the first sentence and or to and in the second to obtain the intended meaning. Fixed. (4) R49 http://dev.w3.org/2006/waf/widgets-reqs/#r49.- The phrase To provide up-to-date is misleading, since cached information may be less up to date than the result of an online query, especially with OCSP. Agreed. Suggest changing rationale paragraph to To enable a widget to obtain revocation information without having to query an online CRL or OSCP server from each device. This is a lot more efficient and eases the load on CRL or OCSP servers. Note, however, that the revocation information may not be as up to date as an online query. However, if this information is updated at the server in a timely manner before widget installations, then an online query would not be necessary at the client. New rationale seems good. Added your text, but with some minor editorial changes. (5) Missing requirement: A signature should indicate the role of the signer. Suggested text A signature may be signed by a widget author as well as a widget distributor. The role of the signer should be indicated to enable the verifier to understand the role of the signer and associated implications. We have been bouncing the idea around of having an author.sig resource inside the package to overcome this issue. However, this is a more elegant solution. Again, would this be something useful for XML Dig Sig 2.0? (6) Missing requirement: A signature should indicate a policy associated with it, independent of information associated with key or certificate information For example, a signature should have a usage (or policy) property indicating that it is associated with the W3C Widget Signature specification and processing rules. The use of a URL is recommended to allow different policies and to enable updated versions. I support this requirement. Can you give me an (XML) example of what this might look like? (7) Missing requirement: Widget packages only require signature validation and certificate and revocation verification upon first installation on a device Proposed text: A widget package signature is validated and associated certificates and revocation information verified, only when the widget is first installed on the device. Signatures and certificate and revocation information may be updated over time
RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
BTW: When it comes to some page/web-app instantiating a widget... how does the publisher/developer make reference to the widget to be instantiated and/or the package from which it is to be instantiated (if those are regarded as separate things)? I'm sorry, I'm not sure I understand your question. Could you rephrase it or give me an example. Ok... I'll try, though I have read very little of the widget spec material, just the bits around addressing. When some webapp developer is developing a webapp they will have to refer in some way to the wigets that they want to use in their application - particularly for the cases where they expect some network retrieval to go on. All I'm asking is *how* they make that reference? - Just a URI refering to (a copy of) the Widget package; - some location independent Widget (package?) name? - a two part name (naming the package and naming the widget within the package)? FWIW, we have removed all requirements for Widgets to be embeddable into Web documents. When you say removed all requirements that doesn't say that current specs don't provide any capabilities there - only that you don't require them to. So... whilst it may not be something that you currently require do the specs that you are working on address or partially address embedding of widgets in Web documents. Widgets, as currently being defined by the Widgets 1.0 Family of Specifications, are solely packaged standalone client-side applications that are authored using Web technologies. BR Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 20 January 2009 08:47 To: Williams, Stuart (HP Labs, Bristol) Cc: www-...@w3.org; public-webapps; public-pkg-uri-scheme-requ...@w3.org Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Hi Stuart, Sorry for taking so long to reply... On 12/15/08 3:16 PM, Williams, Stuart (HP Labs, Bristol) s...@hp.com wrote: Hello Marcos, snip/ At the TAG F2F last week we began to start discussing responding to the direct request that you made to us for feedback: http://lists.w3.org/Archives/Public/www-tag/2008Nov/0114.html ...I again ask the TAG for direct feedback on the following URI-related requirements, which I have modified post the F2F meeting. You go on to quote requirements R6 and R36. We persued R6 and chased down some discussion of configuration documents and thence found: http://dev.w3.org/2006/waf/widgets/#step-1 ins the chapter of Widget spec titled: 8. Steps for Processing a Widget Resource ...in particular step (#1) titled: Step 1 - Acquire a Potential Zip Archive from the Network, or from Local Storage or Other Media which suggests that networked based acquisition of widget resources is very much part of your design. Given what you have said that has left the TAG and I a little confused about your requirements for networked references. In regards to network acquisition, the processing that occurs in Step 1 just refers to downloading zip files (not acquiring the resources from within a package that is somewhere on the network). It strikes me that *if*, as appears to the case, there is a potential need to be able to reference, obtain/install widget packages across the network, then you should factor that into your design early. I see 3 broad requirements: 1) relative addressing withing the package - basically uri: scheme-less with absolute (from package root) or relative paths. question arises of how to turn internal relative references into absolute URI. This is exactly the only problem WebApps-WG was trying to solve. This is the highest priority for the WebApps-wg wrt Widgets 1.0. 2) referencing into a package from 'outside' - which requires some means to refer to the package as a whole plus an approach to refering inside the package. Until now, this was _not_ a problem that WebApps was trying to solve. However, you have convinced me that this will be useful in the future and I would like to pursue it for Widgets 2.0. 3) [Possibly] referencing between instantiated widgets - (ie referencing run-time objects rather than the (shared?) package(s) from which they are instantiated.) This is a low priority item for Widgets 1.0. It is unlikely that it will make it into the spec. However, it is something that we may pursue in Widgets 2.0. Can you help us more specifically with set of scenarios that more clearly illustrate your requirements for networked package/widget referencing and access? Like I said, our main priority is 1). Simply: 1. Get widget package from HTTP(S): e.g.,
Re: [Web Workers API] Data synchronization
On Jan 16, 2009, at 6:10 PM, Jonas Sicking wrote: On Fri, Jan 16, 2009 at 5:17 PM, Nikunj Mehta nikunj.me...@oracle.com wrote: I have reviewed the draft specification dated 1/14 [1]. I am not sure about the status of this spec vis-a-vis this WG. Still, and without having reviewed any mailing list archives about prior discussion on this draft, here are some questions around the scope of this spec: 1. Are background workers executing outside the current browsing context completely out of consideration? As an implementor of sync engines and developer of applications that use them, Oracle's experience shows that trickle sync is the most usable approach and that in trickle sync an application doesn't need to be active for data to be moved back and forth. All workers execute outside the context of a current browsing context. However the lifetime of a dedicated worker is tied to the lifetime of a browsing context. However shared workers can persist across contexts. Extending the lifetime too far beyond the lifetime of a browsing context has usability, and possibly security, issues though. Let's be specific here. What are the kinds of threats introduced that are do not already exist with these background workers? If a foreground script takes too long, browsers pop up a dialog asking if the user wants to terminate the script. Why can the same not be said about workers whose lifetime is not tied to any browsing context, per se? As a browser developer I'm not really comfortable with allowing a site to use up too much resources after a user has navigated away from a site. How does the current design of workers protect available resources against malfeasance or unfair use. In fact, if anything, using the current WebWorkers draft, naïve design can easily rob users of the ability to control network usage and remove the ability of a user to terminate a worker when so required, if an application does not provide suitable means for doing so. 2. Long running scripts pose a problem especially when script containers leak memory over time. Is it giving too much freedom to workers to run as long as they wish and use as many network/memory resources as they wish? By script containers, do you mean script engines? Correct If so, long running scripts are no different from scripts that run short but often as is the alternative in browsing contexts. We can run garbage collection in the middle of a running script. Then why does my browser's memory usage keep increasing when I keep pages open for a number of days, especially if those pages have a fair amount of JavaScript? Or may be Firefox has resolved such issues in recent releases. 3. On devices which do not like background processes making continuous use of CPU/network resources (such as iPhone and BlackBerry). how can one take advantage of native notification services to provide up-to-date information at a low enough resource cost? This is actually a pretty interesting question. I see a fundamental shortcoming in the WebWorkers spec because it seems to wish away some of the problems of efficient synchronization simply by providing a background execution model. While having multiple distinct use cases for WebWorkers seems like a good thing, IMHO, the current spec will not support industrial strength synchronization for Web applications on mobile devices, which should be an explicit goal of this spec. It's really more a property of which APIs we expose to workers, rather than the worker API itself I'd say. We need someone to define an API that allows native notification services to be the transport layer, and then we can expose that API to workers. What's interesting is that the HTML5 spec actually makes an attempt at defining such an API. The problem is that it uses an eventsource element to do it, which means that we can't use the API directly inside workers. Hixie: Should we consider making eventsource a pure JS API so that it can be reused for workers? 4. Why is the spec biased towards those implementors who would like to persist synchronization results and application data in the structured/local storage only? Why not consider needs of those who would prefer to keep their data accessible directly through HTTP/S, even in the disconnected case? Because such APIs already exist. As soon as there is a spec for synchronization with a server I see no reason not to expose that to workers. Indeed, the people coming up with a server sync API could define that the API is available to workers if they so desire. I am afraid you may have misunderstood me here. My point is that it is being assumed that applications that wish to hoard their data for offline use want to do so only through the localStorage/database mechanisms being introduced in HTML5. I have been a proponent of architecture wherein applications to use the same API for accessing data regardless
Re: [Web Workers API] Data synchronization
On Tue, Jan 20, 2009 at 9:57 AM, Nikunj Mehta nikunj.me...@oracle.com wrote: On Jan 16, 2009, at 6:10 PM, Jonas Sicking wrote: On Fri, Jan 16, 2009 at 5:17 PM, Nikunj Mehta nikunj.me...@oracle.com wrote: I have reviewed the draft specification dated 1/14 [1]. I am not sure about the status of this spec vis-a-vis this WG. Still, and without having reviewed any mailing list archives about prior discussion on this draft, here are some questions around the scope of this spec: 1. Are background workers executing outside the current browsing context completely out of consideration? As an implementor of sync engines and developer of applications that use them, Oracle's experience shows that trickle sync is the most usable approach and that in trickle sync an application doesn't need to be active for data to be moved back and forth. All workers execute outside the context of a current browsing context. However the lifetime of a dedicated worker is tied to the lifetime of a browsing context. However shared workers can persist across contexts. Extending the lifetime too far beyond the lifetime of a browsing context has usability, and possibly security, issues though. Let's be specific here. What are the kinds of threats introduced that are do not already exist with these background workers? If a foreground script takes too long, browsers pop up a dialog asking if the user wants to terminate the script. Why can the same not be said about workers whose lifetime is not tied to any browsing context, per se? Any time we need to open a dialog, it is a problem if we can't also switch to the page that that dialog is related to. For example when fetching a network resource, we may need to open a dialog asking for password. When that happens we switch to show the window and tab of the page making the request. This is important to prevent users from thinking that they are entering the password for a bank page, while they are in fact sending it to a background tab. While we do also show the url that the password will be sent to, it has been shown that users often don't read the details of a dialog box, and that showing the appropriate tab is more effective. As a browser developer I'm not really comfortable with allowing a site to use up too much resources after a user has navigated away from a site. How does the current design of workers protect available resources against malfeasance or unfair use. In fact, if anything, using the current WebWorkers draft, naïve design can easily rob users of the ability to control network usage and remove the ability of a user to terminate a worker when so required, if an application does not provide suitable means for doing so. In Firefox only in the sense that if a user notices that a lot of resources, the user can attempt to close the page that he/she suspects is using a lot of resources. 2. Long running scripts pose a problem especially when script containers leak memory over time. Is it giving too much freedom to workers to run as long as they wish and use as many network/memory resources as they wish? By script containers, do you mean script engines? Correct If so, long running scripts are no different from scripts that run short but often as is the alternative in browsing contexts. We can run garbage collection in the middle of a running script. Then why does my browser's memory usage keep increasing when I keep pages open for a number of days, especially if those pages have a fair amount of JavaScript? Or may be Firefox has resolved such issues in recent releases. Because of bugs in the browser, and bugs in the page. However you'll run into the exact same bugs from running one script long (which is what you can do on a worker) or having to return from the script and resume on a timer (which is what people do in the main browsing context). 3. On devices which do not like background processes making continuous use of CPU/network resources (such as iPhone and BlackBerry). how can one take advantage of native notification services to provide up-to-date information at a low enough resource cost? This is actually a pretty interesting question. I see a fundamental shortcoming in the WebWorkers spec because it seems to wish away some of the problems of efficient synchronization simply by providing a background execution model. While having multiple distinct use cases for WebWorkers seems like a good thing, IMHO, the current spec will not support industrial strength synchronization for Web applications on mobile devices, which should be an explicit goal of this spec. As I said before, this is a function of the APIs we expose to the workers, not a function of the worker API itself. Nothing prevents anyone from coming up with a synchronization API and exposing it to main browsing contexts or workers. And nothing that I can see that we've done has made it harder for anyone to do so. If you do see anything we are
[widgets] A proposal on widget modes
Hi All, In the current Widgets 1.0: Packaging and Configuration specification [1], the window modes feature is identified as being at risk. Vodafone believes that window modes are an important feature and should be supported in Widgets 1.0. This email provides a proposal for how modes could be specified and why we think this would be of value. Our proposal is based on our experiences with current and prototype widget implementations, however, we welcome any suggestions on how this proposal could be improved. Thanks, Mark --- Proposal --- Vodafone has identified the need for floating, fullscreen and docked modes. We have not identified a need for an application mode, although we recognise that this may not be aimed at mobile devices. We would therefore support the addition of the following attribute definition to [1]: Start of addition-- Mode Attribute A keyword attribute whose value is one of the following valid modes: floating, fullscreen, docked. The default value, which is used when the attribute is omitted or has a value other than one of the valid modes, is floating. End of addition-- Vodafone has also identifed the need to allow a widget author to declare a preferred mode of operation in the configuration document. This value would be used by the widget user agent to determine which mode to start the widget in. If a widget user agent does not support the indicated mode it should open the widget in floating mode. Vodafone also believes that it should be possible for a widget to be able to indicate which modes it has been designed to support. We therefore propose the introduction of a mode element, i.e. Start of addition-- The mode Element The mode element represents the modes that a widget has been designed to operate in. Context in which this element may be used: In the widget element. Content model: Empty. Occurrences: Zero or one. Attributes default Optional. A mode attribute that indicates the default mode of operation for a widget. fullscreen Optional. A boolean attribute that indicates whether the widget has been designed to run in fullscreen mode. dockable Optional. A boolean attribute that indicates whether the widget has been designed to run in dockable mode. Usage Example This section is non-normative. This example shows the expected usage of the mode element. widget xmlns=http://www.w3.org/ns/widgets; mode default=floating dockable=true fullscreen=false/ /widget End of addition-- The fullscreen and dockable attributes would be used by the widget user agent to determine whether it should support transition to the indicated mode. For example, if a widget declared dockable=false the widget user agent should not try and render the widget within a dock and might instead choose to display the widget's icon. It is expected that all widgets will be capable of running in floating mode. There is therefore no need to indicate support for floating mode, i.e. using a floating attribute. --- Background --- The following text is provided as background information to support the proposal above. It defines the supported widget modes, their expected behavioural differences and the relationship to configuration elements. It is not our expectation that any of this text should be included in the Packaging or Configuration specification but we hope it will be useful in explaining our proposal and as input to the drafting of the APIs and Events specification. A widget mode is a visual and behavioural state of a widget instance. As such, each widget instance can only be in a single mode at any one given time. Transition from one mode to another may be triggered by user interaction and potentially by the widget itself, although this is for further study. Widget user agents may support the ability to open multiple instances of the same Widget Resource, in which case each instance will have its own independent mode. Only one widget instance can ever operate in fullscreen mode at any one time. A widget user agent may display icons as shortcuts to instantiated widgets, however an icon is not considered to be a widget mode. The widget user agent is expected to provide the APIs, events and properties to support modes, e.g.: a.)onModeChange - an event triggered when the widget transitions to a new mode; b.)getMode - an API that returns the current mode of the widget, alternatively this could be a property of the widget object; c.)onBlur - an event triggered when the widget loses focus; d.)onFocus - an event triggered when the widget gets focus; e.)resize(height, width) - an API for changing the size of a floating widget; f.)onResize - an event triggered when the widget is re-sized in floating mode; g.)getDockSize() - an API that returns the size of the dock(s) supported by the widget
Re: Comments on Widgets 1.0 Security requirements
Hi Frederick, On Tue, Jan 20, 2009 at 4:23 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Requirements related to widgets should be clearly stated, even if mechanisms can be used beyond widgets. Thus if widgets need expiration then we should be able to articulate both the use case and the requirement. Agreed. We should probably discuss these requirements in this weeks teleconf and decide on which ones we are going to formally specify as part of Widgets 1.0 and which can be deferred to XML Dig Sig. Thanks for updating the requirements document for the other items. No problem. Thank you for providing the feedback and helping clarify the requirements! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [whatwg] onerror
On Fri, 16 Jan 2009, Jonas Sicking wrote: So I think it'd be nicer to have parity with other onX properties, than to have parity on this one aspect with window.onerror. Done. Second, does the spec define what happens if an error is thrown from 'error' event handler? Now fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
