from:"Maciej Stachowiak"




On May 12, 2008, at 9:38 AM, Bjoern Hoehrmann wrote:


* Maciej Stachowiak wrote:

You can just use `function(p) { return namespaces[p]; }` then.


Sure, but there's no actual need to allow running arbitrary code and
all the risks that creates/


Which is no risks at all. You can simply parse the selector for the  
pre-
fixes, resolve all the distinct ones and the default namespace, then  
use

the gathered information in the selection process. That's no different
than the calling script doing the same, filling a table in the  
process,
and passing the table. If you want to do something more clever, you  
may

also cleverly shoot yourself in the foot, yes.


It is better API design to remove the possibility of some categories  
of errors.


(There are other problems with using an object like the one you  
propose,

like being unable to specify a default namespace, unless you introduce
some kind of magic prefix representing the default namespace;  
ultimately

you don't gain much; you could also just accept a simple string in the
form "prefix1=ns1 prefix2=ns2 ..." like MSXML does for XPath, but  
there

isn't really a problem worth solving with the resolver function.)


I'm convinced. I like the string better than my proposal. It removes  
the need to specify anything regarding setters or other language  
bindings.


Using a function does not seem to provide any value over providing the  
data in some trivial static form, and at least some complications. It  
seems like the only reason we have that design in the spec is inertia.  
Are you willing to argue that it is better than other solutions on the  
merits, for any reason other than it happens to be what is already in  
the draft spec?


Regards,
Maciej

Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1




On May 12, 2008, at 8:00 AM, Bjoern Hoehrmann wrote:


* Maciej Stachowiak wrote:

This does not look much better (it does avoid repeatedly mentioning
the xmlns namespace at least):

function resolver(prefix) {
   if (prefix == "xht") {
return "http://www.w3.org/1999/xhtml";;
   } else if if (prefix == "svg") {
return "http://www.w3.org/2000/svg";;
   } else if (prefix == "mml") {
return "http://www.w3.org/2000/xmlns/";;
   }
   return null; // ???
}

However, this does look better:

var namespaces = {xht: "http://www.w3.org/1999/xhtml";; svg: 
"http://www.w3.org/2000/svg
"; mml: "http://www.w3.org/1998/Math/MathML"; };


You can just use `function(p) { return namespaces[p]; }` then.


Sure, but there's no actual need to allow running arbitrary code and  
all the risks that creates/


You'll have to define what happens if you pass `{ get svg()  
{ ... } }` if you

allow this,


I would define that getters are ignored (after all, the point of this  
is to avoid code execution)



and what to pass in other language bindings.


Other language bindings are the 1% case for this API (and that's being  
generous). They can just use Nodes. Or anyone who wishes to champion a  
more convenient syntax for some specific binding can propose what  
language-specific dictionary type should be allowed to use Nodes.


Regards,
Maciej

Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1




On May 12, 2008, at 6:16 AM, Lachlan Hunt wrote:



This is possible, since the spec is already compatible with  
Node.lookupNamespaceURI().  I think it would just require that a  
Node be passed and ignore any other type of object.  But, there are  
a few problems with the approach.


If scripts were to use elements from the actual document to obtain  
prefixes, it ties the script to that document and others that use  
the same prefixes only.  Scripts intended for reuse elsewhere would  
need to construct their own node and set all necessary namespaces.


The code for creating that is, unfortunately, a little complex, and  
so it is not ideal.


var nsresolver = document.createElementNS("http://www.w3.org/1999/xhtml 
", "div");

nsresolver.setAttributeNS("http://www.w3.org/2000/xmlns/";, "xmlns",
 "http://www.w3.org/1999/xhtml";);
nsresolver.setAttributeNS("http://www.w3.org/2000/xmlns/";,  
"xmlns:svg",

 "http://www.w3.org/2000/svg";);
nsresolver.setAttributeNS("http://www.w3.org/2000/, "xmlns:math",
 "http://www.w3.org/1998/Math/MathML/";);


With HTML5 available (and therefore innerHTML on XML nodes), I'd do it  
like this:


var doc = document.implementation.createDocument();
doc.firstChild.innerHTML=
   'http://www.w3.org/1999/xhtml"; xmlns:svg="http://www.w3.org/2000/svg 
" xmlns:math="http://www.w3.org/1998/Math/MathML/"; />';

var nsNode = doc.firstChild.firstChild;

That doesn't look so bad for authors. But see also my alternative  
proposal.


The Namespace URI Lookup algorithm [1] seems to indicate that the  
element needs to have an expicit xmlns attribute set in order to get  
the default namespace from its value, instead of just obtaining it  
from the element's actual namespace.  But the problem is,  
implementations don't agree with each other.  They also don't agree  
on what to return when the paramter is null, undefined or "".


If querySelector takes a node, it doesn't matter what the Namespace  
URI Lookup algorithm says because Selectors API can iteself spec  
something useful and consistent notwithstanding what  
Node.lookupNamespaceURI does.


The bottom line here is that we're trying to represent what should  
really be a simple dictionary with a function, and it creates all  
sorts of unnecessary complexity.


Regards,
Maciej

Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1




On May 12, 2008, at 5:52 AM, Bjoern Hoehrmann wrote:


* Maciej Stachowiak wrote:
A function is not a particularly convenient way to specify a  
namespace
mapping, and it creates these error handling issues as well as  
causing

problems with case (in)sensitivity. Even though NSResolver is what
XPath uses, wouldn't it be simpler to just accept an object that
provides the relevant namespace mappings?


That would preclude simple solutions to the resolution problem like
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0204.html

I originally thought that >this could be a JSON-style JavaScript  
object,

but it seems to me that a DOM node would actually work just as well.
Most of the time, you want to use the namespace prefixes in effect  
for

the root element, and if not, then it is pretty simple to construct a
DOM node with all the right xmlns declarations.


That would not have the particular problem above, but many others.
I do not think you want the prefixes on the document element most
of the time, it is not as easy to create such a node as you suggest,
and all in all this would likely cause great confusion. It's hard
to imagine the typical user of this API using code like this:

 var node = document.createElementNS(null, "magic-ns-element");
 node.setAttributeNS('http://www.w3.org/2000/xmlns/',
   'xmlns:xht', 'http://www.w3.org/1999/xhtml');
 node.setAttributeNS('http://www.w3.org/2000/xmlns/',
   'xmlns:svg', 'http://www.w3.org/2000/svg');
 node.setAttributeNS('http://www.w3.org/2000/xmlns/',
   'xmlns:mml', 'http://www.w3.org/1998/Math/MathML');

I think this would be a very bad idea.


This does not look much better (it does avoid repeatedly mentioning  
the xmlns namespace at least):


function resolver(prefix) {
if (prefix == "xht") {
return "http://www.w3.org/1999/xhtml";;
} else if if (prefix == "svg") {
return "http://www.w3.org/2000/svg";;
} else if (prefix == "mml") {
return "http://www.w3.org/2000/xmlns/";;
}
return null; // ???
}

However, this does look better:

var namespaces = {xht: "http://www.w3.org/1999/xhtml";; svg: "http://www.w3.org/2000/svg 
"; mml: "http://www.w3.org/1998/Math/MathML"; };


I therefore make a second proposal to accept either vanilla JS objects  
of this format or DOM nodes, instead of NSResolver objects.


Regards,
Maciej

Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1




On May 12, 2008, at 12:44 AM, Jonas Sicking wrote:



Lachlan Hunt wrote:

Jonas Sicking wrote:
What are the remaining issues that are still holding us back? It  
seems to me like if we know we're going to add this in a version  
2, but we already have a done specification for it, why not  
include it?
In relation to the NSResolver, the major issue is that I need to  
define how to handle hostile NSResolvers and deal with unexpected  
DOM modifications.


I don't actually think there is a lot to do spec-wise here. IMHO all  
that is needed is to say something like:


"An implementation encouraged to deal with hostile NSResolvers and  
are allowed to throw an exception if such resolvers are detected".


Having considered it for some time, I think running arbitrary code to  
resolve namespace prefixes is a bad approach.


A function is not a particularly convenient way to specify a namespace  
mapping, and it creates these error handling issues as well as causing  
problems with case (in)sensitivity. Even though NSResolver is what  
XPath uses, wouldn't it be simpler to just accept an object that  
provides the relevant namespace mappings? I originally thought that  
this could be a JSON-style JavaScript object, but it seems to me that  
a DOM node would actually work just as well. Most of the time, you  
want to use the namespace prefixes in effect for the root element, and  
if not, then it is pretty simple to construct a DOM node with all the  
right xmlns declarations. I think this would be better than copying  
the bad NSResolver design from XPath. It would also likely be more  
efficient, and quite possibly less error-prone.


It seems to me that implementations aren't going to be affected  
one way or the other on this. If we do include it in the spec  
anyone can still implement everything but namespaced selectors. I  
think implementors are competent enough to prioritize  
appropriately without us holding their hand. Especially if their  
CSS engine does not yet support namespaced selectors.

...

I guess except that they couldn't do silly PR claims like "full  
Selectors API v1 support"). If we wanted to satisfy such desires  
we could say that it's ok to claim full support even without  
NSResolver if your CSS engine does not support namespaced selectors.
I decided to retain the NSResolver in the spec for now.  However, I  
have made support for it optional and defined that if it isn't  
supported, a NOT_SUPPORTED_ERR exception must be raised if an  
NSResolver is passed.


Sounds good to me.


I'm not very happy with this because it precludes coming up with a  
better solution than NSResolver.


Regards,
Maciej

Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)




On May 11, 2008, at 6:01 PM, Aaron Boodman wrote:

On Sun, May 11, 2008 at 5:46 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:
Well, that depends on how good the OS buffer cache is at  
prefetching. But in

general, there would be some disk access.


It seems better if the read API is just async for this case to prevent
the problem.


It can't entirely prevent the problem. If you read a big enough chunk,  
it will cause swapping which hits the disk just as much as file reads.  
Possibly more, because real file access will trigger OS prefetch  
heuristics for linear access.


I see what you mean for canvas, but not so much for XHR. It seems  
like
a valid use case to want to be able to use XHR to download very  
large
files. In that case, the thing you get back seems like it should  
have

an async API for reading.


Hmm? If you get the data over the network it goes into RAM. Why  
would you
want an async API to in-memory data? Or are you suggesting XHR  
should be
changed to spool its data to disk? I do not think that is practical  
to do
for all requests, so this would have to be a special API mode for  
responses

that are expected to be too big to fit in memory.


Whether XHR spools to disk is an implementation detail, right? Right
now XHR is not practical to use for downloading large files because
the only way to access the result is as a string. Also because of
this, XHR implementations don't bother spooling to disk. But if this
API were added, then XHR implementations could be modified to start
spooling to disk if the response got large. If the caller requests
responseText, then the implementation just does the best it can to
read the whole thing into a string and reply. But if the caller uses
responseBlob (or whatever we call it) then it becomes practical to,
for example, download movie files, modify them, then re-upload them.


That sounds reasonable for very large files like movies. However,  
audio and image files are similar in size to the kinds of text or XML  
resources that are currently processed synchronously. In such cases  
they are likely to remain in memory.


In general it is sounding like it might be desirable to have at least  
two kinds of objects for representing binary data:


1) An in-memory, mutable representation with synchronous access. There  
should also be a copying API which is possibly copy-on-write for the  
backing store.


2) A possibly disk-backed representation that offers only asynchronous  
read (possibly in the form of representation #1).


Both representations could be used with APIs that can accept binary  
data. In most cases such APIs only take strings currently. The name of  
representation #2 may wish to tie it to being a file, since for  
anything already in memory you'd want representation #1. Perhaps they  
could be called ByteArray and File respectively. Open question: can a  
File be stored in a SQL database? If so, does the database store the  
data or a reference (such as a path or Mac OS X Alias)?


Regards,
Maciej

Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)




On May 11, 2008, at 4:40 PM, Aaron Boodman wrote:

On Sun, May 11, 2008 at 4:22 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:
Here's one additional question on how this would work with  
ByteArray.
The read API for ByteArray is currently synchronous. Doesn't this  
mean

that with large files accessing bytearray[n] could block?


If the ByteArray were in fact backed by a file, then accessing  
bytearray[n]
could lead to part of the file being paged in. However, the same is  
true if

it is backed by RAM that is swapped out. Even accessing uninitialized
zero-fill memory could trap to the kernel, though that's in general  
not as

bad as hitting disk (whether for swap or file bytes).


But expressing the API as an array makes it seem like access is always
cheap, encouraging people to just burn through the file in a tight
loop. Such loops would actually hit the disk many times, right?


Well, that depends on how good the OS buffer cache is at prefetching.  
But in general, there would be some disk access.


I can see how you may want to have an object to represent a file  
that can be
handed to APIs directly, but that has only an async read interface  
for JS.

However, I am pretty sure you would not want to use such an object to
represent binary data returned from an XHR, or the pixel contents  
of a
. After all, the data is already in memory. So perhaps  
files need a
distinct object from other forms of binary data, if we wanted to  
enforce

such a restriction.


I see what you mean for canvas, but not so much for XHR. It seems like
a valid use case to want to be able to use XHR to download very large
files. In that case, the thing you get back seems like it should have
an async API for reading.


Hmm? If you get the data over the network it goes into RAM. Why would  
you want an async API to in-memory data? Or are you suggesting XHR  
should be changed to spool its data to disk? I do not think that is  
practical to do for all requests, so this would have to be a special  
API mode for responses that are expected to be too big to fit in memory.


Regards,
Maciej

Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)




On May 11, 2008, at 4:08 PM, Aaron Boodman wrote:

On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:
Both of these can be addressed by the APIs (including the worker  
transfer
mechanism) making a copy, which can use a copy-on-write mechanism  
to avoid

actually making a copy in the common case.


Ok, so just so I'm clear, does the following example snippet
accurately reflect how you propose that things work?


I'm not sure I am following it all exactly, but I think yes. Variable  
assignment would not trigger any copy-on-write behavior, since it is  
still the same object. Passing to an API (including sendMessage to a  
worker) would make a copy-on-write virtual copy.





var req = new XMLHttpRequest();
req.open("GET", "example", true);
req.onreadystatechange = handleResult;
req.send(null);

function handleResult() {
 if (req.readyState != 4) return;

 var b1 = req.responseByteArray;
 var b2 = b1;
 assert(b1 === b2); // they refer to the same object

 // print the contents of the array
 for (var i = 0; i < b1.length; i++) {
   print(b1[i]);
 }

 b1[0] = 42;
 assert(b2[0] == 42);

 var worker = window.createWorker("worker.js");
 worker.sendMessage(b1); // branches b1
 b1[0] = 43; // modification does not affect what got sent to worker
}

// worker.js
worker.onmessage = function(b) {
 assert(b[0] == 42);
};







I'm still not convinced that immutability is good, or that the  
ECMAScript

ByteArray proposal can't handle the required use cases.


Here's one additional question on how this would work with ByteArray.
The read API for ByteArray is currently synchronous. Doesn't this mean
that with large files accessing bytearray[n] could block?


If the ByteArray were in fact backed by a file, then accessing  
bytearray[n] could lead to part of the file being paged in. However,  
the same is true if it is backed by RAM that is swapped out. Even  
accessing uninitialized zero-fill memory could trap to the kernel,  
though that's in general not as bad as hitting disk (whether for swap  
or file bytes).


I can see how you may want to have an object to represent a file that  
can be handed to APIs directly, but that has only an async read  
interface for JS. However, I am pretty sure you would not want to use  
such an object to represent binary data returned from an XHR, or the  
pixel contents of a . After all, the data is already in  
memory. So perhaps files need a distinct object from other forms of  
binary data, if we wanted to enforce such a restriction.


Regards,
Maciej

Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)




On May 10, 2008, at 11:39 PM, Chris Prince wrote:



On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:

I'm not really clear on why Blobs must be distinct from ByteArrays.
The only explanation is: "The primary difference is that Blobs are
immutable*, and can therefore represent large objects." But I am not
sure why immutability is necessary to have the ability to represent
large objects. If you are thinking immutability is necessary to be
able to have large objects memory mapped from disk, then mmap with a
private copy-on-write mapping should solve that problem just fine.


Making Blobs immutable simplifies a number of problems:

(1) Asynchronous APIs.

Large Blobs can be passed to XmlHttpRequest for an asynchronous POST,
or to Database for an asynchronous INSERT.  If Blobs are mutable, the
caller can modify the contents at any time.  The XmlHttpRequest or
Database operation will be undefined.

Careful callers could wait for the operation to finish (at least in
these two examples; I'm not sure about all possible scenarios).  But
this is starting to put quite a burden on developers.

(2) HTML5 Workers.

There are cases where apps will get a Blob on the UI thread, and then
want to operate on it in a Worker.  Note that the Blob may be
file-backed or memory-backed.

Worker threads are isolated execution environments.  If Blobs are
mutable, it seems like tricky (or impossible) gymnastics would be
required to ensure one thread's file writes aren't seen by another
thread's reads, unless you create a copy.  And that is doubly true for
memory-backed blobs.

(I'm not even considering older mobile operating systems, which may
not have all the file and memory capabilities of modern OSes.)


Both of these can be addressed by the APIs (including the worker  
transfer mechanism) making a copy, which can use a copy-on-write  
mechanism to avoid actually making a copy in the common case.


It seems like immutability creates its own problems. If you have a  
large piece of binary data, say retrieved over the network from XHR,  
and the only way to change it is to make a copy, and you have multiple  
pieces of your code that want to change it, you are going to be  
allocating memory for many copies.


(I should add that I also find the name "Blob" distasteful in an API,  
but that is a minor poin).


I'm still not convinced that immutability is good, or that the  
ECMAScript ByteArray proposal can't handle the required use cases.


Regards,
Maciej

Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)

2008-05-10 Thread Maciej Stachowiak




On May 7, 2008, at 10:08 PM, Aaron Boodman wrote:



Hi everyone,

Opera has a proposal for a specification that would revive (and  
supersede)

the file upload API that has been lingering so long as a work item.


The Gears team has also been putting together a proposal for file
access which overlaps in some ways with Opera's, but is also
orthogonal in some ways:

http://code.google.com/p/google-gears/wiki/BlobWebAPIPropsal


I really like the idea of adding consistent APIs for binary data in  
the many places in the Web platform that need them. However, I'm not  
really clear on why Blobs must be distinct from ByteArrays. The only  
explanation is: "The primary difference is that Blobs are immutable*,  
and can therefore represent large objects." But I am not sure why  
immutability is necessary to have the ability to represent large  
objects. If you are thinking immutability is necessary to be able to  
have large objects memory mapped from disk, then mmap with a private  
copy-on-write mapping should solve that problem just fine.


In fact, immutability seems clearly undesirable for many of these  
APIs. Seems like you will want to modify such things and create them  
from scratch.


I also notice that you used int64 in many of the APIs. JavaScript  
cannot represent 64-bit integers in its number type. All JavaScript  
numbers are IEEE floating point doubles. This will lose precision at  
the high end of the int64 range, which is likely unacceptable for many  
of these APIs. Thus, if 64-bit is really needed, then a primitive type  
will not do. You either need two int32s or an object type  
encapsulating this.


Regards,
Maciej





I would summarize the key differences this way:

* We introduce a new interface - a blob - that represents an immutable
chunk of (potentially large) binary data
* We propose adding the ability to get and send blobs to many
different APIs, including XHR, the  element,
database, , etc.
* We attempt far less interaction with the filesystem (just extending
the input element and allowing exporting a blob to a file).

To answer one of Maciej's questions from the other thread, we intend
this for use on the open web and do not intend for it to require any
particular security authorization.

We would also love feedback, and would like to work with any
interested vendors to iterate this to something others would
implement.

Thanks,

- a

Re: Security Re: File IO...

2008-05-08 Thread Maciej Stachowiak




On May 8, 2008, at 1:18 AM, Arve Bersvendsen wrote:

On Wed, 07 May 2008 20:57:25 +0100, Maciej Stachowiak  
<[EMAIL PROTECTED]> wrote:


They both said that this proposal was only meant for things like  
widgets, and agreed with my assessment that it would be a giant  
security hole if exposed to web content.


Without commenting further: Yes, in its current incarnation it  
raises security concerns, but what I meant to say was more "Our  
primary use case, and concerns that we have put into the initial  
proposal are centered around locally installed web applications, aka  
widgets".


I would not exclude making a subset of the proposal available to web  
applications though. Note that the current proposal speaks of  
FileStreams -- ideally, these should be generic IOStreams, and  
should apply to other protocols than "mountpoint" or "file".  Think  
scratch areas, webdav/svn integration, file upload with folder watch  
(but the method of doing so would have to be well-defined and more  
secure).  The initial proposal is not meant to cover this, but a  
properly worked out, future revision could cover both.


I would be happy to review a proposal that is intended for Web  
content, once one is available.


Regards,
Maciej

Re: specification of "legacy" key events

2008-05-08 Thread Maciej Stachowiak




On May 8, 2008, at 2:14 AM, Hallvord R. M. Steen wrote:



but when re-reading the E-mail what Oliver actually said is a bit  
more complex than I managed to capture in the proposed spec.


The most important point is that the keyCode of any keydown and  
keypress event must be 229 if an IME is processing the input. Apart  
from that there is some inconsistency -


Firefox fires keydown and keypress for the *first* character - the  
one that initiates IME processing. Then it fires no keydown/press/up  
events until character conversion is confirmed in the IME (for  
Japanese IME this is done by pressing enter and Firefox fires a  
keyUp for the enter key).


On the other hand, MSIE fires keydown and keyup events - keydown has  
code 229 and keyup has the virtual key code normally associated with  
the given key.


Safari behaves like IE.

Opera seems to fire an initial keydown and no more events - nearly  
what Firefox does but without the keypress.


IMHO, there is no strong use case for firing events while IME is  
processing - AFAIK there is nothing the web app can do about the  
input except confuse itself. Unless someone brings up use cases or  
content that depends on what Safari&IE do I'd suggest we specify  
something along the lines of what Firefox&Opera do. To be specific,  
a keydown and a keypress with codes 229 initally and no events while  
IME is handling input. Inserting the text might cause a keyup for  
enter (if that IME uses enter to confirm input) and must cause a  
textInput event.


We have had requests to fire some kind of identifiable event when  
typing occurs during IME processing for use cases like the following:


1) To resize an area based on user typing, even during IME entry (yes,  
this works right, the text is in the text field even when unconfirmed..
2) To have special keyboard shortcuts work in a text field even during  
IME entry.


We originally had the Firefox-like model and deliberately switched to  
the IE-like model to cater to use cases like this and because we  
believe it is more Web compatible.


As such, I would strongly argue for the IE/Safari model instead of the  
Firefox/Opera model.


Regards,
Maciej

Re: Security Re: File IO...

2008-05-07 Thread Maciej Stachowiak




Hey Chaals,

On May 7, 2008, at 10:39 AM, Charles McCathieNevile wrote:



On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak  
<[EMAIL PROTECTED]> wrote:


Yep. That's the idea.

Here are some of the more obvious security issues:

[several obviously interesting things]
6) Despite clearly having major security considerations, the  
document has no Security Considerations section.


Indeed. (It also has no table of contents). There are obviously  
security issues any time you give access to something like the  
filesystem. That said, there are valuable use cases for access to  
the filesystem. The idea of standardising this currently rough  
proposal is that we identify and deal with those. An obvious  
approach would be to limit availability of this to "trusted content"  
for some definition of that (and different browsers currently have  
different definitions).


Before I follow up, can you clarify whether this API is intended to be  
exposed to general Web content, or only to special local "trusted"  
content such as widgets? I briefly discussed the spec on IRC with Anne  
van Kesteren and Arve Bersvendson (who said he was the author of the  
proposal). They both said that this proposal was only meant for things  
like widgets, and agreed with my assessment that it would be a giant  
security hole if exposed to web content.


On the other hand, the way you presented the proposal sounded to me  
like it was intended for general Web content, including content served  
over HTTP. The proposal itself says, "This document describes an  
interface for an abstract File I/O interface where web applications  
can interact with a file system, without any prior knowledge about the  
underlying filesystem." And you suggested that it could replace the  
File Upload deliverable, which I believe was targeted at general Web  
content.


Can you please clarify which is intended?

My security comments were all based on an assumption that this  
proposal is meant for general Web content. I believe the proposal is  
not even an adequate starting point for an API exposed to the Web.  
Designing a filesystem API without concern for security is easy, and  
pretty much the only hard part is figuring out how to fit it into the  
Web security model. As such, I do not think it is particularly helpful  
to throw out a proposal with no security and ask the group to bolt  
security on. I would like to ask that Opera take at least a first pass  
at designing a security model if this is indeed intended as a Web- 
facing API.


If the proposal is only intended for content like widgets, then it  
might be adequate, but I don't think we could count it as fulfilling  
any of our work items for Web-facing APIs. Apple would also prefer to  
see the group put higher priority on Web-facing APIs than widget-only  
APIs. We are unlikely to implement widget-only specs. However, if  
others in the group would like to standardize widget-only API then I  
do not object on security grounds.


Regards,
Maciej

Re: File IO...

2008-05-07 Thread Maciej Stachowiak




On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:



Hi folks,

Opera has a proposal for a specification that would revive (and  
supersede)

the file upload API that has been lingering so long as a work item.

In a nutshell, it provides the ability for a web application to get a
filespace, by asking the user to identify such a space, and making it
available to that application something like a virtual file system.


I am concerned about the security implications of this proposal. File  
upload in HTML is based on the user explicitly selecting a particular  
file. This has relatively low security risk, since the user is  
choosing one specific file that he or she wishes to transmit, and all  
that can be done with that file is upload its bytes.


However, this API grants much more power than that. Here are some of  
the more obvious security issues:


1) It allows access to a whole directory at a time. In fact,  
browseForDirectory() starts in the user's home directory by default.  
This makes it very easy to get the unaware user to grant access to  
their whole home directory, or a large part of it. Thus, a user could  
think they are only going to let the web app use a couple of files,  
but in fact it can scan their whole home directory in the background  
for sensitive information.


2) browseForDirectory() can grant access that persists beyond the  
current session. Thus, unlike , which grants one- 
time access, browseForDirectory() grants permanent access to  
everything in a directory for all time. This greatly heightens the  
security risk. Even if I trust a site to read some files once, now if  
it gets hacked and I visit it, it has access to all my files right  
away, without giving me a chance to notice. In addition, users may not  
even be aware that access has been granted permanently, and no  
provision is made for revoking that access.


3) browseForFile() does not have a user interaction restriction or in  
general the good security qualities of .


4) The File object gives many capabilities beyond reading files,  
including copying, moving, and deleting files, and creating files and  
directories. This creates many new security risks. For the first time,  
if the user clicks OK on a dialog, it will be possible for a web  
application to wipe his or her directory. In addition, it will be  
possible to replace applications or other files in the user's home  
directory with malicious native code.


5) The mountpoint: URL protocol is pretty vaguely specified, however,  
if the intent is that this URL scheme is exposed to all web content,  
then as soon as the user has granted one web application access to his  
files, all web sites will have access. If this is not the intent, then  
the new URL scheme has a context-sensitive meaning that is based on  
the refering site, which is complex and is likely to lead to coding  
errors in security policy.


6) Despite clearly having major security considerations, the document  
has no Security Considerations section.



Here are some comments that are not directly security related:

A) The "storage" system directory provides a private filesystem  
sandbox to a web application. Given HTML5 key/value storage and
HTML SQL storage, is it really necessary to have yet another form of  
local data scratch area? Direct file system access, even if sandboxed,  
carries many more risks since for example the UA must be careful to  
avoid following symlinks out of the storage directory and so forth.  
The two HTML5 storage mechanisms avoid this risk. In addition, unlike  
the HTML5 mechanism, no provision is made for quota.


B) The "application" system directory is described as giving access to  
"The files and folders where the application resides". In the case of  
Web applications, the normal place where the application resides is an  
HTTP URL, not a location on the filesystem. The emerging standards- 
based way to locally "install" a web application is HTML5 Application  
caches. This part of the spec seems to presuppose a mechanism to  
locally install a Web application by copying its files to a local  
directory, which is not described in the spec.


C) Instead of building on the successful   
mechanism, which has received close security scrutiny for years, this  
spec builds a whole separate mechanism. No justification is given for  
why a brand new API is better than extending 




Use cases include single or bulk file upload (e.g for images, a set of
files, etc),


Web Forms 2 already covers this with multi-file upload.


I do not think we can seriously consider this proposal until security  
issues are addressed. The current spec does not seem to have given any  
consideration to Web security.



Regards,
Maciej

Re: [SelectorsAPI] Analysis of Context-Rooted Queries (was: Thoughts on querySelectorAll)

2008-05-05 Thread Maciej Stachowiak




On May 5, 2008, at 2:13 PM, Lachlan Hunt wrote:



*Solution 5*

 Define the methods to behave as if an implicit :scope selector
 and descendant combinator were prepended to each selector in
 the group.

This would work by taking the selector and appending the equivalent  
of ":scope " to the beginning of it, and then parsing as  
usual.  :scope could be implemented in any way the UA wanted here  
since it's not actually used by the author.



While this looks promising on the surface, the real problem lies in  
the implementation of the selector parsing. This requires signifant  
changes to the grammar of selectors, and thus alteration of the  
selector engines in browsers.


Consider the following selector:

">strong, >em"

The expectation would be for this to become:

":scope >strong, :scope >em"

The question is how to parse and convert it.


One possibility is to make the scoped API (whether that is  
querySelector on elements or some new method) only accept a single  
selector, not a group of selectors. This would remove any parsing  
difficulties. Also, if commas are only ever used to separate the  
selectors in a group in Selector syntax, then prepending ":scope " and  
inserting " :scope " after every comma before parsing would work. I  
believe this is currently true of Selectors, though it may change in  
the future. I would guess the only likely place for commas to appear  
would be in parameters to function-like pseudo-classes, in which case  
the algorithm above but excluding commas nested inside parentheses  
would be more future-proof. Detail of the algorithm:


1. Initialize nesting level to 0
2. Initialize the output string to the empty string
3. While characters in the input string remain:
3.a. read the current character
3.b. if the current character is:
   ",": if the nesting level is 0, append ", :scope " to the  
output string
   "(": increase the nesting level by 1, and append "(" to the  
output string
   ")": decrease the nesting level by 1, and append ")" to the  
output string

   anything else: append the current character to the output string
 3.c. advance to the next character
4. return the output string


Regards,
Maciej

Re: [selectors-api] Extended Attribute [NoNull] in the IDL




On May 2, 2008, at 8:17 PM, Boris Zbarsky wrote:



Cameron McCormack wrote:
I think of it more like that null is the actual namespace URI  
value, and

that an empty string is the non-standard way of specifying it (rather
than the other way around).  Which makes me think of this more as
something the method should handle, rather than something the  
bindings

worry about.


But the method signature in IDL is DOMString.  So by the time it  
sees the argument, it will be a DOMString.  The only question is  
which DOMString.


In Gecko, if you pass in "" it will see the string "".

If you pass in null, it will see a string that is equal to "" but  
has a "this is a null string" bit set.


Conceptually, the latter is more like a |char * str = NULL| and the  
former is more like a |char * str = "";| but both represented by a  
String object of some sort.


This is essentially what WebKit does as well (for methods where we've  
indicated null should convert to null string). In other cases, the  
default JS rule is used, yielding "null".


It might make sense to declare this the default conversion of null  
to DOMString and then have NoNull mean that the  
Object.prototype.toString conversion should be used instead.


It would be a little awkward that the DOM default is not the same as  
JS language builtins but we effectively have this problem already.


Regards,
Maciej

Re: [selectors-api] Extended Attribute [NoNull] in the IDL




On May 2, 2008, at 8:03 PM, Cameron McCormack wrote:



Maciej Stachowiak:
I'm not sure what NoNull is supposed to mean, but existing DOM APIs  
that
take strings almost always either treat JS null the same as "", or  
the
same as "null". I think Web IDL should define a property to  
distinguish

these cases. In WebKit's IDL we have the overly verbose
[ConvertNullToNullString] extended attribute for the first case (we
internally distinguish null string from empty string and I think  
there

may be a tiny number of APIs that actually treat null and empty
differently). I am not sure which of these behaviors [NoNull] applies
to.


[NoNull] is meant to mean that null values won’t get passed  
through, and
instead have to be treated the same as a value of whatever is inside  
the
valuetype<>.  Thus for DOMString, you’d get the normal  
stringification

behaviour.

What’s the distinction between a null string and the null value?   
Is the

null string just a way to force the null value into your string type,
internally?


It's not generally a meaningful distinction. Our string type  
internally distinguishes empty and null strings. JS strings do not  
have such a distinction, and null is not a valid instance of the  
string type. Both typically act the same as the empty string, but a  
very few places may check specifically for null string basically as a  
hack to let JS null pass through a string-typed argument.



We have similar extended attributes for IDL method return values or
attributes that are nominally DOMString but may return other values  
such

as null, or occasionally undefined,


I think because DOMString is actually a
valuetype, a null value is allowed.


Well, JS is an odd duck here. It does not have an instance of the  
string type, but it does have a null value (of a different type) and  
dynamic type conversion and a weird rule for how null is converted to  
string.


I guess what NoNull is saying is that null should stringify according  
to JS rules, yielding "null", with the default assumption being that  
DOMString parameters in IDL may take JS null. But NoNull does not seem  
like a very clear way to express that idea (at least to me, as an  
implementor more familiar with JS and DOM internals than with the  
details of OMG IDL).


Also, notwithstanding the polite fiction that DOMString is a  
valuetype>, in real bindings it is treated as  
a custom type that matches the native language's string type. So I  
would not read too much into its theoretical IDL definition.



or in at least one crazy case, boolean false (thanks to whoever
designed queryCommandValue).


Maybe in crazy cases like that the return value should be │any│?


For our bindings code at least we prefer to be specific, since |any|  
without additional knowledge of the actual types possible would  
require hand-coding.


Regards,
Maciej

Re: [selectors-api] Extended Attribute [NoNull] in the IDL




On May 2, 2008, at 7:37 PM, Cameron McCormack wrote:



Boris Zbarsky:
In that case, the null behavior doesn't make any sense to me...  I  
would
expect querySelector(null) to either behave as  
querySelector("null") (as
in Opera) or as querySelector("") (as in Gecko and apparently  
Webkit)...


If there’s a need for null to stringify to "", then I can add another
extended attribute to Web IDL.


It needs to for many standard DOM methods. Most core DOM methods that  
take namespaces treat a null namespaceURI or prefix parameter the same  
as the empty string, not the same as the string "null". As mentioned,  
I advise looking at WebKit's IDL files since we have represented most  
of the weird cases there. I think the empty string conversion may  
actually be somewhat more common in DOM APIs, although it is not the  
native ECMAScript string conversion behavior.


Regards,
Maciej

Re: [selectors-api] Extended Attribute [NoNull] in the IDL




On May 2, 2008, at 7:23 PM, Boris Zbarsky wrote:



Lachlan Hunt wrote:
What do they do if there is an element named  in the  
document?


IE 8 Beta: Returns null or empty NodeList


Interesting.   What happens in IE8b1 if you do:

 document.querySelector("")

Throws a SYNTAX_ERR.


In that case, the null behavior doesn't make any sense to me...  I  
would expect querySelector(null) to either behave as  
querySelector("null") (as in Opera) or as querySelector("") (as in  
Gecko and apparently Webkit)...


Sounds like whatever gets specified here we need a test for it in  
the test suite, at least.


I'm not sure what NoNull is supposed to mean, but existing DOM APIs  
that take strings almost always either treat JS null the same as "",  
or the same as "null". I think Web IDL should define a property to  
distinguish these cases. In WebKit's IDL we have the overly verbose  
[ConvertNullToNullString] extended attribute for the first case (we  
internally distinguish null string from empty string and I think there  
may be a tiny number of APIs that actually treat null and empty  
differently). I am not sure which of these behaviors [NoNull] applies  
to.


We have similar extended attributes for IDL method return values or  
attributes that are nominally DOMString but may return other values  
such as null, or occasionally undefined, or in at least one crazy  
case, boolean false (thanks to whoever designed queryCommandValue).


Regards,
Maciej

Re: [SelectorsAPI] Thoughts on querySelectorAll




On May 2, 2008, at 5:35 PM, Jonas Sicking wrote:



One alternative solution would be to say that the string ":scope "  
is always prepended to the passed in selector. That would mean that  
a selector like "div span" would be matched as ":scope div span"  
where obviously the "div" and "span" parts can only match  
descendants of the context node, and selection can never leak out  
outside the context node. It would even make a selector like "> div"  
work since it would be matched as ":scope > div" which is a valid  
selector.


I proposed something similar on #whatwg today, that we add  
queryScopedSelector / queryScopedSelectorAll to elements, which has  
this behavior. See  for discussion.


Yes, if we wanted this to handle cases like "div, p" right, you can't  
just do a simple prepend of ":scope", you have to treat it as ":scope  
div, :scope p". Such an API would make clear that we were introducing  
a new notion of "scoped selector" which differs from selectors in the  
CSS sense. Also, this could be specified in Selectors API without  
waiting for :scope to make it into a spec, by saying the selector acts  
as if some simple selector that uniquely matches the scope node had  
been prepended to each selector in the group.


The only real downside with that proposal is that the passed in  
selector is not a valid selector. And it doesn't work really well  
for selector groups such as "div, span", where what you'd really  
want is for ":scope" to be prepended to each group, which makes  
parsing a lot of fun...


Yes, unfortunately I think significant parsing hackery would be  
required to handle this. Either a second Selector parser, or a special  
pre-parser that could inject ":scope" or nonstandard equivalent in the  
right places. Or we could just say that a "scoped selector" can only  
be a selector, not a group of selectors, so commas are a syntax error.


Regards,
Maciej

Re: [SelectorsAPI] Thoughts on querySelectorAll




On May 2, 2008, at 2:15 PM, John Resig wrote:




There's a solution to the above that is both simple and intuitive:  
The first character of the selector that the UA doesn't know what to  
do with. For example, in the above, it would be:


:not(a:link)
  ^
:not|test|
^
:note
^


Your proposed "first character of the selector that the UA doesn't  
know what to do with" carries a lot of assumptions. For example, it's  
not obvious to me why in the second case, | isn't "the first character  
the UA doesn't know what to do with". It's also not clear why the  
error pointer is not at "a" in the second example, since the whole  
subexpression inside :not is what is in error (since it is not a  
simple selector).


I think it would be fairly complicated to define a way of reporting a  
specific "error character" in the face of varying browser support for  
different aspects of selectors. What exactly is the goal? Are you  
trying to distinguish real syntax errors from selectors that the UA  
doesn't know, but the library does? Or are you trying to find a  
reliable way to feature-test for different aspects of selectors up  
front?


In the former case, why not just have the library always try to parse  
the selector, and if it fails, you know that neither the UA nor the  
library could handle it. In the latter case, you could do it like this:


querySelector("a") --> exception means simple element selectors are  
not supported, unlikely, but probably means this impl is unusable
querySelector("a > b") --> exception means direct descendant  
combinator is not supported
querySelector(":not(a)") --> exception means :not descendant  
combinator is not supported
querySelector(":not(a > b)") --> exception means non-simple selectors  
inside :not are not supported


I am not entirely sure how this preflighting helps, but perhaps in  
some cases, you could arrange to have querySelector do most of the  
work for a selector it can't handle, with additional filtering by the  
JS library. I think specific capability testing would be more useful  
for this than an indicator of the error location.


You just have to ask yourself "am I use this expression?" if not,  
then it's an error and that's where you mark it. It's  
inconsequential that the useragent supports :not in the :not|test|  
example since not enough information is provided to actually use it.


I'm not sure I understand the distinction. What about this invalid  
selector: ":not(a". The error is lack of a close paren. Is the failure  
past the a (where you saw the end of the string instead of a close  
paren or some other character that would be allowed), or at the a  
(since that is the start if the subexpression that did not complete  
":not(") or at the colon, since you don't have a full valid :not  
expression? I am not sure how to tell. To a Selectors parser this case  
is actually no different than your :not(a:link) case, since you push a  
":not(" token and then an "a" token and then hit a parse error. But it  
is not really the same kind of mistake.


So, in summary, it is pretty complex to define interoperable "first  
bad character" error info. And this doesn't even match the way CSS  
parsers tend to work. If you build an LALR(1) parser, as with the  
reference grammar, the failure is often that it can't combine a  
sequence of tokens that are individually valid and the parser doesn't  
generally know enough to identify which token was bad. Compare this to  
a C compiler. They have basically the same idea of what programs are  
valid, but gcc and MSVC will not give you identical column numbers for  
errors, even though the C grammar is well-defined. It would take  
additional spec language to guarantee that.



We may still be able to help the use case you want handled, but I'd  
still like to understand more what you want to do with the error info.  
Is it for total library fallback, partial library fallback, or some  
other reason?


By the way, I appreciate that you and other JS library authors are  
looking at this API and providing feedback. I am inclined to add :- 
webkit-scoped support in WebKit's implementation as this would allow a  
very easy way to achieve the usual JS library semantics.


Regards,
Maciej

Re: [SelectorsAPI] Thoughts on querySelectorAll

2008-05-01 Thread Maciej Stachowiak




On Apr 30, 2008, at 1:37 PM, John Resig wrote:



* Combinator-rooted Queries

I read about some prior discussion concerning this (especially in  
relation to DOMElement.querySelectorAll-style queries). This is an  
important part of most libraries, as it stands. Maciej's proposed  
solution of using :root to allow for front-leading combinators is  
perfectly acceptable to me (where :root is made equivalent to the  
element, not the document element).


My most recent suggestion was to introduce a :scope pseudo-class for  
this instead of :root. I think this could also be used to do element  
scoped queries that work the way current JS libraries do: ":scope div  
> span" would find only a span child of a div that is somewhere in  
the current scope.


Regards,
Maciej

Re: IE Team's Proposal for Cross Site Requests

2008-04-29 Thread Maciej Stachowiak




On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:



On Tue, 29 Apr 2008, Chris Wilson wrote:


Given the multitude of issues raised, and the obvious back-and-forth
that denotes many differing opinions, I'd suggest having a telecom to
discuss these questions, and make sure that Sunava, Eric and myself  
can

attend.


I'm with Anne on this. Please reply to the e-mails before convening a
telecon. It is very difficult to carefully consider feedback in the
context of a telecon.

The problem isn't "back-and-forth" denoting "many differing  
opinions", the

problem is that we don't know what Microsoft's opinion _is_.

Telecons are by their nature much less open, and minutes are almost
uniformly so poor that it is hard to impossible to get precise  
technical
details out of telecons. A telecon would not be appropriate at this  
point.


I would also prefer to see a clear statement of Microsoft's position  
in written form ahead of the telecon. By their nature, these are  
issues that need careful analysis, and cannot be evaluated fully in  
the context of a teleconference.


Regards,
Maciej

Re: [XMLHttpRequest] Last Call




On Apr 16, 2008, at 7:50 PM, Kris Zyp wrote:



We still do not have anyway to advice user agents of long-lived  
responses in order to avoid the problem of indefinitely queued  
pipelined requests/responses. With both pipelining and long-lived  
responses becoming more common, this seems to be an envitable  
problem. It doesn't seem acceptable to simply ignore this issue. I  
am not asking for anything increasing the XHR implementation burden,  
simply a standard way of advising so that authors and user agents  
can communicate, so user agents have an approach for implementing  
proper delegation of pipelined requests when users start complaining  
of problems.


I think this would be more appropriate to deal with in XHR2, since we  
don't have a settled design for this feature and XHR1 is already way  
behind schedule.


 - Maciej



Thank you,
Kris

- Original Message - From: "Anne van Kesteren" <[EMAIL PROTECTED] 
>

To: "Web API WG (public)" 
Sent: Tuesday, April 15, 2008 12:40 PM
Subject: [XMLHttpRequest] Last Call




Hi,

The Web API WG resolved yesterday to publish a Last Call Working  
Draft of The XMLHttpRequest Object specification. Thanks to the  
webmasters at the W3C it was published earlier today. Last Call  
comments can be made until 2 June 2008. (Please don't comment about  
the "befor" typo there. My mistake.)


The draft is located here:

 http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/

This is a rough list of the changes since the last published draft:

 * Removed dependency on DOM Level 3 Events
 * Removed dependency on Window Object 1.0
   (we already depended on HTML 5 so we could use that instead)
 * Clearly marked which HTTP methods are to raise SECURITY_ERR
 * Mention HttpOnly in the security section
 * Accept-Language is set conditionally
 * Requests using a GET method will not have an entity body
 * responseText can no longer return null
 * responseText and responseXML no longer throw
 * Headers starting with Sec- will raise
 * getResponseHeader() will return null for invalid headers
 * getAllResponseHeaderS() returns empty string in case of failure

A more detailed log of these changes, including links to the actual  
text changes, is available from dev.w3.org, here:


 http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest/Overview.html

Happy times reviewing!

Kind regards,


--
Anne van Kesteren

Re: [selectors-api] Handling :link and :visited Pseudo Classes




On Apr 16, 2008, at 2:58 PM, Travis Leithead wrote:

Travis, last time I asked about this you declined how to say how  
this

could be solved but said you thought it was possible. Would you be
willing to explain further now?

Sorry Maciej, I'm still going to decline to say how, but insist that  
it is possible. With Software, anything's possible :)


No, not anything. No amount of brilliant engineering will solve the  
halting problem.


But I agree that in this case the question is more what the  
consequences are of a solution, rather than whether it is possible at  
all. For making technical decisions as a group, "trust me" is not very  
high quality input.


David's described solution sounds almost feasible, other than possibly  
compatibility impact (I'm not sure how common it is to set properties  
other than color or background-color in :visited rules, or how  
often :link rules set a non-color property that is not set  
for :visited). It also seems to still leave holes for timing attacks.


Cheers,
Maciej





-----Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 2:40 PM
To: Arve Bersvendsen
Cc: Travis Leithead; Lachlan Hunt; public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo  
Classes



On Apr 16, 2008, at 2:26 PM, Arve Bersvendsen wrote:



On Wed, 16 Apr 2008 22:49:30 +0200, Travis Leithead <[EMAIL PROTECTED]

wrote:



Yes, the selectors API will ignore any selector with a :link
or :visited pseudo-class. We shipped that with the intention of
providing a 360 degree protection from the :link/:visited problem
in our final release, but I believe that the rest of the plan has
been cut.


I am curious as to what the benefit of this would be.


Agreed. Besides what Arve posted, there are all sorts of ways
for :link vs :visited to affect the layout of other elements. Besides
normal flow siblings it could affect the size and/or position of other
floats in the same containing block (if floated), its children, its
parent, and so forth. So I don't see how you could hide visited link
information for attackers short of doing an extra style resolution and
layout solely to handle queries for  style or layout information.
Furthermore, giving answers from these queries that don't match the
true layout could break scripts doing animations or script-driven
layout.

In addition, CSS inheritence could alter non-size properties of
children like color, so restricting :link and :visited to properties
that don't affect size or position wouldn't work either.

I'd like us to understand how it is feasible to every fully solve this
problem before catering to partial solutions in the Selectors API  
spec.


Travis, last time I asked about this you declined how to say how this
could be solved but said you thought it was possible. Would you be
willing to explain further now?

Regards,
Maciej


A simple exploit that routes around the entire problem roughly
consists of this:




p,body,a { margin: 0; padding: 0 }
a:link { display: block; }
a:visited { display: none; }


onload = function(){
  var ele = document.getElementById('adjacentElement')
  if (0 == ele.offsetTop){
ele.innerText = "FAIL: Visit to slashdot.org detected"
  }
}



http://slashdot.org";>Visit this linkPASS



Note that I could replace the particular means of getting the
reference to the paragraph with any number of other means:

var ele = document.querySelector('p');
var ele = document.querySelector('a+p');
var ele = document.querySelector('#adjacentElement');
var ele = document.getElementsByTagName('a').nextSibling;

Which leaves you only the option of checking whether layout has been
affected and refuse to return anything whenever layout has been
affected by the :visited state of a link.

Also note that it is impossible to protect against Anne's suggested
exploit where you load a randomized and unique tracker image as
background or content for visited links, and do the data collection
serverside instead.

--
Arve Bersvendsen

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

Re: [selectors-api] Handling :link and :visited Pseudo Classes




On Apr 16, 2008, at 3:28 PM, L. David Baron wrote:


On Wednesday 2008-04-16 23:26 +0200, Arve Bersvendsen wrote:
Also note that it is impossible to protect against Anne's suggested  
exploit

where you load a randomized and unique tracker image as background or
content for visited links, and do the data collection serverside  
instead.


It's not impossible; it just requires deviations from current
standards and probably a lot of work.

On Wednesday 2008-04-16 14:39 -0700, Maciej Stachowiak wrote:
I'd like us to understand how it is feasible to every fully solve  
this
problem before catering to partial solutions in the Selectors API  
spec.


My current thinking (from
https://bugzilla.mozilla.org/show_bug.cgi?id=14#c65 ) is that
what we'd need to do to fix this is:

1. change CSS selector matching so that :visited rules are used
   *only* for the non-alpha components of the 'color' and
   'background-color' properties (and everything else is computed
   based on the :link rules)


2. make getComputedStyle and any other APIs lie about those two
   properties


I guess you would have to extend this to rules that use :visited  
or :link anywhere in the selector (for example before a sibling or  
descendant combinator) and make sure the getComputedStyle lies extend  
to descendants that inherit the color as well.


Also, I think setting background-color may be subject to a timing- 
based attack if the default is transparent, since it will require  
extra rect fills, and setting color may be subject to a timing based  
attack if the anti-aliasing mode changes based on the color of text,  
resulting in different cost of drawing the text. I believe this is  
true on Mac OS X.


Regards,
Maciej

Re: [selectors-api] Handling :link and :visited Pseudo Classes




On Apr 16, 2008, at 2:26 PM, Arve Bersvendsen wrote:



On Wed, 16 Apr 2008 22:49:30 +0200, Travis Leithead <[EMAIL PROTECTED] 
> wrote:


Yes, the selectors API will ignore any selector with a :link  
or :visited pseudo-class. We shipped that with the intention of  
providing a 360 degree protection from the :link/:visited problem  
in our final release, but I believe that the rest of the plan has  
been cut.


I am curious as to what the benefit of this would be.


Agreed. Besides what Arve posted, there are all sorts of ways  
for :link vs :visited to affect the layout of other elements. Besides  
normal flow siblings it could affect the size and/or position of other  
floats in the same containing block (if floated), its children, its  
parent, and so forth. So I don't see how you could hide visited link  
information for attackers short of doing an extra style resolution and  
layout solely to handle queries for  style or layout information.  
Furthermore, giving answers from these queries that don't match the  
true layout could break scripts doing animations or script-driven  
layout.


In addition, CSS inheritence could alter non-size properties of  
children like color, so restricting :link and :visited to properties  
that don't affect size or position wouldn't work either.


I'd like us to understand how it is feasible to every fully solve this  
problem before catering to partial solutions in the Selectors API spec.


Travis, last time I asked about this you declined how to say how this  
could be solved but said you thought it was possible. Would you be  
willing to explain further now?


Regards,
Maciej

A simple exploit that routes around the entire problem roughly  
consists of this:





p,body,a { margin: 0; padding: 0 }
a:link { display: block; }
a:visited { display: none; }


 onload = function(){
   var ele = document.getElementById('adjacentElement')
   if (0 == ele.offsetTop){
 ele.innerText = "FAIL: Visit to slashdot.org detected"
   }
 }



 http://slashdot.org";>Visit this linkid="adjacentElement">PASS




Note that I could replace the particular means of getting the  
reference to the paragraph with any number of other means:


 var ele = document.querySelector('p');
 var ele = document.querySelector('a+p');
 var ele = document.querySelector('#adjacentElement');
 var ele = document.getElementsByTagName('a').nextSibling;

Which leaves you only the option of checking whether layout has been  
affected and refuse to return anything whenever layout has been  
affected by the :visited state of a link.


Also note that it is impossible to protect against Anne's suggested  
exploit where you load a randomized and unique tracker image as  
background or content for visited links, and do the data collection  
serverside instead.


--
Arve Bersvendsen

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

Re: [DOML3Events] ACTION-267 Proposal for event iterator

2008-04-14 Thread Maciej Stachowiak




On Apr 14, 2008, at 3:26 PM, Doug Schepers wrote:



Hi, Jonas-

Jonas Sicking wrote (on 4/14/08 5:58 PM):
Like Boris points out, there is no need to expose debugging APIs to  
web pages. Browsers can expose those thorough internal APIs to  
their tools.


Actually, I've seen Web apps that allow creation and debugging of  
content, and I think that's a perfectly legitimate use case.  I  
would like to have this list of event listeners available.


As Jonas pointed out, many other APIs needed for debugging are not  
available to web content. Debugging web content inside other web  
content will not be made practical by this one feature. So I don't  
find it that compelling a use case.


Cheers,
Maciej

Re: [DOML3Events] ACTION-267 Proposal for event iterator

2008-04-09 Thread Maciej Stachowiak




On Apr 9, 2008, at 2:16 PM, Travis Leithead wrote:



I've been specifically requested to add such support into IE by  
various customers. Most of their use-cases involve script that is  
trying to 'clean-up' event handlers for which they did not set, and  
do not have a pre-existing handle to the function callback.


Could you be more specific about the use cases? That sounds pretty  
vague, and from your example, it's also not clear that enumeration is  
even the most useful API to address these use cases. It sounds like an  
API to clear all event listeners on a node would be more appropriate.


I also wonder why anyone would want to remove event handlers that they  
did not install themselves, we have not received requests like this  
for Safari or WebKit. I wonder if this might be due to the fact that  
leaving event listeners attached after leaving the page can cause  
memory leaks in IE. Other browsers don't have this problem, so I think  
the right solution, if this is the motivation, would be to fix the  
memory leaks.


Also I am not sure why IE customers would be requesting extensions to  
DOM Events, since IE doesn't yet support DOM Events at all. (Though to  
be fair, perhaps you are translating requests for extensions to IE's  
event model into requests for extensions to DOM events.)


Regards,
Maciej

Re: [DOML3Events] ACTION-267 Proposal for event iterator

2008-04-09 Thread Maciej Stachowiak




On Apr 9, 2008, at 11:07 AM, Travis Leithead wrote:



In considering a design for the event iterator (allow devs to  
enumerate what events have been _added_ via addEventListener to a  
given object), I looked at too general approaches:


Before analyzing the pros and cons of specific designs, what is the  
motivation for adding this functionality at all? Previously, the  
working group resolved to remove the related but less powerful  
hasEventListenerNS method for lack of a use case, and because there  
are potential security issues.


Regards,
Maciej

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

2008-04-02 Thread Maciej Stachowiak

Hi Tyler,

On Apr 2, 2008, at 6:08 PM, Close, Tyler J. wrote:

Maciej Stachowiak wrote:

On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote:

Sending the user's cookies, as AC4CSR does, is just not a viable
design, since the target resource cannot determine whether or not
the user consented to the request. I've posted several explanations
of the attacks enabled by this use of ambient authority, and, in my
opinion, the issues are still outstanding. The use of ambient
authority in AC4CSR is a show-stopper, as reflected in the decision
Mozilla announced on this mailing list.

Can you please post these examples again, or pointers to where you
posted them? I believe they have not been previously seen on the Web
API list.

I've written several messages to the appformats mailing list. I
suggest reading all of them.

W3C's search finds the following 50 messages from you:

http://www.w3.org/Search/Mail/Public/search?hdr-1-name=from&hdr-1-query=tyler.close%40hp.com&index-grp=Public__FULL&index-type=t&type-index=public-appformats&resultsperpage=20&sortby=date&page=2

Can you help me out with finding which contain descriptions of
security flaws in the spec (which have not yet been addressed through
spec changes)? The first three I looked at randomly did not contain
any descriptions of security flaws.

The most detailed description of the attacks are in the message at:

http://www.w3.org/mid/[EMAIL PROTECTED]

with a correction at:

http://www.w3.org/mid/[EMAIL PROTECTED]

Thanks for stepping up with some actual specific attacks. I will read
them carefully and respond soon with my analysis (also in light of
Ian's reply to you).

A number of people have mentioned that the AC approach to
cross-site XHR is insecure (or that XDR is somehow more secure),
but I

have not yet seen any examples of specific attacks. I would love to
see this information. If I do not see a description of a specific
attack soon I will assume these claims are just FUD.

I think we've met before at a SHDH event. That was a more pleasant
conversation. Hopefully, we'll be able to regain that tone.

Sorry for tossing you in the same bucket as those making (so far)
unsubstantiated claims. I'm not trying to be unfriendly here, I'm just
trying to get us to objective facts about security, which so far have
been lacking in this discussion. This is very frustrating to me,
because saying a spec is insecure without giving details is just
yelling fire in a crowded theater. Whereas describing specific attacks
is very helpful, so thank you for doing so.

Note also that sending of cookies is not an essential feature of
AC4CSR; certainly it could be a viable spec with that feature
removed.

Do you believe there are any other showstopper issues?

Possibly. There is a lot of complexity in the AC4CSR proposal. I've
been writing about the most severe things as I find them.

Now would be a great time to collapse the wave function on that
"possibly". I have been trying to think of attack models against both
AC and XDR myself and so far have not come up with anything that holds
water (I did mistakenly think AC had a DNS rebinding vulnerability,
but I was wrong). We must carefully identify the security issues
(including second-order effects that may result from limiting
capabilities) to make informed decisions about this technology area.

Regards,
Maciej

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

2008-04-02 Thread Maciej Stachowiak




On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote:



Sending the user's cookies, as AC4CSR does, is just not a viable  
design, since the target resource cannot determine whether or not  
the user consented to the request. I've posted several explanations  
of the attacks enabled by this use of ambient authority, and, in my  
opinion, the issues are still outstanding. The use of ambient  
authority in AC4CSR is a show-stopper, as reflected in the decision  
Mozilla announced on this mailing list.


Can you please post these examples again, or pointers to where you  
posted them? I believe they have not been previously seen on the Web  
API list. A number of people have mentioned that the AC approach to  
cross-site XHR is insecure (or that XDR is somehow more secure), but I  
have not yet seen any examples of specific attacks. I would love to  
see this information. If I do not see a description of a specific  
attack soon I will assume these claims are just FUD.


Note also that sending of cookies is not an essential feature of  
AC4CSR; certainly it could be a viable spec with that feature removed.  
Do you believe there are any other showstopper issues?


Regards,
Maciej

Re: [Element Traversal LC] access to element by index

2008-04-02 Thread Maciej Stachowiak




On Apr 2, 2008, at 2:44 AM, Jonas Sicking wrote:



Henri Sivonen wrote:

On Apr 2, 2008, at 00:48, Boris Zbarsky wrote:
OK.  So item() would be available on Element after casting it to  
NodeList in those implementations.  I guess you're saying that the  
cast would not longer be unambiguous if there were multiple  
NodeLists that might make sense?  So childElements couldn't be  
implemented with a |return this;|?


That doesn't seem like such a terrible implementation burden to  
me, to be honest...
I'm not claiming it would be awfully hard, but it does change the  
impact of Element Traversal from adding four or five methods on an  
existing class (mere code footprint; super-simple) to adding more  
run-time object instances. And then, there are issues like should  
childElements return the same object every time. And if yes, then  
the implementor needs to add a new pointer to each element node or  
to add a hashtable on the owner document or something along those  
lines. Again, not awfully hard, but still more complex than just  
adding convenience methods on an existing class.


Sure it's more complex, but it's still trivial.


In WebKit, it would be more than one line of code to add a new kind of  
NodeList. Not a ridiculous amount of code though.


However, I think live NodeLists are an anti-pattern. They tend to be  
horrible for performance in the face of mutation (and even when there  
isn't mutation, extra objects are allocated). This is part of why I  
strongly argued for querySelectorAll to return a non-live list. And  
using indexing is not really any more convenient than using next/ 
previous methods.


I can live with the editor's decision either way on this one.

Cheers,
Maciej

Re: [Bindings] What does typeof return for interface objects?

2008-03-19 Thread Maciej Stachowiak




On Mar 19, 2008, at 12:08 AM, Maciej Stachowiak wrote:



ECMA-262 actually allows typeof to return anything at all for host  
objects (which all of the DOM binding objects are). So it would not  
be an ECMA-262 violation, technically, for an uncallable object to  
give typeof == 'function', but I do think it would be a bad idea.


In WebKit we currently follow the ECMA-262 callability-based  
approach even for host objects, but not all web engines do. For  
example, I believe that in Trident, NodeLists are callable but give  
a typeof result of 'object' instead of 'function'.


Alexey points out that we have had a bug filed because we report  
'function' in this case: <http://bugs.webkit.org/show_bug.cgi?id=14547>.


But it's not really clear if the IE behavior of being callable but  
reporting typeof == 'object' is required for compatibility (it is  
clear that NodeLists actually being callable is).


There is much more discussion in the bug.

Regards,
Maciej

Re: [Bindings] What does typeof return for interface objects?

2008-03-19 Thread Maciej Stachowiak




On Mar 18, 2008, at 11:06 PM, Cameron McCormack wrote:



Travis Leithead:

I can think of some interesting use cases for implementing [[call]]
on an interface object... I'd prefer to leave it unspecified at best.


OK.


I agree with Hixie on the point of specifying the behavior of typeof,
and to me typeof HTMLDocument == 'function' makes sense, since I  
think

of these as 'constructor objects' (even if they don't allow object
construction in some cases).


But if you want ‘typeof HTMLDocument == 'function'’, then you would
need to mandate [[Call]] being implemented on the interface object,
since ECMA-262 says that the typeof operator returns 'function' only  
if
the object implements [[Call]].  And then if you require [[Call]] to  
be

implemented, then you’d need to say what that function would do.


ECMA-262 actually allows typeof to return anything at all for host  
objects (which all of the DOM binding objects are). So it would not be  
an ECMA-262 violation, technically, for an uncallable object to give  
typeof == 'function', but I do think it would be a bad idea.


In WebKit we currently follow the ECMA-262 callability-based approach  
even for host objects, but not all web engines do. For example, I  
believe that in Trident, NodeLists are callable but give a typeof  
result of 'object' instead of 'function'.


Regards,
Maciej

Re: Safari 3.1 adding showModalDialog??

2008-03-18 Thread Maciej Stachowiak




On Mar 18, 2008, at 2:22 PM, Travis Leithead wrote:



Not to say that I object... :)

...but why this API and not showModelessDialog too?
I'd be interested to know the rationale for this decision on  
WebKit's part.


We've been shipping showModalDialog for years on Mac, but I think it  
didn't work on Windows in our betas. We had to add it for  
certification with certain "enterprise" web applications years ago.


We've never had a request for showModelessDialog or equivalent  
functionality (as far a sI know).



Also, was openDialog considered (from FF)?


We asked the ISVs who wanted a way to do a modal dialog and they  
preferred the IE API. Neither seemed technically better or worse as  
far as we could tell.


Regards,
Maciej

Re: IE Team's Proposal for Cross Site Requests

2008-03-18 Thread Maciej Stachowiak



On Mar 17, 2008, at 7:52 PM, Sunava Dutta wrote:



Maciej Stachowiak [EMAIL PROTECTED] noted:
<server side is likely to increase, not reduce attack surface.>>


If a service is defined as accepting one format, it need only accept  
that format, and can reject anything else.  Sniffing is not  
recommended or desirable.


Such a service should reject an incorrect MIME type, which text/plain  
would be for XML.




Remember, even if you allow the Content-Type to be specified by the  
caller, the server has NO guarantee that the Content-Type specified  
is an accurate description of the POST body content.  To remain  
secure, servers MUST be robust in the face of malformed input.


However, sniffing in text/plain is a whole different ball of wax.




Maciej Stachowiak [EMAIL PROTECTED] noted:
<Access- Control model as compared to XDR, at least none that have  
held up to closer scrutiny. Is Microsoft aware of any specific such  
risks, as opposed to general concerns?>>


The Security Worries section here: http://wiki.mozilla.org/Cross_Site_XMLHttpRequest 
 and the Security section here:http://www.w3.org/TR/access-control/#security 
  describe some of the concerns related to the Access-Control  
model.  We believe that the XDR model effectively mitigates the  
concerns described.


Do you have any specifics? Which of those items, in particular, do you  
think represent security vulnerabilities in XHR2+AC? Which are  
addressed by XDR? I can do this analysis myself if necessary, but if  
Microsoft is making the claim that XDR is more secure and that you  
believe XHR2+AC has security vulnerabilities, I think you should  
provide specific evidence to back up these claims.


(Note that these are both lists of issues that are believed to be  
adequately addressed, so it is not immediately obvious which items you  
believe are vulnerabilities.)




Maciej Stachowiak [EMAIL PROTECTED] noted:
<authoring and implementation are worth discussing as well, but I  
think the approaches are similar enough that simplicity in itself is  
not a major security issue.>>


While simplicity alone obviously is no guarantee of security, design  
complexity almost always leads to implementation bugs.   
Implementation bugs in access control mechanisms lead to security  
bugs.


That is true. But based on my experience writing the original  
implementation of XMLHttpRequest for WebKit, and my review of the  
spec, I do not think XHR2+AC rises to the level of complexity that is  
highly likely to lead to implementation bugs.


Regards,
Maciej

Re: IE Team's Proposal for Cross Site Requests

2008-03-17 Thread Maciej Stachowiak




On Mar 17, 2008, at 2:29 PM, Sunava Dutta wrote:


Maciej Stachowiak [EMAIL PROTECTED] said:
<content with a proper MIME type cross-domain.>>


You're right-- setting an arbitrary request content-type is a  
capability not present in HTML forms today.  While we believe that  
this is a minimal increase in attack surface, we agree that it's  
worth considering whether or not such capability should be removed.


If removed, all XDR POST requests could be sent with:

   Content-Type: text/plain; charset=UTF-8

Servers would then be flexible in interpreting the data in the  
higher-level format they expect (JSON, XML, etc).


I think encouraging more content sniffing of text/plain on the server  
side is likely to increase, not reduce attack surface.



Maciej Stachowiak [EMAIL PROTECTED] asked:
<to the API and protocol differences.>>


We believe that the XDR proposal represents a simpler mechanism for  
enabling the most commonly requested types of cross-domain access.   
We believe that such simplicity will lead to improved security in  
practical implementations by browsers.


There are many threats against a cross-domain communication  
mechanism, so we believe the simplicity of XDR makes it more  
suitable than attempting to plumb cross-domain capabilities into the  
existing XHR object.  In particular, we are concerned that  
attempting to introduce new restrictions/added complexity on an XHR  
object when it is used in a cross-domain manner will result in a  
confusing programming model for the web developer.


So far I have not heard any *specific* security risks of the Access- 
Control model as compared to XDR, at least none that have held up to  
closer scrutiny. Is Microsoft aware of any specific such risks, as  
opposed to general concerns?


Certainly simplicity of client-side authoring, server-side authoring  
and implementation are worth discussing as well, but I think the  
approaches are similar enough that simplicity in itself is not a major  
security issue.


Regards,
Maciej

Re: IE Team's Proposal for Cross Site Requests

2008-03-15 Thread Maciej Stachowiak




On Mar 14, 2008, at 4:59 PM, Eric Lawrence wrote:



=

Maciej Stachowiak [EMAIL PROTECTED] asked:
<XMLHttpRequest standard that is being developed by Web API and Web  
App Formats (and as implemented in Firefox betas)? From Apple's  
point of view we would like to have a unified standard in this area.>>


We believe that the XDR proposal exposes a smaller surface of attack  
than the Cross-Site extensions for XHR.  Specifically, it can be  
demonstrated that the capabilities exposed by XDR are virtually  
identical to the capabilities exposed by existing HTML tags.  The  
one exception (obviously) is that the XDR object allows examination  
of response bodies cross-domain if and only if the server explicitly  
indicates that such access is permissible via the  
XDomainRequestAllowed header.


But not exactly identical, since forms can't be used to POST XML  
content with a proper MIME type cross-domain. This is actually more  
restricted in XHR2+AC.



=

Maciej Stachowiak [EMAIL PROTECTED] asked, in part:
<some other method can do anything that you can't do with a cross- 
domain form submission. You can set custom headers, but that seems  
unlikely to make the difference between safe and unsafe.>>


It's certainly a possibility.  For instance, consider a device which  
accepts SOAP XML as input  The designers of the device were wise to  
note that a cross-domain form submission could be made (encType =  
text/plain) that contains XML-formatted content, and thus they  
devised an anti-CSRF mechanism of rejecting requests that do not  
bear a proper SOAPAction header.  Such restriction properly blocks  
CSRF via HTML forms, but is put at risk if a cross-domain XHR  
request is able to send arbitrary headers.


On the other hand, if the anti-CSRF mechanism were checking for a  
proper XML Content-Type instead of looking for a SOAPAction header,  
XDR would be more vulnerable than XHR2+AC. If the server also checks  
the Host header, then XHR2+AC would be completely safe (since no DNS  
rebinding attack is then possible).


In any case, it seems like this could be addressed through a strict  
whitelist of allowed request headers, including such critical headers  
as Accept and Accept-Language but ruling out SOAPAction. Or XHR2+AC  
could even block all custom headers on cross-site requests. Let's take  
that point as negotiable. Allowed methods are also a negotiable point.  
These issues both address what may be customized on the request, but  
the most obvious incompatibilities between XDomainRequest and XHR2+AC  
are the API and protocol.


What I'd like to understand is whether there are security benefits to  
the API and protocol differences. Or if not, if there is any other  
reason to prefer the Microsoft-proposed API and protocol to the  
current draft standards. Can anyone from Microsoft address that point?


Regards,
Maciej

Re: [selectors-api] Why no querySelector(All) on DocumentFragments?




On Mar 14, 2008, at 2:25 PM, Boris Zbarsky wrote:



Jonas Sicking wrote:
If we merge DocumentSelector and ElementSelector into simply  
NodeSelector we'll more or less automatically get the functions on  
DocumentFragments.


Not necessarily.  I'm not advocating that all Nodes be castable to  
NodeSelector.  Just that whatever nodes querySelector(All) work on  
are.



We'd also get it for attribute nodes which might be less desirable.


I don't think it's desirable at all.

Though we could say that the interface is only required to be  
implemented on Documents, Elements and DocumentFragments.


That would be my suggestion, yes.  ;)

If we could get a :scope pseudo-element that would be an excellent  
solution IMHO, and would be great with scoped stylesheets as has  
been pointed out elsewhere in the last few days.


Agreed.

That said, is there interest in getting this spec to CR quickly,  
since it seems some UAs are planning to ship it in the near future  
even though it's a Working Draft?  Or are said UAs willing to make  
changes to their implementation after shipping as the spec changes?


UAs are also planning to ship HTML5 features, and that's nowhere near  
CR. For Safari/WebKit we are willing to keep up with changes but we  
hope and assume there wouldn't be gratuitous incompatibilities  
created. For example, extending the interface to DocumentFragment,  
adding :scope, or adding parallel methods for element-rooted queries  
would both be reasonable changes from our point of view. Because this  
API is driven to a large extent by a desire to replace AJAX library  
functionality with more performance native versions, I think it's  
important to make sure we actually satisfy their use cases, and we're  
learning about that from the existing early implementations as JS  
library authors play with them.


The main thing I'd like to see ASAP is a good test suite, and we don't  
need to wait for CR to start building that.


Cheers,
Maciej

Re: [selectors-api] Why no querySelector(All) on DocumentFragments?




On Mar 14, 2008, at 1:56 PM, Jonas Sicking wrote:



I think ability to do element-rooted selector queries (either  
through a new method or a :scope pseudo-element) is more important,  
since it's needed to replicate the feature set of JS query libraries.


If we could get a :scope pseudo-element that would be an excellent  
solution IMHO, and would be great with scoped stylesheets as has  
been pointed out elsewhere in the last few days.


Is that something that should be defined by this WG? It would suck  
to have to wait for Level 4 Selectors. Other WGs have defined  
selectors, but I'm not sure how good of an idea that is.


I would prefer to see it in the Selectors spec, but it would have to  
come out of CR for that. Perhaps the editor of the Selectors spec  
(Hixie) would like to weigh in. Alternately, we could temporarily  
define the pseudo-element in the Selectors API spec.


The alternative, defining another set of methods would be something  
that we could do, but that solution feels a lot less appealing.


I agree, :scope seems more elegant, and parallel methods can't handle  
the "> span" immediate children use case very nicely.


Regards,
Maciej

Re: IE Team's Proposal for Cross Site Requests




On Mar 14, 2008, at 2:42 PM, Jonas Sicking wrote:

Also, the OPTIONS request is there to prevent requests that XDR  
simply always allows, i.e. cross site requests using unsafe methods.  
So I'm not sure I see how XDR is safer in that regard here.


I would be very interested to hear back on the two first emails I  
posted to this thread as they relate to this exact subject.


The attack scenario would be like this:
- evil.com binds rebind-domain.com to point to evil.com's IP
- evil.com does a cross-domain XHR to rebind-domain.com with POST or a  
custom method, making sure to allow

- evil.com rebinds rebind-domain.com to point to webstore.com's IP
- evil.com does a cross-domain XHR to rebind-domain.com with POST or a  
custom method, it is now allowed


The end result is that you send a request with a disallowed method to  
webstore.com, but the user's normal cookies or other credentials won't  
be sent since the request is sent to rebind-domain.com, not  
webstore.com, as far as the client knows.


However, after thinking about this, you could achieve the same by DNS  
rebinding using evil.com itself, making the XHR not cross-domain at  
all. So, even though there seems to be a potential gap in the OPTIONS  
pre-request here, it does not appear to be a new hole.


I am also not sure if a DNS rebound cross-domain XHR with POST or some  
other method can do anything that you can't do with a cross-domain  
form submission. You can set custom headers, but that seems unlikely  
to make the difference between safe and unsafe. You can also use  
methods besides the ones allowed for form posting. I am not sure why  
the OPTIONS preflight check was added in the first place, I hope  
whoever came up with the pre-check design can chime in to indicate  
whether this attack subverts the purpose of the check.


Regards,
Maciej





/ Jonas

Jonas Sicking wrote:
So the worry here is a scenario where an attacker tricks a user to  
go to evil.com which does an evil POST to webstore.com. And at the  
same time the attacker launches a DNS rebind attack on the user for  
the webstore.com domain name such that the OPTIONS request goes to  
an attacker controlled server which approves the POST, but then  
lets the actual post go to the real webstore.com server?
If so, couldn't the user simply trick the user to go to  
webstore.com, and use a DNS rebind attack so that when  
webstore.com/ is fetched it returns a HTML page that contains  
script that uses normal XHR to do a POST to webstore.com. When the  
POST happens the attacker lets that go to the real webstore.com  
server.
I.e. I don't see how Cross-site XHR in combination with DNS rebind  
attacks lets you do something that DNS rebind attacks doesn't  
already let you do on it's own.

XXX = Cross-site Extensions to XHR. So basically XHR+AC spec.
/ Jonas
Chris Wilson wrote:
Yes, DNS rebinding is one of the major attack vectors I was  
talking about.  If the access controls are negotiated  
independently of the actual request/response, this is nearly  
always a concern.  (Yes, you could require follow-ups to go to the  
same IP address; that's both a pain to actually implement (because  
a high-level request needs low-level access; typically, I don't  
believe we need to know about the IP address at the XHR level) and  
somewhat confusing (because it will break if there's normal,  
permitted DNS round-robin going on, e.g.).


Maciej, does XXX = XHR L2 or XDR?

-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 1:25 PM
To: Jonas Sicking
Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu;  
Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey

Subject: Re: IE Team's Proposal for Cross Site Requests


On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:


Can you describe what you mean by "persistent allow" design?


Anne and I discussed this comment on IRC. One possible flaw is that
the OPTIONS request to guard against an unaware server receiving  
cross-

domain POST or other methods is subject to a DNS rebinding attack
(though this could be fixable by requiring the OPTIONS and the  
follow-

up request to go to the same IP or something along those lines). I'm
not sure if this is the vulnerability Chris had in mind. I don't  
think
XXX has the same vulnerabilities as Flash though, because the  
access-

control headers are not an out-of-band control file so the actual
access control check can't be bypassed via DNS rebinding, only the
method check.

 - Maciej



/ Jonas

Chris Wilson wrote:

Oops.  Obviously, this was not to go to the whole group.
I've been asked a lot, over the last week and a half, why we
implemented XDR rather than the current cross-domain XHR
proposals.  The short version is, as Sunava discusses in the
summary of this mail, that x-domain XHR (and Flash's approach, et
al) is su

Re: [selectors-api] Why no querySelector(All) on DocumentFragments?




On Mar 12, 2008, at 12:25 PM, Boris Zbarsky wrote:



Is there a reason why querySelector(All) is not supported on  
DocumentFragment nodes?  It seems to me that such support could be  
useful...  It's already supported on disconnected subtrees rooted by  
an Element, as far as I can tell, so it doesn't seem like the  
DocumentFragment case would be all that different.


I'd have no objection to supporting these methods on DocumentFragment  
too, although it does not seem terribly important.


I think ability to do element-rooted selector queries (either through  
a new method or a :scope pseudo-element) is more important, since it's  
needed to replicate the feature set of JS query libraries.


Regards,
Maciej

Re: IE Team's Proposal for Cross Site Requests




On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:



Can you describe what you mean by "persistent allow" design?


Anne and I discussed this comment on IRC. One possible flaw is that  
the OPTIONS request to guard against an unaware server receiving cross- 
domain POST or other methods is subject to a DNS rebinding attack  
(though this could be fixable by requiring the OPTIONS and the follow- 
up request to go to the same IP or something along those lines). I'm  
not sure if this is the vulnerability Chris had in mind. I don't think  
XXX has the same vulnerabilities as Flash though, because the access- 
control headers are not an out-of-band control file so the actual  
access control check can't be bypassed via DNS rebinding, only the  
method check.


 - Maciej




/ Jonas

Chris Wilson wrote:

Oops.  Obviously, this was not to go to the whole group.
I’ve been asked a lot, over the last week and a half, why we  
implemented XDR rather than the current cross-domain XHR  
proposals.  The short version is, as Sunava discusses in the  
summary of this mail, that x-domain XHR (and Flash’s approach, et  
al) is subject to specific x-domain injection attacks because of  
its persistent-allow design.

*From:* Chris Wilson
*Sent:* Friday, March 14, 2008 11:00 AM
*To:* Sunava Dutta; Web API WG (public)
*Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug  
Stamper; Marc Silbey

*Subject:* RE: IE Team's Proposal for Cross Site Requests
I’d move half the summary section up front to make it clear why  
we’re not wild about x-domain XHR.  You need to lead with that.

*From:* Sunava Dutta
*Sent:* Thursday, March 13, 2008 8:47 PM
*To:* Sunava Dutta; Web API WG (public)
*Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath  
Udupa; Doug Stamper; Marc Silbey

*Subject:* IE Team's Proposal for Cross Site Requests
Purpose
XDR helps web developers to create secure mashups, replacing less  
secure or non-performant approaches, including SCRIPT SRC’ing  
content or IFRAME injection.
Microsoft would like to submit XDR to the W3C for standardization  
so that other browsers can benefit from this technology.

 XDomainRequest (XDR)
   Table of Contents
1.0   Summary
2.0   Background: /Overview of how XDR allows cross site requests/
3.0   API Documentation: /Lists the programming interface/methods/ 
properties/
4.0   Security Model Flowchart: /Highlights the security checks  
that IE8 makes for an XDR Request./
5.0   Sample Site and Script: /For developers wishing to create an  
XDR page./
6.0   Developer Benefits of using XDR: /Covers XDR’s strengths by  
demonstrating XDR’s goals of security and simplicity./
7.0   Developer Release Notes: /A short bulleted list of issues  
developers should we aware of when using the object and a summary  
of what XDR cannot do./

1.0 Summary
/With* Cross Domain Request* *(XDR)* developers can create cross  
site data aggregation scenarios. Similar to the XMLHttpRequest  
object  but with a simpler programming model, this request, called  
XDomainRequest, is an easy way to make anonymous requests to third  
party sites that support XDR and opt in to making their data  
available across domains. Three lines of code will have you making  
basic cross site requests. This will ensure data aggregation for  
public sites such as blogs etc will be simple, secure and fast. XDR  
is an approach designed from the grounds up with a focus on  
security. We understand the current cross domain XMLHTTPRequest  
proposal and recognize its ability to provide a broader set of  
services particularly around declarative auditing for access  
control based scenarios and authenticated connections. It does  
however come at the risk of more complexity and surface area of  
attack. While these are certainly compelling scenarios we realize  
that existing implementations have bugs (linked 1 , 2 ), some  
of which are resolved from the past like TOUCTOU and others like  
DNS Rebinding remain mostly unaddressed. In addition, maintaining  
configuration is challenging post deployment as Flash has  
encountered   
(wildcarding) in the past. The IE team is not comfortable  
implementing a feature with a high surface area of attack and open/ 
incoming security issues and proposes XDR as a safer alternative.///

2.0 Background
 Browsers enforce the same site origin policy, which blocks web  
pages from accessing data from another domain. Websites often work  
around this policy by having their server request content from  
another site’s server in the backend, thus circumventing the check  
within the browser.


	Text Box: Figure 1 – IE7 and below need to make a request to  
the mashup server which then needs to be proxied to the web server.
In IE8 web pages can simply make a cross domain data request within

Re: [selectors-api] Why have two identical differently named interfaces?

2008-03-13 Thread Maciej Stachowiak




On Mar 13, 2008, at 4:53 AM, Alex Russell wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 12, 2008, at 8:46 AM, liorean wrote:



On 12/03/2008, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
I guess I could do the two interfaces, but I'm having a hard time  
seeing

different extensions being made to these two interfaces (as

opposed to wholly

new interfaces being invented, as was done here).


I can actually imagine one extension that only makes sence on  
elements

and not on any other nodes - element-rooted instead of
subtree-only-but-document-rooted queries. (I don't see any real
benefit from such an interface though, but I've seen the idea
mentioned on the mailing lists.)


The benefit here is the (potential) ability to root queries to  
containing nodes. Nearly every JavaScript library that does CSS  
selectors handles the equivalent of:


node.querySelectorAll("> .thinger");

Which currently has no expression via valid CSS 3 selectors. There's  
no concept of a query being a descendant of a selector root node  
although the above use-case occurs very frequently in real-world  
scripts.


It seems foolish to extend the CSS 3 selectors WD to support a  
syntax that is simple-selector free, whereas it has use in the DOM- 
centric APIs.


Whether this needs to be handled via separate interfaces, I can't  
say (and don't care).


Maybe the best solution would be to add a :scope pseudo-element which  
is the target of the querySelectorAll call if not called on the  
document. That would allow old-school JS library semantics just by  
prepending ":scope ".


Regards,
Maciej

Re: XHR setRequestHeader("connection", "close") is bogusly rejected

2008-03-11 Thread Maciej Stachowiak




On Mar 11, 2008, at 7:00 AM, Kris Zyp wrote:

for UAs is best approach, and that it should be a number-based   
advice, not a boolean, so that it could be used more effectively  
and  flexibly in heuristic algorithms for making informed  
pipelining  decisions.


Can you be more specific in what you mean about "number-based  
advice"? (Apologies if you explained this in an earlier message, I  
tried  skimming them and did not find a description).


I couldn't find my previous message in the archives, so I included  
below again (sorry about posting it again). Basically I was  
suggesting that a property (called "durability") could take a number  
(rather than a boolean), that would represent advice about how long  
the author expected the response to take. The user agent could  
utilize this advice in any way it sees fit. A number provides more  
information (a greater range of values) than a boolean, and it could  
effectively be used as weighting in user agent heuristics. The  
advice could be used by user agents to determine if the connection  
should be counted against the connection limit (if it is larger than  
a threshold), and it could used as advice for pipelining. The user  
agent is not required to respond in any certain way, but this is  
author provided advice, that the user agent may use in any way it  
desires.


The advantage of a number may be more clearly seen in a pipeline  
ordering example. Suppose I issue 4 requests, and I expect request A  
to take a few milliseconds, request B to take a half a second,  
request C to take a couple seconds, and request D could last  
indefinitely. I could set different durability values for each XHR  
request, and then the user agent could potentially use these values  
(possibly in combination with other information, like connection  
speed, proxy information, and so forth) to determine the order of  
pipelining:

xhrA.durability = 0.01;
xhrB.durability = 0.5;
xhrC.durability = 2;
xhrD.durability = 100;
In this situation, a browser may decide to send A and B on different  
connections, and send C as pipelined by request A. It may also  
choose to send D on completely separate connection and not count  
that against the connection limit. However, the advice does not  
require the user agent to take any specific action, the browser can  
weigh the advice in combination with other factors, depending on the  
situation. Anyway, here is the more detailed proposal I had sent  
out, I apologize if you have already received it/read it (it had a  
subject "Re: Pipelining Control Proposal"):


As a browser implementor, I don't think I would find this more useful  
than a boolean property indicating a connection is likely to be long- 
lived. I can't imagine doing anything more complicated than picking a  
threshold value to decide whether to count a request towards the  
connection limit and whether to consider pipelining requests on its  
connection. If all implementors did this, we'd likely end up with  
somewhat different threshold values, which would be unfortunate.


Also, I'm skeptical that authors can estimate request latency with  
anything near that kind of precision. Thus, it is likely to be an  
unreliable source of information, meaning that the details of the  
value couldn't be trusted anyway, and even a high-low threshold might  
be unreliable. But most authors know if their XHR connection is  
intended to be used persistently, so the one bit of info would be more  
trustworthy.


Are there any implementors who would find an estimate of the request  
latency more useful than a boolean "likely to be persistent" indicator?


Regards,
Maciej

Re: XHR setRequestHeader("connection", "close") is bogusly rejected

2008-03-10 Thread Maciej Stachowiak




On Mar 10, 2008, at 4:37 PM, Jonas Sicking wrote:



Kris Zyp wrote:

However, there are web apps in existence (e.g., Gmail)
that set the "connection: close" header to inform the
user-agent that the HTTP transaction is going to take
a long time.  (This is also informative for the
server.)  This allows a user-agent to not count this
connection against the RFC 2616 recommended maximum of
2 persistent connections per host.
As far as I can tell, Firefox is the only browser that regards  
"connection: close" as an indication that the connection should not  
be counted against the connection limit


What gives you that idea? I'm not actually sure since I don't know  
the inner workings of the network code, but I have never heard of  
such behavior.


A commenter on this WebKit bug said so: . But further testing does not seem to bear out this claim.


Regards,
Maciej

Re: XHR setRequestHeader("connection", "close") is bogusly rejected

2008-03-10 Thread Maciej Stachowiak




On Mar 10, 2008, at 7:34 AM, Kris Zyp wrote:

If the problem we are trying to solve is preventing potentially  
long- lived requests from blowing out the connection limit I think  
it would  be better to either:


1) Add an explicit XHR property that indicates this request may be  
long-lived - this would not only bypass the connection limit but  
would also indicate to the UA that it should not pipeline other  
requests on  the same connection, if it supports pipelining.


2) Never count XHR-initiated http requests towards the per-server  
connection limit.
 not seem necessary for the goal of bypassing the connection  
limit on the UA side. And it seems that an explicit XHR property  
for this would  be more clear.
I agree, I think #1 is the way to go. I don't like #2, because  
connection limits really are valuable for minimizing server load,  
and even can help prevent DOS attacks. As I just mentioned in the  
other email, "Connection: close" is not an appropriate form of  
advice, IMO. I think that an explicit property that provides advice  
for UAs is best approach, and that it should be a number-based  
advice, not a boolean, so that it could be used more effectively and  
flexibly in heuristic algorithms for making informed pipelining  
decisions.


Can you be more specific in what you mean about "number-based advice"?  
(Apologies if you explained this in an earlier message, I tried  
skimming them and did not find a description).


Regards,
Maciej

Re: XHR setRequestHeader("connection", "close") is bogusly rejected




On Mar 7, 2008, at 3:02 PM, Morgan L wrote:


Ah, that make sense to me.  I think the current text
has caused major browser engines to "mistakenly" stop
supporting connection: close.  It is easy to blindly
implement whatever the "standards" say :-)

I think it would help if a caveat were added along the
lines of what you have written here.  I think the
"connection: close" example should be used to
demonstrate why it might be wise for a user-agent to
customize what request headers it rejects.

I'm not sure that section 13.5.2 implies that
"connection: close" can be wrong.  It is true that an
XHR users cannot assume that the origin server will
see the "connection: close" header, but it is still
always the case that the UA would see it.  And, in the
example that I provided, the goal is to tell the UA
that it does not need to count this request against
the max-persistent-connections-per-host limit.At
least, I can't see how allowing XHR users to specify
"connection: close" can be regarded as harmful.

Thoughts?


If the problem we are trying to solve is preventing potentially long- 
lived requests from blowing out the connection limit I think it would  
be better to either:


1) Add an explicit XHR property that indicates this request may be  
long-lived - this would not only bypass the connection limit but would  
also indicate to the UA that it should not pipeline other requests on  
the same connection, if it supports pipelining.


2) Never count XHR-initiated http requests towards the per-server  
connection limit.


Given that IE has increased their per-server connection limit to 6,  
and since the HTTP working group is considering dropping the  
connection limit as a formal spec requirement, I would probably advise  
#2 for WebKit and have commented to that effect in the bug you cited.  
From the spec point of view, I think #1 makes more sense since it may  
be inappropriate to require #2 (thoughts from other implementors  
welcome).


Requiring UAs to recognize "Connection: close" as a hint that the  
connection may be long-lived and should not count towards the limit is  
also possible as a variant of option 1. But I am not sure they should  
be required to also pass the header to the origin server. This does  
not seem necessary for the goal of bypassing the connection limit on  
the UA side. And it seems that an explicit XHR property for this would  
be more clear.


Regards,
Maciej

Re: [xmlhttprequest] getResponseHeader() for invalid header




On Mar 7, 2008, at 3:12 PM, Anne van Kesteren wrote:

On Sat, 08 Mar 2008 00:06:02 +0100, Maciej Stachowiak  
<[EMAIL PROTECTED]> wrote:

On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:
Currently getResponseHeader() returns the empty string for invalid  
header names.  Would people object if I changed that to returning  
null instead (basically making it equivalent to headers not part  
of the response)? Thanks.


What do current implementations do for these cases?


I think three out of four return null for a non-existent header (IE  
being the exception, iirc). Firefox and an internal version of Opera  
also return null for invalid headers. (Although for Firefox it seems  
to differ on based on whether the request has happened already or  
something...)


In that case I think it makes sense to use null for both missing and  
invalid headers.


 - Maciej

Re: [xmlhttprequest] getResponseHeader() for invalid header




On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:



Currently getResponseHeader() returns the empty string for invalid  
header names.  Would people object if I changed that to returning  
null instead (basically making it equivalent to headers not part of  
the response)? Thanks.


What do current implementations do for these cases?

 - Maciej

Re: Geolocation API proposal




On Mar 7, 2008, at 2:38 AM, Doug Schepers wrote:



Hi, Aaron-

Aaron Boodman wrote (on 3/6/08 8:55 PM):

I work on Google Gears team. If you're not familiar with what Gears
is, you can learn more here: http://code.google.com/apis/gears.
We've been working on an API that will allow an application to obtain
(with permission) the user's current location. I posted this to the
WhatWG mailing list, but it was suggested that this might be a more
appropriate place.
Anyway, here's our current design:
http://code.google.com/p/google-gears/wiki/LocationAPI
We think there's a lot of potential for interesting applications with
a API like this. Some examples would be recommendations for nearby
restaurants, turn by turn directions, or city walking tours.
Are there any other vendors interested in implementing something like
this? If so, we'd like to work together to come up with a standard.
Otherwise, I'll just put this out there for comment for the time
being. We'd appreciate any feedback on the design, one way or the
other.


This is interesting stuff, and I agree it is very useful to have.

There is already some activity happening in this area, in the  
Ubiquitous Web Applications Working Group (UWA or UbiWeb). [1]  It's  
obviously a hot topic, and one I personally hope can be specified  
and deployed quickly (since we're already about 15 years behind  
Japan in this stuff ^_^ ).


I think you hit the nail regarding vendors... that's a crucial next  
step.


I'm happy to facilitate bringing your insight in this area to W3C,  
and I'm sure we can find the best way to move this forward, and get  
involvement from other vendors.  Feel free to drop me a line  
offlist, and I can do a bit more research and point you in the right  
direction.


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


I am much more interested in Aaron's proposal than in DCCI (comments  
forthcoming).


Regards,
Maciej

Re: Extra Connection Support Proposal

2008-03-06 Thread Maciej Stachowiak




On Mar 6, 2008, at 7:09 AM, Kris Zyp wrote:



Thanks for the heads up, Mark, I will be watching the activity  
there, that would be great if the problem can be dealt with in that  
group.
However, the issues of responses being indefinitely queued in  
pipelining situations and unbounded memory growth on continuous  
streaming responses are still present, and I don't think there is  
anything the HTTP WG can do about that.


I think a hint that a request is expected to be long-term persistent  
would be useful in any case, to let the user agent know that it  
shouldn't pipeline other requests on the same connection. Perhaps this  
can be a simple boolean, if http itself relaxes connection limits and  
so removes the need for more complex functionality along these lines.


 - Maciej



Thanks,
Kris
- Original Message - From: "Mark Baker" <[EMAIL PROTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, March 06, 2008 6:16 AM
Subject: Re: Extra Connection Support Proposal


FYI, you might be interested in this recent discussion in the HTTP  
WG,

which could make this proposal unnecessary;

http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0423.html

Mark.

Re: multipart, server-sent events, and

2008-02-19 Thread Maciej Stachowiak




On Feb 19, 2008, at 11:12 AM, Robert Sayre wrote:


On Feb 19, 2008 1:50 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:


Probably the appropriate forum to make this proposal would be the  
IETF

HTTP Working Group. I'll join the appropriate mailing list if others
are interested in pursuing it there. In advance of this, we could
agree by convention on an unofficial "Connection: x-pipeline" value  
to

see how well this proposal works in practice.

Thoughts?



It's a good idea, but some proxies forward hop-by-hop headers. :(
See <http://www.mnot.net/blog/2007/06/20/proxy_caching>


That document mentions some proxies forwarding headers listed in  
"Connection", and some specific fixed hop-by-hop headers (Trailer, TE,  
Upgrade). But do any proxies actually forward the "Connection" header  
itself?



FWIW, the next Firefox beta will have pipelining enabled for https. I
won't be surprised if we hit bad bugs. Falling back to https in
combination with your proposed connection token might be a fine idea.


That would certainly remove the risk of mistaken forwarding of the  
"Connection" header.


Regards,
Maciej

Re: Extra Connection Support Proposal

2008-02-19 Thread Maciej Stachowiak




On Feb 19, 2008, at 7:55 AM, Kris Zyp wrote:


Extra Connection Support

The XMLHttpRequest should define a property called  
"extraConnection". When

extraConnection is set to true, it indicates that this XHR object's
connection SHOULD NOT be counted against the user agent's connection  
limit.
That is if the user agent adheres to the two-connection limit as  
recommended
by RFC 2616 section 8.1.4, it SHOULD allow two connections not  
counting this
XHR object's connection. If the user agent has other or additional  
connection
limits, this connection should not be counted in the accounting for  
these

connection limits.


As with pipelining, I think this would be better handled at the HTTP  
level than the XHR API level. We could define response headers for a  
server to indicate that it allows more than two connections per  
client, or alternately that a specific connection should not count  
towards the limit.


 - Maciej




Only one XHR object should be allowed to gain extra connection  
status per
document per server. Each document in the browser may be permitted  
one extra

connection per server. Within a document if an XHR object has an extra
connection status for domain1.com, no other XHR objects may have extra
connection status for that server until the first XHR object has  
terminated

it's connection. However, another XHR object may have extra connection
status to domain2.com. Each document in the browser should have it's  
own set
of extra connections for XHR objects. This limitation is intended to  
prevent

a vector of denial of service attacks.


To gain extra connection status, the extraConnection property on the  
XHR
object can be set to true. When it is set to true, if the XHR object  
is
allowed to gain extra connection status (no other XHR objects  
currently have
extra connection status in this document for the specified target  
server),
the XHR object will be given extra connection status and subsequent  
access
to the property will return true. If the XHR object is not allowed  
to gain
extra connection status, subsequent access to the property should  
return

false. The following is an example of valid usage:

var xhr = new XMLHttpRequest();
xhr.open("GET","/resource",true);
xhr.extraConnection = true;
var succesful = xhr.extraConnection;

Setting the extraConnection property should throw an exception if it  
is
called before a URL is provided to the XHR object (through the open  
method
or the constructor). The extra connection status remains in effect  
until the
connection is closed (by network error on normal termination), at  
which point

the property should return false.

Since the extraConnection property usually indicates that the  
response will be a
long-lived streaming response, user agents SHOULD NOT pipeline  
requests on this
connection unless the author explicitly specifies such pipelines  
using pipelining

control (see the Pipelining Control Proposal).

Re: multipart, server-sent events, and

2008-02-19 Thread Maciej Stachowiak

e. (See end of this  
message).



On Feb 18, 2008, at 9:20 PM, Mark Baker wrote:

Hi Maciej,

On 2/18/08, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

Last time I looked into this, there were some proxies and some origin
server configurations (in particular certain Apache modules, perhaps
now obsolete) that broke with pipelining.


Can you define "broke"?

I've done a search on Apache and Squid pipelining bugs, and didn't
find any open ones.


I'll try to do more thorough research, but see above. The result was  
undetectable data corruption in at least some cases.



Since it is not possible to
find out from the server if pipelining is correctly supported, and
since it is not generally possible to tell from the response that it
has failed, enabling it by default in the browser http stack was  
not a

safe thing to do.

Since the breakage is caused in at least some cases by proxies, it is
not in general safe to let XHR users opt in since they may control  
the

origin server but generally would not control whatever proxies are
between the server and the user.

Pipelining is a great potential performance improvement and it's sad
that it can't safely be used on the public Internet right now, so I
hope we someday find a way out of the impasse.


Well, I'd like to see some hard evidence of this before we write it  
off.


I think we need some research before making a decision either way. I  
just wanted to make clear the nature of the risks, and in particular  
that content author opt-in was not sufficient to fully mitigate them.



In any case, I think there is a safer way to enable safe opt-in to  
HTTP pipelining, not just for XHR but for all content. I think the  
best solution is to us a hop-by-hop HTTP header to signal server-side  
support for pipelining. In particular, the "Connection" header is hop- 
by-hop, allows an open-ended series of values, and is semantically  
appropriate for this purpose. So I would propose that we define an  
HTTP response header field of "Connection: pipeline" to indicate that  
the server supports pipelining and encourages its use for this  
particular connection.


I believe this solution is better than a script-side solution in two  
ways:


1) The opt-in uses a hop-by-hop mechanism, so it will not cause  
problems with proxies when the origin server can promise to correctly  
implement pipelining but an intervening proxy cannot. Therefore it  
will save us the effort of even investigating the potential problems  
caused by troublesome proxies and weighing their cost.


2) It can work for ordinary resource loads as well as for XHR, so the  
potential performance benefit is much greater.


Probably the appropriate forum to make this proposal would be the IETF  
HTTP Working Group. I'll join the appropriate mailing list if others  
are interested in pursuing it there. In advance of this, we could  
agree by convention on an unofficial "Connection: x-pipeline" value to  
see how well this proposal works in practice.


Thoughts?

Regards,
Maciej

Re: multipart, server-sent events, and

2008-02-18 Thread Maciej Stachowiak




On Feb 15, 2008, at 2:09 PM, Mark Baker wrote:



On 2/14/08, Kris Zyp <[EMAIL PROTECTED]> wrote:


Another functionality that I believe would be extremely valuable to  
expose
for XHR would be HTTP pipelining control. Most browsers do not  
provide HTTP
pipelining because of compatibility concerns and performance  
implications of

improperly order requests.


I thought it was just that most proxies don't support it on the
outbound connection.  And I've never seen any ordering problems from
the support, or lack thereof, of pipelining.

But I certainly agree that pipelining control would be really useful.


Last time I looked into this, there were some proxies and some origin  
server configurations (in particular certain Apache modules, perhaps  
now obsolete) that broke with pipelining. Since it is not possible to  
find out from the server if pipelining is correctly supported, and  
since it is not generally possible to tell from the response that it  
has failed, enabling it by default in the browser http stack was not a  
safe thing to do.


Since the breakage is caused in at least some cases by proxies, it is  
not in general safe to let XHR users opt in since they may control the  
origin server but generally would not control whatever proxies are  
between the server and the user.


Pipelining is a great potential performance improvement and it's sad  
that it can't safely be used on the public Internet right now, so I  
hope we someday find a way out of the impasse.


Regards,
Maciej

Re: IE Team's Feedback on the XHR Draft

2008-02-08 Thread Maciej Stachowiak




On Feb 8, 2008, at 12:03 PM, Charles McCathieNevile wrote:



On Fri, 08 Feb 2008 22:22:59 +0530, Chris Wilson <[EMAIL PROTECTED] 
> wrote:


2) In fact, on that note, we're interested to see the test suite be  
linked, normatively if necessary.


Yes. I think this is a valuable piece of feedback. Currently W3C  
process doesn't require test suites until you're trying to get out  
of CR and I think it would be better to have them earlier.


I agree that official test suites should be developed earlier than CR.  
Thorough test suites are critical to identifying implementation  
issues, and especially important for specs written after the fact for  
de facto standard technologies. This is a case where it is hard to  
tell if we have met our technical goals without a test suite.  
Fortunately, we have unofficial test suites as a starting point.


However, I think that per standard practice the test suite should not  
be considered normative, only the text of the spec. In particular,  
conformance requirements that are not covered by a test must still be  
binding, and in case of conflict between the test suite and the spec,  
the spec must win. Of course, if the test suite and the spec ever  
disagree we will have to publish bug fixes to the test suite or errata  
to the spec, but in the meantime we need to be clear which is normative.


Regards,
Maciej

Re: IE Team's Feedback on the XHR Draft

2008-02-07 Thread Maciej Stachowiak



Hi Doug,

On Feb 7, 2008, at 2:32 PM, Doug Schepers wrote:



Hi, Anne-

I'm stepping in here to inform on a matter of process.  This is not  
a judgment on the technical merits of either position.



Anne van Kesteren wrote (on 2/7/08 5:42 AM):


o   As per our agreement in the tech plenary the spec will conform  
to IE's implementation of XHR (with the exception of constants)  
and will be changed accordingly. The tests are important for us  
and other UAs as it's the guarantor of that.
We have had no such agreement. I indicated that we have followed  
the IE for a lot of scenarios, but there are some deviations.


It is true that there was no formal resolution on this issue.

(As an aside: Sunava, for future reference, it's most expeditious to  
request a formal resolution on matters about which you feel very  
strongly.  This clears up any ambiguity, makes a point of reference  
for future discussion, and gives opponents an opportunity to present  
counter-arguments. )


However, I seem to recall general agreement about this point among  
the majority of participants; alas, this was not clearly captured in  
the minutes (though the minutes are good, it's hard to grab general  
sentiment).


I was present for the discussion at the Tech Plenary, and I recall the  
following:


1) Sunava was concerned that the XMLHttpRequest spec as written would  
cause compatibility problems for IE, because it might deviate  
significantly from IE's current behavior.
2) Anne indicated that the spec in fact followed IE behavior pretty  
closely, more so than other browsers, where behavior diverged, and  
that this was a general goal but not a strict requirement.
3) We all agreed that it was Microsoft's responsibility to review the  
spec, test IE's implementation, and reported on differences between  
IE's behavior and the spec, and particularly note ones that may affect  
web compatibility.
4) We agreed that, given this information, we would study what changes  
to the spec were appropriate and would make reasonable accomodations.


In particular, Sunava promised that Microsoft would do #3 with a  
deadline of a month after the tech plenary. Now three months later,  
Microsoft has not provided the information they agreed to gather.


I certainly do not recall the group making an agreement to change the  
spec to be 100% IE-compliant, or to make any changes for IE's benefit  
in the absence of further specific information from Microsoft.


Given this, I think the ball remains in Microsoft's court to point out  
where the spec deviates from IE's behavior, and how important these  
behaviors are for compatibility. I am opposed to the group making any  
kind of open-ended commitment in the absence of specific information.


Moreover, this is, in fact, what this WG was chartered to do  
regarding XHR:
"This deliverable should begin by documenting the existing  
XMLHttpRequest interface."


The question becomes, is IE's implementation to be considered  
canonical, or is it up to interpretation vis a vis later  
implementations (FF, Opera, Safari, et al)?


We also later agreed that a spec so broad that it made all existing  
implementations conforming would end up being useless; the conformance  
requirements would have not aided interoperability. Thus we extended  
our goal to specify something as close to existing implementations as  
possible, but also specific in its conformance requirements.


Pursuant to that, is there a way to document the existing behavior  
such that it does not make existing implementation retroactively  
"non-conforming"?  Or that does not affect existing content?  I  
don't know whether or not the existing specification meets these  
criteria, but I think that would be the best path forward.


I think the spec should consider all of the existing implementations  
and in particular what aspects of those implementations are important  
in practice for web compatibility. I believe it does a good job of  
this, but of course specific information to the contrary from  
Microsoft or other parties would be welcome.


Regards,
Maciej

Re: [XHR] send doesn’t explain what to do when method is GET

2007-12-17 Thread Maciej Stachowiak




On Dec 17, 2007, at 5:44 PM, Jonas Sicking wrote:


Maciej Stachowiak wrote:

On Dec 14, 2007, at 4:11 PM, Jonas Sicking wrote:

Julian Reschke wrote:

Jonas Sicking wrote:
Does any currently released browse include the body when doing  
an XHR GET request? If a big majority of them currently drop the  
body, then it seems like it would help interoperability if the  
spec explicitly stated that the body should be dropped.
Disagreed. Please do not try to standardize HTTP APIs that  
profile what HTTP allows.


XHR already disallows a lot of things that HTTP allows. Setting  
certain headers, cross site requests, etc. Why is this different?


Besides that, Björn already reported that both IE7 and FF happily  
pass the body, as they should (IMHO).


My reading of Björns email was that they did not drop it for HEAD,  
OPTIONS and EXAMPLE did not drop the entity body. In my testing  
IE, Firefox and Opera all dropped the entity body of GET requests.

Did you try Safari (or can you post the test case so I can try it?)


I did not try safari. You can try it here:

http://people.mozilla.com/~sicking/xhr_body.html


Safari 3.0.4 (on Mac OS X 10.5) also appears to drop the entity body.  
(Side not for future testing: if you can test IE you can probably test  
Safari for Windows.)


Cheers,
Maciej

Re: [XHR] send doesn’t explain what to do when method is GET

2007-12-15 Thread Maciej Stachowiak




On Dec 14, 2007, at 4:11 PM, Jonas Sicking wrote:


Julian Reschke wrote:

Jonas Sicking wrote:
Does any currently released browse include the body when doing an  
XHR GET request? If a big majority of them currently drop the  
body, then it seems like it would help interoperability if the  
spec explicitly stated that the body should be dropped.
Disagreed. Please do not try to standardize HTTP APIs that profile  
what HTTP allows.


XHR already disallows a lot of things that HTTP allows. Setting  
certain headers, cross site requests, etc. Why is this different?


Besides that, Björn already reported that both IE7 and FF happily  
pass the body, as they should (IMHO).


My reading of Björns email was that they did not drop it for HEAD,  
OPTIONS and EXAMPLE did not drop the entity body. In my testing IE,  
Firefox and Opera all dropped the entity body of GET requests.


Did you try Safari (or can you post the test case so I can try it?)

Regards,
Maciej

Re: ISSUE-119: names lengthComputable and total




On Dec 10, 2007, at 11:16 AM, Charles McCathieNevile wrote:

On Mon, 10 Dec 2007 17:54:49 +0100, Maciej Stachowiak  
<[EMAIL PROTECTED]> wrote:


What would look compelling to me is web content depending on the  
specific names. That's more important than whether someone shipped  
an implementation.


That could indeed be a much more compelling argument. Can you show  
that such content does or does not exist?


As far as I know, it does not. I think the burden of proof would be on  
anyone who wants to claim it does. I don't think anyone is claiming  
this, though.


Having an implementation that is difficult to change, shipped in  
millions of devices, does seem like an argument of some strength in  
the absence of a strong counter argument.


I don't think the API we design for the Web should be driven by non- 
Web uses like JSR-280. It's nice when they can benefit, sure, but the  
W3C's mission is the Web.


I'll admit that method naming isn't the biggest issue. But it seems  
like bad precedent to start giving weight to external standards  
that copy very early stage W3C standards, as this subverts the  
W3C's own standards process, which runs by different rules than the  
Java Community Process.


The base specification has been around for a long time (we inherited  
it from SVG), and it was pretty baked already. People have  
implemented, people have written it up (although it is only draft),  
and based other stuff on it. Others have just chosen equally bad  
names for the same thing. And fundamentally, this naming issue  
doesn't seem to be a really big deal.


The spec has been significantly reworked since it started.  
lengthComputable in particularly was removed entirely for a while and  
added back in March 2007. The whole event design was changed  
significantly based in part on my feedback. I'm not sure we can  
consider it "pretty baked".


This specific issue isn't that big a deal. However, in the past in  
other working groups, the argument "we can't change this because it's  
in JSR-something-or-other" was used many times to reject comments that  
pointed out serious substantive problems with the spec. Allowing a  
Final JSR spec which cut and pasted a W3C Working Draft  to affect  
what may change on the W3C side subverts the W3C Process. Clearly,  
agreements to note what W3C specs are a work in progress are not  
enough to prevent this.


So I'd like to request that Sun not copy immature Web API WG  
specifications into JSRs in the future.


Regards,
Maciej

Re: ISSUE-119: names lengthComputable and total




On Dec 10, 2007, at 8:17 AM, Jean-Yves Bitterlich wrote:



Maciej Stachowiak wrote:




On Dec 10, 2007, at 7:15 AM, Charles McCathieNevile wrote:



Ikivo have told me that they also implemented already with the  
existing event names, and would write to say so.


I am therefore resolving this issue by not changing the names.


I don't think the JSR objection is very strong, since JSR-280 says:

"Note – Note that MouseWheelEvent and ProgressEvent are newly  
included in the W3C DOM3 draft specification and have not yet gone  
through the W3C public review.  These W3C specifications are  
therefore to be considered as work in progress. There may be some  
modifications to these event types in the JSR280 Maintenance  
Release to ensure alignment with the DOM3 Event types."
This clause has been added in respect to the agreement between W3C  
and Sun/JSR-280 given the current state of the related W3C  
specifications.


Sure, and I think we need to respect the spirit and not just the  
letter of that agreement. It seems like a bad idea to freeze W3C specs  
in very early development just because a faster-moving standards  
process copies them.


In general I don't think we want to set a precedent of locking in  
bad names in Editor's Drafts without a compelling reason. An  
implementation alone is not much reason, there would have to be  
significant content depending on it.
agreed. However, JSR-280 is Final Release: i.e. a Reference  
Implementation (RI) as well as a Test and Compatibility Kit (TCK)  
are available and licensed/licensable; Moreover a development kit   
is also available and compliant.

This looks compelling enough ... too me :-)



What would look compelling to me is web content depending on the  
specific names. That's more important than whether someone shipped an  
implementation.


I'll admit that method naming isn't the biggest issue. But it seems  
like bad precedent to start giving weight to external standards that  
copy very early stage W3C standards, as this subverts the W3C's own  
standards process, which runs by different rules than the Java  
Community Process.


Regards,
Maciej

Re: ISSUE-119: names lengthComputable and total




On Dec 10, 2007, at 7:15 AM, Charles McCathieNevile wrote:



Ikivo have told me that they also implemented already with the  
existing event names, and would write to say so.


I am therefore resolving this issue by not changing the names.


I don't think the JSR objection is very strong, since JSR-280 says:

"Note – Note that MouseWheelEvent and ProgressEvent are newly included  
in the W3C DOM3 draft specification and have not yet gone through the  
W3C public review.  These W3C specifications are therefore to  
beconsidered as work in progress. There may be some modifications to  
these event types in the JSR280 Maintenance Release to ensure  
alignment with the DOM3 Event types."


In general I don't think we want to set a precedent of locking in bad  
names in Editor's Drafts without a compelling reason. An  
implementation alone is not much reason, there would have to be  
significant content depending on it.


Regards,
Maciej




cheers

Chaals

On Mon, 05 Nov 2007 21:34:50 +0100, Jean-Yves Bitterlich <[EMAIL PROTECTED] 
> wrote:



Hi,
To the question in ISSUE-119 whether "[...] they already get  
implemented
with these names somewhere?", the answer would yes given that the  
Final
Release of "JSR-280 XML API" (http://www.jcp.org/en/jsr/detail? 
id=280)

defines the following methods based on the already existing names:


|boolean| 	|*getLengthComputable  
*()|

 Specifies whether the total size of the transfer is known.
| int|  |*getLoaded *()|
 Specifies the number of bytes downloaded since the beginning
of the download.
| int|  |*getTotal *()|
 Specifies the expected total number of bytes of the content
transferred in the operation.



Charles McCathieNevile wrote:


Anne opined, a while ago, that these two attributes should have  
names

more closely related. In my request for further information, nobody
said they had any great reason for keeping the current names.

I therefore propose to resolve this issue by changing the name
"lengthComputable" to "totalKnown". Any objections?

cheers

Chaals


Jean-Yves Bitterlich, Senior Staff Engineer
Sun Microsystems GmbH, Sonnenallee 1, 85551 Heimstetten, Germany

Geschäftsführer: Wolfgang Engels, Dr. Roland Bömer;
Vorsitzender des Aufsichtsrates: Martin Häring
Amtsgericht München: HRB 161028, WEEE-Reg.-Nr. DE 20803943
HypoVereinsbank München, Konto 31 625 009, BLZ 700 202 70







--
Charles McCathieNevile  Opera Software, Standards Group
   je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals  Try the Kestrel - Opera 9.5  
alpha

Re: [XHR] send doesn’t explain what to do when method is GET