Subject: HTTPbis and the Same Origin Policy

From: Tyler Close <[email-masked]>
Date: Wed, 25 Nov 2009 07:39:51 -0800

AFAICT, HTTPbis says nothing about the Same Origin Policy (SOP), yet
this policy is a major constraint on the behavior of many HTTP user
agents, restricting what HTTP requests can be sent and what HTTP
responses can be delivered. SOP is not defined by any standard. Should
HTTPbis step up?

--Tyler

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Nov 2009 16:50:40 +0100

Tyler Close wrote:
> ...

Well, HTTPbis (as WG and set of specs) is really constrained in what 
we're doing, see <http://www.ietf.org/dyn/wg/charter/httpbis-charter>. 
And that's a good thing, because an open-ended charter would make it 
likely that we never finish.

That being said, defining this in a spec probably *is* a good idea. Did 
you just volunteer? Note that to produce a spec you actual IETF WG is 
required.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Nov 2009 17:16:49 +0100

> you just volunteer? Note that to produce a spec you actual IETF WG is 

s/you/no/

Br, Julian

---

From: Tyler Close <[email-masked]>
Date: Wed, 25 Nov 2009 09:27:46 -0800

On Wed, Nov 25, 2009 at 7:50 AM, Julian Reschke <[email-masked]> wrote:
> Well, HTTPbis (as WG and set of specs) is really constrained in what we're
> doing, see <http://www.ietf.org/dyn/wg/charter/httpbis-charter>. And that's
> a good thing, because an open-ended charter would make it likely that we
> never finish.

Quoting from the charter:
"""
The working group will refine RFC2616 to:
...
* Document the security properties of HTTP and its associated
echanisms (e.g., Basic and Digest authentication, cookies, TLS) for
common applications
"""

Given that charter, it's hard to see how the WG can escape documenting
the Same Origin Policy. It is a necessary part of how common
applications use HTTP Auth, cookies and even unadorned HTTP requests
and responses.

> That being said, defining this in a spec probably *is* a good idea. Did you
> just volunteer? Note that to produce a spec you actual IETF WG is required.

;) No, I wasn't trying to throw myself on that grenade. ;) Not yet at
least. Documenting SOP is a *big* task. I understand why it makes you
worry about slipping deadlines. So, should the charter be revised to
exclude the primary security policy that governs use of HTTP? ;)

--Tyler

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 25 Nov 2009 18:46:15 +0100

Much of this material is in fact part of the HTML5 and XMLHttpRequest specifications.

The XMLHttpRequest specification is in Last Call as of 19 November (with 16 December deadline), and it includes a specification of the same origin policy for XMLhttpRequest -- see step 13 of the open() method [1].

http://www.w3.org/TR/XMLHttpRequest/#the-open-method

I'll note that that specification lacks any security considerations at this point, and that calling out the same origin policy more prominently (and talking about DNS rebinding) sound like they would be fine and timely additions to that spec.

Additionally, I suspect that in-depth review from the HTTP Working Group would be an extremely valuable for this spec.

HTML5 defines a number of relevant policies:

  http://dev.w3.org/html5/spec/Overview.html#security
  http://dev.w3.org/html5/spec/Overview.html#security-1
  http://dev.w3.org/html5/spec/Overview.html#security-2
  http://dev.w3.org/html5/spec/Overview.html#relaxing-the-same-origin-restriction
  http://dev.w3.org/html5/spec/Overview.html#security-and-privacy-considerations
  http://dev.w3.org/html5/spec/Overview.html#security-with-canvas-elements
  
There are a few more places.  Unfortunately, the easiest way to identify all cases in which HTML5 explicitly specifies a security policy seems to be searching for the "SECURITY_ERR" exception.

Regards,
--
Thomas Roessler, W3C  <[email-masked]>

---

From: Arthur Barstow <[email-masked]>
Date: Wed, 25 Nov 2009 13:25:02 -0500

Mark, All,

As Thomas notes below, the WebApps WG seeks comment on the LCWD of  
the XHR spec:

  http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/

If you have any comments, please send them to [email-masked] ;  
comment deadline is 15 December 2009.

-Art Barstow

Begin forwarded message:

