[widgets] Agenda for 30 October 2008 Voice Conference

[Arthur Barstow]

NOTE TIME ZONE CHANGE FOR US PARTICIPANTS -> ONE HOUR LATER THAN  
"Normal" THIS WEEK!


Below is the draft agenda for the October 30 Widgets Voice Conference  
(VC).


Inputs and discussion on the agenda topics before the meeting is  
encouraged.


Logistics:

  Time: 08:00 Boston; 13:00 Paris; 20:00 Tokyo; 21:00 Brisbane
  Duration = 60 minutes
  Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1")
  IRC channel = #wam; irc.w3.org:6665
  Confidentiality of minutes = Public

Agenda:

1. Review and tweak agenda

2. Announcements

3. P&C spec:
  ED: 

a. URI scheme: issues and comments by TAG members:

 Minutes: 
 Summary: 


b. Version string: discuss Marcos' proposal and related comments:

 


c. ID attribute: discuss Marcos' proposal:
 


4. DigSig spec:
  ED: 

a. Issue 22 - Is sha1 as a DigestMethod strong enough for Widgets  
digital signatures? - has this been sufficiently addressed to Close?

  

b. Issue 19 - Widgets digital Signatures spec does not meet required  
use cases and requirements - what needs to be done to address this  
issue?

  

c. Follow-ups from Joint meeting with XMLSec WG:

  Minutes: 

5. AOB

[selectors-api] All Issues Resolved

[Lachlan Hunt]

Hi,
  As of now, all of the outstanding issues relating to Selectors API 
have now been resolved and closed.  The last updates to the spec 
included revising the example section, which needed updating after the 
NSResolver was removed, and updating the list of acknowledgements.


The latest editors draft can be reviewed here.

http://dev.w3.org/2006/webapi/selectors-api/

I have also prepared and published the disposition of comments.

http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html

I believe the draft is now ready to proceed to Last Call again, as 
agreed at the F2F last week.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] What DOM feature "Selectors API" belongs to?

[Lachlan Hunt]

Lachlan Hunt wrote:
It's been suggested to me that the spec should say something about 
support for the other methods that use feature strings, including:


interface DOMImplementationSource {
  DOMImplementation  getDOMImplementation(in DOMString features);
  DOMImplementationList getDOMImplementationList(in DOMString features);
};
...

I'm not sure what exactly I should say about them, nor really understand 
the purpose of them. But they're in DOM3Core and will need to be tested 
in the test suite.


I ended up dealing with this issue by making the DOM feature string 
section more generic, mostly deferring to DOM3 for applicable 
conformance criteria.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Fwd: Position paper deadline extended to 5 Nov. 08 ( Security for Access to Device APIs from the Web - W3C Workshop)

[Arthur Barstow]

The deadline for position papers for the workshop on Security &  
Device API Access has been extended to November 5.


However, note there are some important details in the e-mail below  
that you must follow ...


-Regards, Art Barstow


Begin forwarded message:


From: "ext Marie-Claire Forgue" <[EMAIL PROTECTED]>
Date: October 29, 2008 9:38:14 AM EDT
Subject: Position paper deadline extended to 5 Nov. 08 ( Security   
for Access  to Device APIs from the Web - W3C Workshop)


Dear Advisory Committee Representative,

Please note that the deadline to send position papers (1 to 5 pages  
long) for the W3C Workshop on "Security for Access to Device APIs  
from the Web" has been extended to *5 November 2008*.


However, to help the organizers plan the workshop, please send,  
before the end of this week (ie, 31 October 2008), a message to  
[EMAIL PROTECTED] with a short (one paragraph) "expression of  
interest" stating:


* that a representative from your organization plans to submit  
a position paper

* whether you want to send one or two participants
* whether or not you wish to make a presentation

More details can be found in the Call for Participation:
[1] http://www.w3.org/2008/security-ws/

For any additional questions, please contact Dominique Hazaël- 
Massieux ([EMAIL PROTECTED]).


Thank you.
Best regards,

--
Marie-Claire Forgue +33 4 92 38 75 94
Head of W3C European Communications and
Business Development+33 4 92 38 78 22 (fax)
mailto:[EMAIL PROTECTED]  -  http://www.w3.org/+33 6 76 86 33 41 (mob)

Follow-up on widgets scheme discussion with TAG members [Was: Re: [Widgets] URI Scheme revisited.... again]

[Arthur Barstow]

Marcos, All,

I agree the main follow-up is that we need to do some additional  
work, particularly regarding fleshing out related requirements.


The minutes indicate there are some requirements that aren't  
explicitly captured in the October 20 version of R6:


 

Perhaps some of these should be more explicit:

