On Tue, 2 Oct 2012, James Graham wrote:
> On 10/02/2012 02:34 AM, Boris Zbarsky wrote:
> > On 10/1/12 6:10 PM, Ian Hickson wrote:
> > > On Tue, 19 Jun 2012, Boris Zbarsky wrote:
> > > > On 6/19/12 1:56 PM, Charlie Reis wrote:
> > > > > That's from the "[if] the user agent determines that the two
>
On 10/02/2012 02:34 AM, Boris Zbarsky wrote:
On 10/1/12 6:10 PM, Ian Hickson wrote:
On Tue, 19 Jun 2012, Boris Zbarsky wrote:
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the "[if] the user agent determines that the two browsing
contexts are related enough that it is ok if they reach ea
On Mon, 1 Oct 2012, Glenn Maynard wrote:
> >
> > Primary goals:
> > + have the new page use a different event loop if possible (new process)
> > + have the window of the new page not be able to reach the opener via
> > a named window.open() or target=""
> >
> > As a result, I think these are
On Mon, Oct 1, 2012 at 8:37 PM, Ian Hickson wrote:
> > The all-too-common bad reason is "we want people to keep pages open in
> > the user's browser for long as possible in the hopes that it'll make
> > them come back by accident, so we'll sprinkle target=_blank everywhere",
> > eg. amazon.co.jp
On Mon, 1 Oct 2012, Glenn Maynard wrote:
> On Mon, Oct 1, 2012 at 5:10 PM, Ian Hickson wrote:
> > >
> > > + have the new page be in a new browsing context
> >
> > ...it's a new browsing context (e.g. target="_blank").
>
> I'm not very familiar with the browsing context concept: what's the
> pr
On 10/1/12 6:10 PM, Ian Hickson wrote:
On Tue, 19 Jun 2012, Boris Zbarsky wrote:
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the "[if] the user agent determines that the two browsing
contexts are related enough that it is ok if they reach each other"
part, which is quite vague.
This i
On Mon, Oct 1, 2012 at 5:10 PM, Ian Hickson wrote:
> > + have the new page be in a new browsing context
>
> ...it's a new browsing context (e.g. target="_blank").
>
I'm not very familiar with the browsing context concept: what's the
practical security issue here? It should never be necessary
Summary: I've changed rel=noreferrer so that when it creates a new
top-level browsing context, it doesn't clone sessionStorage. Turns out
that as specced, it already did everything else that was needed.
On Wed, 6 Jun 2012, Charlie Reis wrote:
>
> I've posted a new proposal to the WhatWG wiki to
On Mon, Sep 24, 2012 at 5:48 PM, Boris Zbarsky wrote:
>
> On 9/24/12 8:42 PM, Mihai Parparita wrote:
>>
>> On Mon, Sep 24, 2012 at 12:11 PM, Ian Hickson wrote:
>>
>>> Why does GMail need to use window.open()? Surely the right way to
expose a
>>> link is to use . What is forcing them to use window
On 9/24/12 8:42 PM, Mihai Parparita wrote:
On Mon, Sep 24, 2012 at 12:11 PM, Ian Hickson wrote:
Why does GMail need to use window.open()? Surely the right way to expose a
link is to use . What is forcing them to use window.open()?
I can't speak for Gmail, but Google Reader uses window.open
On Mon, Sep 24, 2012 at 12:11 PM, Ian Hickson wrote:
> Why does GMail need to use window.open()? Surely the right way to expose a
> link is to use . What is forcing them to use window.open()?
>
I can't speak for Gmail, but Google Reader uses window.open since it allows
"unrelated" links to be op
On Mon, 27 Aug 2012, Charlie Reis wrote:
> >
> > Does this need to be done from window.open()?
>
> Yes. For example, Gmail uses window.open() for the links in emails, but
> would like the links to open in an unrelated context.
Why does GMail need to use window.open()? Surely the right way to e
On Wed, Aug 29, 2012 at 3:01 PM, Charlie Reis wrote:
> On Tue, Aug 28, 2012 at 9:39 AM, Glenn Maynard wrote:
> > I had to do this recently (a script-initiated rel=noreferrer
> navigation). FYI, I worked around it by creating a temporary
> HTMLAnchorElement, setting its href and rel properties a
On Tue, Aug 28, 2012 at 9:39 AM, Glenn Maynard wrote:
>
> On Tue, Aug 28, 2012 at 11:18 AM, Charlie Reis wrote:
>>
>> There are two main differences from the rel=noreferrer feature. First
(as
>> you note), this does still send the referrer. That's useful for sites
that
>> don't want to be affec
On Tue, Aug 28, 2012 at 11:18 AM, Charlie Reis wrote:
> There are two main differences from the rel=noreferrer feature. First (as
> you note), this does still send the referrer. That's useful for sites that
> don't want to be affected by the newly opened page but that still rely on
> referrers
On Mon, Aug 27, 2012 at 11:43 PM, Maciej Stachowiak wrote:
>
>
> James pointed out to me that the proposal explains the difference to
noreferrer, which is essential that it *does* send a referrer, but has the
rel=noreferrer behavior of nulling out window.opener.
>
> I'm still not clear on the use
James pointed out to me that the proposal explains the difference to
noreferrer, which is essential that it *does* send a referrer, but has the
rel=noreferrer behavior of nulling out window.opener.
I'm still not clear on the use case for nulling the opener but still sending
the Referer header.
I overlooked that it's also in the spec itself, not just the registry:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer
Regards,
Maciej
On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak wrote:
>
> Someone earlier in the thread mentioned that this featu
Someone earlier in the thread mentioned that this feature sounds an awful lot
like rel=noreferrer, which has been in WebKit for several years:
http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/
It is also mentioned in the official link relation registry:
http
On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson wrote:
>
> On Wed, 6 Jun 2012, Charlie Reis wrote:
> >
> > I've posted a new proposal to the WhatWG wiki to give web sites a way
> > to open a link in an unrelated browsing context. These links would open
> > in a new window with no script connection
On Wed, 6 Jun 2012, Charlie Reis wrote:
>
> I've posted a new proposal to the WhatWG wiki to give web sites a way
> to open a link in an unrelated browsing context. These links would open
> in a new window with no script connections back to the original site,
> which is useful for web apps li
On Thu, Jun 28, 2012 at 9:00 PM, Charlie Reis wrote:
> What's the next step for this proposal? Hixie, does the "_unrelated"
> target approach sound good to you at this point?
> http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts
FWIW, all emails to the list will be read by the edito
On Tue, Jun 19, 2012 at 2:52 PM, Charlie Reis wrote:
> On Tue, Jun 19, 2012 at 2:16 PM, James Graham wrote:
>>
>> The way the process here works is that Hixie reads these emails agrees that
>> the change is a good idea (hopefully; in this case it seems likely since we
>> seem to have three impl
On Tue, Jun 19, 2012 at 2:16 PM, James Graham wrote:
>
> The way the process here works is that Hixie reads these emails agrees that
> the change is a good idea (hopefully; in this case it seems likely since we
> seem to have three implementors in agreement) and it happens. There isn't any
> ne
On Tue, 19 Jun 2012, Charlie Reis wrote:
On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky wrote:
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the "[if] the user agent
determines that the two browsing contexts are related enough that
it is
ok if t
On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky wrote:
> On 6/19/12 1:56 PM, Charlie Reis wrote:
>
>> That's from the "[if] the user agent
>> determines that the two browsing contexts are related enough that it is
>> ok if they reach each other" part, which is quite vague.
>>
>
> This is, imo, th
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the "[if] the user agent
determines that the two browsing contexts are related enough that it is
ok if they reach each other" part, which is quite vague.
This is, imo, the part that says unrelated browsing contexts should not
be able to reach
On Mon, Jun 18, 2012 at 7:59 PM, Boris Zbarsky wrote:
> On 6/18/12 6:10 PM, Charlie Reis wrote:
>
>> I'm going to go out on a limb and say that it's ok if named but
>> unrelated windows are able to discover each other.
>>
>
> I actually don't; I think the fact that it happens in Firefox is a
> (l
On 6/18/12 6:10 PM, Charlie Reis wrote:
I'm going to go out on a limb and say that it's ok if named but
unrelated windows are able to discover each other.
I actually don't; I think the fact that it happens in Firefox is a
(longstanding) bug that needs to get fixed.
If we want to change that
On Thu, Jun 14, 2012 at 10:45 AM, Charlie Reis wrote:
> I do observe that Safari, IE, and even Opera currently allow windows in
> unrelated contexts to discover named windows, though. Just do a
> window.open("foo.html", "foo") from two independently opened windows and
> they'll both target the s
On Thu, Jun 14, 2012 at 4:04 AM, James Graham wrote:
> On 06/14/2012 04:06 AM, Boris Zbarsky wrote:
>
>> On 6/13/12 7:44 PM, Michal Zalewski wrote:
>>
>>> The degree of separation between browsing contexts is intuitive in the
>>> case of Chrome
>>>
>>
>> Except it's not, because Chrome will somet
On Thu, Jun 14, 2012 at 12:59 AM, Simon Pieters wrote:
> On Thu, 14 Jun 2012 01:44:12 +0200, Michal Zalewski
> wrote:
>
> Any feedback on this revised approach?
>>>
>>
>> My vague concern is that the separation is a bit fuzzy, beyond saying
>> that window.opener will be null... if that's the on
On 06/14/2012 04:06 AM, Boris Zbarsky wrote:
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different one
On Thu, 14 Jun 2012 01:44:12 +0200, Michal Zalewski
wrote:
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearl
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different ones, based on whatever
heuristics it uses for
On Wed, Jun 13, 2012 at 4:44 PM, Michal Zalewski wrote:
> > Any feedback on this revised approach?
>
> My vague concern is that the separation is a bit fuzzy, beyond saying
> that window.opener will be null... if that's the only guaranteed
> outcome, then maybe that should be spelled out more clea
> Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly? The
degree of separation between browsing contexts is intuiti
On Tue, Jun 12, 2012 at 7:39 AM, Charlie Reis wrote:
> On Mon, Jun 11, 2012 at 11:24 PM, Anne van Kesteren wrote:
>
>> Having a rel attribute imply a target attribute value seems bad. Thus
>> far they have been orthogonal. Maybe it should be a new target
>> attribute value instead?
>>
>>
> I'm no
On Mon, Jun 11, 2012 at 11:24 PM, Anne van Kesteren wrote:
> On Mon, Jun 11, 2012 at 11:32 PM, Charlie Reis wrote:
> > Any other feedback on this proposal?
> > http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts
>
> Having a rel attribute imply a target attribute value seems bad. Thu
On Mon, Jun 11, 2012 at 11:32 PM, Charlie Reis wrote:
> Any other feedback on this proposal?
> http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts
Having a rel attribute imply a target attribute value seems bad. Thus
far they have been orthogonal. Maybe it should be a new target
attr
On Thu, Jun 7, 2012 at 9:21 AM, Charlie Reis wrote:
> On Wed, Jun 6, 2012 at 11:47 PM, Adam Barth wrote:
>
>> On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard wrote:
>> > On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius <
>> svartma...@gmail.com>wrote:
>> >> On Wed, Jun 06, 2012 at 07:32:34PM -0
On Wed, Jun 6, 2012 at 11:47 PM, Adam Barth wrote:
> On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard wrote:
> > On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius >wrote:
> >> On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
> >> > Please don't encourage yet more sites to open new t
On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard wrote:
> On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius
> wrote:
>> On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
>> > Please don't encourage yet more sites to open new tabs when I didn't ask
>> > for it.
>> It's merely a new brow
On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius wrote:
> On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
> > Please don't encourage yet more sites to open new tabs when I didn't ask
> > for it.
> It's merely a new browsing context IIUC, not necessarily a new window
> (frame, tab,
On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
> Please don't encourage yet more sites to open new tabs when I didn't ask
> for it.
It's merely a new browsing context IIUC, not necessarily a new window (frame,
tab, tile or whatever it's called this year). Someone that understands t
On Wed, Jun 6, 2012 at 6:56 PM, Charlie Reis wrote:
> I'm hoping to bypass all of those by overriding any specification of target
> in the link. That is, if "rel=unrelated" is specified, that forces target
> to be "_blank".
>
Please don't encourage yet more sites to open new tabs when I didn't
I'm hoping to bypass all of those by overriding any specification of target
in the link. That is, if "rel=unrelated" is specified, that forces target
to be "_blank".
Charlie
On Wed, Jun 6, 2012 at 4:53 PM, Michal Zalewski wrote:
> Several questions:
>
> 1) How would this mechanism work with na
Several questions:
1) How would this mechanism work with named windows (which may be targeted
by means other than accessing opener.*)? In certain implementations (e.g.,
Chrome), the separation in this namespace comes free, but that's not given
for other browsers. There are ways in which the attack
Hi all--
I've posted a new proposal to the WhatWG wiki to give web sites a way to
open a link in an unrelated browsing context. These links would open in a
new window with no script connections back to the original site, which is
useful for web apps like Gmail that open user-contributed links.
49 matches
Mail list logo
