Re: Semi-public resources in Uniform Messaging

On Thu, Dec 10, 2009 at 12:19 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 10 Dec 2009, Tyler Close wrote:
>> On Thu, Dec 10, 2009 at 10:17 AM, Ian Hickson <ian@hixie.ch> wrote:
>> > That looks _really_ complicated.
>>
>> By many measures, your CORS based solution is more complicated.
>
> The measure I care about is how easy is it to explain and implement. By
> that measure, CORS is simpler. (It's not my solution, by the way; I
> personally haven't really been involved in CORS' development and don't
> really have a horse in this race.)

By "your CORS based solution", I meant your solution to providing Site
B with access to a feed hosted by Site A. I meant your *use* of CORS
for this example, not CORS itself.

In terms of ease of explanation, if you're willing to let the user do
a single copy-paste operation, much of the complexity melts away.
Start with that explanation and then refer them to the appendix for a
design that avoids the copy-paste if they think that user gesture is
evil.

>> 1. It requires a login to Site A for every login to Site B, wheres the
>> UMP solution does not. That means the UMP solution has:
>> - fewer HTTP requests across the full lifetime of the interaction
>> - fewer user interactions across the full lifetime of the interaction
>
> In practice, Site A has a login mechanism already, so this isn't a big
> deal. (If it didn't, then it wouldn't have per-user data that it could
> expose to multiple other sites.)

I wasn't counting new lines of code to be written. I was counting the
requests generated by that code and the user gestures required.

>> 2. It creates a CSRF-like vulnerability. In an interaction with Site C,
>> Site B must be careful with how it handles the response to a GET request
>> done on at the direction of Site C. For the GET request, Site C could
>> provide the well-known URL for user feeds. A page from Site B could then
>> inadvertently expose this data to Site C because the code wasn't written
>> with the expectation that Site A might be involved.
>
> This only happens if you use URIs as tokens, which I strongly believe is a
> bad idea in general. It's simpler, and safe, not to.

In the sentence above, are you using the word "token" as a synonym for
"identifier"?

>> 3. The CORS solution is not implementable for popular user agents today.
>> The XDR API does not support the kind of request the CORS solution needs
>> to make. The UMP solution can be implemented in a cross-platform way
>> today (the code needs browser specific customizations for different
>> constructor names and parameters, but it can work).
>
> Indeed. Today that's what people do. It's complicated and I'd like us to
> provide a simpler solution.

I guess we just disagree on what counts as complexity.

>> The UMP spec may not be exactly what you had in mind; but I believe I've
>> shown that it meets all the requirements, is safer, and represents a
>> consensus amongst current deployments.
>
> I honestly think that any benefit that might be reaped from avoiding
> sending the Origin explicitly is completely outweighed by the risks
> involved in having such a complicated implementation.

The scenario you outlined requires more than just the Origin header,
it also requires the user cookies. Adding the Origin header by itself
wouldn't eliminate any complexity. It would create CSRF-like problems.

--Tyler

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

Received on Thursday, 10 December 2009 21:06:46 UTC