Re: [cors] unaddressed security concerns

[Maciej Stachowiak]

On Nov 5, 2009, at 6:04 PM, Devdatta wrote:


Hi Maciej,



Read 
 If the  resource is owned by the domain specified by Origin,  
return

the data.


.
CrossDomainCopydomain>

 


I don't understand the aim of the whole protocol you have outlined  
above.


I'm sorry, I outlined it in a pretty sketchy way because I was writing  
in a hurry and had other things to get to.


Are you saying CORS should be rewritten to directly support such a  
design ?


No - there are no changes to CORS needed to support it.



or Is this a design pattern you are recommending (for use with CORS) ?


This is a possible design when building applications that do cross- 
site networking, and in particular ones that may involve delegated  
requests or requests combining information from multiple sites.



If the latter, do you honestly expect web developers to read and
understand all that ?


The complexity in my proposed protocol is not related to CORS - you'd  
face the same complexity or greater doing a purely token-based  
protocol over something like GuestXHR. And you can use a much simpler  
approach with CORS if you are only doing simpler two-party interactions.



Or have I missed the point completely ?


I wouldn't put it that way. I wrote something without a simple  
explanation assuming readers would have context and I guess it  
confused you, which is my fault. Sorry!


 - Maciej

Re: [cors] unaddressed security concerns

[Maciej Stachowiak]

Hi Tyler,

On Nov 5, 2009, at 5:48 PM, Tyler Close wrote:


Closing remark:

In another thread, you've written "I do think that a way to do an
anonymous XHR is justified", so I don't know how much sense it makes
to continue this thread. You put so much effort into this email that I
felt I owed you a response.


Let me make sure I understand your position and overall goal in this  
discussion. Is it:


A) An API to do anonymous XHR (such as GuestXHR) should be provided  
*AND* CORS should be abandoned (and perhaps removed from  
implementations shipping it.


OR:

B) An API to do anonymous XHR (such as GuestXHR) should be added, but  
you can live with CORS continuing to exist.



