Re: XHR without user credentials

[Adam Barth]

On Fri, Jun 12, 2009 at 7:17 PM, Mark S. Miller wrote:
> On Fri, Jun 12, 2009 at 7:03 PM, Adam Barth  wrote:
>>
>> > What server side behavior difference do you expect between messages with
>> > no Origin and messages with "Origin: null".
>>
>> You'll have to include Origin: null for POST requests.  You should
>> include it for GET as well.
>
> Does "have to" == "MUST"?

That's what's required (at the MUST level) by draft-abarth-origin.

> On credential-free GET, why "should" rather than "MUST"?

Because draft-abarth-origin doesn't require it at the MUST level.

> Isn't your answer above only about client (user agent) behavior? I'd still
> like understand what the recommended/expected difference in server behavior
> should/might be depending of whether Origin is absent or null. Thanks.

Suppose GuestXHR doesn't send an Origin header for any requests and a
server uses the algorithm in draft-abarth-origin to mitigate CSRF
attacks.  Now, an attacker can mount a CSRF attack against the server.

Adam

Re: XHR without user credentials

[Mark S. Miller]

On Fri, Jun 12, 2009 at 7:03 PM, Adam Barth  wrote:

> > What server side behavior difference do you expect between messages with
> no Origin and messages with "Origin: null".
>
> You'll have to include Origin: null for POST requests.  You should
> include it for GET as well.
>

Does "have to" == "MUST"?
On credential-free GET, why "should" rather than "MUST"?

Isn't your answer above only about client (user agent) behavior? I'd still
like understand what the recommended/expected difference in server behavior
should/might be depending of whether Origin is absent or null. Thanks.

-- 
   Cheers,
   --MarkM

Re: XHR without user credentials

[Adam Barth]

2009/6/12 Mark S. Miller :
> On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth  wrote:
>> On Mon, Jun 8, 2009 at 5:59 PM, Mark S. Miller wrote:
>> > For concreteness, for the Origin header for these requests, I'll start with
>> > the simplest proposal that meets my goals: no Origin header for either same
>> > origin requests or cross origin requests. But for both the same origin case
>> > and the cross origin case, I am actually indifferent between no Origin
>> > header and an "Origin: null" header. If there's a reason for the "Origin:
>> > null" header, I'm happy with that.
>>
>> Please send "Origin: null" in these cases.  The problem with omitting
>> the origin header is that the server can't tell if the request comes
>> from a legacy client or if the header was removed in transit.
>
> * Why does this argument not also apply to credential-free GuestXHR requests 
> back to the same origin?

It does.  If you want to send a credential-free XHR, please use
Origin: null.  That is, in fact, what the null means.

> What server side behavior difference do you expect between messages with no 
> Origin and messages with "Origin: null".

You'll have to include Origin: null for POST requests.  You should
include it for GET as well.

> This difference does not affect much anything I care about, so I'm still 
> happy to spec it as we agreed.

Great.

> I'd just like to understand the rationale. It makes more sense to me for all 
> GuestXHR requests be labeled the same way regardless of the origin of the 
> originating page. Either same way seems more coherent to me than the current 
> agreement.

Yes.  I agree.  They should all have Origin: null.

Adam

Re: XHR without user credentials

[Mark S. Miller]

On Mon, Jun 8, 2009 at 2:44 PM, Anne van Kesteren  wrote:

> I sort of like the idea of having a new (named) constructor or maybe have
> the constructor take an argument to indicate credentials are supposed to be
> omitted. This would also allow us to drop the withCredentials flag.
>

Starting with this new GuestXMLHttpRequest constructor, I am working on a
simpler cross-origin resource sharing proposal. (My working name is
"cors-lite". Thanks to Jasvir for inspiring the pun.) Some questions:

* What drafts need revision to bring this about? Obviously, cors itself. And
Adam's IETF I-D. Also in seems, <
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/>. Is this the right version
to start from? What other documents might need coordinated revision?

* The existing XHR2 draft above specifies XMLHttpRequest in WebIDL as

[Constructor]
interface XMLHttpRequest : XMLHttpRequestEventTarget {
//... API of instances...
};

In the favored style of WebIDL use, should I declare GuestXMLHttpRequest to
inherit from XMLHttpRequest, or should I move the above API to a shared
AbstractXMLHttpRequest and have both XMLHttpRequest and GuestXMLHttpRequest
inherit from it? AFAICT, these should result in identical language bindings,
so it's only a question of specification easthetics.


On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth  wrote:

