Ian Hickson wrote on 5/24/2010 7:55 PM:
On Mon, 24 May 2010, Bil Corry wrote:
Adam Barth wrote on 7/16/2009 10:38 AM:
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote:
I think you mean everything will NOT be privacy-sensitive except non-XHR
GETs.
I don't think we've quite
On Mon, 24 May 2010, Bil Corry wrote:
The only reference I could find was in 2.6 Fetching Resources:
---8---
For the purposes of the Origin header, if the fetching algorithm was
explicitly initiated from an origin, then the origin that initiated the
HTTP request is origin.
Adam Barth wrote on 7/16/2009 10:38 AM:
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote:
I think you mean everything will NOT be privacy-sensitive except non-XHR
GETs.
I don't think we've quite settled on exactly what will be privacy
sensitive. It's most likely that POSTs
On Mon, 24 May 2010, Bil Corry wrote:
Adam Barth wrote on 7/16/2009 10:38 AM:
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote:
I think you mean everything will NOT be privacy-sensitive except non-XHR
GETs.
I don't think we've quite settled on exactly what will be
Ian Hickson wrote on 7/15/2009 4:53 PM:
On Wed, 15 Jul 2009, Bil Corry wrote:
Ian Hickson wrote on 7/14/2009 6:37 PM:
On Tue, 14 Jul 2009, Bil Corry wrote:
Ian Hickson wrote on 7/14/2009 12:49 AM:
(Trimmed cc list to avoid cross-posting.)
On Thu, 25 Jun 2009, Bil Corry wrote:
Thanks for
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote:
I think you mean everything will NOT be privacy-sensitive except non-XHR GETs.
I don't think we've quite settled on exactly what will be privacy
sensitive. It's most likely that POSTs and XHR will not be and that
hyperlinks and
Ian Hickson wrote on 7/14/2009 6:37 PM:
On Tue, 14 Jul 2009, Bil Corry wrote:
Ian Hickson wrote on 7/14/2009 12:49 AM:
(Trimmed cc list to avoid cross-posting.)
On Thu, 25 Jun 2009, Bil Corry wrote:
Thanks for the clarification. Will there be some mechanism within HTML5
to denote links
On Wed, 15 Jul 2009, Bil Corry wrote:
Ian Hickson wrote on 7/14/2009 6:37 PM:
On Tue, 14 Jul 2009, Bil Corry wrote:
Ian Hickson wrote on 7/14/2009 12:49 AM:
(Trimmed cc list to avoid cross-posting.)
On Thu, 25 Jun 2009, Bil Corry wrote:
Thanks for the clarification. Will there be
Ian Hickson wrote on 7/14/2009 12:49 AM:
(Trimmed cc list to avoid cross-posting.)
On Thu, 25 Jun 2009, Bil Corry wrote:
Thanks for the clarification. Will there be some mechanism within HTML5
to denote links that are privacy-sensitive versus those that are not?
I'm imagining that by
On Tue, 14 Jul 2009, Bil Corry wrote:
Ian Hickson wrote on 7/14/2009 12:49 AM:
(Trimmed cc list to avoid cross-posting.)
On Thu, 25 Jun 2009, Bil Corry wrote:
Thanks for the clarification. Will there be some mechanism within HTML5
to denote links that are privacy-sensitive versus
(Trimmed cc list to avoid cross-posting.)
On Thu, 25 Jun 2009, Bil Corry wrote:
Thanks for the clarification. Will there be some mechanism within HTML5
to denote links that are privacy-sensitive versus those that are not?
I'm imagining that by default, links to external resources would
Jonas Sicking wrote on 6/25/2009 5:35 PM:
On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote:
Jonas Sicking wrote on 6/25/2009 2:11 AM:
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote:
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote:
Continuing
On Wed, Jul 1, 2009 at 7:48 AM, Bil Corryb...@corry.biz wrote:
Jonas Sicking wrote on 6/25/2009 5:35 PM:
On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote:
Jonas Sicking wrote on 6/25/2009 2:11 AM:
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote:
On Wed, Jun
Jonas Sicking wrote on 7/1/2009 3:42 PM:
On Wed, Jul 1, 2009 at 7:48 AM, Bil Corryb...@corry.biz wrote:
Jonas Sicking wrote on 6/25/2009 5:35 PM:
On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote:
Jonas Sicking wrote on 6/25/2009 2:11 AM:
On Wed, Jun 24, 2009 at 8:57 PM, Adam
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote:
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote:
Continuing your example, if XHTML defines requests from form as
privacy-sensitive, then the UA will have two different behaviors for
Sec-From, depending on if
On Thu, 25 Jun 2009 05:50:32 +0200, Bil Corry b...@corry.biz wrote:
Continuing your example, if XHTML defines requests from form as
privacy-sensitive, then the UA will have two different behaviors for
Sec-From, depending on if it's rendering HTML5 or XHTML?
HTML5 defines an XHTML
Jonas Sicking wrote on 6/25/2009 2:11 AM:
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote:
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote:
Continuing your example, if XHTML defines requests from form as
privacy-sensitive, then the UA will have two
On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote:
Jonas Sicking wrote on 6/25/2009 2:11 AM:
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote:
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote:
Continuing your example, if XHTML defines requests from
Adam Barth wrote on 6/20/2009 6:25 PM:
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote:
I've lost track, is this still something being considered?
I should have an updated draft posted soon.
I'm not clear with the new draft if it now allows Sec-From for same-origin GET
On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote:
Adam Barth wrote on 6/20/2009 6:25 PM:
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote:
I've lost track, is this still something being considered?
I should have an updated draft posted soon.
I'm not clear with
Adam Barth wrote on 6/24/2009 8:58 PM:
On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote:
Adam Barth wrote on 6/20/2009 6:25 PM:
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote:
I've lost track, is this still something being considered?
I should have an updated
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote:
Continuing your example, if XHTML defines requests from form as
privacy-sensitive, then the UA will have two different behaviors for
Sec-From, depending on if it's rendering HTML5 or XHTML?
That's correct. Hopefully folks
Ian Hickson wrote on 6/2/2009 8:11 PM:
On Thu, 2 Apr 2009, Bil Corry wrote:
Related, HTML5 currently prohibits sending the XXX-Origin header for GET
requests. This is to prevent intranet applications leaking their
internal hostnames to external sites (are there other reasons?).
However,
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote:
I've lost track, is this still something being considered?
I should have an updated draft posted soon.
Adam
On Thu, 2 Apr 2009, Bil Corry wrote:
Since the public-webapps list was never able to reconcile[1] HTML5's
Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3],
we're left with two headers with similar implementations and similar
names. Due to this, it may prudent to
On Thu, 9 Apr 2009, Bil Corry wrote:
For example, imagine instead you visit a malicious site, and it wants to
phish your banking credentials. But rather than choosing a random bank
and hoping you bank there, it instead launches a series of timing
attacks against the top 30 banks,
Ian Hickson wrote on 4/9/2009 1:42 AM:
On Thu, 9 Apr 2009, Bil Corry wrote:
For example, imagine instead you visit a malicious site, and it wants to
phish your banking credentials. But rather than choosing a random bank
and hoping you bank there, it instead launches a series of timing
On Thu, Apr 9, 2009 at 8:48 AM, Bil Corry b...@corry.biz wrote:
My point is that a robust Origin moves us closer to better security controls,
perhaps not all the way, but certainly much closer than CORS-Origin gets us.
I think we should focus on clear use cases and techniques that address
Adam Barth wrote on 4/7/2009 4:36 PM:
HTML5:
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step
Barth: http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
These two, at least, are the same. We separated the XXX-Origin
On Wed, Apr 8, 2009 at 10:34 AM, Bil Corry b...@corry.biz wrote:
Is draft-abarth-origin-00.txt entirely compatible now with CORS-Origin?
Yes, as far as I know. If you find any incompatibility, please let me
know and I'll fix it.
Adam
Adam Barth wrote on 4/9/2009 12:21 AM:
On Wed, Apr 8, 2009 at 10:09 PM, Bil Corry b...@corry.biz wrote:
Using the above scenario, if Origin was populated and sent for all
same-origin requests (including GET), the website could simply redirect any
request for any protected resource that
On Mon, Apr 6, 2009 at 2:09 PM, Bil Corry b...@corry.biz wrote:
Can we please include the Origin header for all same-origin requests,
including GET and HEAD? Or is there a compelling reason why not do to so?
Also, would there be value in having Origin sent for *all* requests, and if
Adam Barth wrote on 4/7/2009 11:54 AM:
On Mon, Apr 6, 2009 at 2:09 PM, Bil Corry b...@corry.biz wrote:
Can we please include the Origin header for all same-origin requests,
including GET and HEAD? Or is there a compelling reason why not do to so?
Also, would there be value in having Origin
On Tue, Apr 7, 2009 at 10:24 AM, Bil Corry b...@corry.biz wrote:
How set in stone is Origin within CORS?
I don't think we want to impede CORS with these issues. CORS is quite
close to shipping in a number of implementations. I certainly don't
want to hold it hostage.
The ideal scenario would
Thomas Roessler wrote on 4/6/2009 4:19 AM:
On 3 Apr 2009, at 20:26, Jonas Sicking wrote:
We've done a lot of discussions internally at mozilla, but was hoping
that Adam Barth would start work somewhere so that we could send our
feedback.
Perhaps it's worthwhile to summarize the
Bil Corry wrote on 4/6/2009 9:32 AM:
Another option that I haven't seen proposed is to keep CORS-Origin
and HTML5-Origin both named Origin but make them contextual, so
that Origin when sent via CORS will behave as outlined in CORS, and
Origin when sent via HTML5 will behave as outlined in
On Mon, Apr 6, 2009 at 2:19 AM, Thomas Roessler t...@w3.org wrote:
Perhaps it's worthwhile to summarize the Mozilla-internal discussions and
send them here first? I'm having a sense that much of what's needed right
now is for somebody to ask the right questions.
I'll let someone from Mozilla
On Mon, Apr 6, 2009 at 8:01 AM, Bil Corry b...@corry.biz wrote:
Nevermind, I forgot that Adam conceded to changing his original Origin spec
to match the redirect behavior in CORS, and reading through his draft, I see
the change has been made to make them compatible.
Yes. This is not ideal
Brandon Sterne wrote on 4/6/2009 3:34 PM:
I'm adding Sid, who has been editing the document:
https://wiki.mozilla.org/Security/Origin
As is mentioned in the first section of that document, the name of the
proposed header is subject to change.
I'm confused, what is the relationship of this
Brandon Sterne wrote on 4/6/2009 3:34 PM:
I'm adding Sid, who has been editing the document:
https://wiki.mozilla.org/Security/Origin
As is mentioned in the first section of that document, the name of the
proposed header is subject to change.
If you're going for an entirely new header,
On Fri, 03 Apr 2009 22:05:52 +0200, Bil Corry b...@corry.biz wrote:
So the first question to ponder is if the referrer header really can
adequately replace Origin. If it can, then we should the move this
discussion over to ietf-http-wg and work to make sure referrer is
updated in a way to
Ian Hickson wrote on 1/14/2009 4:07 PM:
On Tue, 13 Jan 2009, Jonas Sicking wrote:
On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 Jan 2009, Jonas Sicking wrote:
It's not just POST that we need to worry about, ideally we should
cover the GET case as well. Or at
Thomas Roessler wrote on 1/12/2009 8:02 PM:
Having the CSRF-Origin defined in an RFC or another separate spec is a
good idea independently of whether or not it ends up being the same
header that's used for cross-site XHR.
If someone wants to form an Origin BOF at the next IETF meeting in
On Tue, 13 Jan 2009, Jonas Sicking wrote:
On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 Jan 2009, Jonas Sicking wrote:
It's not just POST that we need to worry about, ideally we should
cover the GET case as well. Or at least it's quite likely that we
On Tue, 13 Jan 2009 01:31:49 +0100, Jonas Sicking jo...@sicking.cc wrote:
My suggestion is to rename Origin to Access-Control-Request-Origin
or Access-Control-Origin if possible (depends on where current
implementers are in their ship schedule), or that we request that the
CSRF protection
On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 Jan 2009, Jonas Sicking wrote:
It's not just POST that we need to worry about, ideally we should cover
the GET case as well. Or at least it's quite likely that we will want
to.
My understanding was that we didn't
On 12 Jan 2009, at 16:31, Jonas Sicking wrote:
There are 3 possible solutions that I can see to this:
1. Change the name of the Origin header in Access-Control
2. Change the name of the Origin header used for CSRF protection
3. Change the behavior of one (or both) of the specs such that they
Thomas Roessler wrote:
On 12 Jan 2009, at 16:31, Jonas Sicking wrote:
There are 3 possible solutions that I can see to this:
1. Change the name of the Origin header in Access-Control
2. Change the name of the Origin header used for CSRF protection
3. Change the behavior of one (or both) of
On Mon, 12 Jan 2009, Jonas Sicking wrote:
Should I remove or rename 'Origin' in HTML5 for now?
Well, HTML5 isn't the only place where this header has been discussed,
but it wouldn't be a bad idea I think.
Which, remove or rename? :-)
--
Ian Hickson U+1047E
49 matches
Mail list logo
