Close, Tyler J. wrote:
Hi Jonas,
Please try re-reading my first post in this thread. I tried to explain this
issue in that message. I'll put some more text below to try for further
clarification.
I might have misunderstood your initial mail, it sounded to me like you
were depending on a dishonest browser, but maybe that wasn't the case?
Jonas Sicking wrote:
Close, Tyler J. wrote:
> Since the cross-domain request is labeled by the browser with the
> Referer-Root of Site A, it is tempting to say Site A should be held
> accountable. Unfortunately, this is not secure since Site B cannot
> know for sure that this labeling was done by an honest
browser. Using
> another tool, the user could send a request to Site B
labeled with a
> Referer-Root for Site A, in effect attempting to blame
Site A for the
> request to Site B. So Site B is left in the position of
not being able
> to hold either the user or Site A accountable for the request.
What accountability mechanism is used today if the browser
isn't honest?
It seems to me like you are hosed then no matter what in the scenario.
Today, the user is assumed to have sole possesion of their password and the
power to determine how it is used. This WG is relaxing this constraint to
additionally give certain approved sites the ability to wield the user's
password. The problem is that in this new world we don't know who to hold
accountable for any given request: the user or the site named by the
Referer-Root header.
Ah, well, I'd say it's the Referer-Root site acting as an agent for the
user. So if you trust the Referer-Root site then you can hold the user
accountable. But if you don't trust the Referer-Root site, such as if
you've never heard of it, then you should hold the Referer-Root site
accountable.
Does that answer your question?
/ Jonas