> From: ext Thomas Roessler <[email-masked]>
> Date: November 25, 2009 12:46:15 PM EST
> Subject: Re: HTTPbis and the Same Origin Policy
> Archived-At: <http://www.w3.org/mid/ 
> [email-masked]>
>
> The XMLHttpRequest specification is in Last Call as of 19 November  
> (with 16 December deadline), and it includes a specification of the  
> same origin policy for XMLhttpRequest -- see step 13 of the open()  
> method [1].
>
> I'll note that that specification lacks any security considerations  
> at this point, and that calling out the same origin policy more  
> prominently (and talking about DNS rebinding) sound like they would  
> be fine and timely additions to that spec.
>
> Additionally, I suspect that in-depth review from the HTTP Working  
> Group would be an extremely valuable for this spec.

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 12:26:28 -0800

> exclude the primary security policy that governs use of HTTP? ;)

The same-origin policy is defined here:

http://tools.ietf.org/html/draft-abarth-origin

Adam

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 12:30:04 -0800

> http://tools.ietf.org/html/draft-abarth-origin

Actually, that draft is out of date.  I've just uploaded a new draft,
which I've also attached to this message.

Adam

---

From: Tyler Close <[email-masked]>
Date: Wed, 25 Nov 2009 13:18:37 -0800

> which I've also attached to this message.

That I-D defines an identifier for an origin, but not the Same Origin
Policy. For example, what document says: a HTTP PUT request cannot be
sent cross-origin.

--Tyler

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 13:25:40 -0800

> Policy. For example, what document says: a HTTP PUT request cannot be

Whether one can send an HTTP PUT request to another origin depends on
which API is being used.  For the HTML Form element, the HTML
specification contains this requirement.  For the XMLHttpRequest API,
the XMLHttpRequest specification contains the requirement.

The essence of the same-origin policy is the "sameness" relation
(i.e., how to compute it on URLs), which is what's contained in that
draft.  The details of what actions are restricted to the "same"
origin are details best left to the application layer.

Adam

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 25 Nov 2009 22:28:58 +0100

On 25 Nov 2009, at 22:18, Tyler Close wrote:

> Policy.

It also defines what the "equality" operator in the same-origin policy means.

> For example, what document says: a HTTP PUT request cannot be
> sent cross-origin.

XMLHttpRequest, for the purposes of HTTP PUT requests caused through that API.

No spec, for form submissions, since the policy doesn't hold for these.

---

From: Tyler Close <[email-masked]>
Date: Wed, 25 Nov 2009 13:34:58 -0800

> origin are details best left to the application layer.

My impression is that the undefined consensus understanding of the
Same Origin Policy incorporates the rule that no API (not just a
specific API, such as HTML form) can allow a cross-origin PUT, unless
the target resource has somehow opted out of SOP protection. This
rule, and others like it, are the source of much of the complexity in
CORS. These rules are not left to the application layer.

--Tyler

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 13:54:12 -0800

On Wed, Nov 25, 2009 at 1:34 PM, Tyler Close <[email-masked]> wrote:
> the target resource has somehow opted out of SOP protection.

I think you're confusing two things:

1) What is an origin?
2) What restrictions ought we to place on cross-origin interactions?

draft-abarth-origin answers question (1), and the answer to this
question has been quite stable for a while as an equivalence relation
on URL/URI/IRIs.  Humorously, the relation has been more stable than
the things it relates!

The answer to question (2) is much less stable and depends on a lot of
application layer issues.  For example, consider the HTML Canvas
Element.  HTML5 lets you draw an image from an arbitrary origin onto
the canvas, but drawing a cross-origin image changes the behavior of
the toDataURL API.

I don't think there's a way to spec the answer to (2) at the protocol
layer.  The restrictions are inherently application-dependent.

> This

Indeed.  Security in the application layer is quite complex.  That's
what makes life interesting.  :)

Adam

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 13:56:23 -0800

> 2) What restrictions ought we to place on cross-origin interactions?

I should also note that the answer to question (2) has very little to
do with HTTP.  For example, the restrictions on interacting with
cross-origin images in an HTML Canvas apply just as well when the HTML
document is retrieved over FTP and the image is retrieved over Gopher.

Adam

---

From: Tyler Close <[email-masked]>
Date: Wed, 25 Nov 2009 14:34:03 -0800

> 2) What restrictions ought we to place on cross-origin interactions?

No, I think I understand the difference between a thing and what you
can do with that thing. I think my point comes down to a rephrasing of
2):

2) What restrictions have been placed on cross-origin interactions and
must forever be obeyed by all APIs?

