Re: [UMP] Request for Last Call

On Wed, Apr 7, 2010 at 8:50 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Here's what I can tell you about Apple's current thinking:
>
> - We are currently shipping support CORS via XMLHttpRequest in Safari and
> WebKit.
> - We do not plan to drop support for CORS.
> - We do not plan to implement UMP directly from the UMP spec.
> - If CORS gains a no-credentials subset, and XHR2 gained an API to use that
> subset, we would likely implement that (no firm promises or timelines
> though).
> - If the CORS no-credentials subset ended up not matching UMP in some
> detail, then our implementation would follow CORS, not UMP.
>
> The reason for this is that the style of the CORS spec will help us
> understand where the if statements should go in our implementation. We do
> not want to implement UMP as a completely separate code path; we'd like it
> to be a mode of the code that already handles CORS.

I see two issues here, one that should be straightforward to address
and one that is more involved.

Starting with the easy one first, I was hoping Section 5, "Uniform
Messaging Policy API Specification Advice", would help CORS
implementers adapt to UMP. Please suggest any clarifications or
elaborations to this section that would be helpful in this regard. The
intent is for implementers to use the "Uniform Messaging Algorithm",
where CORS uses the "Simple Cross-Origin Request".

The second issue is addressed at the end of this email.

> Thus, while we may end up implementing UMP by coincidence, our plans will
> likely not be directly affected by the UMP spec, whether or not it proceeds
> to Last Call, or the existence of a UMP test suite. (I'm actually not sure
> how it is even possible to make a UMP test suite without having a client API
> that does UMP processing.)
>
>
> I cannot speak for the whole WebKit community, since I haven't gathered
> broad input, but it is likely that the broader WebKit community would lean
> in a similar direction. For example, patches to add a UMP-specific DOM API,
> or to add UMP client code wholly separate from CORS client code, would
> likely be rejected.
>
> Also, none of this is set in stone. We reserve the right to change our plans
> in the future.

Assuming a fix for the implementation advice section of UMP, I think
all of your stated concerns can be addressed, allowing WebKit to claim
conformance to both UMP and CORS. Since you indicate this conformance
might even arise by accident, the implementation burden should be
small.

Reading between the lines, and please correct me if I'm mistaken, I
suspect what you're really saying is that you don't want two specs to
exist and you feel committed to CORS. There's again an easy and a hard
way to address this point. The easy way is for CORS to be written as
an extension of UMP. There's no technical reason why this can't be
done. CORS is the superset and so could be written as an extension of
the subset. The harder choice is to drop support for CORS. Whichever
choice is made, I think there is a burden on CORS to explain the
"Don't Be A Deputy" (DBAD) policy you've claimed enables developers to
safely use CORS. If this policy is fully explained to developers, I
believe its restrictions will seem onerous and error prone. If this
policy is not successfully communicated to developers, CORS creates a
subtle and dangerous security trap of a kind we've seen developers
fall victim to already with CSRF attacks.

Regardless of how Apple decides to handle the superset part of CORS,
standardizing the subset that we all feel is useful is valuable for
the Web. We should find a way to capture this value by pushing UMP
forward.

--Tyler

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

Received on Thursday, 8 April 2010 12:40:37 UTC