Sunava Dutta wrote:
>This message is not attempting to set forth in detail all the
objections we have had; Sunava will >deliver that in a concise form.
Can you give us a ballpark ETA on this?
> [Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to
> be ready and available to the Web API by mid June in the latest.
Wow, this is really bad news that we won't get this feedback until just
two weeks before the face to face meeting. Especially given the numerous
delays in getting this feedback in the past I am very worried that there
will be further delays. Are you absolutely certain that won't happen again?
Even just having two weeks in order to discuss this feedback prior to
the meeting seems like very short on time.
I would really encourage you to consider providing this feedback more
promptly. I do not wish to attend a face to face meeting solely to
discuss new feedback which we have not had the opportunity to research
and cannot usefully discuss. I also hope to cover much more than
microsofts feedback during the meeting.
> I don't think there should be any surprises here as we have
> communicated our concerns before.
I most certainly do expect there to be plenty of surprises here. I and
many others have had a very difficult time understanding the concerns
that microsoft has had so I hope that most of what you will be providing
will be new information.
[Sunava Dutta] Wildcarding was a problem in Flash (one of many?). I'm not sure
if AC is vulnerable to that but it certainly seems possible? The point here is
that a number of developers won't ready the security notes on the docs and
inadvertently expose their services. Solutions should be coded for the lowest
common denominator. That's hard to understand given that most Web API
participants are quite technical.
http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html
Please note that that article does not point out a single site that is
in fact vulnerable. It does seem to say that 1 site out of fortune 500
and 2 out of the alexa top 100 sites has a wildcarded crossdomain.xml
policy. It does not say if any of those sites actually host sensitive
information.
However I do agree that crossdomain.xml is a very interesting case
study. We should make sure to study that and learn from any mistakes
made there.
[Sunava Dutta] If we can agree on the security principles (hopefully
the F2F) hopefully a safe way to do AC can be developed.
First off, i certainly hope that we will be discussing the security
principles before the F2F. I am very glad to see that microsoft recently
have become active on this mailing list and hope that that will not stop.
The more we can discuss the issues before the F2F the more productive we
can be at the meeting.
These are
certainly scenarios that this feature is useful for that's why we're
proposed XDR alongside. Although we invented XHR here we've been
concerned about using it cross domain as mentioned before. I think the
uber point with CS-XHR is the behavior is different in the two modes
(same site and cross domain). That's confusing enough.
While this is certainly an interesting discussion to have, I'm not sure
I see the security implications between using an old API with new
restrictions vs. creating a new API.
This rather simply seems like a DOM API issue rather than a security
model issue.
We desire this also. Specifics help illustrate points best.
[Sunava Dutta] Again, specifics will be provided however I reiterate, don't
expect a stream of specifics to ensure that solution is ready to ship.
I'm not sure I follow what you are saying here. Is your email on June
15th not going to include enough specifics to be able to discuss needed
changes to the spec? That would seem very very unfortunate.
/ Jonas
