Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

On Mon, Apr 12, 2010 at 5:28 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Apr 12, 2010 at 4:28 PM, Tyler Close <tyler.close@gmail.com> wrote:
>> On Mon, Apr 12, 2010 at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Mon, Apr 12, 2010 at 3:48 PM, Tyler Close <tyler.close@gmail.com> wrote:
>>>> On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>> On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close <tyler.close@gmail.com> wrote:
>>>>>>> I think even taken together, your set of subset conditions does guarantee
>>>>>>> that a CORS client implementation is automatically also a UMP client
>>>>>>> implementation. If we went that way, then we would have to consider whether
>>>>>>> there will ever be client implementors of UMP itself, or it will be
>>>>>>> impossible to fulfill CR exit criteria.
>>>>>>
>>>>>> If there are implementers of CORS, then by definition, there are
>>>>>> implementers of UMP. I don't see anything in CR exit criteria that
>>>>>> requires implementers to swear not to also implement other
>>>>>> specifications.
>>>>>
>>>>> So is sending the 'Origin' and 'Referer' headers ok per UMP?
>>>>
>>>> Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value
>>>> for Referer would be OK.
>>>>
>>>>> The current CORS implementation in firefox always sends those headers.
>>>>
>>>> Then that implementation is only compatible with UMP when used in
>>>> combination with some mechanism for putting the requesting content in
>>>> an anonymous <iframe>. Ideally, Firefox would allow this to be
>>>> expressed via the messaging API instead of requiring the anonymous
>>>> <iframe>.
>>>>
>>>>> I would have imagined that UMP would explicitly forbid any ambient
>>>>> authority or identity information other than IP number?
>>>>
>>>> Correct.
>>>
>>> It seems to me then that Firefox implements CORS, but does not
>>> implement UMP. The fact that a web page can use javascript to
>>> implement UMP using the primitives implemented by the browser doesn't
>>> change the fact that the browser doesn't implement UMP. We have had
>>> similar situations in the past where javascript libraries have been
>>> able to implement various CSS features, despite those features not
>>> being natively implemented by the browser. I also think it would be
>>> possible to implement CORS purely in javascript as well, as long as
>>> you can set the 'Origin' header for same-site XHR requests (this is
>>> possible in older browser versions).
>>>
>>> We have traditionally not counted such javascript implementations
>>> towards the "two implementations" requirement.
>>
>> Does that tradition necessarily apply to a specification that only
>> defines a security policy and no API, such as CORS or UMP? That kind
>> of spec hasn't been done before. With the CSS example, there is an
>> actual piece of syntax you can point to and show that the browser
>> doesn't implement it. In UMP, the only syntax to point at is the
>> "Access-Control-Allow-Origin" header and Firefox implements that as
>> specified. Neither CORS nor UMP specify the syntax required for making
>> a request. The browser is free to use whatever arcane syntax it wants.
>
> Yes, both CORS and UMP are effectively protocol specifications. Other
> specs, such as XHR L2, specifies when they are to be used. I don't
> think that makes a difference as far as the 2 implementation
> requirement though. But note that I'm not the ultimate authority on
> the matter by any means.
>
>> In either case, my ultimate goal is to get a nice syntax for UMP in
>> the browser. Given that we all recognize the value of this
>> functionality and some have actually implemented it, why not give it a
>> nice syntax? Shouldn't a future version of Firefox make it easy to
>> express a uniform request instead of requiring the developer to jump
>> through hoops?
>
> I wouldn't be opposed to implementing UMP, as long as there's a decent
> API for invoking it, and that it's a good subset relative to CORS. I
> think we've talked about various constructors or flags that let you
> use the XHR API together with the UMP protocol.

Oh, I should mention one concern that I have with UMP though. The spec
seems to explicitly forbid sending the 'Referer' header [1]. I
understand the purpose of this as the Referer header can be
interpreted as ambient authentication.

However a problem is that I think many sites rely on this header for
things other than authentication. Such as measuring load from various
3rd parties, measuring who loads data in order to provide back links,
etc. This is done for public data as much as for private.

I don't have a solution to propose. Nor do I at this time think that
this is a blocker issue. However I wouldn't be surprised if sites will
not want to deploy UMP because of this.

[1] Section 3.2, Sending a Uniform Request, says: "MUST NOT add any
information obtained from ... or the referring resource". For what
it's worth, I think this could be made more clear.

/ Jonas

Received on Tuesday, 13 April 2010 17:18:06 UTC