Re: More CORS Tuesday afternoon...

[Adam Barth]

On Tue, Nov 3, 2009 at 8:10 AM, Adam Barth  wrote:
> On Tue, Nov 3, 2009 at 7:39 AM, Anne van Kesteren  wrote:
>> On Mon, 02 Nov 2009 23:46:30 -0800, Adam Barth  wrote:
>>> It is somewhat frustrating to be unable to participate in this forum.
>>
>> Any particular reason you cannot be here? Would be nice if you could come.
>
> It's really tight, but I'm going to try to be there.

I'm sorry I wasn't able to make it.  My meeting at Mozilla went long.
Hopefully you figured everything out anyway.  :)

Adam

[widgets]: Reminder: Request for Comments: 8-Oct-2009 LCWD of Widgets 1.0: Widget URIs; deadline 10 November

[Arthur Barstow]

Reminder ...

Begin forwarded message:


From: "Barstow Art (Nokia-CIC/Boston)" 
Date: October 8, 2009 12:37:20 PM PDT
To: public-webapps 
Subject: Request for Comments: 8-Oct-2009 LCWD of Widgets 1.0:  
Widget URIs; deadline 10 November

Reply-To: public-webapps 
Archived-At: 


Bcc to: www-...@w3.org and public-pkg-uri-sch...@w3.org

On Oct 8 WebApps WG published a Last Call Working Draft of the
"Widgets 1.0: Widgets URIs" spec:

   http://www.w3.org/TR/2009/WD-widgets-uri-20091008/

The deadline for comments is 10 November and all comments should be
sent to public-webapps@w3.org (archived at [1]).

-Regards, Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/

[widgets] Draft Minutes for 3 November 2009 f2f meeting

[Arthur Barstow]

The draft minutes from the November 3 Widgets f2f meeting are  
available at the following and copied below:


 http://www.w3.org/2009/11/03-wam-minutes.html **

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before November 12 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.


-Regards, Art Barstow

** The date on the HTML page says "2 November" but should say "3  
November. That bug will be fixed. The date is correct in the minutes  
below.


=

   [1]W3C

  [1] http://www.w3.org/

   - DRAFT -

   Widgets F2F Meeting in Santa Clara CA US

03 Nov 2009

   [2]Agenda

  [2] http://www.w3.org/2008/webapps/wiki/ 
TPAC2009Widgets#Agenda_Items


   See also: [3]IRC log

  [3] http://www.w3.org/2009/11/03-wam-irc

Attendees

   Present
  Art, Josh, Benoit, Marcos, Jere, Arve, Magnus, Jean-Pierre,
  Hixie

   Regrets
   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Packaging and Configuration spec
 2. [6]View Modes Media Feature
 3. [7]AOB
 4. [8]TWI spec
 5. [9]TWI attributes
 6. [10]Hixie: Invited Guest
 7. [11]Widgets Planning
 * [12]Summary of Action Items
 _



Scribe: Art

ScribeNick: ArtB

Scribe: Art

   Date: 2 November 2009

Packaging and Configuration spec

   AB: P+C Test Suite is first topic

   MC: I made some tests pre Dusseldorf
   ... at that test fest a bunch of tests were created
   ... I have cleaned those tests
   ... We now have Present Technologies people helping
   ... I create the test cases
   ... Present Technologies then checks the test cases and runs them
   ... So far they have tested Windows Mobile 6.5 using emulator
   ... Blackberry emulator

   
   [13]http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix
   /trunk/index.html

 [13] http://samaxes.svn.beanstalkapp.com/ 
widgets_compatibility_matrix/trunk/index.html


   MC: the Present Technology guys are now Invited Experts
   ... they have found some issues with the test cases
   ... they have found some bugs but nothing serious
   ... we haven't yet moved over the stuff from PT to CVS

   AB: do you need help from the Team?