> On Mon, Jun 8, 2009 at 5:59 PM, Mark S. Miller wrote:
> > For concreteness, for the Origin header for these requests, I'll start
> with
> > the simplest proposal that meets my goals: no Origin header for either
> same
> > origin requests or cross origin requests. But for both the same origin
> case
> > and the cross origin case, I am actually indifferent between no Origin
> > header and an "Origin: null" header. If there's a reason for the "Origin:
> > null" header, I'm happy with that.
>
> Please send "Origin: null" in these cases.  The problem with omitting
> the origin header is that the server can't tell if the request comes
> from a legacy client or if the header was removed in transit.
>

* Why does this argument not also apply to credential-free GuestXHR requests
back to the same origin? What server side behavior difference do you expect
between messages with no Origin and messages with "Origin: null". This
difference does not affect much anything I care about, so I'm still happy to
spec it as we agreed. I'd just like to understand the rationale. It makes
more sense to me for all GuestXHR requests be labeled the same way
regardless of the origin of the originating page. Either same way seems more
coherent to me than the current agreement.



> Also, the Referer header should be on your hit-list as a credential.  :)
>


Absolutely! Good catch. Thanks.
* Are there any other hidden credentials that we may have overlooked?


-- 
   Cheers,
   --MarkM

Re: "send data using the Web Socket" and UCS-2

[Ian Hickson]

On Tue, 2 Jun 2009, Jeff Walden wrote:
>
> The specification should say what happens when 
> WebSocket.postMessage(data) is called where data is not structurally 
> correct UTF-16 -- lone surrogates, backwards surrogates, and any similar 
> structural errors I might have forgotten.  The IETF protocol 
> specification implicitly assumes the data can be encoded as UTF-8 when 
> this may not be the case.  I mentioned similar issues in #whatwg 
> recently for DOM APIs in general, possibly to be handled by WebIDL. 
> Since this instance of that problem explicitly requires interpretation 
> of a bogus DOMString and can't be described as storing a sequence of 
> opaque 16-bit numbers for later retrieval, I think it's worth raising 
> this concern specially, and I would like precise behavior specified 
> before this proceeds to a finalized state.

I've made WebSockets catch unpaired surrogates and throw an exception.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Public call for prior art on Widget updates

[Rigo Wenning]

http://www.w3.org/2009/03/widgets-pag/cfpa

The W3C hereby issues a call for prior art on US patent 5,764,992 [1] 
that may apply to the Widgets updates specification[2]. Pursuant to 
its rights under W3C's Patent Policy, Apple Inc. has excluded all 
claims of the aforementioned patent from the W3C Royalty-Free License 
commitment. The PAG seeks information about software update systems 
available before June 1995 that offer a viable solution that may apply 
to the use of updates in Widgets. People who wish to provide feedback 
should refer to the call[3] for more information or write back to 
public-widgets-...@w3.org

Please distribute this call for prior art as widely as possible.

1.http://is.gd/101wZ
2.http://www.w3.org/TR/2008/WD-widgets-updates-20081007/
3.http://www.w3.org/2009/03/widgets-pag/cfpa.html

Rigo Wenning
Widgets update PAG chair
W3C Legal counsel


signature.asc
Description: This is a digitally signed message part.

Comments on Widgets spec

[Dominique Hazael-Massieux]

Hi,

5.3 Zip Relative Paths has the following bugs:
 * the ABNF for zip-rel-path uses "localized-folder", but only
"locale-folder" is defined
 * the third rule for the conformance checker should be:
 "A CC must inform the author of any Zip relative paths whose length
exceed 120 characters" (rather than "bytes").

http://www.w3.org/TR/widgets/#conformance-checker-behavior4 seems to be
misplaced under 7.2 instead of 7.3

There are quite a few aspects that make a zip archive an invalid widget
described in the processing section, but which are not highlighted as
conformance checker requirements, e.g:
 * Step 1  labels an archive with a wrong media type as invalid
 * Step 2 adds as cause of invalidity "split"-zips, and encrypted-zips
(beyond the already noted requirements on version and compression
method)
 * requirements on the configuration file (XML well-formed, vocabulary
constraints)
(and probably more)

Dom

Reminder: June 19 deadline for comments re LCWD of Widgets 1.0: Packaging and Configuration spec

[Arthur Barstow]

This is a reminder that June 19 is the deadline for comments for the  
LCWD of the Widgets 1.0: Packaging and Configuration spec.


-Regards, Art Barstow


Begin forwarded message:


