W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Semi-public resources in Uniform Messaging

From: Tyler Close <tyler.close@gmail.com>
Date: Wed, 9 Dec 2009 13:30:14 -0800
Message-ID: <5691356f0912091330s54a8b233rec754ac85e3db2d1@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps@w3.org
On Wed, Dec 9, 2009 at 10:10 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 9 Dec 2009, Tyler Close wrote:
>> On Wed, Dec 9, 2009 at 7:43 AM, Ian Hickson <ian@hixie.ch> wrote:
>> > Ok, let's move on to a more complex case.
>> >
>> > Consider a static resource that is protected by a cookie authentication
>> > mechanism. For example, a per-user static feed updated daily on some
>> > server by some automated process. The server is accessible on the public
>> > Web. The administrator of this service has agreements with numerous
>> > trusted sites, let's say a dozen sites, which are allowed to fetch this
>> > file using XHR (assuming the user is already logged in). The sites that
>> > fetch this file do not require authentication (e.g. one could be my portal
>> > page, which is just a static HTML page, without any server-side script).
>> > Other sites must not be allowed access to the file.
>> >
>> > How does one configure the server to handle this case?
>>
>> Again going with the simplest thing that could possibly work:
>>
>> Each of the per-user static feeds is referenced by a unique
>> unguessable URL of the same format used in the previous example. For
>> example,
>>
>> https://example.com/user123/?s=42tjiyrvnbpoal
>> https://example.com/user456/?s=sdfher34nvl34
>> ...
>>
>> Again, a GET response from such a URL carries the same-origin opt-out
>> header.
>>
>> The user gives this URL only to those services he wants to access the
>> feed. For example, you could copy this URL into your personal static
>> HTML page that acts as your portal.
>
> I think asking users to pass around secret tokens is a non-starter.

Users pass around secret tokens all the time, they just don't realize
that's what they're doing. I assume your statement above is actually
meant to say: "I don't want users to see the secret tokens". That's
fine. There are a number of ways of doing the GUI such that the user
doesn't see the token. We did just such an example for Maciej's
calendar scenario. For the above challenge, you specifically asked
about the configuration of the server, not the GUI. We can move on to
discussing the GUI if you're saying you have no problem with the
server configuration. The permission grant and permission exercise
phases are analogous to the previous Maciej calendar scenario, so we
can reuse those diagrams for the explanation. Just substitute "feed
reeder" for "upcoming event" site, and "read feed" for "add event".

http://sites.google.com/site/guestxhr/maciej-challenge

I'll note that I am providing UMP solutions to challenge problems that
meet arbitrary constraints placed on server and GUI. On the other
hand, no one has offered a CORS solution to the printing a photo
scenario that doesn't resort to using similar secret token techniques.
AFAICT, there is agreement that use of secret tokens is a necessary
technique, which is far from being a "non-starter".

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Wednesday, 9 December 2009 21:30:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT