Last Comment Bug 408098 - Implement XMLHttpRequest cross-site spec changes
: Implement XMLHttpRequest cross-site spec changes
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: ---
Assigned To: Jonas Sicking (:sicking)
Depends on: xxx 411530 416957 416958 416968 424923
  Show dependency treegraph
Reported: 2007-12-12 13:01 PST by Boris Zbarsky [:bz]
Modified: 2008-10-01 02:34 PDT (History)
33 users (show)
mbeltzner: wanted‑next+
jonas: blocking1.9-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Boris Zbarsky [:bz] 2007-12-12 13:01:58 PST
From bug 389508 comment 42:

Anne van Kesteren   2007-12-12 06:23:57 PST

The API for cross-site non-GET requests has changed. Before Firefox 3 is
released this should probably be implemented along with the other requirements.
Comment 1 Boris Zbarsky [:bz] 2007-12-12 13:02:52 PST
And might I say that implementing unstable draft specs is a huge pain?  :(
Comment 2 Anne (:annevk) 2007-12-12 15:18:08 PST
(FWIW, Jonas has agreed with the design changes. Given that the WG was aware of the implementation work he was explicitly asked about this change.)
Comment 3 Peter Van der Beken [:peterv] 2007-12-12 22:55:06 PST
Is this different from bug 397879?
Comment 4 Jonas Sicking (:sicking) 2007-12-13 00:40:58 PST
Yes, we also need to send a no-cache header. And preferably build a local cache that is keyed off of all relevant headers.

Upping this to P1 as we really should fix this for next beta.
Comment 5 Anne (:annevk) 2007-12-13 01:04:27 PST
And implement method on <?access-control?> and Access-Control.
Comment 6 Mike Schroepfer 2008-02-11 20:12:45 PST
Sicking - we doin ok here?
Comment 7 Jonas Sicking (:sicking) 2008-02-12 01:27:01 PST
There are things left, mostly due to a new feature that was recently added (hopefully last one). Filed bug 416957 on that.

There's also been some changes to the headers, so i filed bug 416958 on that.
Comment 8 Anne (:annevk) 2008-02-12 01:43:32 PST
Should I file a bug on removing deny support or is that covered somewhere?
Comment 9 Jonas Sicking (:sicking) 2008-02-12 01:47:27 PST
Please file.
Comment 10 Anne (:annevk) 2008-02-12 03:36:41 PST
Bug 416968.
Comment 11 Jonas Sicking (:sicking) 2008-02-27 15:47:21 PST
We're not doing cross-site XHR for this release due to security concerns :(
Comment 12 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 04:01:46 PST
Can we elaborate on that somewhere?  I thought this was a _real_ blocker, in that we would hold the release for it, and we've certainly been advertising it to developers as a done deal.  If nothing else, we're going to need help explaining to them in more detail than "security concerns" (concerns with our implementation? concerns with the inherent semantics of the spec?) to defuse things.
Comment 13 Brendan Eich [:brendan] 2008-02-28 09:10:24 PST
With the WHAT-WG postMessage API, one can construct communicating windows to do cross-domain XHR anyway. That gives some defense in not sharing a DOM, mixing DOM data loaded from different domains. Is that sufficient reason for requiring users to load a JS library constructing such communicating windows/iframes in order to do cross-site XHR?

Comment 14 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 10:02:42 PST
How does my client-side app construct a window that has an origin of and put my own script in it to listen to postMessage and XHR for me?  That sounds like a major security model violation, if so.
Comment 15 Brendan Eich [:brendan] 2008-02-28 10:07:27 PST
The two sides of the postMessage channel need to cooperate, yeah -- that's the real defensive win compared to native cross-site XHR.

Comment 16 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 10:22:26 PST
So that means that any site that wants to permit people to load data from it needs to serve up a page from a well-known URL that implements some postMessage protocol?  That seems like pretty painful and unlikely to take off at useful scale.
Comment 17 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 10:27:25 PST
I'll ask, because we'll be asked for sure: are the security characteristics of what Flash does (well-known file per site, etc.) better than the W3C proposal?  Are there security liabilities associated with the model Flash has that make it inappropriate for us to just adopt?
Comment 18 Anne (:annevk) 2008-02-28 10:45:21 PST
Flash is worse, I'm told. Also note that for cross-site XHR the target site needs to cooperate too. It has to explicitly allow access from the request origin ("Access-Control: allow <>" for origin
Comment 19 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 10:51:33 PST
Yes, but there's a specification for that, and it's a lot easier to do it than to write the postMessage recipient page and tell people how to find it for a given service.
Comment 20 Anne (:annevk) 2008-02-28 12:08:41 PST
There's a spec for postMessage too... And regarding simplicity, I guess that's true, but with copy & paste. :-)
Comment 21 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 12:12:03 PST
Copy & paste and reimplementing the location patterns and method restrictions and such, no?
Comment 22 Brendan Eich [:brendan] 2008-02-28 12:35:30 PST
Shaver, please: Ajax libraries. Users don't have to reinvent wheels these days.