From: "Barstow Art (Nokia-CIC/Boston)" 
Date: May 28, 2009 1:58:47 PM EDT
To: public-webapps 
Subject: Request For Comments: Last Call WD of Widgets 1.0:  
Packaging and Configuration; deadline 19 June 2009

Reply-To: public-webapps 
Archived-At: 


Bcc: public-i18n-c...@w3.org, public-b...@w3.org, public-m...@w3.org
Reply-to: public-webapps@w3.org

On May 28 the Web Applications WG published a new Last Call WD of the
Widgets 1.0: Packaging and Configuration spec:

  

We welcome comments from all, particularly the I18N Core WG, Mobile
Web Best Practices WG and the Mobile Web Test Suites WG.

The deadline for comments is June 19. Comments after that date are
welcome but will not be included in this spec's Disposition of
Comments document.

-Regards, Art Barstow

P.S. Bcc was used to help reduce cross-posting. Please send all
replies to public-webapps@w3.org

[widgets] Draft Minutes from 11 June 2009 f2f meeting

[Arthur Barstow]

The draft minutes from the June 10 Widgets f2f are available at the  
following and copied below:


 

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before 18 June 2009 (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

11 Jun 2009

   See also: [2]IRC log

  [2] http://www.w3.org/2009/06/11-wam-irc

Attendees

   Present
  Art, Marcos, Benoit, Jere, Mike, David, Magnus, Laura, Robin,
  Dan, Richard, Josh, Marcin

   Regrets
   Chair
  Art

   Scribe
  Dan

Contents

 * [3]Topics
 1. [4]Process and LC
 2. [5]Anne's Comments
 3. [6]Process
 4. [7]Next f2f
 5. [8]WebApps in General
 * [9]Summary of Action Items
 _



ScribeNick: DKA

Scribe: Dan

Date: 11 June 2009

Process and LC

   Art: before we start looking at Anne's comments, 2 things.
   ... first thing: a go-through of the process document to discuss the
   relevant parts relating to last call and take a look at what the
   process document says.

   [looking at "last call announcement" in process document]

AB: Process doc 7.2 #2 says:

[[

Provide public documentation of all changes (both substantive
   and minor) to the technical report since the previous step. A
   substantive change (whether deletion, inclusion, or other
   modification) is one where someone could reasonably expect that
   making the change would invalidate an individual's review or
   implementation experience. Other changes (e.g., clarifications, bug
   fixes, editorial repairs, and minor error corrections) are minor
   changes.

]]

AB: the L10N model was the last part added to the P+C spec

... I would characterize the changes we agreed to make as
   "bug fixes"

... rather than substantive

   AB: [Read-through of relevant clause.]

   Benoit: we need to find out if the changes we've done are "bug
   fixes" or if it's breaking an existing implementation.

   Marcos: If we're fixing bugs in the spec then we might fix
   implementation.

   Robin: It's meant to leave room for [interpretation].

   Benoit: Is it possible to make a diff?

   Marcos: using HTML diff we can do that - a w3c tool.

   Art: One of our tasks is to - using these definitions - have a
   discussion about whether the changes we agreed to earlier this week
   are "substantive" or not.

   JS: In the case of the locale stuff we don't have anyone who's
   implemented a test suite.

   MS: Not sure that's valid because there could be someone who has not
   publicly disclosed their implementation.

   JS: The question is: can I "reasonably" expect that someone has
   implemented this?
   ... I would have thought someone trying to implement this would have
   complained [about locale] and would have complained

   AB: I completely understand what you're saying - but I can tell you
   that Nokia hasn't got that far. Would any other members - e.g. OMTP
   - go on record on what test cases they've created?
   ... Is it reasonable to expect that someone has done enough
   implementation of P&C such that if we make the changes we've agreed
   this week that the implementation would break?

   David: My initial read is "no."

   AB: If we agree that the changes are substantive then we have to go
   back to working draft.

   RB: You can go to a 2nd last call.

   MS: Yes that's true.

   [[minimum period was 3 weeks]

   DR: What's the change that's proposed?

   Marcos: We corrected some stuff in the internationalization
   processing. We changed the way the user agent language tags work.
   That's it.

   Jere: if we reconsider the change then we don't have this problem.

   Dan: but it's an important change.

   AB: Is it a bug fix?

   MS: No.

   AB: So what is a bug fix?

   Benoit: in a way it's a bug fix.

   AB: Mike why do you rule it out as a bug fix?

   MS: In a normal universe that would not be considered a bug fix.

   JS: How could someone reviewing it not have complained? Anyone who
   did a good job reviewing it would have noticed it.

   MS: We need to follow process. But we can do as Josh suggests - move
   forward on the assumption that nobody could have been effected by
   this change so they would have noticed the problem.

   AB: Let's remember that the last part of the document was the L10N
   part - and it [therefore] had some bugs.

   RB: And we did nothing to the spirit of the algorithm.

   MS: That's viable. We can explicitly document that [thought process]
   and move forward.

   PROPOSED RESOLUTION: The changes we've made so far to P&C are
   considered "bug fixes" (with regard to the process docume

[widgets] Draft Minutes from 10 June 2009 f2f meeting

[Arthur Barstow]

The draft minutes from the June 10 Widgets f2f are available at the  
following and copied below:


 

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before 18 June 2009 (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

10 Jun 2009

   [2]Agenda

  [2] http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009

   See also: [3]IRC log

  [3] http://www.w3.org/2009/06/10-wam-irc

Attendees

   Present
  Benoit, Mike, Josh, Jere, Robin, AndyB, Marcos, DanA, David,
  Laura, Marcin, Magnus, Kai

   Regrets
   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]A+E spec
 2. [6]A+E spec - again ...
 3. [7]Window Modes / Query spec
 4. [8]Testing
 * [9]Summary of Action Items
 _



ScribeNick: ArtB

Scribe: Art

   Date: 10 June 2009

trackbot, status?

This channel is not configured

   trackbot, associate this channel with #webapps

Associating this channel with #webapps...

trackbot, status?

This channel is not configured

ArtB: trackbut is confused

   Scribe+ David

A+E spec

ScribeNick: drogersuk

   AB: Agenda is API and Events
   ... we have several red block issues
   ... and there is a discussion related to storage

[10]http://dev.w3.org/2006/waf/widgets-api/

 [10] http://dev.w3.org/2006/waf/widgets-api/

   MC: To progress this, viewMode is not a big issue here

   AB: Let's go back to the start of the document. Is the abstract
   up-to-date?
   ... The title includes events but there aren't a whole lot of events

   MC: There are events

   JS: 3rd bullet point in abstract doesn't make sense

   MH pointed out some editorial issues in the abstract

   scribe: defined by... defines for example

   JS: requests in the 4th bullet should be request

   AB: What is the interface that supports the last bullet?
   hasFeature()?

   MC: Yes
   ... Perhaps we should concentrate on some of these issues rather
   than the editorial points

   AB: Are there any definitions we are missing?
   ... In section 4
   ... we've talked about nailing down origin

   MC: it isn't really relevant in this spec, because origin pertains
   to the storage interface and that already defines where you get
   origin from

   AB: So we can have this discussion when we discuss the storage
   attribute

   MC: As long as we have consensus in the group that each widget has
   its own storage and that storage cannot be accessed by other
   widgets..

   AB: We'll deal with this as we get to it in the document
   ... Section 5 begins with the block of the widget interface...

   JK: We need to define what is a feature etc.

   MC: Do we need a more technical definition than P&C?

   There was a discussion about how to define feature

[11]http://www.w3.org/TR/SVG11/struct.html#SwitchElement

 [11] http://www.w3.org/TR/SVG11/struct.html#SwitchElement

actually, this better:
   [12]http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement

 [12] http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement

AB: Back to section 4 - let's look at the first red block

We considered offering a video decoder as another
   example of a "feature" in addition to an API. While we decided not
   to list it as an example, this isn't because it isn't an example,
   but merely because we decided not to list a second.

MC: The first red block item covers some items that are
   not defined - e.g. viewMode

...viewMode should be in the window modes spec which is
   not written

AB: Robin agreed to be the editor of this

...obviously Robin has had higher priorities

AB: mediaquery and windowmodes were going to be two specs

MC: and I think they should be one

AB: We don't want a dependency on the CSS working group

MH: This is a question of timeline

AB: So what is the consensus?

It was agreed that there would be one spec for this

RESOLUTION: There will be one specification for
   windowmodes and mediaquery

MC: We need to align the attributes with the steps to
   remove the next red block

5.1 - viewMode attribute:

in mediaquery spec - feature is defined too

...we need an explanatory note here

MC: The text does not make sense



MC: The user agent makes the decision about the window
   mode display

...it is described in the P&C spec (lifecycle) and also in
   the windowmodes spec

AB: The sentence: "Upon instantiation" was removed#

The red block issue: this is a computed value was edited
   to change to editorial note. It is to be dealt with by the 

[widgets] Draft Minutes from 9 June 2009 f2f meeting

[Arthur Barstow]

The draft minutes from the June 9 Widgets f2f are available at the  
following and copied below:


 

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


-Regards, Art Barstow

   [1]W3C

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

  Widgets F2F Meeting
  09 Jun 2009

   [2]Agenda

  [2] http://www.w3.org/2008/webapps/wiki/ 
WidgetsLondonJune2009#Agenda


   See also: [3]IRC log

  [3] http://www.w3.org/2009/06/09-wam-irc

Attendees

   Present
  Benoit, Mike, Josh, Jere, Art, Robin, Marcos, AndyB, DanA,
  David, Laura, Marcin, Bryan, Magnus, Richard, Frederick,
  Thomas, SteveL

   Regrets
   Chair
  Art

   Scribe
  ArtB, Art, Bryan, Art, Mike, Dan

Contents

 * [4]Topics
 1. [5]Introductions
 2. [6]Confidentiality of Minutes
 3. [7]Agenda Tweaking
 4. [8]Packaging and Config spec
 5. [9]Localization
 6. [10]Localisation
 7. [11]Access Requests Policy
 8. [12]URI Scheme
 9. [13]P+C
10. [14]Updates
11. [15]Discussing Brian's input
 * [16]Summary of Action Items
 _

Introductions

   AB: Arve had a last minute cancelation and will not attend
   ... registered but not here yet: Paddy, Richard Tibbett, Jonathon,
   Nick and Ivan

Confidentiality of Minutes

   AB: all of the minutes will be Public
   ... any questions about that?

   [ None ]

Agenda Tweaking

   AB: Agenda:
   [17]http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda
   _Items
   ... we will start with P+C this morning
   ... talk about high priority issues
   ... from 13:00-15:00 today we will talk about Security Model
   vis-a-vis  and the WARP document

 [17] http://www.w3.org/2008/webapps/wiki/ 
WidgetsLondonJune2009#Agenda_Items


Packaging and Config spec

   AB: spec: [18]http://dev.w3.org/2006/waf/widgets/
   ... other than feature and L10N are there other hot topics?

 [18] http://dev.w3.org/2006/waf/widgets/

   MC: no not really

   AB: Henri's
   [19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/06
   99.html
   ... comment about clarifying purpose of feature
   ... I think the way we have documented feature in P+C is OK
   ... but there are questions about what a UA will do with the data
   ... what is our plan to specify the behavior?

 [19] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0699.html


Scribe: Art, Mike

Scribenick: MikeSmith

   ArtB: what work remains to be done for ?

   Marcos: I don't think anything more needs to be done.. it's
   specified.

   ArtB: Anybody disagree with that?

   Marcos: Biggest impact is on BONDI, so it matters most if it is OK
   as-is for them.
   ... I think it meets the BONDI use cases.

   Robin: If OMTP is OK with it, I'm OK with it.
   ... I'm happier with use cases that don't require it, because that's
   more Web-like.

   David: In the absence of a more proper security model, we still
   support this.
   ... We are happy for [the editors] to take the lead on this.

   Marcin: We just want it to be stable.

   ArtB: Is OMTP going to extend it after?

   Bryan: We may add some semantics, but we are not planning to add
   additional attributes.

   David: If we have a policy mechanism -- some way of regulating
   access for the user -- then this element is actually redundant.

   Marcos: So it really is more of a stop-gap for now

   ArtB: Anybody else have anything to add on this topic?

   PROPOSED RESOLUTION: The group agrees that the  element as
   defined in the LC WD is complete.

   ArtB: Any objections?

   [none]

   RESOLUTION: The group agrees that the  element as defined
   in the LC WD is complete.

   Marcos: [discussing issue of case sensitivity in localization
   system]

   [discussion about mailing-list discussions from last couple days]

   Marcin: [talking specifically about recent BONDI decisions around
   requestFeature() and widgets vs. Web pages]

   Marcos: as far as requestFeature(), as this point, it does not exist
   in the Widgets specs.

   David: Yeah, we are still just discussing it within OMTP.

   Marcin: [explaining background on submission of BONDI specs for
   review within W3C]

   Bryan: One question is: Do we have the ability to author [a
   document] as both a Web page and a Widget.
   ... Another question is around dynamically loading.

   Marcos: I think the DAP WG will be the one that needs to answer
   that.

   timeless_mbp: because of localization and path constraints,
   currently you won't be able to [drop a widget into a page and have
   it work]

   Marcin: In theory, for this case, the widget UA should be behaving