[[


Marcos: We don't want the URI scheme to have the ability to reference  
things outside the resource


Marcos: the real use case for this is resolving the DOM nodes. For  
example, images, iframes, they all need to resolve to something.


Arve: it [widget: scheme] is only a convenience for resolving resources

Josh: For these things, the general expectation is that the names are  
local. They're just so that widget can introspect itself.
Josh: It shouldn't be able to be remotely readable. It's a privacy  
violation if you can see what else is running.


DanC: did the requirements list the security policy, e.g. same  
origin, details?


Arve: it also establishes a security model for accessing things as  
the browser can reuse the cross domain security module. We're using  
an identifier because it's an incredibly convenient way to establish  
a same origin policy.

]]

Also, some related suggestions and questions were raised:

* Transparency: Can the scheme be modeled such that it is an  
implementation detail (i.e. names are private to the UA) and thus  
never [publicly] exposed? What are the consequences if the scheme  
leaks? If the scheme will be public, is there a need for a registry?


* Update scenarios: How would the widget scheme fit into various  
update scenarios?


* Extensibility: What, if any, extensibility mechanism is required  
for the widget scheme? What are the related use cases?


-Regards, Art Barstow


On Oct 24, 2008, at 6:51 AM, ext Marcos Caceres wrote:



Hi Mark,
Please see [1] for TAG discussion about WebApps proposal of widget URI
scheme. From what I got from the discussion, the TAG seems to agree
that we likely do need our own URI scheme. We just need to flesh out
our technical argument a little more. We are also going to try to
coordinate with the Open Document Format people as they also need
something very similar.

I again ask for your help in defining the scheme correctly, rather
than arguing against it.

[1] http://www.w3.org/2008/10/20-wam-minutes.html#item11

Kind regards,
Marcos

On Mon, Oct 13, 2008 at 4:59 PM, Mark Baker <[EMAIL PROTECTED]> wrote:

On Mon, Oct 13, 2008 at 10:31 AM, Marcos Caceres
<[EMAIL PROTECTED]> wrote:

On Mon, Oct 13, 2008 at 5:08 AM, Mark Baker <[EMAIL PROTECTED]> wrote:

On Fri, Oct 10, 2008 at 4:00 PM, Marcos Caceres
<[EMAIL PROTECTED]> wrote:

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.


Sure, but standardizing on a URI scheme won't fix this, because one
can guess URIs in any scheme.  Less opaque schemes like  
hierarchical
ones are a little more susceptible of course, but it's a problem  
for

all schemes.


In the case of widgets, it's not a problem at all for the  
structure of

the package to be guessed (as anyone can just decompress the widget
locally anyway and take a look at it's directory structure; that is
not the issue). What we don't want is a situation where the  
underlying

operating system is also exposed.

That is why we proposed the new scheme. I don't see how a scheme  
like

"widget://myWidget.wgt/path/to/file" exposes anything about the
underlying file system (apart from the name of the widget package)?
Instead, file: exposes way too much IMO (i.e.
"file:///Users/marcos/Library/..."! my username is exposed in the
path, which  everyone can acknowledge is pretty a bad thing, no?).


file:, despite the name, doesn't have to be mapped to the file  
system.

 Its scope could be limited in exactly the same way you've limited
widget: there.  Similarly, ftp or http - even part of the space -
*could* be mapped to the file system.  So the issue you're worried
about has little to do with the URI scheme.


I suspect implementors are familiar with t

Re: [selectors-api] Selectors API comments: section 2

[Lachlan Hunt]

Lachlan Hunt wrote:

Boris Zbarsky wrote:
* I don't see any indication of what the language bindings for this 
IDL should look like in languages which do not support function 
overloading based on number of arguments and do not allow functions 
with variable numbers of arguments.  If it has been decided that no 
one is ever going to implement bindings for this specification in 
such a language , it might be good to explicitly say so in the 
specification so that it's clear that the problem has been 
considered.  Another possible solution is to take the approach taken 
in other existing DOM specifications and tack "NS" onto the end of 
the name of a namespace-aware version of a method that is also 
available in a non-namespace-aware version.  If the intent is to 
indicate that the bindings in some languages may allow omitting the 
second argument, I think that should be done via some mechanism that 
doesn't look like normative IDL.


I would prefer to address this issue in the IDL, but I'm not yet sure 
how to fix it.  The intention is for the methods to be overloaded, and 
for implementations that don't support method overloading, then the 
author will need to pass null as the NSResolver.


Since the NSResolver was removed, we no longer have any function
overloading, and so I'm closing this issue.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api]

[Lachlan Hunt]

Boris Zbarsky wrote:

Anne van Kesteren wrote:
To ensure that naïve implementors don't overlook the potential issue 
here. An implementation of NSResolver can be provided by the script 
author as the specification explains and the script author can do all 
kinds of weird things that don't match a conforming implementation of 
NSResolver (such as mutating the DOM tree).


Is a conforming querySelector implementation allowed to throw an 
exception when this happens?


In fact, is a conforming querySelector implementation allowed to throw 
an exception if the NSResolver does something that it detects is 
non-conforming?


Since NSResolver has since been removed from the spec, I'm closing this
issue as it is no longer relevant.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/