Re: Use Cases and Requirements for Saving Files Securely

[Charles McCathieNevile]

On Tue, 10 Nov 2009 01:21:06 +0100, Maciej Stachowiak   
wrote:




On Nov 9, 2009, at 12:08 PM, Ian Hickson wrote:


On Mon, 2 Nov 2009, Doug Schepers wrote:


Please send in use cases, requirements, concerns, and concrete
suggestions about the general topic (regardless of your opinion about  
my

suggestion).


Some use cases:

* Ability to manage attachments in Web-based mail clients, both  
receiving  and sending

* Ability to write a Web-based mail client that uses mbox files or the
 Maildir format locally
* Ability to write a Web-based photo management application that handles
 the user's photos on the user's computer
* Ability to expose audio files to native media players
* Ability to write a Web-based media player that indexes the user's  
media


These are good use cases.


I would like to expand them a little, in each case making it possible to  
use existing content, or expose content directly to the user enabling them  
to change the software they use, or even use multiple tools on the same  
content - a web app one day, a different one next week, a piece of  
shrink-wrap software from time to time.


And add:

* A document management system as hybrid web app, allowing file-based  
access to the documents as well.


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

Re: Use Cases and Requirements for Saving Files Securely

[Charles McCathieNevile]

On Tue, 10 Nov 2009 21:36:36 +0100, Ian Hickson  wrote:


On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:

Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
> Some use cases:
> […]
> * Ability to write a Web-based photo management application that  
handles

>   the user's photos on the user's computer
> * Ability to expose audio files to native media players
> * Ability to write a Web-based media player that indexes the user's  
media


Note that these three use cases would be potentially better addressed by
the potential Media/Gallery API the group is supposed to work on
(“Gallery API, an API to manage the local media file storage” in our
charter [1]).


Wouldn't such an API be over-specialisation?


Depends how deeply people care about specific types. It seems the general  
feeling in HTML is that knowing something is a video, rather than just an  
embedded object, is enough to add an element for it, so probably not  
although one would *hope* that there were a general framework behind such  
an API to allow mutiple (over-)specialised access APIs to be developed as  
deemed useful.


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

Re: Use Cases and Requirements for Saving Files Securely

[Jonas Sicking]

On Tue, Nov 10, 2009 at 5:53 PM, Maciej Stachowiak  wrote:
>
> On Nov 10, 2009, at 12:36 PM, Ian Hickson wrote:
>
>> On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
>>>
>>> Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :

 Some use cases:
 […]
 * Ability to write a Web-based photo management application that handles
  the user's photos on the user's computer
 * Ability to expose audio files to native media players
 * Ability to write a Web-based media player that indexes the user's
 media
>>>
>>> Note that these three use cases would be potentially better addressed by
>>> the potential Media/Gallery API the group is supposed to work on
>>> (“Gallery API, an API to manage the local media file storage” in our
>>> charter [1]).
>>
>> Wouldn't such an API be over-specialisation?
>
> Many modern platforms (well, at least iPhone and Mac OS X) have APIs to
> manipulate a system notion of media gallery. We have considered exposing the
> ability to choose from the user's media collection via ,
> possibly keying off of accept="image/*" or "audio/*" or "video/*".

It would be awesome if you exposed it that way. That's exactly what we
have in mind too at mozilla. Won't happen in the Firefox 3.6 release,
but hopefully not long after that.

/ Jonas

Re: STS and lockCA

[Bil Corry]

Gervase Markham wrote on 10/01/2009 5:51 PM:
> I therefore propose a simple extension to the STS standard; a single
> token to be appended to the end of the header:
> 
> lockCA

One idea to consider, especially for lockCA, is to somehow denote that STS 
should expire at the same time as the cert, perhaps by omitting max-age or 
allowing max-age=cert, etc.  This will prevent accidentally causing STS to last 
longer or shorter than the cert expiration, especially when it's rotated out or 
revoked.


- Bil

Re: CfC: to publish Last Call Working Draft of XHR (1); deadline 18 November

[Sam Weinig]

I also support this publication.

-Sam

On Nov 10, 2009, at 5:41 PM, Maciej Stachowiak wrote:


I support this publication.

- Maciej

On Nov 10, 2009, at 2:01 PM, Arthur Barstow wrote:

Anne has now resolved the last issue for XHR (1) and as discussed  
during last week's f2f meeting [1], the spec is ready for a Last  
Call Working Draft publication:


http://dev.w3.org/2006/webapi/XMLHttpRequest/

This CfC satisfies the group's requirement to "record the group's  
decision to request advancement" for this LCWD. Note that as  
specified in the Process Document [2], a Working Group's Last Call  
announcement is a signal that:


* the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements  
document) in the Working Draft;


* the Working Group believes that it has satisfied significant  
dependencies with other groups;


* other groups SHOULD review the document to confirm that these  
dependencies have been satisfied. In general, a Last Call  
announcement is also a signal that the Working Group is planning to  
advance the technical report to later maturity levels.


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 18.


-Regards, Art Barstow

[1] http://www.w3.org/2009/11/02-webapps-minutes.html
[2] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Re: Use Cases and Requirements for Saving Files Securely

[Maciej Stachowiak]

On Nov 10, 2009, at 12:36 PM, Ian Hickson wrote:


On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:

Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :

Some use cases:
[…]
* Ability to write a Web-based photo management application that  
handles

 the user's photos on the user's computer
* Ability to expose audio files to native media players
* Ability to write a Web-based media player that indexes the  
user's media


Note that these three use cases would be potentially better  
addressed by

the potential Media/Gallery API the group is supposed to work on
(“Gallery API, an API to manage the local media file storage” in our
charter [1]).


Wouldn't such an API be over-specialisation?


