http://krijnhoetmer.nl/irc-logs/whatwg/20080925#l-43:
# # [04:24] gsnedders Hixie: Nobody is working on a new version of HTTP,
though: 2616bis is just revising the spec, and can't make any normative changes to it.
That's not entirely true; for instance, we can make normative changes if
we
On Thu, 25 Sep 2008 10:36:01 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
As far as I can tell, you are speaking of a new header. This can be
defined in an IETF document, in a W3C document, and in other places. You
just need to register it with IANA, and expert review (hopefully) will
Anne van Kesteren wrote:
...
What's true is that you can't require existing HTTP/1.1 clients to
send it with every POST request (did anybody seriously suggest that?).
The suggestion was for POST requests the browser makes based on Web APIs
(e.g., XMLHttpRequest, form, etc.).
OK, so that
On Thu, 25 Sep 2008 11:07:54 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
...
What's true is that you can't require existing HTTP/1.1 clients to
send it with every POST request (did anybody seriously suggest that?).
The suggestion was for POST requests the browser
Anne van Kesteren wrote:
On Thu, 25 Sep 2008 11:07:54 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
...
What's true is that you can't require existing HTTP/1.1 clients to
send it with every POST request (did anybody seriously suggest that?).
The suggestion was for
On Thu, 25 Sep 2008 11:16:06 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
So what's the spec defining Origin? I thought it was XmlHttpRequest(2)?
Access Control for Cross-Site Requests.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Anne van Kesteren wrote:
On Thu, 25 Sep 2008 11:16:06 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
So what's the spec defining Origin? I thought it was XmlHttpRequest(2)?
Access Control for Cross-Site Requests.
Ah, forgot about that one.
If Origin is used by more than one spec, it might
On Thu, 25 Sep 2008 11:28:21 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
http://www.ietf.org/mail-archive/web/ietf-message-headers/current/index.html
So, is there a case where IANA registration was attempted and expert
review did *not* happen?
This e-mail from
Anne van Kesteren wrote:
This e-mail from January 27 never got a reply:
http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html
Several changes to the specification have since then be made, including
changing header names again, but that happened in August. Between
On Thu, 25 Sep 2008 12:04:46 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
This e-mail from January 27 never got a reply:
http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html
Several changes to the specification have since then be
Hi folks,
I am posting here on the advice of Ian Hickson; I'm new to the list, so
please forgive me if any of this brings up long-dismissed concepts;
hopefully not.
For a couple of months now, along with a number of my colleagues at
Google, we were investigating a security problem that we
Michal Zalewski wrote:
3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin
frame.
Something like focus-follows-mouse plus autoraise for IFRAMEs might
work.
--
Toby A Inkster
mailto:[EMAIL PROTECTED]
On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
Other quick fixes are easy to come up with, but in general prove problematic
in many usage scenarios. Based on our internal conversations, we have a
number of proposals for approaches to how to address the issue, along
On Thu, 25 Sep 2008, Collin Jackson wrote:
6) New cookie attribute: The httpOnly cookie flag allows sites to
put restrictions on how a cookie can be accessed. We could allow a new
flag to be specified in the Set-Cookie header that is designed to
prevent CSRF and UI redress attacks. If a cookie
On Thu, Sep 25, 2008 at 1:46 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
7) New HTTP request header: Browser vendors seem to be moving away from
same origin restrictions towards verifiable origin labels that let the
site decide whether two security origins trust each other. Recent examples
On Sep 25, 2008, at 10:24 AM, Michal Zalewski wrote:
3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin
frame.
By carefully designing the mechanism, we can prevent legitimate uses
(such as dynamic
On Sep 25, 2008, at 1:17 PM, Collin Jackson wrote:
On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski [EMAIL PROTECTED]
wrote:
Other quick fixes are easy to come up with, but in general prove
problematic
in many usage scenarios. Based on our internal conversations, we
have a
number of
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
C) Treat a case where top-left corner of the IFRAME is drawn out of
a visible area (CSS negative margins, etc) as a special case of
being obstructed by the owner of a current rendering rectangle
(another IFRAME or window.top) and carry
On Fri, Sep 26, 2008 at 7:33 AM, Toby A Inkster [EMAIL PROTECTED]wrote:
Something like focus-follows-mouse plus autoraise for IFRAMEs might work.
I actually like this idea quite a lot. It would have to allow the IFRAME to
escape clipping (and other graphical effects) as well (except for
Other than sliding content over the top of the IFRAME, there are fun ways to
get exactly the appearance the attacker wants ... keep in mind when
designing a solution:
-- make the IFRAME opacity:0 (or 0.01) and draw whatever you want underneath
it
-- use SVG filter effects (in conjunction with SVG
On Fri, Sep 26, 2008 at 10:23 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
I meant, corner of the container, rather than actual document rendered
within. If deals strictly with the frame beginning outside the current
viewport to hide some of its contents, but leave small portions of the UI
On Fri, 26 Sep 2008, Robert O'Callahan wrote:
Seems like this will create a really bad user experience. The user
scrolling around in the outer document will make IFRAMEs in it
mysteriously become enabled or disabled.
Well, to put this in perspective - we are talking about cross-domain
On Fri, Sep 26, 2008 at 12:27 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
On Fri, 26 Sep 2008, Robert O'Callahan wrote:
Seems like this will create a really bad user experience. The user
scrolling around in the outer document will make IFRAMEs in it mysteriously
become enabled or disabled.
On Thu, Sep 25, 2008 at 4:08 PM, Ian Hickson [EMAIL PROTECTED] wrote:
form of experimental implementations. Personally I think the idea of
disabling the contents of a cross-origin iframe that has been partially
obscured or rendered partially off-screen is the best idea, but whether we
can
On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote:
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
C) Treat a case where top-left corner of the IFRAME is drawn out of
a visible area (CSS negative margins, etc) as a special case of
being obstructed by the owner of a current rendering
On Sep 25, 2008, at 8:07 PM, Maciej Stachowiak wrote:
On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote:
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
C) Treat a case where top-left corner of the IFRAME is drawn out of
a visible area (CSS negative margins, etc) as a special case of
26 matches
Mail list logo