ACTION: smith work with Marcos to get test stuff from
   Present Technologies moved to CVS [recorded in
   [14]http://www.w3.org/2009/11/03-wam-minutes.html#action01]

Created ACTION-435 - Work with Marcos to get test stuff
   from Present Technologies moved to CVS [on Michael(tm) Smith - due
   2009-11-10].

   MC: we want to make the Compat Matrix made Public
   ... some stuff cannot be tested because of the way we created the
   test suite

   AB: what's an example of something that cannot be tested?

   MC: there is no need for a P+C UA to test TWI dependency
   ... we want the test cases to all be verified

   BS: should the "can't test" test cases be put in a different test
   suite?

   MC: no, I want these tests in the core P+C test suite
   ... their coverage of test runs is getting pretty good
   ... also tested LG, BONDI and Wookie

   AB: so the next step is to get all of this to CVS?

   MC: yes

   AB: what about the BONDI impl?

   MC: it is running in an emulator

   DR: we are thankful for this work
   ... if you need anything from us, let us know

   MC: there are some prereqs
   ... UA must support HTML4.01, CSS1, PNG, ISO-8859-1
   ... for example must be able to display
   ... and support Red, Green
   ... we want to implementations to support "feature:a9bb79c1
   ... to support the feature element
   ... must be able to support the "en" locale
   ... Eventually, we can create an Acid Test and it will have more
   thorough L10N tests

   DR: re this featue: a9*, what does impl need?

   MC: just need to return true
   ... test suite is:
   [15]http://dev.w3.org/2006/waf/widgets/test-suite/
   ... there are 4 testable assertions that need to be written
   ... when I finish there will be about 16 more tests
   ... results are all in an XML file

 [15] http://dev.w3.org/2006/waf/widgets/test-suite/

   AB: is the MWTS WG still helping with P+C test suite?

   MC: no, Kai is working on the DigSig test suite
   ... the main goal is to be able to test interop
   ... I think the suite will do that

   AB: any questions or comments?

   MC: I need feedback from implementors

   DR: the RIM stuff gets compiled into a JAR
   ... so how do you test?

   MC: we test via their emulator
   ... it is no longer a req that a UA be able to download a package
   from the Web

   AB: after CR#2 we would have some type of interop fest?

   MC: yes and Present Technologies is willing to host it

   AB: if we use the same Exit Criteria as CR#1, we need 2 impls

   DR: we should have a RI by December for BONDI 1.01

   s/BOND 1.01/BONDI 1.1/

[widgets] Draft Minutes for 2 November 2009 f2f meeting

[Arthur Barstow]

The draft minutes from the November 2 Widgets f2f meeting are  
available at the following and copied below:


 http://www.w3.org/2009/11/02-wam-minutes.html

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before November 12 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.


-Regards, Art Barstow

   [1]W3C

  [1] http://www.w3.org/

   - DRAFT -

   Widgets F2F Meeting in Santa Clara CA US

02 Nov 2009

   [2]Agenda

  [2] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday. 
2C_November_2


   See also: [3]IRC log

  [3] http://www.w3.org/2009/11/02-wam-irc

Attendees

   Present
  Art, Marcos, Benoit, Magnus, Larry, Josh, Marcin

   Regrets
   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Agenda Review
 2. [6]Widget URIs
 3. [7]Packaging and Configuration Spec
 * [8]Summary of Action Items
 _


   Date: 2 November 2009

ScribeNick: ArtB

Scribe: Art

Agenda Review

   AB: Agenda is
   [9]http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_Nov
   ember_2
   ... any change requests?
   ... the agenda includes some specs that will not be on the agenda

  [9] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday. 
2C_November_2


   BS: when does widgets meet with DAP?

   AB: today 15:30-16:30

   BS: on a recent call, we talked about widgets and html5 and caching
   ... think this is something we need to state
   ... eg where do we define that
   ... we don't have to take it now but should figure out who are the
   right people to chat

   AB: can you take an action to define the problem statement?

   BS: I'm not that familiar with that subject

   MC: I think the topic is well known

   BS: but has the interaction been stated or defined?

   MC: they just work together

   AB: I think we need to differentiate overlapping specs and
   synergistic usage of HTML5 specs

   MC: we don't create overlapping specs with HTML5

   AB: how do we want to handle this?
   ... put it on the agenda of a VC?

   MC: I think we've talked about this before
   ... we can talk about App Cache's uses by widgets

   AB: on the way to SFO I created
   [10]http://www.w3.org/2008/webapps/wiki/Coordination

 [10] http://www.w3.org/2008/webapps/wiki/Coordination

if a wua is online and doesn't offer caching, will the
   widget author complain?

   AB: this is intended to capture various "coordination points"

   
   [11]http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_No
   vember_2

 [11] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday. 
2C_November_2


   [ Art adds a new "Widgets and HTML5" section to the Coordination
   wiki ]

   MO: what about HTML4

   MC: we have a dependency on some parts of HTML5

   MO: at least one of the widgets specs references an HTML5 spec

   MC: yes, the TWI spec references Web Storage
   ... it does mean we can't progress to REC until Web Storage is more
   mature

   AB: re plans, I added a new Plans column to our PubStatus page
   [12]http://www.w3.org/2008/webapps/wiki/PubStatus

 [12] http://www.w3.org/2008/webapps/wiki/PubStatus

great

   AB: this provides useful data to the WG and the Public
   ... my expectation is that by the end of the day tomorrow, the Plans
   will have the best data we have for each of WebApps specs
   ... Hixie told me a week or so ago he expects Web Storage to be
   ready for LC in November
   ... I believe that spec already has a number of impls

   MC: that was true but isn't so any more given the new Structured
   Clones stuff that has been added
   ... with structued clones can now store more complex structues
   ... and it has no serialization syntax

   AB: we will discuss TWI spec tomorrow morn for 1.5 hours
   ... we should add Web Storage status and related discussions
   ... I'm not convinced we must have that dependency on Web Storage
   ... apparently Opera thinks otherwise

   MC: yes, that's true

Widget URIs

   AB: we decided not to include this spec on this week's agenda for a
   couple of reasons:

[13]http://dev.w3.org/2006/waf/widgets-uri/

 [13] http://dev.w3.org/2006/waf/widgets-uri/

   AB: 1. the LC comment period doesn't end until Nov 10
   ... 2. the Editor, Robin Berjon, is Chairing the DAP WG meeting on
   Nov 2-3
   ... 3. We discused this during our Oct 29 weekly call and Robin
   stated he would look for Larry this week

   LM: does anyone have any comments

   AB: this is a great idea
   ... I'm expect more comments and wanted to queue them up to take
   them all at once

   LM: my comments aren't from the TAG
   ... want to know if it meets the guidelines for a new scheme

   MC: I share some of your concerns

   AB: I'm OK with talking about it but it's highly l

CfC: to publish First Public Working Draft of File API spec; deadline Nov 10

[Arthur Barstow]

This is a Call for Consensus (CfC) to publish the First Public  
Working Draft (FPWD) of the File API spec, latest Editor's Draft at:


 http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

This CfC satisfies the group's requirement to "record the group's  
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to  
begin reviewing the document. The FPWD reflects where the group is on  
this spec at the time of publication; it does not necessarily mean  
there is consensus on the spec's contents.


As with all of our CfCs, positive response is preferred and  
encouraged and silence will be assumed to be assent.


The deadline for comments is November 10.

-Regards, Art Barstow

FW: OMTP BONDI 1.1 Candidate Release now available

[David Rogers]

As mentioned in the widgets meeting yesterday, comments welcomed:

 

From: public-device-apis-requ...@w3.org
[mailto:public-device-apis-requ...@w3.org] On Behalf Of David Rogers
Sent: 02 November 2009 17:30
To: W3C Device APIs and Policy WG
Subject: OMTP BONDI 1.1 Candidate Release now available

 

Dear all,

 

As I announced at the start of the DAP meeting, the OMTP BONDI 1.1
Candidate Release now available at http://bondi.omtp.org/1.1/CR/ .
Please find the release notes below:

 

 

BONDI 1.1 (Candidate Release) Release Notes

===

 

The BONDI 1.1 release define the composite specifications to allow web
applications (widget and web pages) to interoperate over BONDI defined
execution environment (widget runtime and web user agent). BONDI
technology enables web based content to access native device capability,
intermediated through a robust, but flexible security framework. There
are three elements to the 1.1 release

 

 - APIs: defines the JavaScript functions that expose the underlying
accessible device capability

 - Architecture and Security Specifications: defines the security layer
and required architectural components that insulate the web application
against risk

 - Compliance: define the compliance process that allows a widget
runtime or web user agent to declare compliance against the BONDI
specifications

 

 The BONDI 1.1 release differs from the 1.0 release in the following
important ways

 

 APIs

 

  - Messaging Events are supported.

  - Binary Messaging Support.

  - Detailed and consistent filtering of PIM info and comm logs.

  - Maps replaced with specific data types.

  - More attributes for PIM elements and messaging.

  - UI Settings management added.

  - Camera API redesigned.

 

  Architecture and Security

  -

  - Widgets use of requestFeature().

  - Features, sub-features, aggregate Features, and associated
clarification of requestFeature()

  - Minor clarification to processing of multi-valued attributes in the
definition of the policy model in A&S appendices

  - IRI vs URI changes

  - Improving use and consistency of terminology for "launch" "invoke"
"instantiate" etc with respect to Widgets.

  - B.4.1 Widget Subject Identity issues

  - Network access features

  - Updates to W3C document references

  - Change Definitions and perhaps other sections to be normative.

  -flat structure of Web IDL

- "module" statement has no semantics in BONDI

  - "implements" Web IDL keyword is used to define the hierarchy of
instantiations

  - "\def-instantiated" keyword in widl is used to specify upon which
feature the interface may be instantiated

  - Feature-sets are used to group features

  - New device capabilities

   - messaging.binary.send

   - messaging.mms.subscribe

   - messaging.sms.subscribe

   - messaging.binary.subscribe

   - ui  

   

   

  Compliance

  --

  - Process document

   - Compliance process document amended

  - Compliance Matrix

- Deleted the empty Policy & Widget Examples
spreadsheets.

- Deleted Device Capabilities List in the Security
Policy Language spreadsheet

- Re-formatting to HTML in progress

  - Fixes have been applied to requirement numbering and cross
referencing

  - Improvements the test coverage have been made

   

   

 Release Process

 ===

 A BONDI candidate release is made publically available for 30 days in
order to elicit public feedback.

 

For 1.1 the consultation phase will start on November 2nd 2009,
therefore feedback must be received by 2nd December 2009.

 

 

Thanks,

 

 

David.

 

David Rogers
OMTP Director of External Relations 

 

[Widget: Warp] - license attribute

[SUZANNE Benoit RD-SIRP-ISS]

All,
Reviewing the spec there is no access to the License  attribute. Shouldn¹t
it be added in the liste of the accessible attributes?

Best Regards, Benoit



Benoit  Suzanne
Orange Widgets Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM
benoit.suza...@orange-ftgroup.com


<><>

ISSUE-110 (code-point conversion): Should we remove the code-point conversion from the D3E spec? [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-110 (code-point conversion): Should we remove the code-point conversion 
from the D3E spec? [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/110

Raised by: Charles McCathieNevile
On product: DOM3 Events

The suggestion is that the conversion from character to codepoint doesn't 
belong in DOM 3 Events, since it needs to be available all over the place and 
is either a short bit of JS code, or should be fixed deeper in the language.

OAuth protocol flow diagrams

[=JeffH]

oauth-protocol-flow-diagrams
http://identitymeme.org/archives/2008/10/22/oauth-protocol-flow-diagrams/

http://identitymeme.org/doc/draft-hodges-oauth-05-figures.txt



HTH,

=JeffH

Multitouch @TPCA 16:30-17:00

[Charles McCathieNevile]

Hi folks,

we are adding a discussion of mulit-touch events (going back to some  
really old issue from webapis' first meeting in 2006) tothe agenda. In the  
APIs room, 4.30-5 pacific time, irc://irc.w3.org:80/webapps


Agenda to be updated now -  
http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Tuesday.2C_November_3


cheers

--
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: [FileAPI] Latest Revision of Editor's Draft

[Adrian Bateman]

On Tuesday, November 03, 2009 10:07 AM, Arun Ranganathan wrote:
> Adrian Bateman wrote:
> > On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
> >> Are you concerned about security bugs in the feature design or in
> >> the implementation?
> >
> > Mostly in the implementation - it increases the surface area to be
> > concerned about and there might be a different approach.
> 
> This feedback as a potential implementor is important :-)
> 
> 1. Can you give us an example of an exploit, or expand on your
> concerns?

If you look through the bugs reported (and fixed) in the Firefox jar: scheme 
handler many of them revolve around mishandling origin. The file urn is 
obviously simpler and also currently refers to a file that the user had to 
select. However, in future this might be used as part of a larger API that 
allows certain web sites to access certain files/folders. A vulnerability might 
involve leaking the URN from one origin to another allowing a site to read a 
file it shouldn't have access to.

> 2. From an implementation perspective, do you care whether we define a
> scheme (such as filedata:) or reuse something like urn:uuid:[UUID] ?
> Are there any barriers with respect to either one?

At first glance, I imagine filedata: would be easier for us to implement but I 
haven't researched this yet - I will ask the question. I wonder from a spec 
perspective whether reusing urn:uuid: might cause problems with this being 
overloaded for different uses in future.

Cheers,

Adrian.

Re: [FileAPI] Latest Revision of Editor's Draft

[Arun Ranganathan]

Adrian Bateman wrote:

On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
  

On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
 wrote:


On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
  

But like Arun, I suspect that this feature is the most controversial
in the spec. Apple expressed concern about having a string represent
a
handle to a resource, and when we talked to Microsoft they briefly
mentioned that they has concerns about this feature too, though I
don't know specifically what their concerns were.


The main concern I had was whether the URN feature was a must have
for v1 given Arun's desire that this be the simplest spec that we could
then build on later. Implementing a new protocol handler is more
complex than just supporting the API part, for us anyway.

I am also concerned about introducing new origin semantics - in the
past this has been a source of security bugs and so I question whether
we need to rush into this part (I accept the use case is valuable but
I'm not sure it is initially essential).
  

I'd really like to try to keep it in version 1. One of the use cases
we hear most often for this API is for uploading images. For example
to photo management sites like Flickr, but also for profile pictures
on sites like twitter. In both these cases it's possible to use
data-uris, but that will most likely result in the several copies of a
several-MB-sized data-uris living in memory. I think the situation
might be even worse in IE which if recall correctly there's some
fairly low limits on how big data-uris can be (is this correct?).



There is a limit on the size of data-uris in IE8 (32K I think). I expect 
addressing this will be a higher priority than a new handler but I agree that 
copying around large strings is problematic.
  


FWIW, the specification makes a provision for URL length limitations in 
certain user agents, so that a file (as a Data URL) that exceeds a 
URL-length limit will force an ENCODING_ERR when the readAsDataURL 
method is called on a FileReader object. 
  

Are you concerned about security bugs in the feature design or in the
implementation?



Mostly in the implementation - it increases the surface area to be concerned 
about and there might be a different approach.
  


This feedback as a potential implementor is important :-)

1. Can you give us an example of an exploit, or expand on your concerns?

2. From an implementation perspective, do you care whether we define a 
scheme (such as filedata:) or reuse something like urn:uuid:[UUID] ? Are 
there any barriers with respect to either one?



This isn't something I feel really strongly about. I imagine that when we look 
at implementing this we will start with just the API part and look at the URN 
handling separately.

  


This is in fact pretty much the approach we have taken with Firefox 3.6 
(currently in beta).


-- A*

Re: [cors] unaddressed security concerns

[Tyler Close]

I was just catching up on email and thought it might be useful to
respond to this one even though it's a couple weeks old now, since in
general the group seems to want more examples.

On Mon, Oct 12, 2009 at 7:19 AM, Maciej Stachowiak  wrote:
> As a side note, I should add that Tyler's scenario would be much simpler
> overall if printer.example.net used a grant of read access to the photo it
> wants to print on storage.example.org, instead of granting write access to a
> new location.

In this scenario, photo.example.com has the opportunity to take the
role of attacker in a CSRF-like attack. In the legitimate case,
photo.example.com is expected to send a URL to printer.example.net
which identifies the photo to be printed, such as
. In the attack case,
photo.example.com could send the URL that identifies the
printer.example.net client list, such as
. Consequently,
photo.example.com receives a print out of the printer.example.net
client list, instead of a photo printout.

> Or it can just ask photo.example.com to read the photo from
> storage.example.org and send the actual data. Either of these much less
> abusable than writing, and would be a safer approach, whether or not the
> overall design depends on secret tokens. The grant of read access can be
> one-time or time-limited if necessary. Thus, I think the scenario is
> somewhat contrived. Likely cross-site interactions would not involve such a
> complex process to transfer data. The root of the vulnerability in Tyler's
> scenario is writing in a shared namespace to transfer data, instead of
> simply granting read access to the existing copy, or transferring the actual
> data bits.

The semantics of the request, read versus write, are not relevant to
the attack. As Maciej explained in the TPAC meeting today, the actual
problem occurs when a request is composed using data received from 2
or more sites. As an historical note, it's interesting to observe the
initial misstep here and so conjecture that web developers may also
misunderstand the dangers and so use CORS-with-Origin in an insecure
way.

A request composed from data received from 2 or more sites should be a
common pattern in any *cross-origin* application. It's the nature of
the problem space. There's no need for examples to be complicated to
demonstrate the problem. If people find Maciej's example simpler, it
demonstrates the vulnerability just as well.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Re: TransAnn: LCWD#3 of Widgets 1.0: Packaging and Configuration published 29 October

[Marcos Caceres]

Hi All,

Phillips, Addison wrote:

Thank you, Arthur. We will review this as soon as possible.


FYI, using ITS is no longer at risk :) However, it is still an optional 
feature for a user agent to implement.


Also, we are still gathering implementation feedback on the i18n model, 
but it seems that some vendors have implemented it and it works well. 
So, a huge thanks to i18n Core for helping us specify that important 
feature!


We again encourage i18n Core to check it over and make sure it's all fine.

To make it easy to review, the relevant sections are:

[1] 
http://dev.w3.org/2006/waf/widgets/#internationalization-and-localization


[2] 
http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget-


[3] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content

[4] 
http://dev.w3.org/2006/waf/widgets/#step-5--derive-the-user-agents-locale


[5] 
http://dev.w3.org/2006/waf/widgets/#step-7--process-the-configuration-docume 



We are really looking forward to your feedback.

Kind regards,
Marcos

RE: [FileAPI] Latest Revision of Editor's Draft

[Adrian Bateman]

On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
> On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
>  wrote:
> > On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
> >> But like Arun, I suspect that this feature is the most controversial
> >> in the spec. Apple expressed concern about having a string represent
> >> a
> >> handle to a resource, and when we talked to Microsoft they briefly
> >> mentioned that they has concerns about this feature too, though I
> >> don't know specifically what their concerns were.
> >
> > The main concern I had was whether the URN feature was a must have
> > for v1 given Arun's desire that this be the simplest spec that we could
> > then build on later. Implementing a new protocol handler is more
> > complex than just supporting the API part, for us anyway.
> >
> > I am also concerned about introducing new origin semantics - in the
> > past this has been a source of security bugs and so I question whether
> > we need to rush into this part (I accept the use case is valuable but
> > I'm not sure it is initially essential).
> 
> I'd really like to try to keep it in version 1. One of the use cases
> we hear most often for this API is for uploading images. For example
> to photo management sites like Flickr, but also for profile pictures
> on sites like twitter. In both these cases it's possible to use
> data-uris, but that will most likely result in the several copies of a
> several-MB-sized data-uris living in memory. I think the situation
> might be even worse in IE which if recall correctly there's some
> fairly low limits on how big data-uris can be (is this correct?).

There is a limit on the size of data-uris in IE8 (32K I think). I expect 
addressing this will be a higher priority than a new handler but I agree that 
copying around large strings is problematic.

> Are you concerned about security bugs in the feature design or in the
> implementation?

Mostly in the implementation - it increases the surface area to be concerned 
about and there might be a different approach.

This isn't something I feel really strongly about. I imagine that when we look 
at implementing this we will start with just the API part and look at the URN 
handling separately.

Cheers,

Adrian.

[widgets] Definition of Instance was: Comments on Section 6 of the 18-Aug-2009 LCWD of A&E spec

[Marcos Caceres]

2009/9/15 Robin Berjon :
> On Sep 15, 2009, at 15:46 , Marcos Caceres wrote:
>>
>> Robin Berjon wrote:
>>>
>>> On Sep 13, 2009, at 23:23 , Marcos Caceres wrote:

 That is, because widget is assumed to be bound to the global scope of
 widget, we can test for it's presence without needing to qualify the
 object with it's global context (which, normally would be 'window'.).
 The problem is that what is meant by the "global object context" is
 not defined. We might need to leech some HTML5 terminology to make
 this more clear.
>>>
>>> Hmmm, I think that we can reference E262 for that, it ought to be enough
>>> (and then implementations normally make that window, but that's not for
>>> us to say).
>>
>> That might work. Nothing in WebIDL?
>
> Not that I know of. The way SVG Tiny 1.2 worked its way around that 
> dependency was by referring to the document's defaultView instead:
>
>  http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window
>
> I think we could do the same.
>
>>> One thing I'm not sure about: in the start file only?
>>
>> Good point.
>
> I guess we need something roughly saying "any JS global context that is also 
> a widget execution context".
>

The "widget instance" definition needs to be crystal clear as it is
effectively the definition of a widget instance makes or breaks W3C
widgets, IMO (and testing is showing that this is a massive interop
issue!): Without a clearly defined for an instance concept, storage,
cookies, view modes, etc.  wont work in an interoperable manner.

I can't stress enough how fundamental this definition is to the
architecture of widgets (I know, I'm getting all dramatic, but hear me
out:)).

I'm trying to bring together the concepts of DefualtView, ViewPort,
Window, Document, etc. here and these interfaces/things MUST be part
of this definition. Without those concepts, a widget instance is just
fluff. However, the terminology is really killing me here... so I'm
just going to list the requirements:

1. Given a widget package, I can instantiate multiple instances of
that widget.

So, from clock.wgt in can instantiate N instances. For example, one
can create a separate instance of the widget  for Boston, New York,
Madrid, Santa Clara, etc.

2. The storage areas are not shared and are protected from other
widgets of the same ilk.

So, for example, setting the location of the Boston clock does not
affect any of the other clocks.

3. Widget instances can be locally "navigated", meaning that the files
inside the widget can be hyper-linked. Navigating to a resource
outside the widget package is not allowed, but iframes certainly are.

So if I have a widget with the following files: a.html, b.html,
c.html. Then I should be able to navigate them as normal:

a.html

 Go to B

b.html

 Go to C

c.html

http://foofum.com"; />
 Go to A 

4. preferences are accessible by all documents or an instance.

So if I have a widget with the following files: a.html, b.html,
c.html. All those files can access the same preferences.

5. Instances are clonable.

It should be possible to deep-clone an instance, though the spec does
not need to say anything about this. For example, if I have an
instance of a clock widget, I should be able to clone it to have
another clock widget already set to whatever locale the first widget
was set to.

6. Styles must be applicable on a per viewport level so that widgets
can be locked into either portrait, landscape, or free to change
orientation.

For example, if I navigate to a page with a video (intro.html), I
should be able to re-orientate the widget into landscape mode. Then
swap the widget to a portrait mode when it is navigated to menu.html.

That is how I want widgets to work. Plain and, um, simple. The
definition of a widget instance needs to allow all the things I listed
above.

--
Marcos Caceres
http://datadriven.com.au



-- 
Marcos Caceres
http://datadriven.com.au

Re: More CORS Tuesday afternoon...

[Adam Barth]

On Tue, Nov 3, 2009 at 7:39 AM, Anne van Kesteren  wrote:
> On Mon, 02 Nov 2009 23:46:30 -0800, Adam Barth  wrote:
>> It is somewhat frustrating to be unable to participate in this forum.
>
> Any particular reason you cannot be here? Would be nice if you could come.

It's really tight, but I'm going to try to be there.

Adam

Re: More CORS Tuesday afternoon...

[Maciej Stachowiak]

On Nov 2, 2009, at 11:46 PM, Adam Barth wrote:


It is somewhat frustrating to be unable to participate in this forum.


We missed having you there on Monday. :-(

 - Maciej



Adam


On Mon, Nov 2, 2009 at 6:30 PM, Charles McCathieNevile > wrote:

Hi folks,

http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Tuesday. 
2C_November_3


We have included a one hour slot in the agenda 15:15-16:15 to  
continue the

CORS discussion on the Confused Deputy problem.

Given the current diversity of views I am expecting to determine  
points of
agreement, the points of disagreement, and possible strategies to  
follow

(drop the spec, ignore the issue, educate authors, etc) and expected
consequences. Convincing others that some course of action is right  
falls

outside the scope of this time-limited discussion.

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

[WARP] local addresses, UPnP, comments

[Marcin Hanclik]

Hi,

Following our yesterday's discussion about specification of the local addresses 
within WARP I have the following proposal.
Additionally, below there are few comments to the existing text.
Change from:

origin
An IRI attribute that defines the specifics of the access request that is 
requested. Additionally, the special value of U+002A ASTERISK (*) MAY be used. 
This special value provides a means for an author to request from the user 
agent unrestricted access to network resources. Only the scheme and authority 
components can be present in the IRI that this attribute contains ([[!URI]], 
[[!RFC3987]]).

subdomains
A boolean attribute that indicates whether or not the host component part of 
the access request applies to subdomains of domain in the origin attribute. The 
default value when this attribute is absent is false, meaning that access to 
subdomains is not requested.

to

origin
One of:
- an IRI attribute that defines the specifics of the access request that is 
requested. Or
- the special value of U+002A ASTERISK (*). This special value provides a means 
for an author to request from the user agent unrestricted access to network 
resources. Only the scheme and authority components can be present in the IRI 
that this attribute contains ([[!URI]], [[!RFC3987]]).
- the special value of "local" (%x6c.6f.63.61.6c in ABNF). This special value 
provides a means for an author to request from the user agent unrestricted 
access to local network resources. The addressing of the resources relies 
primarily on IP addressing of hosts. It is up to the underlying network which 
version of the IP protocol is used and how local network is identified.

subdomains
A boolean attribute that indicates whether or not the host component part of 
the access request applies to subdomains of domain in the origin attribute. The 
default value when this attribute is absent is false, meaning that access to 
subdomains is not requested. This attribute applies only to the origin 
attribute values that rely on the DNS.

The above abstract specification of locality shall allow for inclusion of 
IPv6,e.g. [1].

Additional comments
1. It should be clarified that the subdomains attribute applies only when the 
host is specified using DNS and not based on IP address. In other cases it 
shall be skipped.

2. " Only the scheme and authority components can be present in the IRI"
"://" should be added between scheme and authority to make IRI [2] (this was 
discussed already in BONDI, although it is not yet in the related spec there).

3. Attributes section uses "authority" whereas the processing model section 
uses "iauthority". There the attributes section shall be corrected.

Thanks,
Marcin


[1] http://tools.ietf.org/html/rfc4193#section-4.6
[2] http://tools.ietf.org/html/rfc3986#section-3

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com




Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is 
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or 
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by 
responding to this e-mail. Thank you.

Re: More CORS Tuesday afternoon...

[Anne van Kesteren]

On Mon, 02 Nov 2009 23:46:30 -0800, Adam Barth  wrote:

It is somewhat frustrating to be unable to participate in this forum.


Any particular reason you cannot be here? Would be nice if you could come.

Cheers,


--
Anne van Kesteren
http://annevankesteren.nl/

Re: Adding a note to DOM2 Views

[Ian Jacobs]

On 3 Nov 2009, at 6:14 AM, Anne van Kesteren wrote:


Hi Ian,

Yesterday the WebApps WG discussed the fate of the views concept and  
we decided that it was not worth keeping the theoretical concept  
around because in practice a lot of the APIs designed are not taking  
it into account and implementations are not interested in  
implementing support for it (or are in the process of removing the  
limited support they have). The interfaces would of course still be  
supported but you would always get the same global object and  
document, regardless of the media the document is being used in.


The idea is that the CSSOM View Module will obsolete DOM2 Views in  
due course, but we thought it would make sense to alert potential  
implementors that they should not be spending time on implementing  
the views concept of DOM2 Views by adding a note to the  
recommendation much like the CSS WG has done with CSS 2.0. We were  
wondering what the process for adding such a note might be.



Please send a request to my attention, cc webreq, with the text you  
would like to appear in the document.

Thanks for letting me know,

 _ Ian

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447

Seeking Comments on LCWD of Guidelines for Web Content Transformation Proxies; 6 November deadline

[Arthur Barstow]

WebApps has been asked to review the following LCWD by the Mobile Web  
Best Practices WG:


 Guidelines for Web Content Transformation Proxies 1.0
 http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/

If you have any comments, please send them - by November 6 at the  
latest - to:


 public-bpwg-comme...@w3.org
 http://lists.w3.org/Archives/Public/public-bpwg-comments/

-Regards, Art Barstow

Begin forwarded message:


From: ext Francois Daoust 
Date: November 3, 2009 12:27:03 AM PST
To: Tim Berners-Lee , Noah Mendelsohn  
, Paul Cotton  
, Sam Ruby ,  
Maciej Stachowiak , Steven Pemberton  
, "Barstow Art (Nokia-CIC/Boston)"  
, Charles McCathieNeville  
, Deborah Dahl technologies.com>, Chris Lilley , Mary Ellen Zurko  


Cc: "cha...@w3.org" 
Subject: [Reminder] Guidelines for Web Content Transformation  
Proxies: Last Call Working  Draft


Dear chairs,

This is a reminder that the Last Call review period of the Guidelines
for Web Content Transformation Proxies ends at the end of the week. We
would be grateful if the group whose chairs are listed in the "To"  
field
could discuss and review the document in their groups. If a group  
would
like to review the document but needs additional time, please let  
us know.


The document is available for review at:
  http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/

More information on the topics covered by the document that your group
might be interested to review can be found in the transition
announcement below.

Thanks,
Francois Daoust,
Staff contact for the Mobile Web Best Practices Working Group.


Francois Daoust wrote:
Hello TAG, HTML WG, XHTML2 WG, WebApps WG, HCG, Web Security  
Context WG

Chairs,

This is a transition announcement for the Last Call Working Draft  
of the
Guidelines for Web Content Transformation Proxies, published today  
at:

http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/

This set of guidelines for Web Content Transformation proxies  
(i.e. non

transparent HTTP proxies) was developed by the W3C Mobile Web Best
Practices Working Group to address some of the needs identified in
particular on mobile networks, in accordance with the working group's
charter [1].

The document was published as Last Call a year ago under the title
"Content Transformation Guidelines", and you had been invited to  
review

the specification back then. The Working Group received many comments
during the last call review period, and has been working on  
updating the
guidelines since then. The group believes it has now addressed all  
the

comments and decided to publish a second Last Call [2]. Status ref.
patent policy is available at [3].

This new Last Call review period extends until 6 November 2009,  
and we
would be grateful if your group could review the document once  
more, in

particular:
 * for the TAG, since the document still relates to its issue
genericResources-53 and its accompanying finding:
 http://www.w3.org/2001/tag/doc/alternatives-discovery
 * for the HTML and XHTML2 Working Groups, since the document  
makes use
of the (X)HTML link element to give hints on content  
transformation proxies
 * for the WebApps Working Group, since the document applies to  
proxies

that may receive requests initiated by XmlHTTPRequest objects.
 * for the HyperText CG, as the official point of liaison with the  
Open

Mobile Alliance which might want to submit a review on the document
given its implications on the mobile ecosystem.
 * for the Web Security Context WG, for the section on HTTPS link
rewriting.

(The Working Group is also requesting a review from the IETF HTTPBis
Working Group).

If your group wants to submit a review but is unable to provide it in
that timeframe, please let us know so that we can determine a  
possible

extension of the review period.

The working group has just sent official replies to the commenters of
the previous Last Call. At this point of time, there are no formal
objections.

Thanks,
Francois Daoust,
Staff Contact of the Mobile Web Best Practices Working Group

[1] http://www.w3.org/2008/06/MWBP-WG-charter.html#deliverables
[2] http://www.w3.org/2009/09/29-bpwg-minutes#item05
[3] http://www.w3.org/2004/01/pp-impl/37584/status

Re: Web Data APIs

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
FWIW, in the server side JavaScript realm, there has been growing
interest in following the WebSimpleDB API as an generic API for
interchangeable data storage systems, to provide a consistent
interface for interacting with various DBs like MongoDB, JavaScriptDB,
CouchDB, and even to some degree relational DBs (of course most DBs
provide additional DB-specific funcionality). We are closely following
the development of this API, since this is such an important part of
JavaScript applications on the server, but I am in support of what I
see so far.
Thanks,
Kris

Jonas Sicking wrote:
> On Sat, Oct 31, 2009 at 10:25 AM, Pablo Castro
>  wrote:
>> We’ve been looking at the web database space here at Microsoft, trying to
>> understand scenarios and requirements. After assessing what was out
there we
>> are forming an opinion around this. I wanted to write to this group to
share
>> how we think about the space, what principles we try to apply, and to
>> discuss specifics.
>>
>> The short story is that we believe Nikunj’s WebSimpleDB proposal, which
>> basically describes a minimum-bar web database API and enables a whole set
>> of diverse options to be built on top, is the right thing to do.
>>
>> During the last couple of weeks we have been talking with various
folks from
>> Mozilla and Oracle and iterating over details of the WebSimpleDB draft. In
>> the process it has become clear that we all share the same high-level
>> expectations on the scope and capabilities of this API, and Nikunj has
been
>> hard at work making changes to the draft to keep up with them. I’ll
touch on
>> a few details below, but bear in mind that several of them are already in
>> the process of being addressed.
>>
>> We would love to hear feedback, requirements, specific application
>> scenarios, etc. We want to make progress quickly and get experimental
>> implementations going to ensure that as we explore we stay grounded, with
>> things that are implementable.
>
> Hi Pablo,
>
> Sorry about the slow response.
>
> While there isn't such a thing as a official mozilla position, this
> very closely (scaringly so ;) ) matches the thinking of most people
> that have participated in the database discussions here. We've had
> conversations with both Oracle and Microsoft, as well as with both
> javascript developers and people that have worked with databases on
> the web, such as the CouchDB people.
>
> >From basically everywhere we've gotten the feedback that a low-level
> API in the style of WebSimpleDB is preferrable to the SQL based API in
> the WebDatabase drafts. The main argument we got for an SQL based API
> was "we don't care what we get, we just want something, though if we
> got to pick a SQL API is not what we'd pick".
>
> So our recommendation is to start with WebSimpleDB and iterate on
> that. The first thing we should do is to see where we can simplify
> things. For example foreign keys, queues and database versions seems
> like something that can probably be removed.
>
> We also got the feedback that something that's more event-based rather
> than callback based was preferable (which came as a surprise to most
> of us). Personally I think this change isn't as urgent, but I do think
> it's something that should be fixed before implementations start to
> happen.
>
> As I'm reading the latest editor drafts I see that some of these
> changes have already been made, which is great to see. I need to
> review these changes more in detail, but in the meantime I wanted to
> let the WG know about what activities have been going on at mozilla.
>
> / Jonas
>
>

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkrwPK0ACgkQ9VpNnHc4zAx+mgCgi9Da29Bp/q4Ua5h6/3rNRBTq
8EAAniVx3Le1aD7M/1J2g4+8K5NiqqYg
=Kzmx
-END PGP SIGNATURE-

Adding a note to DOM2 Views

[Anne van Kesteren]

Hi Ian,

Yesterday the WebApps WG discussed the fate of the views concept and we  
decided that it was not worth keeping the theoretical concept around  
because in practice a lot of the APIs designed are not taking it into  
account and implementations are not interested in implementing support for  
it (or are in the process of removing the limited support they have). The  
interfaces would of course still be supported but you would always get the  
same global object and document, regardless of the media the document is  
being used in.


The idea is that the CSSOM View Module will obsolete DOM2 Views in due  
course, but we thought it would make sense to alert potential implementors  
that they should not be spending time on implementing the views concept of  
DOM2 Views by adding a note to the recommendation much like the CSS WG has  
done with CSS 2.0. We were wondering what the process for adding such a  
note might be.


Kind regards,


--
Anne van Kesteren
http://annevankesteren.nl/