Many modern platforms (well, at least iPhone and Mac OS X) have APIs  
to manipulate a system notion of media gallery. We have considered  
exposing the ability to choose from the user's media collection via  
, possibly keying off of accept="image/*" or "audio/ 
*" or "video/*".


I think an API to freely add and remove items from the media  
collection is something we might not be comfortable with exposing to  
the Web, for security reasons. We might consider an API to save to the  
media collection as long as there is user control.


Regards,
Maciej

Re: Rename “File API” to “FileReader API”?

[Maciej Stachowiak]

On Nov 10, 2009, at 3:09 AM, Robin Berjon wrote:


On Nov 10, 2009, at 11:27 , Maciej Stachowiak wrote:

On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth   
wrote:



Which is the proper mailing list to follow development of the file
writing API?  I'd like to follow it's security considerations.


public-device-a...@w3.org


At TPAC, I recall that we proposed drawing the line between file  
reading/writing on the one hand (presumably to go in the current  
File API spec) and filesystem access (including messing with  
directories, mountpoints, file renames etc) to be done in the  
Filesystem API spec. Do we need further discussion to settle what  
goes in which spec?


No, we agreed that File Reader would keep going on in WebApps  
because there's no reason to move something that's making progress  
(unless Arun wants to move it, he's in both WGs anyway), but that  
the rest would be done in DAP since it's more security sensitive and  
new (and chartered there).



I don't recall agreeing to that. I remember that we discussed multiple  
options, and I do not believe there was a resolution recorded along  
the lines of what you say. (But if I'm wrong, I guess the minutes will  
show.


I think file writing (once the script has securely received a file  
handle) has different security considerations than directory  
manipulation and opening of arbitrary files. File writing should be  
designed with the browser security model in mind, because it's  
something that is reasonable to expose to Web content, given the right  
model for getting a writable handle (private use area or explicitly  
chosen by the user via "Save As" dialog). I think directory  
manipulation and opening of arbitrary files can't be fit into that  
security model and has to rely on a "widget security model" where  
there is an overall user trust decision.


I would be concerned with leaving file writing to DAP, because a  
widely held view in DAP seems to be that security can be ignored while  
designing APIs and added back later with an external "policy file"  
mechanism. I would also be concerned with tying file writing to  
directory manipulation, because I think the former is reasonable to do  
in browsers and not the latter. Perhaps this means that we need three  
specs?


Regards,
Maciej

Re: CfC: to publish Last Call Working Draft of XHR (1); deadline 18 November

[Maciej Stachowiak]

I support this publication.

 - Maciej

On Nov 10, 2009, at 2:01 PM, Arthur Barstow wrote:

Anne has now resolved the last issue for XHR (1) and as discussed  
during last week's f2f meeting [1], the spec is ready for a Last  
Call Working Draft publication:


http://dev.w3.org/2006/webapi/XMLHttpRequest/

This CfC satisfies the group's requirement to "record the group's  
decision to request advancement" for this LCWD. Note that as  
specified in the Process Document [2], a Working Group's Last Call  
announcement is a signal that:


* the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements  
document) in the Working Draft;


* the Working Group believes that it has satisfied significant  
dependencies with other groups;


* other groups SHOULD review the document to confirm that these  
dependencies have been satisfied. In general, a Last Call  
announcement is also a signal that the Working Group is planning to  
advance the technical report to later maturity levels.


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 18.


-Regards, Art Barstow

[1] http://www.w3.org/2009/11/02-webapps-minutes.html
[2] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Re: [FileAPI] File.name

[Maciej Stachowiak]

On Nov 10, 2009, at 5:29 PM, Anne van Kesteren wrote:

"The name of the file as a UTF8-encoded string." A DOMString is not  
UTF-8-encoded. I think this should just say "Returns the filename".  
It is not more complicated than that as far as I can tell.


There are some filesystems on (mostly legacy) Unix-like systems where  
filenames are stored in some other encoding than UTF-8, and in some  
cases the encoding is not even known. For example, in Japan there  
exist NFS fileservers where the filenames are encoded in Shift-JIS. In  
cases like that it's a little more complicated than "Return the  
filename" but it's probably ok to just leave it to the UA or the  
operating system to figure out how to deal. Interpreting it as UTF-8  
is likely to be a poor choice in such cases.


 - Maciej

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

[Arun Ranganathan]

Dominique Hazael-Massieux wrote:

Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit :
  
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/FileAPI/



My understanding is that the FPWD would have a “security considerations”
section, as alluded to by an action item Arun took during the joint
DAP/WebApps meeting last week:
http://www.w3.org/2009/dap/track/actions/40

Given that I don’t see it in the editors draft, is this something that
we’re dropping from FPWD? dropping altogether? just something that was
missed in the process? (in the two former cases, I think this should at
least be noted to DAP)
  


I did indeed take the action item, and am committed to completing the 
action item.  I shall turn it around by Thursday, so that the FPWD 
contains a security considerations section.


-- A*

Dom

  

Re: CfC: to publish Last Call Working Draft of XHR (1); deadline 18 November

[Jonas Sicking]

On Tue, Nov 10, 2009 at 2:01 PM, Arthur Barstow  wrote:
> Anne has now resolved the last issue for XHR (1) and as discussed during
> last week's f2f meeting [1], the spec is ready for a Last Call Working Draft
> publication:
>
>  http://dev.w3.org/2006/webapi/XMLHttpRequest/
>
> This CfC satisfies the group's requirement to "record the group's decision
> to request advancement" for this LCWD. Note that as specified in the Process
> Document [2], a Working Group's Last Call announcement is a signal that:
>
> * the Working Group believes that it has satisfied its relevant technical
> requirements (e.g., of the charter or requirements document) in the Working
> Draft;
>
> * the Working Group believes that it has satisfied significant dependencies
> with other groups;
>
> * other groups SHOULD review the document to confirm that these dependencies
> have been satisfied. In general, a Last Call announcement is also a signal
> that the Working Group is planning to advance the technical report to later
> maturity levels.
>
> 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
> 18.

I approve!

/ Jonas

Re: [XHR2] timeout

[Jonas Sicking]

On Tue, Nov 10, 2009 at 10:17 AM, Anne van Kesteren  wrote:
> On Tue, 10 Nov 2009 18:41:32 +0100, Jonas Sicking  wrote:
>>
>> On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren 
>> wrote:
>>>
>>> abort() has some legacy attached to it that I rather not copy.
>>
>> Such as?
>
> Actually, apart from switching the state to 0 in the end there is nothing.
> (This does not happen for user aborts though so I still rather not copy
> that.)
>
> Anyway, do you have opinions on the synchronous case? Do you agree we should
> use TIMEOUT_ERR there? What do the people from Microsoft think?

That makes sense to me.

/ Jonas

CfC: to publish Last Call Working Draft of XHR (1); deadline 18 November

[Arthur Barstow]

Anne has now resolved the last issue for XHR (1) and as discussed  
during last week's f2f meeting [1], the spec is ready for a Last Call  
Working Draft publication:


 http://dev.w3.org/2006/webapi/XMLHttpRequest/

This CfC satisfies the group's requirement to "record the group's  
decision to request advancement" for this LCWD. Note that as  
specified in the Process Document [2], a Working Group's Last Call  
announcement is a signal that:


* the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements  
document) in the Working Draft;


* the Working Group believes that it has satisfied significant  
dependencies with other groups;


* other groups SHOULD review the document to confirm that these  
dependencies have been satisfied. In general, a Last Call  
announcement is also a signal that the Working Group is planning to  
advance the technical report to later maturity levels.


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 18.


-Regards, Art Barstow

[1] http://www.w3.org/2009/11/02-webapps-minutes.html
[2] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Re: [WARP] Comments to WARP spec

[Marcos Caceres]

SULLIVAN, BRYAN L (ATTCINW) wrote:

Placing broad restrictions on widget-context webapp access to network resources 
(substantially different from browser-context webapps) is not an effective 
approach to creating a useful widget-context webapp platform. That would create 
a significant barrier to market acceptance of the W3C widget standards.


Opera does not agree. We've had a similar model in place for a long time 
in our proprietary implementation and we have not faced any issues in 
the marketplace.


The WARP spec solves many problems that arise from not actually having a 
network established origin, and may even avoid the confused deputy 
problem CORS is currently facing (which locally running widgets won't be 
able to use anyway).


I think that technically we are in agreement; but we are just in 
disagreement about the level of granularity that the WARP spec affords 
to authors. For the record, I like the way WARP is currently specified: 
it's easy to use, and essentially works in much the same way as the same 
origin policy does for Web documents... but with the added bonus of 
being able to do cross origin - but with the restriction of not being 
unrestricted, like it's the case for web documents.

Re: Use Cases and Requirements for Saving Files Securely

[Ian Hickson]

On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
> Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
> > Some use cases:
> > […]
> > * Ability to write a Web-based photo management application that handles 
> >   the user's photos on the user's computer
> > * Ability to expose audio files to native media players
> > * Ability to write a Web-based media player that indexes the user's media
> 
> Note that these three use cases would be potentially better addressed by
> the potential Media/Gallery API the group is supposed to work on
> (“Gallery API, an API to manage the local media file storage” in our
> charter [1]).

Wouldn't such an API be over-specialisation?

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

Re: Rename “File API” to “FileReader API”?

[Ian Hickson]

On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
> 
> I alluded to this during the joint F2F meeting between WebApps and DAP 
> last week, but thought I would make the proposal more formally: given 
> that the current “File API” [1] really defines a FileReader 
> interface, and given that DAP is supposed to come up with a more generic 
> filesystems API (including the possibility to write to files), I suggest 
> that “File API” should be renamed to “FileReader API.”

Regardless of which working group it ends up in, the same spec should do 
the reading and writing. So even if we decide to do work on reading first, 
in WebApps, and then move the spec to DAP to add writing, it still doesn't 
make sense to rename it, IMHO.

I would also suggest that to avoid running into the issue of people having 
different idea of what a file system is, we should call the other spec the 
Directory API. That way we have a clear delineation -- one spec to define 
how directories work, and one to define how files work.

Note that in the case of the File API, most of the API's entry points are 
actually in HTML APIs (primarily in  and DataTransfer, 
but also in postMessage) and in Web Storage. It's likely that for the non- 
widget version of these APIs, the same will be true of the Directory API.

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

Re: WebSimpleDB object caching

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


Nikunj R. Mehta wrote:
> Hi Kris,
>
> Thanks for the insightful feedback.
>
> On Nov 7, 2009, at 8:12 PM, Kris Zyp wrote:
>
>> Is there any intended restrictions on caching of objects returned by
>> queries and gets with WebSimpleDB?
>
> Currently, the spec does specify any required behavior in terms of
> caching objects. As an implementation choice, it would be good if
> the object returned by a database from a cursor can be reused by the
> user agent.
>
>> For example (using the address book
>> example in the spec):
>>
>> |database = window.openDatabase('AddressBook', '1', 'Address Book',
>> true);
>> database.transaction(function(Transaction txn) {
>> var store = txn.getEntityStore('Contact');
>> var allCursor = store.entities();
>> var lCursor = store.getIndex('ContactName').entities('L');
>> var l1 = lCursor.next();
>> l1 = lCursor.next();
>> var l2 = allCursor.next();
>
> From this example, the two calls to lCursor.next() may return the
> exact same object each time even though its contents may be
> completely different. In other words, they could respond positively
> to the identity match '===' but not to the equality match '=='. As a
> spec user which one do you prefer? As spec implementors, what would
> you prefer?
>
>>
>> Now, is there any intended requirement that l1==l2 must be false even
>> if ||they represent the same record (that is l1["id"] === l2["id"]) or
>> can cursors potentially reuse JS objects?
>
> Cursors can potentially reuse JS objects. Would you object if this
> were to be a requirement of the spec?
>
>> Also should store.get(l1.id)
>> == l1 be false as well?
>
> In general, nothing can be said about '==' test, except on
> primitives that are supported by the spec. I currently intend to
> support only String and Number types for use as keys in the spec.
> That means,
>
> store.get(l1.id).id == l1.id but _not_ store.get(l1.id) == l1
>
>> In other words, if one does l2.number =
>> '3322', is there any guarantee that l1.number would be unchanged (or
>> would be changed)?
>
> There is no such guarantee presently. Please explain your
> requirement as that might help shed light on which route to take.
I don't have a hard requirement, we are just using the WebSimpleDB API
as a common interface to different storage system in server side
JavaScript. But, if store.entities().next() !==
store.entities().next() is not guaranteed, it could potentially add an
extra burden on users. If they modify an object return from a cursor,
and have not yet called update or put with it, then it would be
unknown if a future cursor might return the modified object or a fresh
object without the modification. Guaranteeing store.entities().next()
!== store.entities().next() seems like it would provide more
determinism. Alternately, we could guarantee store.entities().next()
=== store.entities().next(), but I don't think you are wanting that,
and it would put extra burden on spec implementors to keep track of
objects that have been returned from cursors.

Presumably the identity guarantee of objects returned from cursors
should be the same as for get(id) calls (if cursors always return a
new JS object, so should get(id)).

Thanks,

- --
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/
 
iEYEARECAAYFAkr5y+4ACgkQ9VpNnHc4zAweBwCfYEVIuyOwR6epf8Ty4IeV9AT0
NrEAoJgaIz6n9SE8qTor82ZtapaugdGh
=kJxr
-END PGP SIGNATURE-

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

[Adam Barth]

Thanks for clarifying your protocol.  How does this protocol compare
to OAuth?  The two appear to be solving the same problem with the same
set of constraints.  I ask because OAuth has had a series of subtle
security vulnerabilities that eluded early security folks who analyzed
the protocol.

I'm still concerned about CSRF in Step 5.  In particular, the scenario
I'm worried about is as follows:

1) The user initiates the protocol with an honest site A.
2) The web attacker interrupts the protocol during Step 3 or Step 4
(e.g., by navigating the top-level browser context in which the
protocol is taking place).
3) The web attacker forges a cross-site request to B, altering the
parameters supplied in Step 5.
4) The user doesn't pay that much attention to confirmation page and
approves the request.

We could run a usability study, but I suspect that relying on the user
to properly confirm the transaction is not a good security assumption.
 This protocol has the flavor of user account control (UAC) in Vista,
in which the user is prompted to confirm transactions immediately
after initiating the transaction.

It seems like Maciej's protocol addresses this use case more securely.
 Notice that Maciej's protocol has half the number of messages and
does not require user confirmation.

Adam


On Tue, Nov 10, 2009 at 11:50 AM, Tyler Close  wrote:
> I've elaborated on the example at:
>
> http://sites.google.com/site/guestxhr/maciej-challenge
>
> I've tried to include all the information from our email exchange.
> Please let me know what parts of the description remain ambiguous.
>
> Just so that we're on the same page, the prior description was only
> meant to give the reader enough information to see that the scenario
> is possible to implement under Maciej's stated constraints. I expected
> the reader to fill in their favored technique where that choice could
> be done safely in many ways. Many of the particulars of the design
> (cookies vs URL arguments, 303 vs automated form post, UI for noting
> conflicts) can be done in several different ways and the choice isn't
> very relevant to the current discussion. All that said, I'm happy to
> fill out the scenario with as much detail as you'd like, if that helps
> us reach an understanding.
>
> --Tyler
>
> On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth  wrote:
>> You seem to be saying that your description of the protocol is not
>> complete and that you've left out several security-critical steps,
>> such as
>>
>> 1) The user interface for confirming transactions.
>> 2) The information the server uses to figure out which users it is talking 
>> to.
>>
>> Can you please provide a complete description of your protocol with
>> all the steps required?  I don't see how we can evaluate the security
>> of your protocol without such a description.
>>
>> Thanks,
>> Adam
>>
>>
>> On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close  wrote:
>>> Hi Adam,
>>>
>>> Responses inline below...
>>>
>>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth  wrote:
 Hi Tyler,

 I've been trying to understand the GuestXHR protocol you propose for
 replacing CORS:

 http://sites.google.com/site/guestxhr/maciej-challenge

 I don't understand the message in step 5.  It seems like it might have
 a CSRF vulnerability.  More specifically, what does the server do when
 it receives a GET request for https://B/got?A=secret123?
>>>
>>> Think of the resource at /got as like an Inbox for accepting an "add
>>> event" permission from anyone. The meta-variable "A" in the query
>>> string, along with the secret, is the URL to send events to. So a
>>> concrete request might look like:
>>>
>>> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
>>> Host: upcoming.example.net
>>>
>>> When upcoming.example.net receives this request, it might:
>>>
>>> 1) If no association for the site exists, add it
>>> 2) If an existing association for the site exists respond with a page
>>> notifying the user of the collision and asking if it should overwrite
>>> or ignore.
>>>
>>> Notice that step 6 is a response from Site B back to the user's browser.
>>>
>>> Alternatively, the response in step 6 could always be a confirmation
>>> page asking the user to confirm any state change that is about to be
>>> made. So, the page from the upcoming event site might say:
>>>
>>> "I just received a request to add a calendar to your profile. Did you
>>> initiate this request?  "
>>>
>>> Note that such a page would also be a good place to ask the user for a
>>> petname for the new capability, if you're into such things, but I
>>> digress...
>>>
 The slides say "Associate user,A with secret123."  That sounds like
 server B changes state to associate secret123 with the the pair (user,
 A).  What stops an attacker from forging a cross-site request of the
 form https://B/got?A=evil123?
>>>
>>> In the design as presented, nothing prevents this. I considered the
>>> mitigation presented above sufficient for

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

[Tyler Close]

I've elaborated on the example at:

http://sites.google.com/site/guestxhr/maciej-challenge

I've tried to include all the information from our email exchange.
Please let me know what parts of the description remain ambiguous.

Just so that we're on the same page, the prior description was only
meant to give the reader enough information to see that the scenario
is possible to implement under Maciej's stated constraints. I expected
the reader to fill in their favored technique where that choice could
be done safely in many ways. Many of the particulars of the design
(cookies vs URL arguments, 303 vs automated form post, UI for noting
conflicts) can be done in several different ways and the choice isn't
very relevant to the current discussion. All that said, I'm happy to
fill out the scenario with as much detail as you'd like, if that helps
us reach an understanding.

--Tyler

On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth  wrote:
> You seem to be saying that your description of the protocol is not
> complete and that you've left out several security-critical steps,
> such as
>
> 1) The user interface for confirming transactions.
> 2) The information the server uses to figure out which users it is talking to.
>
> Can you please provide a complete description of your protocol with
> all the steps required?  I don't see how we can evaluate the security
> of your protocol without such a description.
>
> Thanks,
> Adam
>
>
> On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close  wrote:
>> Hi Adam,
>>
>> Responses inline below...
>>
>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth  wrote:
>>> Hi Tyler,
>>>
>>> I've been trying to understand the GuestXHR protocol you propose for
>>> replacing CORS:
>>>
>>> http://sites.google.com/site/guestxhr/maciej-challenge
>>>
>>> I don't understand the message in step 5.  It seems like it might have
>>> a CSRF vulnerability.  More specifically, what does the server do when
>>> it receives a GET request for https://B/got?A=secret123?
>>
>> Think of the resource at /got as like an Inbox for accepting an "add
>> event" permission from anyone. The meta-variable "A" in the query
>> string, along with the secret, is the URL to send events to. So a
>> concrete request might look like:
>>
>> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
>> Host: upcoming.example.net
>>
>> When upcoming.example.net receives this request, it might:
>>
>> 1) If no association for the site exists, add it
>> 2) If an existing association for the site exists respond with a page
>> notifying the user of the collision and asking if it should overwrite
>> or ignore.
>>
>> Notice that step 6 is a response from Site B back to the user's browser.
>>
>> Alternatively, the response in step 6 could always be a confirmation
>> page asking the user to confirm any state change that is about to be
>> made. So, the page from the upcoming event site might say:
>>
>> "I just received a request to add a calendar to your profile. Did you
>> initiate this request?  "
>>
>> Note that such a page would also be a good place to ask the user for a
>> petname for the new capability, if you're into such things, but I
>> digress...
>>
>>> The slides say "Associate user,A with secret123."  That sounds like
>>> server B changes state to associate secret123 with the the pair (user,
>>> A).  What stops an attacker from forging a cross-site request of the
>>> form https://B/got?A=evil123?
>>
>> In the design as presented, nothing prevents this. I considered the
>> mitigation presented above sufficient for Maciej's challenge. If
>> desired, we could tighten things up, without resorting to an Origin
>> header, but I'd have to add some more stuff to the explanation.
>>
>>>  Won't that overwrite the association?
>>
>> That seems like a bad idea.
>>
>>> There doesn't seem to be anything in the protocol that binds the "A"
>>> in that message to server A.
>>
>> The "A" is just the URL for server A.
>>
>>> More generally, how does B know the message https://B/got?A=secret123
>>> has anything to do with "user"?  There doesn't seem to be anything in
>>> the message identifying the user.  (Of course, we could use cookies to
>>> do that, but we're assuming the cookie header isn't present.)
>>
>> This request is just a normal page navigation, so cookies and such
>> ride along with the request. In the diagrams, all requests are normal
>> navigation requests unless prefixed with "GXHR:".
>>
>> We used these normal navigation requests in order to keep the user
>> interface and network communication diagram as similar to Maciej's
>> solution as possible. If I were approaching this problem without that
>> constraint, I might do things differently, but that wasn't the goal of
>> this exercise.
>>
>>> Can you help me understand how the protocol works?
>>
>> My pleasure. Please send along any follow up questions.
>>
>> (I would have chosen a different Subject field for these questions though)
>>
>>> P.S., It also seems that the protocol does not comply with th

Re: CORS Background slides

[Tyler Close]

I've updated the web page that describes the calendar access grant. See:

http://sites.google.com/site/guestxhr/maciej-challenge

More comments inline below...

On Wed, Nov 4, 2009 at 6:14 PM, Maciej Stachowiak  wrote:
>
> On Nov 4, 2009, at 6:04 PM, Maciej Stachowiak wrote:
>
>>
>> I forgot to mention another shared secret management risk with the
>> proposed GuestXHR-based protocol. The protocol involves passing the shared
>> secret in URLs, including URLs that will appear in the browser's URL field.
>> URLs should not be considered confidential - there have a high tendency to
>> get inadvertently exposed to third parties. Some of the ways this happens
>> include caching layers, the browser history (particularly shared sync of the
>> browser history), and users copying URLs out of the URL field without
>> considering whether this particular URL contains a secret.
>>
>> I believe this can be fixed by always transmitting the shared secret in
>> the body of an https POST rather than as part of the URL, so this risk is
>> not intrinsic to this style of protocol.
>
> On second thought - I don't see an obvious way to change the access grant to
> avoid sending the shared secret in the URL of a GET request. You can't just
> change the 303 redirect to a 307, since the original post body did not
> contain the shared secret; and there is no way to redirect in a way that
> changes the POST body. Maybe someone else can think of a way to do it.

Personally, I think including a secret in a URL is a fine technique,
but if you want to avoid it, you could instead return a 200 response
in step 4 and have JavaScript in the page do an automated form
submission with the secret in the body of the POST request.

For those interested, I've argued in favor of secret token in the URL at:

http://waterken.sf.net/web-key

> Another issue: how does Server B defend against a CSRF vulnerability in
> receiving the shared secret from Server A? It seems like a page from any
> server could send it an invalid shared secret at any time, thus breaking
> Server B's ability to access Server A.

.. assuming Server B is willing to silently overwrite its current
state with the new invalid secret. That would be a poor choice. For
clarity, I've expanded the description of what Server B could do to
avoid such attack scenarios.

--Tyler

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

Re: [XHR2] timeout

[Anne van Kesteren]

On Tue, 10 Nov 2009 18:41:32 +0100, Jonas Sicking  wrote:
On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren   
wrote:

abort() has some legacy attached to it that I rather not copy.


Such as?


Actually, apart from switching the state to 0 in the end there is nothing.  
(This does not happen for user aborts though so I still rather not copy  
that.)


Anyway, do you have opinions on the synchronous case? Do you agree we  
should use TIMEOUT_ERR there? What do the people from Microsoft think?



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

Re: [XHR2] timeout

[Jonas Sicking]

On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren  wrote:
>> I agree that firing readystatechange seems like the most consistent thing
>> to do.
>>
>> I agree that firing timeout (and IMHO abort) on the XHRUpload object
>> unless upload has already finished.
>>
>> In general, I think essentially behaving as if a "timeout" event was
>> fired, and then abort() is called is how we should behave.
>
> abort() has some legacy attached to it that I rather not copy.

Such as?

/ Jonas

Re: [FileAPI] FileReader

[Jonas Sicking]

On Tue, Nov 10, 2009 at 8:56 AM, Anne van Kesteren  wrote:
> The design of the FileReader API is a bit awkward. It's sort of the inverse
> of the XMLHttpRequest API (by having separate read methods rather than
> separate response getters) though the moment we add support for octet
> streams we get both? Or will the result attribute start to return non-string
> values?

Either works. I was thinking the latter.

> I have been thinking about alternatives, e.g. by letting the FileReader
> constructor accept a Blob as argument, having the event objects carry the
> data, but have not really gotten much further yet. I do think that letting
> the events carry a pointer to the data is better. The only reason
> XMLHttpRequest does not have that is historical. Most other APIs that
> involve transmission of data do it that way (WebSocket / EventSource).

I'd rather be consistent with XHR here. I think the API actually make
more sense for FileReader than it does for XHR since in most cases
with file reader I think people will not care about progress events
given how fast a file typically loads. So in most cases you'd just
register a "load" (or "loadend") listener and get the data there.

I do think having a "streaming" mode for both XHR and FileReader makes
sense, but I think that should be a separate mode. Either activated
using a constructor argument, or using a property (similar to
.withCredentials).

I don't really see the advantage of making the reader take the
Blob/File as a constructor argument. That looses the ability to reuse
the reader to read multiple files (not a big deal), and makes it
different from XHR (bigger deal) for seemingly no reason.

> I also still think we should not introduce getAsDataURL() (there is
> File.urn/URL) and getAsBinaryString() (temporary hack).

We had the discussion about dataURLs before and I still think there
are good use cases. Such as creating a HTML editor with inline images
and then sending that over the wire or allowing the user to save it as
a single file.

I agree that getAsBinaryString is somewhat of a hack, however I'm
reluctant to remove it until ByteArray (or whatever it will be called)
has actually been defined.

/ Jonas

Re: [FileAPI] File.mediaType

[Boris Zbarsky]

On 11/10/09 11:58 AM, Anne van Kesteren wrote:

True, can you ever get this situation when reading a file from disk?


I'm not sure what you're asking...  When loading a file from disk, the 
type is always unknown and has to be determined by the UA somehow, no?



Sure, but there's also 

Re: [XHR2] timeout

[Anne van Kesteren]

On Tue, 10 Nov 2009 18:23:04 +0100, Jonas Sicking  wrote:

Are all of these comments for synchronous XHR only?


Only the TIMEOUT_ERR exception was for the synchronous case. I think the  
synchronous case it would be most consistent to not dispatch any events.  
This is however not what Internet Explorer is currently doing as I  
understand things (have not been able to test yet).




I agree with most of your comments. Though I think we should fire an
"abort" event since Progress Events spec says to fire one of
abort/error/load, and abort seems to fit the bill the best. Or are you
suggesting that Progress Events should say that one of
abort/error/load/timeout is always fired?


It seems better to change Progress Events. We already agreed to make  
requirements on specifications less strict.



I agree that firing readystatechange seems like the most consistent  
thing to do.


I agree that firing timeout (and IMHO abort) on the XHRUpload object
unless upload has already finished.

In general, I think essentially behaving as if a "timeout" event was
fired, and then abort() is called is how we should behave.


abort() has some legacy attached to it that I rather not copy. I rather  
copy how the generic "abort error" network steps behave.



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

Re: [XHR2] timeout

[Jonas Sicking]

On Tue, Nov 10, 2009 at 5:22 PM, Anne van Kesteren  wrote:
> I was looking at defining the timeout feature. For consistency with "abort
> error" and "network error" it would make sense to introduce a TIMEOUT_ERR
> for synchronous requests, but Internet Explorer is probably not doing this
> (at least not per documentation).
>
> For consistency with "abort error" and "network error" it would make sense
> to dispatch a readystatechange event. Per comments from Sunava Internet
> Explorer does not do this. Similarly it would make sense to move the state
> of the object to 4 rather than 0. Again, per Sunava Internet Explorer does
> not do this.
>
> Personally I think we want to dispatch the readystatechange event, we want
> to switch the state of the object to 4, we want to dispatch a loadend event
> after the timeout event, we do not want to dispatch an abort event (this was
> suggested before), and we want to throw a TIMEOUT_ERR exception (code 23 or
> 24, depending on whether we want to reserve 23 for v2-datagrid) for the
> synchronous request case rather than dispatching events.
>
> I also think we want to dispatch the timeout event to the
> XMLHttpRequestUpload object (in the asynchronous case) for consistency.
>
> Thoughts?

Are all of these comments for synchronous XHR only?

I agree with most of your comments. Though I think we should fire an
"abort" event since Progress Events spec says to fire one of
abort/error/load, and abort seems to fit the bill the best. Or are you
suggesting that Progress Events should say that one of
abort/error/load/timeout is always fired?

I agree that firing readystatechange seems like the most consistent thing to do.

I agree that firing timeout (and IMHO abort) on the XHRUpload object
unless upload has already finished.

In general, I think essentially behaving as if a "timeout" event was
fired, and then abort() is called is how we should behave.

/ Jonas

Re: [FileAPI] File.mediaType

[Anne van Kesteren]

On Tue, 10 Nov 2009 17:53:14 +0100, Boris Zbarsky  wrote:

On 11/10/09 8:33 PM, Anne van Kesteren wrote:

This should be a bit more exact as to how the mediaType is returned. I
would prefer ASCII-lowercase. Returning "application/octet-stream"
rather than null also seems better if the type is not known. That way
you do not have to type check. Other parts of the platform also handle
"application/octet-stream" as unknown.


That's not necessarily true.  Most simply, loading a url in a browser  
doesn't treat application/octet-stream the same way it treats a missing  
Content-Type header.


True, can you ever get this situation when reading a file from disk?



Also, maybe we should just call this type? File.type seems unambiguous
enough.


It seems that many people think of "JPG" or "PNG" or "HTML" etc as the  
"file type".  Witness all the dialog in various software that talk about  
"PNG files" and such.


Sure, but there's also 

[FileAPI] FileReader

[Anne van Kesteren]

The design of the FileReader API is a bit awkward. It's sort of the  
inverse of the XMLHttpRequest API (by having separate read methods rather  
than separate response getters) though the moment we add support for octet  
streams we get both? Or will the result attribute start to return  
non-string values?


I have been thinking about alternatives, e.g. by letting the FileReader  
constructor accept a Blob as argument, having the event objects carry the  
data, but have not really gotten much further yet. I do think that letting  
the events carry a pointer to the data is better. The only reason  
XMLHttpRequest does not have that is historical. Most other APIs that  
involve transmission of data do it that way (WebSocket / EventSource).


I also still think we should not introduce getAsDataURL() (there is  
File.urn/URL) and getAsBinaryString() (temporary hack).



(There is also various issues with how the read methods are defined in  
terms of event handling and task queues, but those can be resolved after  
the general API is agreed upon I suppose.)



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

Re: [FileAPI] File.mediaType

[Boris Zbarsky]

On 11/10/09 8:33 PM, Anne van Kesteren wrote:

This should be a bit more exact as to how the mediaType is returned. I
would prefer ASCII-lowercase. Returning "application/octet-stream"
rather than null also seems better if the type is not known. That way
you do not have to type check. Other parts of the platform also handle
"application/octet-stream" as unknown.


That's not necessarily true.  Most simply, loading a url in a browser 
doesn't treat application/octet-stream the same way it treats a missing 
Content-Type header.



Also, maybe we should just call this type? File.type seems unambiguous
enough.


It seems that many people think of "JPG" or "PNG" or "HTML" etc as the 
"file type".  Witness all the dialog in various software that talk about 
"PNG files" and such.


-Boris

Re: Use Cases and Requirements for Saving Files Securely

[Dominique Hazael-Massieux]

Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
> Some use cases:
> […]
> * Ability to write a Web-based photo management application that handles 
>   the user's photos on the user's computer
> * Ability to expose audio files to native media players
> * Ability to write a Web-based media player that indexes the user's media

Note that these three use cases would be potentially better addressed by
the potential Media/Gallery API the group is supposed to work on
(“Gallery API, an API to manage the local media file storage” in our
charter [1]).

Dom — hello DAP’s ISSUE-39

1. http://www.w3.org/2009/05/DeviceAPICharter

[FileAPI] FileReader constants

[Anne van Kesteren]

It might make sense to rename INITIAL to EMPTY for consistency with  
HTMLMediaElement. Instead of LOADING READING might be better though I care  
less about that one.



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

[FileAPI] File.mediaType

[Anne van Kesteren]

This should be a bit more exact as to how the mediaType is returned. I  
would prefer ASCII-lowercase. Returning "application/octet-stream" rather  
than null also seems better if the type is not known. That way you do not  
have to type check. Other parts of the platform also handle  
"application/octet-stream" as unknown.


Also, maybe we should just call this type? File.type seems unambiguous  
enough.



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

[FileAPI] File.name

[Anne van Kesteren]

"The name of the file as a UTF8-encoded string." A DOMString is not  
UTF-8-encoded. I think this should just say "Returns the filename". It is  
not more complicated than that as far as I can tell.



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

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

[Dominique Hazael-Massieux]

Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit :
> 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/FileAPI/

My understanding is that the FPWD would have a “security considerations”
section, as alluded to by an action item Arun took during the joint
DAP/WebApps meeting last week:
http://www.w3.org/2009/dap/track/actions/40

Given that I don’t see it in the editors draft, is this something that
we’re dropping from FPWD? dropping altogether? just something that was
missed in the process? (in the two former cases, I think this should at
least be noted to DAP)

Dom

[XHR2] timeout

[Anne van Kesteren]

I was looking at defining the timeout feature. For consistency with "abort  
error" and "network error" it would make sense to introduce a TIMEOUT_ERR  
for synchronous requests, but Internet Explorer is probably not doing this  
(at least not per documentation).


For consistency with "abort error" and "network error" it would make sense  
to dispatch a readystatechange event. Per comments from Sunava Internet  
Explorer does not do this. Similarly it would make sense to move the state  
of the object to 4 rather than 0. Again, per Sunava Internet Explorer does  
not do this.


Personally I think we want to dispatch the readystatechange event, we want  
to switch the state of the object to 4, we want to dispatch a loadend  
event after the timeout event, we do not want to dispatch an abort event  
(this was suggested before), and we want to throw a TIMEOUT_ERR exception  
(code 23 or 24, depending on whether we want to reserve 23 for  
v2-datagrid) for the synchronous request case rather than dispatching  
events.


I also think we want to dispatch the timeout event to the  
XMLHttpRequestUpload object (in the asynchronous case) for consistency.


Thoughts?

(In case you miss the background, the API is a simple timeout attribute  
(unsigned long) on the XMLHttpRequest object that defines the timeout to  
be used when making a request. Whichever of the full response or the  
timeout "runs" to completion first wins. If the timeout attribute is 0  
(default value) the timeout API semantics do not affect the API and in  
case of a UA-defined timeout NETWORK_ERR/error will be returned instead.)



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

RE: [WARP] Comments to WARP spec

[SULLIVAN, BRYAN L (ATTCINW)]

Marcos,
Re "the whole point of WARP is to put these boundaries around the behavior of 
widgets because they run locally.", there is really no difference between 
browser-context and widget-context webapps in that sense. Both run on the 
device, and both can access device resources and network resources. The only 
essential difference is that widgets are downloaded and installed as a package 
which can define some extra information that is useful in the install phase of 
the application lifecycle (e.g. compatibility checks via the the  and 
 elements).

I don’t believe it is correct to say that "How a browsing context should behave 
when run locally is not really defined by HTML5.". I believe that regardless of 
where a web page originates, the security model must be consistent. For the 
part of HTML5 (e.g. access to DOM elements) that depends upon same-origin 
restrictions, the source of the stored content is important (and should anyway 
be known by the browser in most cases), but for the other parts (e.g. img tag 
and referenced scripts) it is irrelevant. 

Placing broad restrictions on widget-context webapp access to network resources 
(substantially different from browser-context webapps) is not an effective 
approach to creating a useful widget-context webapp platform. That would create 
a significant barrier to market acceptance of the W3C widget standards.

Best regards,
Bryan Sullivan | AT&T
-Original Message-
From: Marcos Caceres [mailto:marc...@opera.com] 
Sent: Tuesday, November 10, 2009 7:30 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec



SULLIVAN, BRYAN L (ATTCINW) wrote:
> Marcos,
> I agree there is an assumption behind the approach I proposed, which I also 
> believe will be valid for the vast majority of widgets which will actually 
> have "index.html" or something like that as the start page. Further, the 
> statements in the config.xml apply to all resources in the widget, not just 
> the start page, i.e. I can start with a non-HTML which references an HTML 
> file in the package, to which the "tag" attribute applies.

So we are clear, the tag attribute does not work in the following 
situation. I want to disable x:script, but allow v:script... unless you 
know what the things different namespaces will not be added dynamically 
to the DOM:

http://www.w3.org/1999/xhtml";>
...
 ... 

http://www.w3.org/2000/svg"; version="1.1">
   ...




> If the proposed solution is inadequate, I welcome other suggestions.

I don't have a suggestion because I don't believe this part of WARP is 
broken or is necessary.

 >But as it stands, the WARP spec is not consistent with the web 
security model, so we need to fix the  element definition somehow.

  Well, the whole point of WARP is to put these boundaries around the 
behavior of widgets because they run locally. How a browsing context 
should behave when run locally is not really defined by HTML5. This 
leaves a gap for us to fill.

Re: XMLHttpRequest: Last Call?

[Anne van Kesteren]

On Tue, 10 Nov 2009 07:17:01 -0800, Charles McCathieNevile  
 wrote:
On Wed, 11 Nov 2009 01:13:56 +0100, Anne van Kesteren   
wrote:

I resolved ISSUE-103 by removing exceptions for the getters as discussed
during the F2F meeting. I don't believe there is anything else  
outstanding so we can try another Last Call I think.



Do we need a CfC through email as well maybe before I request to publish
that?


Yep, although the default is yes given those at the meeting already  
resolved to ask for it.


Is the draft ready for it now?


Yes, http://dev.w3.org/2006/webapi/XMLHttpRequest/ contains the edits we  
agreed upon. Once we decide to publish I can add the Last Call boilerplate.



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

Re: Proposal for sending multiple files via XMLHttpRequest.send()

[Jonas Sicking]

Yay!

On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren  wrote:
 WebKit presently supports sending File.  It does not support FileData
 yet.
>>>
>>> Is Content-Type set to anything specific if the author has not set it?
>>
>> // FIXME: Should we set a Content-Type if one is not set.
>>
>> ^^^ looks like it presently depends on the web page setting the C-T header
>> manually :-/  I think that should be fixed to be based on the system's
>> knowledge of the file's mime type.
>
> So far I have only added support for Blob (the new FileData) of these two
> and set the Content-Type to application/octet-stream if not provided by the
> Web author. Should I also add File and set the Content-Type to
> File.mediaType?

I definitely think so yes.

Same thing for the send() function.

On a separate note, is sending "application/octet-stream" really
better than simply sending no Content-Type header at all when sending
a Blob (or a File with empty mediaType)?

/ Jonas

Re: [WARP] Comments to WARP spec

[Marcos Caceres]

SULLIVAN, BRYAN L (ATTCINW) wrote:

Marcos,
I agree there is an assumption behind the approach I proposed, which I also believe will be valid 
for the vast majority of widgets which will actually have "index.html" or something like 
that as the start page. Further, the statements in the config.xml apply to all resources in the 
widget, not just the start page, i.e. I can start with a non-HTML which references an HTML file in 
the package, to which the "tag" attribute applies.


So we are clear, the tag attribute does not work in the following 
situation. I want to disable x:script, but allow v:script... unless you 
know what the things different namespaces will not be added dynamically 
to the DOM:


http://www.w3.org/1999/xhtml";>
...
 ... 

http://www.w3.org/2000/svg"; version="1.1">
  ...





If the proposed solution is inadequate, I welcome other suggestions.


I don't have a suggestion because I don't believe this part of WARP is 
broken or is necessary.


>But as it stands, the WARP spec is not consistent with the web 
security model, so we need to fix the  element definition somehow.


 Well, the whole point of WARP is to put these boundaries around the 
behavior of widgets because they run locally. How a browsing context 
should behave when run locally is not really defined by HTML5. This 
leaves a gap for us to fill.

Re: XMLHttpRequest: Last Call?

[Charles McCathieNevile]

On Wed, 11 Nov 2009 01:13:56 +0100, Anne van Kesteren   
wrote:



I resolved ISSUE-103 by removing exceptions for the getters as discussed
during the F2F meeting. I don't believe there is anything else  
outstanding so we can try another Last Call I think.



Do we need a CfC through email as well maybe before I request to publish
that?


Yep, although the default is yes given those at the meeting already  
resolved to ask for it.


Is the draft ready for it now?

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

XMLHttpRequest: Last Call?

[Anne van Kesteren]

I resolved ISSUE-103 by removing exceptions for the getters as discussed
during the F2F meeting. I don't believe there is anything else outstanding
so we can try another Last Call I think. Do we need a CfC through email as
well maybe before I request to publish that?


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

RE: [WARP] Comments to WARP spec

[SULLIVAN, BRYAN L (ATTCINW)]

Marcos,
I agree there is an assumption behind the approach I proposed, which I also 
believe will be valid for the vast majority of widgets which will actually have 
"index.html" or something like that as the start page. Further, the statements 
in the config.xml apply to all resources in the widget, not just the start 
page, i.e. I can start with a non-HTML which references an HTML file in the 
package, to which the "tag" attribute applies.

If the proposed solution is inadequate, I welcome other suggestions. But as it 
stands, the WARP spec is not consistent with the web security model, so we need 
to fix the  element definition somehow.

Best regards,
Bryan Sullivan | AT&T
-Original Message-
From: Marcos Caceres [mailto:marc...@opera.com] 
Sent: Tuesday, November 10, 2009 1:36 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec



SULLIVAN, BRYAN L (ATTCINW) wrote:
> Marcos,
>
> Re "I'm personally not in favor of trying to deviate too much from the Web 
> security model.": I agree with you, and that is the point of the comments. 
> The "web security model" (I think you mean the same-origin restriction) does 
> not restrict access to image content from anywhere, like the  element 
> would. The  element as currently in the WARP spec goes beyond the 
> "web security model".
>
> My point is that the statement below in the WARP spec needs to change, 
> because this is not compatible with the "web security model", and also "makes 
> more work for implementers" because the security model for widget-context 
> webapps would not be the same as for browser-context webapps: "In the default 
> policy, a user agent must deny access to network resources  external to the 
> widget by default, whether this access is requested through APIs (e.g. 
> XMLHttpRequest) or through markup (e.g. iframe, script, img)."
>
> So either:
> (1) we need to be specific about which API's / resource types are affected by 
> inclusion (or exclusion) of domains in  (and keep this equivalent to 
> HTML5)
> (2) we must add a way for the developer to indicate which types of references 
> should be allowed for the domain
>
> My preference would be (1), but I proposed the use of "tag=" to illustrate 
> how (2) might work.
>

Again, @tag= assumes HTML. There could be many different variant start 
files in a widget. Consider the case where you have a compound XML 
document as the start file (HTML + SVG + Custom XML)... how would you 
say which element this applies to and in which namespace? Also "tag" 
makes no sense in the context of CSS, XHR, etc.

Re: Proposal for sending multiple files via XMLHttpRequest.send()

[Anne van Kesteren]

I added support for Blob and FormData to XMLHttpRequest Level 2 also based  
on the discussion at the F2F:


  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/

More comments below.


On Tue, 20 Oct 2009 10:28:57 -0700, Darin Fisher   
wrote:

Sorry...  I just meant that I need to read up on discussions about
octet-array support before I can comment ;-)


See the email from Maciej to public-script-coord and es-discuss.


WebKit presently supports sending File.  It does not support FileData  
yet.


Is Content-Type set to anything specific if the author has not set it?


// FIXME: Should we set a Content-Type if one is not set.

^^^ looks like it presently depends on the web page setting the C-T  
header

manually :-/  I think that should be fixed to be based on the system's
knowledge of the file's mime type.


So far I have only added support for Blob (the new FileData) of these two  
and set the Content-Type to application/octet-stream if not provided by  
the Web author. Should I also add File and set the Content-Type to  
File.mediaType?




Does it make a straight copy of the file or can modifying the file cause
potential problems?


Modifying the file can cause potential problems.  The same is true of
ordinary HTML form submissions.  I don't think we should spec this  
behavior.


HTML5 should probably be more explicit about this. I used the  
multipart/form-data algorithm that HTML5 defines. (It mostly defers to  
RFC2388.)




After TPAC means the week of November 9. Does that work?


Sure.  We might start on things sooner, but it doesn't mean it can't be
revised.


Do you have a demo implementation already? :-)


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

Re: View modes: more precision on fullscreen

[Marcos Caceres]

Robin Berjon wrote:

On Nov 9, 2009, at 16:41 , Marcos Caceres wrote:

That would be 'application', but not maximized.


Uh, but those can be two different windowing modes, with the chrome
subtly different and different behaviour (e.g. the window can't be
dragged if maximised).


That's UA/OS dependent.


How it is implemented is UA/OS/UI dependent, but it doesn't mean that
there isn't a semantic difference. The differences are:

- show me alongside other apps (windowed mode)
- show me, no other app, but keep the OS UI (maximised)
- show me, and nothing else (fullscreen)


Right.


I'm happy for implementers to map the values we list to whatever makes
sense on their platform, but we need to at least have a vocabulary that
covers the more common modes. All versions of Windows in recent memory
as well as most Linux windowing managers support the three levels above,
only OSX believes that it's a good idea to annoy people who are two
pixels off in clicking on the scrollbar. Without the three levels above,
we can't capture the most usual windowing semantics.


I agree. I wonder if we can leverage some text from CSS. However, it 
should not be too hard to specify this.



Or are you thinking about this in terms of the broken OSX UI that can't
tell the difference? If so, I strongly object — it's a usability
nightmare.


Exactly, so stop imposing your dirty Vi command-line view of the world
on the rest of us, Robin! :)


Actually, I'm thinking of usable click-and-drool UIs as my primary use
case.


But seriously, I don't think we need to get to the level where we are
specifying behavior.


No, but we do need a level of semantic description that matches typical
UIs.


Agreed.

Re: Rename “File API” to “FileReader API”?

[Robin Berjon]

On Nov 10, 2009, at 11:27 , Maciej Stachowiak wrote:

On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth   
wrote:



Which is the proper mailing list to follow development of the file
writing API?  I'd like to follow it's security considerations.


public-device-a...@w3.org


At TPAC, I recall that we proposed drawing the line between file  
reading/writing on the one hand (presumably to go in the current  
File API spec) and filesystem access (including messing with  
directories, mountpoints, file renames etc) to be done in the  
Filesystem API spec. Do we need further discussion to settle what  
goes in which spec?


No, we agreed that File Reader would keep going on in WebApps because  
there's no reason to move something that's making progress (unless  
Arun wants to move it, he's in both WGs anyway), but that the rest  
would be done in DAP since it's more security sensitive and new (and  
chartered there).


--
Robin Berjon - http://berjon.com/

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

[Robin Berjon]

On Nov 10, 2009, at 11:27 , Charles McCathieNevile wrote:
I support publication of the document, but suggest that it be named  
"File Reader API" or something to reduce the confusion with the more  
complete File API being edited in DAP.


+1 to File Reader API. I think we can keep all of this clear by having  
the other spec called File Writer.


--
Robin Berjon - http://berjon.com/

Re: Rename “File API” to “FileReader API”?

[Dominique Hazael-Massieux]

Le mardi 10 novembre 2009 à 02:27 -0800, Maciej Stachowiak a écrit :
> At TPAC, I recall that we proposed drawing the line between file  
> reading/writing on the one hand (presumably to go in the current File  
> API spec) and filesystem access (including messing with directories,  
> mountpoints, file renames etc) to be done in the Filesystem API spec.  
> Do we need further discussion to settle what goes in which spec?

My understanding of the line was different: FileReader on the one hand,
on a fast track in WebApps, and a more generic file interaction APIs
(including file writing, and file systems operations as needed by
well-defined use cases) in DAP.

So we probably need further discussion if that’s not a shared
understanding :)

That said, unless the plan is to include file writing in the 1.0 version
of the current File API (which I think was not the case wherever it gets
done), I think my suggestion of renaming it to FileReader still makes
sense.

Dom

Re: Rename “File API” to “FileReader API”?

[Maciej Stachowiak]

On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:

On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth   
wrote:



Which is the proper mailing list to follow development of the file
writing API?  I'd like to follow it's security considerations.


public-device-a...@w3.org


At TPAC, I recall that we proposed drawing the line between file  
reading/writing on the one hand (presumably to go in the current File  
API spec) and filesystem access (including messing with directories,  
mountpoints, file renames etc) to be done in the Filesystem API spec.  
Do we need further discussion to settle what goes in which spec?


Regards,
Maciej

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

[Charles McCathieNevile]

On Wed, 04 Nov 2009 06:27:53 +0100, Arthur Barstow   
wrote:


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



I support publication of the document, but suggest that it be named "File  
Reader API" or something to reduce the confusion with the more complete  
File API being edited in DAP.


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

Re: Rename “File API” to “FileReader API”?

[Arve Bersvendsen]

On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth  wrote:


Which is the proper mailing list to follow development of the file
writing API?  I'd like to follow it's security considerations.


public-device-a...@w3.org
--
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/

Re: Rename “File API” to “FileReader API”?

[Adam Barth]

Which is the proper mailing list to follow development of the file
writing API?  I'd like to follow it's security considerations.

Thanks,
Adam


On Tue, Nov 10, 2009 at 1:56 AM, Dominique Hazael-Massieux  wrote:
> Hi,
>
> I alluded to this during the joint F2F meeting between WebApps and DAP
> last week, but thought I would make the proposal more formally: given
> that the current “File API” [1] really defines a FileReader interface,
> and given that DAP is supposed to come up with a more generic
> filesystems API (including the possibility to write to files), I suggest
> that “File API” should be renamed to “FileReader API.”
>
> Dom
>
> 1. http://dev.w3.org/2006/webapi/FileAPI/
>
>
>
>

Rename “File API” to “FileReader API”?

[Dominique Hazael-Massieux]

Hi,

I alluded to this during the joint F2F meeting between WebApps and DAP
last week, but thought I would make the proposal more formally: given
that the current “File API” [1] really defines a FileReader interface,
and given that DAP is supposed to come up with a more generic
filesystems API (including the possibility to write to files), I suggest
that “File API” should be renamed to “FileReader API.”

Dom

1. http://dev.w3.org/2006/webapi/FileAPI/

Re: Constrained specification of Icon element

[Ola Andersson]

Hi,
I understand it might be too late to modify the spec now but I still think the 
spec isn't clear with regards to  size and should be clarified, maybe in 
some future version at least. I'm also not fully convinced your description 
(bottom of this mail) about clipping an SVG icon is correct. This is because 
the Widget P&C spec states for the  width/height attributes: "The width 
  is only applicable to graphic 
formats that have no intrinsic width or height (e.g., SVG)." However, SVG do 
have intrinsic size when SVG width/height are specified [1] (except in the case 
when widht/height are %-values) so the widget spec might want to clarify this 
and your example below should, according to the  definition, ignore the 
 width/height and render the icon using the intrinsic 1000x1000px size.

To me this behavior is not what you want, rather I propose the following 
changes to the  size:

1. For the widget  element's width and height attributes the spec should 
state that the width and height attribute values are to be seen as a guide to 
the UA in order for the widget provider to indicate the preferred size of the 
icon. The UA is allowed to ignore the width/height in order to change the size 
of the icon, exampels of when this might occur is if a UA is to display icons 
from different providers in a single GUI (and thus prefer to display them all 
at the same size). Or if a UA needs to enlarge icons in a GUI due to 
accessability requirements (vision impaired users...) 

2. icon width/height attributes should apply to all graphic formats, not just 
those without intrinsic size. Having this would make it possible to reuse the 
same icon resource for multiple resolutions. The following example (almost from 
the widget spec): 

 
 
 

could then be rewritten as: 

 
 
 

Which would save the author the work of creating different pngs, and save 
bandwith. All UAs have features for raster scaling so no issue with that. 

Best regards
/ola andersson


[1] http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementWidthAttribute


>>2009/11/2 Magnus Olsson >
>> >

>>  The icon element 
>> (*http://dev.w3.org/2006/waf/widgets/#icon0*>  
>> 
>>  >)
>> has width/height properties which only applies to SVG icons. To me the spec
>> isn't fully clear how to use them. Is it ok for a user agent to ignore the
>> width/height of an SVG icon? IMO it should be since it will be hard to do a
>> consistent "widget desktop manager" with widgets from multiple sources (and
>> therefore possibly with different width/height set) if the widget icons are
>> of different sizes. To me the width/height should just be a guide to the
>> user agent but the user agent should have the choice of scaling to the
>> appropriate size. This is of course also important for widgets intended to
>> run on multiple platforms with different screen sizes.
>>
>
>Yes, the user agent can decide how best to treat icons based on the
>available size. Where the width and height help is to establish the viewport
>(the window in which the SVG will be rendered).  So, if an SVG declares
>itself to be 1000 by 1000px (), but the
>width and height of the icon both say 100 pixels, then the rendered
>representation of the SVG will simply get clipped because it won't fit in
>the 100 by 100 viewport.

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


___

Ola Andersson 
Senior System Manager 
Solution Area TV (SATV)
BU Multimedia Products (BMUM)

Mobile: +46 761 441320
Email: ola.anders...@ericsson.com

Ericsson AB
Tellusborgsvägen 83-87
SE-126 37, Stockholm, Sweden
www.ericsson.com

Re: [WARP] Comments to WARP spec

[Marcos Caceres]

SULLIVAN, BRYAN L (ATTCINW) wrote:

Marcos,

Re "I'm personally not in favor of trying to deviate too much from the Web security model.": I agree with you, 
and that is the point of the comments. The "web security model" (I think you mean the same-origin restriction) 
does not restrict access to image content from anywhere, like the  element would. The  
element as currently in the WARP spec goes beyond the "web security model".

My point is that the statement below in the WARP spec needs to change, because this is not compatible with 
the "web security model", and also "makes more work for implementers" because the 
security model for widget-context webapps would not be the same as for browser-context webapps: "In the 
default policy, a user agent must deny access to network resources  external to the widget by default, 
whether this access is requested through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, 
img)."

So either:
(1) we need to be specific about which API's / resource types are affected by 
inclusion (or exclusion) of domains in  (and keep this equivalent to 
HTML5)
(2) we must add a way for the developer to indicate which types of references 
should be allowed for the domain

My preference would be (1), but I proposed the use of "tag=" to illustrate how 
(2) might work.



Again, @tag= assumes HTML. There could be many different variant start 
files in a widget. Consider the case where you have a compound XML 
document as the start file (HTML + SVG + Custom XML)... how would you 
say which element this applies to and in which namespace? Also "tag" 
makes no sense in the context of CSS, XHR, etc.