Re: [widgets] Updates FPWD published
Henri Sivonen [EMAIL PROTECTED], 2008-10-10 10:38 +0300: On Oct 10, 2008, at 01:44, Marcos Caceres wrote: http://www.w3.org/TR/widgets-updates/ [...] The Editor's Draft link points to the Editor's Draft of another spec. Fixed --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [widgets] Updates FPWD published
Hi Henri, On Fri, Oct 10, 2008 at 8:38 AM, Henri Sivonen [EMAIL PROTECTED] wrote: On Oct 10, 2008, at 01:44, Marcos Caceres wrote: http://www.w3.org/TR/widgets-updates/ As always, comments welcomed. The sentence An update source is the URi referenced by the src attribute of the an update element. probably means the *widget*update element. Fixed. The Editor's Draft link points to the Editor's Draft of another spec. Fixed (Thanks Mike!). The processing model should probably say that non-DOM implementations are allowed if the result isn't black-box-distinguishable. Added a note to such effect (based on what we have in the other Widget specs): Note: The following processing model is written with more concern for clarity over efficiency. As such, user agents may optimize the processing model so long as the end result is indistinguishable from the result that would be obtained by the following the specification. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32
Jonas Sicking wrote: * 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. The list is here: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0048.html / Jonas
Re: [Widgets] URI Scheme revisited.... again
On Fri, Oct 10, 2008 at 3:29 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok. I will add Any hierarchical URI scheme as the proposed solution into the spec. I will say that, personally, I feel it is irresponsible for the WebApps WG to not recommend a complete and a secure solution for this issue. I also fear that not mandating a URI scheme will lead to interoperability issues (especially going forward into V2, where we might want to support things like queries and fragments, which something like file: does not support). Well, the questions I asked of you were intended to discover whether or not interoperability was impacted by not specifying a URI scheme. Is there some aspect of this I didn't consider? Can you give me an example of an interoperability (or security, as you say) problem that's created by not specifying a URI scheme? Mark.
Re: [Widgets] URI Scheme revisited.... again
On Fri, Oct 10, 2008 at 8:35 PM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 3:29 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok. I will add Any hierarchical URI scheme as the proposed solution into the spec. I will say that, personally, I feel it is irresponsible for the WebApps WG to not recommend a complete and a secure solution for this issue. I also fear that not mandating a URI scheme will lead to interoperability issues (especially going forward into V2, where we might want to support things like queries and fragments, which something like file: does not support). Well, the questions I asked of you were intended to discover whether or not interoperability was impacted by not specifying a URI scheme. Is there some aspect of this I didn't consider? Can you give me an example of an interoperability (or security, as you say) problem that's created by not specifying a URI scheme? Ok, In one of my previous emails I said that this was a potential privacy/security issue: 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). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. -- Marcos Caceres http://datadriven.com.au
