ay CSP was
thought out.
Dave
-Original Message-
From: Adam Barth [mailto:i...@adambarth.com]
Sent: Monday, September 03, 2012 10:26 AM
To: Tobias Gondrom
Cc: websec@ietf.org; t...@w3.org; David Ross
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
On Mon, Sep 3, 2012 at 9
overhead. I
really don't want to lose the momentum.
Dave
From: Adam Barth [mailto:i...@adambarth.com]
Sent: Wednesday, July 18, 2012 4:17 PM
To: David Ross
Cc: Hill, Brad; Tobias Gondrom; websec@ietf.org
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
Here are t
al Message-
From: Hill, Brad [mailto:bh...@paypal-inc.com]
Sent: Tuesday, July 17, 2012 4:33 PM
To: David Ross; =JeffH; IETF WebSec WG
Subject: RE: [websec] Coordinating Frame-Options and CSP UI Safety directives
Dave,
What's the case for the "NoAncestors" behavior? Is it just
2012 5:30 PM
To: David Ross; IETF WebSec WG
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
thanks for your thoughts Dave,
> My concern is mostly around the degree to which a move to CSP might >
> complicate or stall the process.
by this I presume
by CSP (eg: the origin header, cookie
security).
Finally, as Brad pointed out in the rosetta stone thread, Frame-Options
provides the flexibility to perform only a top level origin check as opposed to
a full ancestor check. (Specified via the "AllAncestors" flag.)
David Ross
dr.
AllAncestors sounds good to me.
David Ross
dr...@microsoft.com
-Original Message-
From: Giorgio Maone [mailto:g.ma...@informaction.com]
Sent: Saturday, February 18, 2012 12:33 AM
To: Adam Barth
Cc: David Ross; Eduardo' Vela; IETF WebSec WG; Michal Zalewski
Subject: Re: [websec]
nd describe the
optional ValidateAllAncestors flag in the RFC draft.
David Ross
dr...@microsoft.com
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
should" implies a
recommendation rather than a requirement.
David Ross
dr...@microsoft.com
-Original Message-
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of
Hill, Brad
Sent: Friday, July 22, 2011 1:32 PM
To: Devdatta Akhawe; Adam Barth
Cc: websec@ietf.
> Given that there's a fair number of web apps (aka websites) emitting
> "X-FRAME-OPTIONS" (see below), and given its wide support in web
> browsers, I think its justifiable to do (a), then see about (b).
Works for me.
David Ross
dr...@microsoft.com
-Original M
cess dictates here. I have to imagine there's a precedent we'd want to
follow.
David Ross
dr...@microsoft.com
-Original Message-
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of
=JeffH
Sent: Friday, July 08, 2011 12:41 PM
To: IETF WebSec WG
Subjec
PTIONS / FRAME-OPTIONS
headers present in a given HTTP response. (Eg: What happens if there is both
an X-FRAME-OPTIONS and a FRAME-OPTIONS header, each with ALLOW-FROM directives
pointing to different sites?)
David Ross
dr...@microsoft.com
-Original Message-
From: websec-boun...@ietf.org
scenario is probably the most
compelling case for the origin list. Add a few more sites to the example
though and the origin list looks less optimal. I'm optimistic that frameworks
could help with the backend complexity of the single-origin scheme.
David Ross
dr...@microsoft.com
-
#3 is a narrowly scoped effort to standardize something that works pretty well
today in practice (X-FRAME-OPTIONS). A conflict with CSP would be bad, but per
Adam it seems like overlap is looking less likely. So proceeding down the
current path on #3 sounds good to me.
David Ross
dr
page, he'd be blocked at step #4 when the browser
actually enforces the origin.
---
David Ross
dr...@microsoft.com
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
14 matches
Mail list logo