I thought your position was (A). If it is in fact (B), then perhaps we  
have all invested more energy than necessary in this debate, because I  
don't think (B) is especially controversial. But if your position is  
(A), then the statement you quoted wasn't meant to agree with that  
position (in case it wasn't clear).



That being said, I feel the input from you and Mark and the ensuing  
discussion has helped the Working Group get a better understanding of  
the security issues in this area, and I believe it will help us make a  
high-quality Security Considerations section. So if you have further  
replies in mind that would help inform the conversation, then please  
feel encouraged to send them.


Regards,
Maciej

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

[Adam Barth]

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 the HTTP
>> specification because the server changes state in response to a GET
>> request.  Presumably, you mean to use a 307 redirect and a POST
>> request.  Unfortunately, that means the protocol will generate a
>> warning dialog in Firefox and will fail completely in Safari 4.
>
> I just said 303 because it was the most succinct way of expressing the
> relevant part of the communication. In deployment, a better solution
> would be to send back a normal 200 response with JavaScript code that
> does an automated form POST of the same data to Server B.
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>

Re: [cors] unaddressed security concerns

[Devdatta]

Hi Maciej,

>
> Read 
>   If the  resource is owned by the domain specified by Origin, return
> the data.
>
.
> CrossDomainCopy
>  

I don't understand the aim of the whole protocol you have outlined above.

Are you saying CORS should be rewritten to directly support such a design ?

or Is this a design pattern you are recommending (for use with CORS) ?

If the latter, do you honestly expect web developers to read and
understand all that ?

Or have I missed the point completely ?

Cheers
Devdatta

Re: [cors] unaddressed security concerns

[Tyler Close]

Hi Maciej,

Responses inline below...

On Wed, Nov 4, 2009 at 9:36 PM, Maciej Stachowiak  wrote:
>
> On Nov 3, 2009, at 5:33 PM, Tyler Close wrote:
>> On Mon, Oct 12, 2009 at 7:19 AM, Maciej Stachowiak  wrote:
>>>
>>> As a side note, I should add that Tyler's scenario would be much simpler
>>> overall if printer.example.net used a grant of read access to the photo
>>> it
>>> wants to print on storage.example.org, instead of granting write access
>>> to a
>>> new location.
>>
>> In this scenario, photo.example.com has the opportunity to take the
>> role of attacker in a CSRF-like attack. In the legitimate case,
>> photo.example.com is expected to send a URL to printer.example.net
>> which identifies the photo to be printed, such as
>> . In the attack case,
>> photo.example.com could send the URL that identifies the
>> printer.example.net client list, such as
>> . Consequently,
>> photo.example.com receives a print out of the printer.example.net
>> client list, instead of a photo printout.
>
> What's the attack here? Is it information disclosure or vandalism?

The problem is information disclosure. My understanding of your
proposed design was that photo.example.com would grant read access
over a file to printer.example.net and send the file's URL to
printer.example.net. The printer.example.net would then use its own
credentials to read the file content, print it out and mail it to the
recipient. In the legitimate case, photo.example.com grants read
access to a photo file that it owns. In the attack case,
photo.example.com sends a URL for the printer.example.net client list.
The printer.example.net site already has permission to read its own
file, so it prints it out and mails it to the attacker.

Perhaps this design is not what you originally intended, but it was my
understanding from the original email:

http://www.w3.org/mid/5d7511b2-da9d-40af-a536-d799fb6ee...@apple.com
"""
As a side note, I should add that Tyler's scenario would be much
simpler overall if printer.example.net used a grant of read access to
the photo it wants to print on storage.example.org, instead of
granting write access to a new location. Or it can just ask
photo.example.com to read the photo from storage.example.org and send
the actual data. Either of these much less abusable than writing, and
would be a safer approach, whether or not the overall design depends
on secret tokens. The grant of read access can be one-time or time-
limited if necessary. Thus, I think the scenario is somewhat
contrived. Likely cross-site interactions would not involve such a
complex process to transfer data. The root of the vulnerability in
Tyler's scenario is writing in a shared namespace to transfer data,
instead of simply granting read access to the existing copy, or
transferring the actual data bits.
"""

Either way, this was an older email and I am happy to move on to
discuss your most current thinking on this topic.

> That being said, my understanding of this threat was greatly improved by the
> discussion at TPAC. I now think the best way to address multi-site
> collaboration is by applying the DBAD discipline. Here's how I would do it
> in this case:
>
> The storage service is designed to allow collaborative access by multiple
> sites, therefore it needs to let them distinguish their own requests from
> third-party requests. One way to do so is to partition resources such that
> each is owned by exactly one storage domain. The only way to share
> information cross-domain is to copy. Resource names include the domain that
> owns them. Then it offers the following command set (angle brackets are used
> to delimit metasyntactic variables):
>
> (This may be more complicated than needed, for the sake of clarity):
>
> Read 
>   If the  resource is owned by the domain specified by Origin, return
> the data.
>
> Write \n
> 
>   If the  resource is owned by the domain specified by Origin, store
>  at the resource.
>
> SameDomainCopy  
>    and  must be in the same domain and must match Origin.
>
> GetReadToken 
>   If the Origin header matches , return a one-time read token
> which can be used to copy a resource cross-domain
>
> GetWriteToken 
>   If the Origin header matches , return a one-time read token
> which can be used to copy a resource cross-domain
>
> CrossDomainCopy
>  
>     must be a valid read token for , and
>  must be owned by .  must be a
> valid write token for , and  must be owned by
> . Origin must match at least one of  or .
>
> This allows two sites to agree to copy a resource from one to the other on
> storage.exmple.org without introducing a confused deputy hazard.
>
> In the original scenario, photo.example.com would get a resource name and a
> write token from printer.example.net, would obtain its own read token for
> the resource to copy using GetReadToken, and then issue a copy request with
> both domains and both tokens using CrossDomainCopy. It's i

Re: Use Cases and Requirements for Saving Files Securely

[Eric Uhrhane]

On Mon, Nov 2, 2009 at 11:01 PM, Jonas Sicking  wrote:
> On Mon, Nov 2, 2009 at 12:48 PM, Doug Schepers  wrote:
>> Hi, Folks-
>>
>> During the TPAC joint meeting between the WebApps and DAP WGs, we discussed
>> security policies and use cases and requirements around saving files in
>> different scenarios: public web resources (web pages and apps), widgets,
>> mobile device and desktop browsers, locally-installed applications, etc. [1]
>>
>> To kick this thread off, I'd like to suggest the trust model that already
>> exists for local applications and browsers, which is to open a modal dialog
>> that allows the user to select the file the application can save to; for
>> webapps, I suggest the extra security consideration we add is to have the
>> file hook which is returned is completely opaque (as far as the directory
>> and file name) to the web app, and it just knows where to write.  Further,
>> we should limit the upper bounds of the file size. I don't have any thoughts
>> about auto-save across sessions, but it should be addressed (probably not
>> allowed).

For a single-object save [Jonas's #1 below], I think this all sounds
good.  I'm not sure about the file size limit, though.  The user's
explicitly asked to save the file, and if it's too big, they'll know
what the problem is.  I could see requiring a page to state in advance
how big a file it wanted to save, so that the UA could warn the user
beforehand, but I think enforcing an arbitrary cap isn't flexible
enough.

I agree that auto-save across sessions should be ruled out for now.

I'd also like to emphasize that the ability to write a file shouldn't
confer the ability to read it.  You might be overwriting data that's
none of your business, and the UA can handle the "Are you sure?"
prompts.

>> This could be evoked through the UI convention of a file dialog, or just as
>> a bare API (if the user preferences allow the API to ask about saving
>> files).  In any case, it should never be a "cool" webapp-specific file API
>> dialog, only ever the native dialog of the browser (be it a desktop or
>> mobile).
>>
>> Please send in use cases, requirements, concerns, and concrete suggestions
>> about the general topic (regardless of your opinion about my suggestion).
>>
>> [1] http://www.w3.org/2009/11/02-dap-irc#T20-40-39-1
>
> It seems to me that there were (at least) two types of 'save' features
> being discussed today.
>
> 1. The ability for something like google docs to bring up a "save as"
> dialog to save the document in a user chosen location.
> 2. The ability for pages to write to a virtual filesystem using a
> location and name picked by the page.
>
> It sounds like you are primarily referring to the first of these, is
> that a correct understanding?
>
> I agree that this seems like a good place to start. You can actually
> do this already, although it's far from elegant:
>
> a = document.createElement('a');
> document.body.appendChild(a);
> a.href = "data:application/octet-stream;base64,...";
> a.click();
>
> I believe that will bring up the standard browser save-as dialog.
> Obviously it would be nice to have something better than that. I think
> what we need is something is:
>
> * A way to create a Blob object based on data created by the page.

Yes, absolutely.

> * An API that given a Blob shows a "safe file as" dialog to the user.

This is a little trickier. I think it would be better to require
asynchronous user intervention, rather than have a call that trivially
brings up a modal dialog.  How about a new HTML element similar to the
current selector for input files, but which when triggered by a user
action brings up a save-as dialog?  If that dialog triggered an event
that carried a writable file handle encapsulation [a FileWriter
similar to Arun's FileReader [1]], we could then pass it a blob to
complete the save.

It would be quite convenient if Jian Li's drag-out [2] and the save-as
dialog could share a similar interface.  I'm not quite sure what that
would look like, though...it would be simpler just to be able to point
the dataTransfer DownloadURL to a URN created from the source blob.
Currently in Arun's spec there's no way to go from blob to URN--urn is
a member on the derived interface File--but I've just posted a
suggestion [3] that we provide one.

> I think the former is something we'll need anyway, and once we have
> that the latter is an easy addition.

Agreed; we can build up in easy layers.

Arun's spec gives us file input, given a read handle.
#1 above gives us file output, given a write handle.
The next layer [#2 above] lets apps manage sandboxed local caches
without user intervention.  This would be a fine place to introduce
directories.
After that, we can consider access to the filesystem at large, a much
harder feature to get right.

 Eric

[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022118.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2

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

[Eric Uhrhane]

Arun:

I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places.  I think that's an excellent goal, but of course,
having said that, I am immediately going to suggest that you add
something to it.
   How would you feel about exposing a way to produce a URN from a
Blob, instead of just getting one from a File?  This seems likely to
have wide-ranging uses.  Pretty much anywhere you have a blob of data,
you might want to hand it off to the browser, even if it didn't come
from, or wasn't, a single user-supplied file.  Here are a few use
cases, but I'm sure more won't be hard to come up with:

* Viewing a single chapter of a book in a frame.
* Slicing one episode out of a DVD and handing it to the video tag, so
that the player controls start and end at the episode boundaries.
* Analogous to the game-asset archive I mentioned at [1], one might
pack a number of small files together to speed download [using only
HTTP compression], then parse them apart on the client.  Picture a
Picasa client written in the web browser; it's got to handle maybe
1+ thumbnails, and putting each in a separate file would be
terribly inefficient.  Pulling down a tarfile would be a lot quicker.

In order for the URN to be useful, it would have to have a mediaType
associated with it, and then there's content-disposition to think
about, which then wants a file name as well...boy, that's a lot of
baggage.  However, since these aren't really inherent properties of
the Blob, just of the way you want the browser to view the Blob, it
would seem natural to me do to something like this:

interface Blob {
  ...
  DOMString getURN(in DOMString mediaType,
   [Optional] in DOMString contentDisposition,
   [Optional] in DOMString name);
};

Given that a File that one gets from the user will still tell you its
name and detected mediaType, and can have a constant urn, there seems
to be no conflict in leaving the File interface as-is and adding
something like getURN to Blob.  On the off chance that you want to
override the detected mediaType for a file, force a contentDisposition
of attachment, or change the name, you might still use getURN there as
well.

This is a pure addition to your spec, so I think we can discuss it in
parallel with the publication of the WD.  I don't want to suggest that
this slow anything else down.

  Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html

On Mon, Oct 26, 2009 at 4:24 AM, Arun Ranganathan  wrote:
> The latest revision of the FileAPI editor's draft is available here:
>
> http://dev.w3.org/2006/webapi/FileAPI/
>
> These changes constitute a substantial reworking of the original API along
> the lines of the "Alternative File API" proposal [1].  There are also some
> additional changes that are worth pointing out explicitly:
>
> 1. This editor's draft now resides in a new location in CVS.  Essentially,
> previous repository names had "FileUpload" in them and were confusing, since
> the API in question had less to do with *uploading a file* than *reading* a
> file.  "FileAPI" is shorter and more intuitive (and better describes what
> we're doing).  Previous drafts are worth keeping as historical artifacts
> reflecting the decision making of the WG, and so now include a caveat on
> them pointing them to the draft above.
>
> 2. Interface names have changed (notably FileData --> Blob) since the
> underlying FileData interface had uses on the platform beyond a file read
> API.  "Blob" as an interface name was first introduced by a Google Gears
> API, which I cite as an informative reference.
>
> 3. The event model resembles that of XHR2, with a few differences.  Notably,
> the APIs differ in their use of the 'loadend' ProgressEvent.
>
> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
> urn:uuid:[2] has been the basis of a rewrite of that feature in this
> version of the specification.
>
> I don't anticipate the event model will be controversial, having seen a fair
> amount of discussion on the listserv.  But I do anticipate feedback about
> 4., as well as the remaining editor's notes.
>
> Looking forward to discussion of this API on this listserv and at the
> upcoming TPAC :)
>
> -- A*
> [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
> [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0091.html
>
>

Binary data (ByteArray/ByteVector) proposal on public-script-coord

[Maciej Stachowiak]

I pulled together a rough proposal for representing binary data in  
ECMAScript and posted it on public-script-coord. I think having this  
is important for many W3C (and particularly WebApps WG) specs, but it  
is probably best defined in ECMAScript. I'm posting a link here in  
case anyone is interested and is not on the public-script-coord  
mailing list yet:


http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html

Regards,
Maciej

Re: bug in example

[Ian Hickson]

On Wed, 4 Nov 2009, Bennet Yee (ä½~Yä»~Uæ~V~L) wrote:
> 
> my apologies in advance if this has already been noted.  i recently was 
> introduced to http://dev.w3.org/2006/webapi/FileAPI/ and noticed that 
> the first example appears to have the following race condition: in 
> getAsText, reader.readAsText occurs before any event callbacks are set, 
> so if the completion occurs after read.readAsText(...) and 
> reader.onprogress = ..., .onload = ... etc, then no callbacks will ever 
> get called.  or am i misunderstanding the way the callbacks are supposed 
> to work -- i.e., they're level triggered and not edge triggered?  (i'd 
> imagine onprogress shouldn't be level triggered.)

Events are asynchronous, so they never trigger before the script has 
finished (including setting the event handler attributes).

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

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

[Tyler Close]

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 the HTTP
> specification because the server changes state in response to a GET
> request.  Presumably, you mean to use a 307 redirect and a POST
> request.  Unfortunately, that means the protocol will generate a
> warning dialog in Firefox and will fail completely in Safari 4.

I just said 303 because it was the most succinct way of expressing the
relevant part of the communication. In deployment, a better solution
would be to send back a normal 200 response with JavaScript code that
does an automated form POST of the same data to Server B.

--Tyler

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

Re: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November

[Maciej Stachowiak]

On Nov 5, 2009, at 10:51 AM, Jeremy Orlow wrote:


On Thu, Nov 5, 2009 at 10:42 AM, Ian Hickson  wrote:
On Wed, 4 Nov 2009, Nikunj R. Mehta wrote:
> On Nov 4, 2009, at 8:42 PM, Jonas Sicking wrote:
> >
> > I know we had this conversation before, and I'm not even sure  
which

> > side of the issue I was on at the time, but given the amount of
> > confusion at the TPAC meeting yesterday, I think we should  
consider

> > renaming the "Web Database" spec.
>
> I am glad you recognize this issue now (noting that I raised this  
point

> in July [1] when. At that time we proposed that this spec be called
> SQLDatabase or WebSQLDatabase.

At the time, I was assuming we would have just the one database  
spec, so

Web Database made sense as a I name. Given the new direction of the
working group, I agree that renaming Web Database to Web SQL  
Database or

something would be sensible. We should probably also rename Web Simple
Database to something more descriptive, so that people can distinguish
them more easily.

I strongly agree.


I agree with renaming both. Would "Web B-Tree Database" be an accurate  
description of SimpleDB? Does anyone else have a more accurate term?


Regards,
Maciej

Re: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November

[Jeremy Orlow]

On Thu, Nov 5, 2009 at 10:42 AM, Ian Hickson  wrote:

> On Wed, 4 Nov 2009, Nikunj R. Mehta wrote:
> > On Nov 4, 2009, at 8:42 PM, Jonas Sicking wrote:
> > >
> > > I know we had this conversation before, and I'm not even sure which
> > > side of the issue I was on at the time, but given the amount of
> > > confusion at the TPAC meeting yesterday, I think we should consider
> > > renaming the "Web Database" spec.
> >
> > I am glad you recognize this issue now (noting that I raised this point
> > in July [1] when. At that time we proposed that this spec be called
> > SQLDatabase or WebSQLDatabase.
>
> At the time, I was assuming we would have just the one database spec, so
> Web Database made sense as a I name. Given the new direction of the
> working group, I agree that renaming Web Database to Web SQL Database or
> something would be sensible. We should probably also rename Web Simple
> Database to something more descriptive, so that people can distinguish
> them more easily.
>

I strongly agree.

Re: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November

[Ian Hickson]

On Wed, 4 Nov 2009, Nikunj R. Mehta wrote:
> On Nov 4, 2009, at 8:42 PM, Jonas Sicking wrote:
> > 
> > I know we had this conversation before, and I'm not even sure which 
> > side of the issue I was on at the time, but given the amount of 
> > confusion at the TPAC meeting yesterday, I think we should consider 
> > renaming the "Web Database" spec.
> 
> I am glad you recognize this issue now (noting that I raised this point 
> in July [1] when. At that time we proposed that this spec be called 
> SQLDatabase or WebSQLDatabase.

At the time, I was assuming we would have just the one database spec, so 
Web Database made sense as a I name. Given the new direction of the 
working group, I agree that renaming Web Database to Web SQL Database or 
something would be sensible. We should probably also rename Web Simple 
Database to something more descriptive, so that people can distinguish 
them more easily.

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