Ok, I'm not advocating a postMessage-based scheme, just repeating loose talk from around the office yesterday. Point is that different domains can communicate in a postMessage-equipped browser. Does that reduce phear of cross-domain XHR?

Giving developers more rope is the way of the web, but I admit it's early and we would like to avoid taking the first cdXHR bath.

Anne, what are Opera's plans, can you say?

Comment 23 Anne (:annevk) 2008-02-28 12:48:23 PST
We want cross-site XMLHttpRequest, but it's too late for 9.5.
Comment 24 Brendan Eich [:brendan] 2008-02-28 13:56:50 PST
(In reply to comment #11)
> We're not doing cross-site XHR for this release due to security concerns :(

Was this a decision made openly, with a newsgroup thread? I'm not throwing stones, but I just heard about it yesterday or the day before, and obviously shaver only heard it here. What's the rationale, in this sense: under what conditions would we ship it, where the conditions don't hold today?

Comment 25 Brendan Eich [:brendan] 2008-02-28 20:43:30 PST
Ok, after talking to sicking (who reminded me the objections were at the 2nd open security review meeting -- sorry for doubting), here's what I think:

* We shouldn't pull cross-site XHR for bad reasons, or vague reasons, or we won't know when to push it back into a release. We need to agree on what constitutes a sound reason for not including this feature.

* Sicking says there's high likelihood of the spec changing (see bug 389508 comment 42 too). He also thought we might force the spec to converge by shipping, which is a bad sign for the committee IMHO.

* There's fear about cookie infrastructure being reused in leaky ways, which is a good concern, but either we give 'em rope with warning labels and good docs, or we are losing. Give 'em rope is the way of the web, and indeed with more work and WHAT-WG postMessage, there's other rope to use anyway.

* dbaron had more thoughts on cookie threats that I can't represent here, but it might be useful to folks if he did.

* Jesse and I seemed to be agreeing that the spec more or less as-is could make the world a better place, by reducing password re-prompting and script injection hacks. In other words, there is likelihood of better security, but it's hard to weigh this against the risk of cookie abuses and other mistakes.

* Sicking said something about features being pushed into the spec at this late date that I do not remember. Performance scaling concerns are fine to fix before finalizing, but please save the features for a successor standard. I'm preaching to the wrong choir here, I'm sure.

All of this sums up to Do Not Ship Yet. I'd rather we ship JSONRequest, which is free of cookies by design and which has a stable spec. See bug 360666.

Comment 26 Anne (:annevk) 2008-02-29 04:17:01 PST
Apart from an issue around setting request headers I'm not sure what sicking is referring to... We actually dropped features on request of Mozilla. I agree that the specification changing in the last month or so has not been ideal. The reason for that is that it starting getting attention pretty late in the game, which is unfortunate.

I'm not really convinced that's enough reason to introduce a new (limited) network API though.
Comment 27 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-02-29 10:13:06 PST
(In reply to comment #25)
> * dbaron had more thoughts on cookie threats that I can't represent here, but
> it might be useful to folks if he did.

I think they added up to that I wasn't convinced by the arguments on either side.  In other words, I haven't been convinced that there are good use cases where cookies can be useful without the author shooting himself in the foot, and I haven't been convinced that allowing cookies is harmful either (at least given appropriately clear documentation on what the risks are).
Comment 28 Mike Beltzner [:beltzner, not reading bugmail] 2008-03-25 07:36:51 PDT
(In reply to comment #25)
> All of this sums up to Do Not Ship Yet. I'd rather we ship JSONRequest, which
> is free of cookies by design and which has a stable spec. See bug 360666.

Should that bug be marked wanted-next?
Should *this* bug be marked wanted-next?
Comment 29 Anne (:annevk) 2008-09-25 08:37:00 PDT
This bug became bug 389508 again, it seems.
Comment 30 Jonas Sicking (:sicking) 2008-10-01 02:34:39 PDT
This was done as part of bug 389508

Note You need to log in before you can comment on or make changes to this bug.