Re: [UMP] Request for Last Call

On 8/04/10 2:40 PM, Tyler Close wrote:
> On Wed, Apr 7, 2010 at 8:50 PM, Maciej Stachowiak<>  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.

To me personally, it only really makes sense for UMP to be merged into 
CORS. Having both specs is confusing. To have UMP as an optional add-on 
does not feel right because of the DBAD issue.

Marcos Caceres
Opera Software

Received on Thursday, 8 April 2010 12:45:16 UTC