> what makes life interesting.  :)

So are you agreeing that there do exist SOP rules that the application
layer must obey? If so, should we document those rules?

--Tyler

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 25 Nov 2009 15:12:19 -0800

> CORS. These rules are not left to the application layer.

CORS attempts to follow this rule: the only requests that can be  
issued cross-origin without explicit opt-in (preflight) are ones that  
could have been issued by following a link or submitting a form. It is  
assumed that just the ability to issue such a request (without reading  
the response) would not create new vulnerabilities. This is the reason  
custom methods and headers are not allowed without preflight. It is  
also the reason Content-Type is restricted to a small whitelist  
without preflight.

In some cases this boundary may be drawn in an overly conservative  
way; but preflight is always available as an alternative. In general  
this is probably a reasonable rule for new networking facilities. I'm  
not sure it's the right answer for every networking API; for example,  
WebSocket has a different way to avoid exposing existing servers,  
namely requiring a very specific handshake sequence. But the general  
principle is to avoid exposing servers to requests that are not  
already possible, unless there is explicit opt-in or the source of the  
request is same-origin with the server (which is taken as presumptive  
opt-in).

Regards,
Maciej

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 26 Nov 2009 10:17:04 +0900

> CORS. These rules are not left to the application layer.

If I write something like a webbot, I can execute whatever PUT requests 
(or other HTTP requests) I want, or can't I? An API such as libcurl 
(http://curl.haxx.se/libcurl/) doesn't contain any such restrictions, or 
does it?

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 17:55:41 -0800

> layer must obey? If so, should we document those rules?

Yes.  At the application layer.

I'm not even sure you can articulate the policy coherently without
referring to application-layer concepts.  How would you explain the
restrictions on images in the HTML Canvas element in terms of HTTP
protocol messages?

Adam

---

From: Tyler Close <[email-masked]>
Date: Mon, 30 Nov 2009 11:00:56 -0800

On Wed, Nov 25, 2009 at 5:17 PM, "Martin J. Dürst"
<[email-masked]> wrote:
> If I write something like a webbot, I can execute whatever PUT requests (or
> other HTTP requests) I want, or can't I?

Depending on how your webbot obtains the target URL, it may be
violating the target resource's expectation for protection under SOP.
For example, ...

> An API such as libcurl

If you use libcurl to send a PUT request and the target resource
responds with a 307, which libcurl then automatically follows, you may
have violated the target resource's expectation of protection under
SOP. Consider a webbot that sends a PUT request to a resource on the
open Internet, which responds with a 307 to a resource behind the same
firewall as the webbot. The webbot has essentially punched a hole in
the firewall.

--Tyler

---

From: Tyler Close <[email-masked]>
Date: Mon, 30 Nov 2009 11:25:05 -0800

> Yes.  At the application layer.

Perhaps we're just talking past each other here. I'll try again...

When creating a new application layer API, the designers must take
into account the SOP protection expected by resources. Currently,
these expectations aren't documented anywhere. In the status-quo, the
application layer API is expected to magically know all the SOP
restrictions and then document how it enforces them. I'm just
suggesting that it would be a good thing to remove some of the magic
here by writing down the SOP restrictions, leaving the application API
with only the task of documenting its enforcement mechanism.

> restrictions on images in the HTML Canvas element in terms of HTTP

The response to a GET request must not be made accessible to content
from another origin, unless the target resource has explicitly
indicated otherwise. The HTML <script> tag is a notable violation of
this restriction for content matching a particular syntax. Otherwise,
this rule seems widely enforced.

--Tyler

---

From: "Mark S. Miller" <[email-masked]>
Date: Mon, 30 Nov 2009 11:51:03 -0800

> this rule seems widely enforced.

Other exceptions I'm aware of:

* size of images fetched using img tags.
* port scanning by differential error behavior

What other exceptions remain?

-- 
    Cheers,
    --MarkM

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 30 Nov 2009 12:17:38 -0800

> with only the task of documenting its enforcement mechanism.

It's important to understand that the same-origin policy is a concept  
specific to a certain kind of client, not to a particular network  
protocol. It's more of an HTML-level concept than an HTTP-level  
concept. In particular, a browser loading a document over FTP or  
Gopher would still enforce the same-origin policy in the same way. But  
a low-level HTTP client library would not enforce the same-origin  
policy at all.

> this rule seems widely enforced.

That's a bit of an oversimplification. How much of the response you  
can get depends on the embedding context:

cross-origin <script> --> contents executed as JavaScript, which may  
let you read some of the contents depending on the nature of what is  
returned.
cross-origin <link rel="stylesheet"> --> contents applied as a  
stylesheet, all of the rules in the stylesheet can be read via CSS
cross-origin <img> --> if a valid image in some known format, height  
and width can be determined; also, can be drawn to <canvas>, but then  
reading the pixels of that canvas is disallowed
cross-origin <video> --> same as <img> plus you can get the duration.
cross-origin <iframe> --> the only way to communicate is via  
postMessage()
cross-origin XMLHttpRequest --> nothing about the response is  
available (unless the server opts in)

Same-origin policy differences are primarily about the embedding  
context, not the networking-level details. All of these examples would  
behave the same for FTP or Gopher or whatever other network protocol  
is supported. In fact, classically the same-origin policy was all  
about scripting access to the DOM, in that scripting access to the DOM  
contents cross-origin frames is denied. It only started to affect  
networking as such with the advent of XMLHttpRequest.

It would be good to gather the distributed knowledge about the same- 
origin policy and make recommendations for new embedding or networking  
facilities. But it's not really about HTTP, and would not make sense  
as part of the HTTPbis effort.

Regards,
Maciej

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 30 Nov 2009 22:00:26 +0100 (CET)

On Mon, 30 Nov 2009, Tyler Close wrote:

>> An API such as libcurl (http://curl.haxx.se/libcurl/) doesn't contain any 
>> such restrictions, or does it?
>
> If you use libcurl to send a PUT request and the target resource responds 
> with a 307, which libcurl then automatically follows

libcurl only "automatically" follows that if the app told it to act like that. 
It follows no redirects by default. I know that's not the topic here but I 
thought I'd clarify.

> Consider a webbot that sends a PUT request to a resource on the open 
> Internet, which responds with a 307 to a resource behind the same firewall 
> as the webbot. The webbot has essentially punched a hole in the firewall.

If a server does that I would consider that server/page to be a security 
problem or flaw. Even evil guys can run webbots I believe.

-- 

  / daniel.haxx.se

---

From: Tyler Close <[email-masked]>
Date: Mon, 30 Nov 2009 14:24:44 -0800

Hi Daniel,

Thanks for engaging with this example. I think it's a useful one
because it makes it clear that this issue is independent of HTML...

> problem or flaw. Even evil guys can run webbots I believe.

In this scenario, the webbot and the person executing it are good
guys. The initial PUT request target resource is an evil guy, beyond
the control of good guys. The 307 redirect target resource is a good
guy. The webbot and the redirect target live behind the same firewall.
The evil resource lives outside the firewall. For the protection of
the good guy resource, the webbot must enforce the SOP, so that the
redirect is not followed. No HTML is involved in this scenario. Whose
specification of the SOP is the webbot enforcing? Of what assistance
should libcurl be in enforcing the SOP?

Note that it may be legitimate for a good guy PUT request target
resource to respond with a 307 redirect to a resource that is not
protected by a firewall. So you can't just say: don't follow any
redirects. Some redirects are safe and some may not be, depending on
the provided Location header.

--Tyler

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 30 Nov 2009 23:34:02 +0100 (CET)

On Mon, 30 Nov 2009, Tyler Close wrote:

> The 307 redirect target resource is a good guy. The webbot and the redirect 
> target live behind the same firewall. The evil resource lives outside the 
> firewall. For the protection of the good guy resource, the webbot must 
> enforce the SOP, so that the redirect is not followed. No HTML is involved 
> in this scenario. Whose specification of the SOP is the webbot enforcing? Of 
> what assistance should libcurl be in enforcing the SOP?

Oh right. I think understand what you're saying now. You want the HTTP client 
to somehow detect that it isn't allowed to follow redirects to that target (in 
that manner) and stop because a SOP somehow says so.

How do you suggest that would be told to the client?

Couldn't the TARGET here rather use Referer (or Origin or what not) to detect 
that there's a redirect coming from externally and ignore it?

It clearly can't be HTTPbis material though, since in my eyes it seems to be a 
rather major extension or change of what HTTP is and what it allows today.

-- 

  / daniel.haxx.se

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 1 Dec 2009 09:52:34 +1100

> enforce the SOP, so that the redirect is not followed.

This actually is covered by the HTTP spec (1.1 and HTTPbis).
For instance, 8.3.8 307 Temporary Redirect says:

   If the 307 status code is received in response to a request method
   that is known to be "safe", as defined in Section 7.1.1, then the
   request MAY be automatically redirected by the user agent without
   confirmation.  Otherwise, the user agent MUST NOT automatically
   redirect the request unless it can be confirmed by the user, since
   this might change the conditions under which the request was issued.

[http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.8]

At the HTTP layer it is not a same-origin issue, but a wider issue with methods that are not "safe".

James Manger

---

From: Tyler Close <[email-masked]>
Date: Mon, 30 Nov 2009 14:54:25 -0800

On Mon, Nov 30, 2009 at 2:34 PM, Daniel Stenberg <[email-masked]> wrote:
>> The 307 redirect target resource is a good guy. The webbot and the
>> redirect target live behind the same firewall. The evil resource lives
>> outside the firewall. For the protection of the good guy resource, the
>> webbot must enforce the SOP, so that the redirect is not followed. No HTML
>> is involved in this scenario. Whose specification of the SOP is the webbot
>> enforcing? Of what assistance should libcurl be in enforcing the SOP?
>
> Oh right. I think understand what you're saying now. You want the HTTP
> client to somehow detect that it isn't allowed to follow redirects to that
> target (in that manner) and stop because a SOP somehow says so.

Yes.

> How do you suggest that would be told to the client?

The SOP rule is something like: Don't follow a cross-domain redirect
of a PUT request, unless the redirect target has opted out of SOP
protection.

So, upon seeing the 307 redirect, libcurl would report an error if the
origin of the Request-URI does not match the origin of the URL in the
Location header; otherwise, the redirect is followed. Until there's a
standard way for a resource to opt out of SOP, that's the best that
can be done.

> Couldn't the TARGET here rather use Referer (or Origin or what not) to
> detect that there's a redirect coming from externally and ignore it?

It could, but it doesn't. Today, the target resource expects the SOP
to protect it from non-same-origin PUT requests.

> It clearly can't be HTTPbis material though, since in my eyes it seems to be
> a rather major extension or change of what HTTP is and what it allows today.

The thing is, it's not an extension or a change. It's the status-quo.
Existing resources depend upon clients enforcing the SOP. We've just
left it unspecified what those protections are. Currently, these
protections are a widely relied upon oral tradition.

--Tyler

---

From: Adam Barth <[email-masked]>
Date: Mon, 30 Nov 2009 16:20:23 -0800

> with only the task of documenting its enforcement mechanism.

I agree with everything you're saying, but you haven't explained why
this documentation should be at the protocol layer instead of the
application layer.

> this rule seems widely enforced.

Maciej already responded to this point, but this is a drastic over
simplification.

Adam

---

From: Tyler Close <[email-masked]>
Date: Mon, 30 Nov 2009 17:11:07 -0800

> this documentation should be at the protocol layer instead of the

1. To document the constraints that all user agents must enforce. The
restrictions apply to all APIs in the entire application layer, not
just some application APIs. HTTP is the layer below the application
API, where constraints upon all user agents are specified.

2. To document the security model that server-side resources are
written to. A HTTP resource expects the SOP to apply regardless of the
API used to generate requests. A HTTP resource is not a <img>
resource, or a <link> resource, or a curl resource, just an HTTP
resource. A resource does not expect the security model to change
based on the API used to produce the request. In many cases, this
distinction is not even knowable based on the content of the HTTP
request.

3. Although some parts of SOP also apply to other protocols, such as
ftp, other parts are specific to HTTP, such as: rules around request
headers, redirects, the distinctions between POST and PUT, etc.

--Tyler

---

From: Adam Barth <[email-masked]>
Date: Mon, 30 Nov 2009 17:23:47 -0800

> API, where constraints upon all user agents are specified.

Not all user agents must enforce these rules.  For example, why
shouldn't wget be able to send PUT requests to any resource it likes?
Why should my SIP telephone follow these rules?

> distinction is not even knowable based on the content of the HTTP

If you assume the SOP will apply regardless of which application-layer
API is used, you'll be sorely mistaken.  You need to understand the
application layer to understand the security consideration.  For
example, it's fine to store certain kinds of secrets in XML documents,
but it's a security vulnerability to store the same kinds of secrets
in ECMAScript documents.

You say "In many cases, this distinction is not even knowable based on
the content of the HTTP request."  That's precisely why these concepts
don't make sense at the protocol layer!

> headers, redirects, the distinctions between POST and PUT, etc.

The vast majority of the SOP is independent of HTTP.  You're right
that some application layer APIs restrict what kinds of HTTP requests
can be made on behalf of various origins, but that's only a tiny part
of the story.

You seem to be picking an choosing which points you reply to.  The
basic points you have yet to address are these:

1) The same-origin policy applies regardless of which protocols are
used (e.g, FTP, Gopher, HTTP).
2) The same-origin policy applies differently to different
application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).

