I do not like this idea at all. That is what LABEL is for, and disappearing
"it's so kewl" text is as annoying as BLINK and BGSOUND.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle
Sent: Tuesday, September 30, 2008 2:20 AM
To: whatwg@lis
On Mon, Sep 29, 2008 at 5:20 PM, Andy Lyttle <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I would like to see Apple's adopted as an official
> standard, but there's one particular feature that would be easy to adopt
> without supporting the rest, and that's the "placeholder" option.
> Currently, lots
Anne van Kesteren wrote:
What is the reason for doing literal comparison on the
websocket-origin and websocket-location HTTP headers? Access Control
for Cross-Site Requests is currently following this design for
access-control-allow-origin but sicking is complaining about so maybe
it should be
On Mon, 29 Sep 2008, Maciej Stachowiak wrote:
> On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote:
> >
> > I'm suggesting just reusing the Access Controls spec for that.
> >
> > So for example, the server could say:
> > Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes
> > Access-C
On Sep 28, 2008, at 2:15 PM, Robert O'Callahan wrote:
On Mon, Sep 29, 2008 at 12:17 AM, Michal Zalewski <[EMAIL PROTECTED]>
wrote:
On Sun, 28 Sep 2008, Robert O'Callahan wrote:
There is no way in the world that Microsoft would implement your
option 3 in a security update to IE6.
Sure, I'
On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote:
On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <[EMAIL PROTECTED]>
wrote:
other browsers are getting cross-domain XMLHttpRequest headers
Using the W3C Access Controls spec, which I am suggesting to reuse
here. If you're not familiar
On Sep 26, 2008, at 2:19 PM, Elliotte Rusty Harold wrote:
Michal Zalewski wrote:
I kinda assumed this suggestion was tongue-in-cheek, but if not -
banning cross-domain IFRAMEs to fix one flaw, without providing
viable methods for sandboxing untrusted same-origin content, would
leave web
On Sep 29, 2008, at 5:20 PM, Andy Lyttle wrote:
Hi all!
I would like to see Apple's adopted as an
official standard, but there's one particular feature that would be
easy to adopt without supporting the rest, and that's the
"placeholder" option. Currently, lots of sites are implementin
Hi all!
I would like to see Apple's adopted as an
official standard, but there's one particular feature that would be
easy to adopt without supporting the rest, and that's the
"placeholder" option. Currently, lots of sites are implementing
placeholder text through a combination of creat
On Tue, Sep 30, 2008 at 12:09 PM, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Sep 2008, Robert O'Callahan wrote:
>
> If the chat gadget is configured to only talk to the site owner, how can
>> it
>> be abused? I suppose the site owner can discover the chat nick of a
>> visitor
>> who
I think the canvas api should get 2 new methods:
CanvasColor createRGBAColor(in float r, in float g, in float b, in
float a)
CanvasColor createHSLAColor(in float h, in float s, in float l, in
float a)
WebKit already has a non-standard function -- setFillColor(r, g, b, a)
-- that pro
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
If the chat gadget is configured to only talk to the site owner, how can it
be abused? I suppose the site owner can discover the chat nick of a visitor
who otherwise wouldn't want to disclose it. That's a risk that the chat
system developers might ve
On Tue, Sep 30, 2008 at 11:14 AM, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Sep 2008, Robert O'Callahan wrote:
>
> We can easily offer these developers the following options:
>> a) developers of privileged gadgets can whitelist domains that they trust
>> to
>> not subvert the UI
>>
Hi,
With the increasing speed of javascript engines, some other
performance issues are starting to become apparent. Take this demo for
example:
http://playground.q42.nl/animatie/blobs/sjoerd/blobscolor.html
A large percentage of the time goes into building color strings for
setting the s
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
We can easily offer these developers the following options:
a) developers of privileged gadgets can whitelist domains that they trust to
not subvert the UI
How is this achieved? If I have a chat ("talk to site owner using your
$foo chat account")
On Tue, Sep 30, 2008 at 9:06 AM, Adam Barth <[EMAIL PROTECTED]> wrote:
> The current proposal is to sent the Origin header for non-GET,
> non-HEAD requests. The main reason not to send the header all the
> time is that it raises similar privacy concerns as the Referer header,
> which have caused
On Tue, Sep 30, 2008 at 2:44 AM, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> Well, so I agree. Yet, given the choice between:
>
> 1) Telling developers that they can't do any "privileged" gadgets safely
> at all, not theirs, and for reasons that are hard to explain to
> regular developer
Incidentally, these issues are why Collin's proposal at the start of
this thread was to list send the origin of all the ancestor frames:
On Thu, Sep 25, 2008 at 12:57 PM, Collin Jackson
<[EMAIL PROTECTED]> wrote:
> make it an "X-Ancestor-Frame-Origin: http://www.evil.com"; HTTP
> request header. T
On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Hmm, we went through this before I believe.
Yeah, we talked about this in the context of CSRF.
> I thought the issue with Referer
> was that it exposed path information, but I guess the problem with Origin is
> that i
On Mon, 29 Sep 2008 16:06:09 -0400, Adam Barth <[EMAIL PROTECTED]>
wrote:
The current proposal is to sent the Origin header for non-GET,
non-HEAD requests. The main reason not to send the header all the
time is that it raises similar privacy concerns as the Referer header,
which have caused the
The current proposal is to sent the Origin header for non-GET,
non-HEAD requests. The main reason not to send the header all the
time is that it raises similar privacy concerns as the Referer header,
which have caused the Referer header to be suppressed a non-trivial
fraction of the time.
Sending
What is the reason for doing literal comparison on the websocket-origin
and websocket-location HTTP headers? Access Control for Cross-Site
Requests is currently following this design for
access-control-allow-origin but sicking is complaining about so maybe it
should be URL-without- comparis
On Mon, 29 Sep 2008, Hallvord R M Steen wrote:
It still completely ignores the question of how we protect gadgets / mashups
/ whatever that are *designed* to be embedded on potentially untrusted
sites, but depend on having the integrity of their UIs preserved
After giving this quite some thoug
I am not sure I have understood Robert correctly but it seems obvious to me
that if a site does not want to reveal its origin it cannot apply for a
tighter cooperation; it will just be treated as any other site in the wild.
And it is better not to rely on the user agent to do the right thing if
pos
2008/9/29 Michal Zalewski <[EMAIL PROTECTED]>:
> I definitely like the "Origin" proposal the most of all the opt-in schemes,
> simply because it permits trusted domains to be whitelisted for many
> applications that rely on same-origin separation to implement security
> sandboxes.
>
> It still comp
On Mon, 29 Sep 2008, Anne van Kesteren wrote:
A cross-site XMLHttpRequest request would always include Origin. I
haven't really seen other specifications start using it yet, but I
believe there are some experimental implementations for including it in
cross-site POST requests.
Yup, I mean t
On Mon, 29 Sep 2008 13:41:59 +0200, Michal Zalewski <[EMAIL PROTECTED]>
wrote:
Note that the current implementation proposals for "Origin" headers
(which I believe are limited to non-GET, non-HEAD requests) would not
prevent this attack, nor some other potential attack vectors; they would
p
On Mon, 29 Sep 2008, Hallvord R M Steen wrote:
To give webmasters more ways to deal with this situation, I think we
should implement the Access Control "Origin" HTTP-header only (assuming
that it should refer to the top site in the frameset hierarchy).
I definitely like the "Origin" proposal
On Sat, Sep 27, 2008 at 12:58 PM, Kristof Zelechovski
<[EMAIL PROTECTED]> wrote:
> If you are in control of the server, you can simulate datagram sockets with
> one-shot controlled sockets
I do not agree with Richard at all, but I have to play devil's
advocate here because I think such a simulatio
On Mon, Sep 29, 2008 at 9:54 PM, Hallvord R M Steen <[EMAIL PROTECTED]>wrote:
> To give webmasters more ways to deal with this situation, I think we
> should implement the Access Control "Origin" HTTP-header only
> (assuming that it should refer to the top site in the frameset
> hierarchy).
>
> Re
2008/9/25 Toby A Inkster <[EMAIL PROTECTED]>:
>> 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.
Not likely. The entire
31 matches
Mail list logo