Those are just facts of the world.  It might be nice to live in a
world where the security considerations for building an HTTP server
were limited to understanding HTTP, but that's not the word in which
we live.  You also need to understand applications of HTTP to get
security right.  Security is hard.

Adam

---

From: Tyler Close <[email-masked]>
Date: Mon, 30 Nov 2009 18:05:28 -0800

> shouldn't wget be able to send PUT requests to any resource it likes?

See:

http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0272.html

> Why should my SIP telephone follow these rules?

Because I want to plug in a SIP telephone behind my firewall without
endangering all my intranet resources.

> application layer to understand the security consideration.

But the application layer is potentially infinite in size and
continues to grow long after a server-side resource is deployed.

>  For

Exactly the kind of obscure fact that HTTP resource authors need to
know. So let's document them.

> don't make sense at the protocol layer!

I suspect we're not understanding each other at a fundamental level.
The resource makes its response based on the request. If the
distinction between APIs is not knowable based on the content of the
request, the response must be made based on the most permissive
security model of any of the possible APIs. To provide this lower
bound, the security model must be fixed by a specification that
applies to all APIs, such as HTTP.

> basic points you have yet to address are these:

I was trying to respond to everything. For example...

> used (e.g, FTP, Gopher, HTTP).

was covered by my point 3 above...

> application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).

was covered by my point 2 above.

> we live.

I agree, that's what I'm suggesting we fix. Currently, authors of HTTP
resources don't have a specification of the security model. They
should be provided with one.

> You also need to understand applications of HTTP to get
> security right.

If the application layer is unconstrained, that's an impossible task.
We need to specify the constraints on the application layer to make
security possible.

>  Security is hard.

Let's not make it impossible.

--Tyler

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 30 Nov 2009 18:41:11 -0800

> application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).

3) The same-origin policy is originally and primarily about scripting,  
not networking. It has only lately and incidentally come to encompass  
networking as well, largely to prevent working around the restrictions  
on client-side scripting in the browser. It's impossible to explain  
the restrictions on networking without reference to the original  
scripting context.

Regards,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Dec 2009 14:25:38 +1100

Tyler,

This is important, but as mentioned firmly out of the scope of the HTTPbis WG. 

There's currently a lot of discussion along these lines both at the IETF and the W3C, and I expect that a new mailing list will be announced shortly to serve as a home for topics like this.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 01 Dec 2009 13:28:20 +0900

On 2009/12/01 4:00, Tyler Close wrote:

> Consider a webbot that sends a PUT request to a resource on the

Yes, the webbot has done this. One has to be very careful when running 
stuff such as webbots, make sure they are either inside or outside the 
firewall, but not both, unless you know exactly what you're doing. This 
not only applies to PUTs, but also to GETs.

On the other hand, if I write (e.g. using libcurl or whatever) a 
"webbot" that periodically checks the balance on one of my bank accounts 
and transfers money from another bank account of mine if the balance on 
the first bank account is low, then I don't see why anybody would want 
to forbid this.

Regards,   Martin.

---

From: Adam Barth <[email-masked]>
Date: Mon, 30 Nov 2009 23:19:05 -0800

On Mon, Nov 30, 2009 at 8:28 PM, "Martin J. Dürst"
<[email-masked]> wrote:
> On the other hand, if I write (e.g. using libcurl or whatever) a "webbot"
> that periodically checks the balance on one of my bank accounts and
> transfers money from another bank account of mine if the balance on the
> first bank account is low, then I don't see why anybody would want to forbid
> this.

As a point of amusement, I recently co-wrote a "stylebot" for the
WebKit project that violates the same-origin policy in precisely this
way (by shuffling data between a Bugzilla instance and another web
service).

Adam