Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Ian Hickson]

On Sat, 18 Jul 2009, Adam Barth wrote:
> On Fri, Jul 17, 2009 at 4:10 PM, Ian Hickson wrote:
> > Suppose that there is a tool where someone can write some text, in which
> > case the text will be displayed when the page is loaded. Suppose that
> > whether the person has written this text is confidential, and that whether
> > one had entered text there or not would reveal something that the user
> > would prefer to keep secret.
> >
> > You could use this API to tell whether or not another user had entered
> > text, by opening an iframe to that page, and then trying to scroll from
> > distance n to distance n+10 many times in a loop, and timing how long it
> > takes to do the scroll. If there is no more content in the page, then
> > scrolling to n and n+10 would take less time than it would if there was
> > more content (since scrolling is slower than doing nothing).
> 
> I suspect you could extract that information more easily by just
> timing the page load:
> 
> http://crypto.stanford.edu/~abortz/papers/timingweb.pdf

Yes, that would be another way of getting this information.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Adam Barth]

On Fri, Jul 17, 2009 at 4:10 PM, Ian Hickson wrote:
> Suppose that there is a tool where someone can write some text, in which
> case the text will be displayed when the page is loaded. Suppose that
> whether the person has written this text is confidential, and that whether
> one had entered text there or not would reveal something that the user
> would prefer to keep secret.
>
> You could use this API to tell whether or not another user had entered
> text, by opening an iframe to that page, and then trying to scroll from
> distance n to distance n+10 many times in a loop, and timing how long it
> takes to do the scroll. If there is no more content in the page, then
> scrolling to n and n+10 would take less time than it would if there was
> more content (since scrolling is slower than doing nothing).

I suspect you could extract that information more easily by just
timing the page load:

http://crypto.stanford.edu/~abortz/papers/timingweb.pdf

Adam

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Ian Hickson]

On Mon, 29 Jun 2009, Ojan Vafai wrote:
> On Tue, Jun 2, 2009 at 11:38 PM, Ian Hickson  wrote:
> > On Fri, 3 Apr 2009, Ojan Vafai wrote:
> > >
> > > I'm suggesting an addition to cross-domain (i)frames that allows 
> > > scrolling specific content into view. The use case is sites that 
> > > aggregate data from many sites (e.g. search engines) and want to 
> > > display that data in an iframe. They can load the page in an iframe, 
> > > but they have no way to make the content visible as they don't have 
> > > access to the iframe's contents.
> > >
> > > A few possible APIs come to mind. I personally prefer the 
> > > javascripty option below, but I'll include another one for good 
> > > measure.
> > >
> > > 1) Add a scrollPathIntoView (with a better name) on iframes that 
> > > takes either an xpath or a css selector and scrolls the specified 
> > > item into view. If no such item exists, it does nothing. If one or 
> > > more such items exist, it calls scrollIntoView on the first matching 
> > > item.
> > >
> > > 2) Add a css or xpath expression to fragment identifiers. Tthe 
> > > iframe src can be set to http://foo.com#css(.foo 
> > >  #bar). Same as above applies. If there's 
> > > no match, it's a noop. If there is a match, it scrolls the first one 
> > > into view.
> > >
> > > In both cases, no explicit success or failure is returned to the 
> > > caller as that would leak the iframes DOM across domains.
> > >
> > > This API can obviously be supported on same-domain iframes as well, 
> > > but it's not really necessary since you can just dig into the DOM of 
> > > the iframe.
> >
> > On Mon, 6 Apr 2009, Jonas Sicking wrote:
> > >
> > > From my point of view I'm not sure how interesting this whole 
> > > feature is. We had support in firefox for XPointer for many years 
> > > and saw little to no uptake. I'm not sure if anyone complained when 
> > > we removed the support even (which would be pretty remarkable).
> >
> > It seems that with such an API and with some careful timing 
> > measurements, you could determine the contents of a foreign iframe. 
> > I'm not sure that's a good idea.
> 
> Can you expand on what you mean a bit? I'd like to see if there's still 
> a way we can meet the use-case.

Suppose that there is a tool where someone can write some text, in which 
case the text will be displayed when the page is loaded. Suppose that 
whether the person has written this text is confidential, and that whether 
one had entered text there or not would reveal something that the user 
would prefer to keep secret.

You could use this API to tell whether or not another user had entered 
text, by opening an iframe to that page, and then trying to scroll from 
distance n to distance n+10 many times in a loop, and timing how long it 
takes to do the scroll. If there is no more content in the page, then 
scrolling to n and n+10 would take less time than it would if there was 
more content (since scrolling is slower than doing nothing).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Ojan Vafai]

On Tue, Jun 2, 2009 at 11:38 PM, Ian Hickson  wrote:

> On Fri, 3 Apr 2009, Ojan Vafai wrote:
> >
> > I'm suggesting an addition to cross-domain (i)frames that allows
> > scrolling specific content into view. The use case is sites that
> > aggregate data from many sites (e.g. search engines) and want to display
> > that data in an iframe. They can load the page in an iframe, but they
> > have no way to make the content visible as they don't have access to the
> > iframe's contents.
> >
> > A few possible APIs come to mind. I personally prefer the javascripty
> > option below, but I'll include another one for good measure.
> >
> > 1) Add a scrollPathIntoView (with a better name) on iframes that takes
> > either an xpath or a css selector and scrolls the specified item into
> > view. If no such item exists, it does nothing. If one or more such items
> > exist, it calls scrollIntoView on the first matching item.
> >
> > 2) Add a css or xpath expression to fragment identifiers. Tthe iframe
> > src can be set to http://foo.com#css(.foo 
> > #bar). Same as above applies. If there's no match, it's a noop. If there
> > is a match, it scrolls the first one into view.
> >
> > In both cases, no explicit success or failure is returned to the caller
> > as that would leak the iframes DOM across domains.
> >
> > This API can obviously be supported on same-domain iframes as well, but
> > it's not really necessary since you can just dig into the DOM of the
> > iframe.
>
> On Mon, 6 Apr 2009, Jonas Sicking wrote:
> >
> > From my point of view I'm not sure how interesting this whole feature
> > is. We had support in firefox for XPointer for many years and saw little
> > to no uptake. I'm not sure if anyone complained when we removed the
> > support even (which would be pretty remarkable).
>
> It seems that with such an API and with some careful timing measurements,
> you could determine the contents of a foreign iframe. I'm not sure that's
> a good idea.


Can you expand on what you
mean a bit? I'd like to see if there's still a way we can meet the use-case.


> I tried to come up with some alternative solutions, but I really haven't
> been very successful.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Ian Hickson]

On Fri, 3 Apr 2009, Ojan Vafai wrote:
>
> I'm suggesting an addition to cross-domain (i)frames that allows 
> scrolling specific content into view. The use case is sites that 
> aggregate data from many sites (e.g. search engines) and want to display 
> that data in an iframe. They can load the page in an iframe, but they 
> have no way to make the content visible as they don't have access to the 
> iframe's contents.
> 
> A few possible APIs come to mind. I personally prefer the javascripty 
> option below, but I'll include another one for good measure.
> 
> 1) Add a scrollPathIntoView (with a better name) on iframes that takes 
> either an xpath or a css selector and scrolls the specified item into 
> view. If no such item exists, it does nothing. If one or more such items 
> exist, it calls scrollIntoView on the first matching item.
>
> 2) Add a css or xpath expression to fragment identifiers. Tthe iframe 
> src can be set to http://foo.com#css(.foo  
> #bar). Same as above applies. If there's no match, it's a noop. If there 
> is a match, it scrolls the first one into view.
> 
> In both cases, no explicit success or failure is returned to the caller 
> as that would leak the iframes DOM across domains.
> 
> This API can obviously be supported on same-domain iframes as well, but 
> it's not really necessary since you can just dig into the DOM of the 
> iframe.

On Mon, 6 Apr 2009, Jonas Sicking wrote:
> 
> From my point of view I'm not sure how interesting this whole feature 
> is. We had support in firefox for XPointer for many years and saw little 
> to no uptake. I'm not sure if anyone complained when we removed the 
> support even (which would be pretty remarkable).

It seems that with such an API and with some careful timing measurements, 
you could determine the contents of a foreign iframe. I'm not sure that's 
a good idea.

I tried to come up with some alternative solutions, but I really haven't 
been very successful.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Alex Russell]

On Tue, Apr 14, 2009 at 9:48 AM, Alex Russell  wrote:
> On Thu, Apr 9, 2009 at 6:21 AM, Jon Barnett  wrote:
>> On Mon, Apr 6, 2009 at 3:51 PM, Jonas Sicking  wrote:
>>>
>>> >From my point of view I'm not sure how interesting this whole feature
>>> is. We had support in firefox for XPointer for many years and saw
>>> little to no uptake. I'm not sure if anyone complained when we removed
>>> the support even (which would be pretty remarkable).
>>>
>>> / Jonas
>>
>> Was it advertized?  I follow Firefox closely enough, but I don't remember
>> when XPointer was supported.  Was it supported by other browsers?  It would
>> be rare in the wild if it's only supported by Firefox.  Do other browsers
>> have easy scripting support for XPath?
>
> IE, FF, and modern Safari/Chrome versions all support some version of
> xpath queries against the HTML DOM.

Ugg...I knew I shouldn't have hit "send". IE does not support XPath on
the HTML dom, but does support it on XML documents. Sorry for the
misinformation.

Regards

> I don't know that any of them
> include xpointer support. That said, CSS seems to be the winner as far
> as node selection/location languages go.
>
> Regards
>

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Alex Russell]

On Thu, Apr 9, 2009 at 6:21 AM, Jon Barnett  wrote:
> On Mon, Apr 6, 2009 at 3:51 PM, Jonas Sicking  wrote:
>>
>> >From my point of view I'm not sure how interesting this whole feature
>> is. We had support in firefox for XPointer for many years and saw
>> little to no uptake. I'm not sure if anyone complained when we removed
>> the support even (which would be pretty remarkable).
>>
>> / Jonas
>
> Was it advertized?  I follow Firefox closely enough, but I don't remember
> when XPointer was supported.  Was it supported by other browsers?  It would
> be rare in the wild if it's only supported by Firefox.  Do other browsers
> have easy scripting support for XPath?

IE, FF, and modern Safari/Chrome versions all support some version of
xpath queries against the HTML DOM. I don't know that any of them
include xpointer support. That said, CSS seems to be the winner as far
as node selection/location languages go.

Regards

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Henri Sivonen]

On Apr 9, 2009, at 16:21, Jon Barnett wrote:


Do other browsers have easy scripting support for XPath?



In addition to Gecko, WebKit and Presto support the  
document.evaluate() API for using XPath from JS.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Kristof Zelechovski]

IMHO, XPath support can be programmed into a script library; the only
requirement is DOM access.

Chris

 

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Boris Zbarsky]

Jon Barnett wrote:

Was it advertized?


Not particularly.


I follow Firefox closely enough, but I don't remember when XPointer was 
supported.


If you only follow "Firefox", then you might not have have noticed it 
anyway.  XPointer support for anchor scrolling was added to Gecko in 
March 2003.  Firefox wasn't even called Firefox until about a year later.


Note that XPointer is only supported for anchor scrolling in XML 
documents (not XHTML ones, from what I can see) in Gecko, which is 
another reason no one's using it, I bet.



Was it supported by other browsers?


No idea.


It would be rare in the wild if it's only supported by Firefox.


Yep.

Do other browsers have easy scripting support for XPath?  


No idea.

Except for the cross-domain iframe case, you could script support for 
XPointer if the browser has decent support for XPath in Javascript.  I 
know I've had instances where I wished for XPointer support. It may or 
may not have had a fair shake.


It probably hasn't.

-Boris

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Jon Barnett]

On Mon, Apr 6, 2009 at 3:51 PM, Jonas Sicking  wrote:

> >From my point of view I'm not sure how interesting this whole feature
> is. We had support in firefox for XPointer for many years and saw
> little to no uptake. I'm not sure if anyone complained when we removed
> the support even (which would be pretty remarkable).
>
> / Jonas
>
Was it advertized?  I follow Firefox closely enough, but I don't remember
when XPointer was supported.  Was it supported by other browsers?  It would
be rare in the wild if it's only supported by Firefox.  Do other browsers
have easy scripting support for XPath?  Except for the cross-domain iframe
case, you could script support for XPointer if the browser has decent
support for XPath in Javascript.  I know I've had instances where I wished
for XPointer support. It may or may not have had a fair shake.


-- 
Jon Barnett

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Jonas Sicking]

On Mon, Apr 6, 2009 at 11:33 AM, Giovanni Campagna
 wrote:
> 2009/4/6 Ojan Vafai :
>> On Fri, Apr 3, 2009 at 10:46 PM, Cameron McCormack  wrote:
>>>
>>> Ojan Vafai:
>>> > 2) Add a css or xpath expression to fragment identifiers. Tthe iframe
>>> > src can be set to http://foo.com#css(.foo #bar). Same as above
>>> > applies. If there's no match, it's a noop. If there is a match, it
>>> > scrolls the first one into view.
>>>
>>> Sounds like XPointer:
>>>
>>>  http://www.w3.org/TR/xptr-framework/
>>
>> Yes, it's a similar idea. XPointer seems focused on XML/XHTML, I'm not sure
>> what it would take to extend the spec to include HTML. In addition, I don't
>> really see the point of adding yet another element addressing scheme to the
>> web. XPath and CSS selectors are already there and familiar to developers.
>
> Actually, XPointer is just the application of XPath in fragment
> identifiers of XML resources, but it is designed in a way that could
> allow a "css" scheme or anything else, if specified.

>From my point of view I'm not sure how interesting this whole feature
is. We had support in firefox for XPointer for many years and saw
little to no uptake. I'm not sure if anyone complained when we removed
the support even (which would be pretty remarkable).

/ Jonas

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Giovanni Campagna]

2009/4/6 Ojan Vafai :
> On Fri, Apr 3, 2009 at 10:46 PM, Cameron McCormack  wrote:
>>
>> Ojan Vafai:
>> > 2) Add a css or xpath expression to fragment identifiers. Tthe iframe
>> > src can be set to http://foo.com#css(.foo #bar). Same as above
>> > applies. If there's no match, it's a noop. If there is a match, it
>> > scrolls the first one into view.
>>
>> Sounds like XPointer:
>>
>>  http://www.w3.org/TR/xptr-framework/
>
> Yes, it's a similar idea. XPointer seems focused on XML/XHTML, I'm not sure
> what it would take to extend the spec to include HTML. In addition, I don't
> really see the point of adding yet another element addressing scheme to the
> web. XPath and CSS selectors are already there and familiar to developers.

Actually, XPointer is just the application of XPath in fragment
identifiers of XML resources, but it is designed in a way that could
allow a "css" scheme or anything else, if specified.

Giovanni

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Ojan Vafai]

On Fri, Apr 3, 2009 at 10:46 PM, Cameron McCormack  wrote:

> Ojan Vafai:
> > 2) Add a css or xpath expression to fragment identifiers. Tthe iframe
> > src can be set to http://foo.com#css(.foo #bar). Same as above
> > applies. If there's no match, it's a noop. If there is a match, it
> > scrolls the first one into view.
>
> Sounds like XPointer:
>
>  http://www.w3.org/TR/xptr-framework/
>

Yes, it's a similar idea. XPointer seems focused on XML/XHTML, I'm not sure
what it would take to extend the spec to include HTML. In addition, I don't
really see the point of adding yet another element addressing scheme to the
web. XPath and CSS selectors are already there and familiar to developers.

On Sun, Apr 5, 2009 at 10:32 PM, Adam Barth  wrote:

> On Sun, Apr 5, 2009 at 1:09 AM, Giorgio Maone 
> wrote:
> > It would make clickjacking attacks more precise, by exactly positioning
> the
> > frame content where the attacker wants it to be.
> > Not that you cannot already be pixel-precise by using absolute
> positioning
> > inside an overflow: hidden div...
> > Let's say it would make them even more script-kiddies friendly.
>
> Hum...  That doesn't sound that bad.  If you're relying on the
> obscurity of pixel offsets for a clickjacking defense, then you've got
> bigger problems than scrollIntoView.


I agree with Adam here. I don't see that this opens any significant attack
vector. That said, if someone can think of a serious security concern, I'm
all ears.

Ojan

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Adam Barth]

On Sun, Apr 5, 2009 at 1:09 AM, Giorgio Maone  wrote:
> It would make clickjacking attacks more precise, by exactly positioning the
> frame content where the attacker wants it to be.
> Not that you cannot already be pixel-precise by using absolute positioning
> inside an overflow: hidden div...
> Let's say it would make them even more script-kiddies friendly.

Hum...  That doesn't sound that bad.  If you're relying on the
obscurity of pixel offsets for a clickjacking defense, then you've got
bigger problems than scrollIntoView.

Adam

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Giorgio Maone]

Peter Kasting wrote, On 05/04/2009 0.54:

On Sat, Apr 4, 2009 at 12:56 PM, timeless  wrote:

  

sounds like a security nightmare.




Can you be less vague?  We've had a number of security people vet this
already, so specific complaints would be very helpful.

PK
It would make clickjacking attacks more precise, by exactly positioning 
the frame content where the attacker wants it to be.
Not that you cannot already be pixel-precise by using absolute 
positioning inside an overflow: hidden div...

Let's say it would make them even more script-kiddies friendly.
--
Giorgio Maone

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Peter Kasting]

On Sat, Apr 4, 2009 at 12:56 PM, timeless  wrote:

> sounds like a security nightmare.


Can you be less vague?  We've had a number of security people vet this
already, so specific complaints would be very helpful.

PK

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[timeless]

sounds like a security nightmare.

we already have people complaining about reframing and spoofing and things.

Re: [whatwg] cross-domain scrollIntoView on frames and iframes

[Cameron McCormack]

Ojan Vafai:
> 2) Add a css or xpath expression to fragment identifiers. Tthe iframe
> src can be set to http://foo.com#css(.foo #bar). Same as above
> applies. If there's no match, it's a noop. If there is a match, it
> scrolls the first one into view.

Sounds like XPointer:

  http://www.w3.org/TR/xptr-framework/

-- 
Cameron McCormack ≝ http://mcc.id.au/

[whatwg] cross-domain scrollIntoView on frames and iframes

[Ojan Vafai]

I'm suggesting an addition to cross-domain (i)frames that allows scrolling
specific content into view. The use case is sites that aggregate data from
many sites (e.g. search engines) and want to display that data in an iframe.
They can load the page in an iframe, but they have no way to make the
content visible as they don't have access to the iframe's contents.

A few possible APIs come to mind. I personally prefer the javascripty option
below, but I'll include another one for good measure.

1) Add a scrollPathIntoView (with a better name) on iframes that takes
either an xpath or a css selector and scrolls the specified item into view.
If no such item exists, it does nothing. If one or more such items exist, it
calls scrollIntoView on the first matching item.
2) Add a css or xpath expression to fragment identifiers. Tthe iframe src
can be set to http://foo.com#css(.foo  #bar). Same
as above applies. If there's no match, it's a noop. If there is a match, it
scrolls the first one into view.

In both cases, no explicit success or failure is returned to the caller as
that would leak the iframes DOM across domains.

This API can obviously be supported on same-domain iframes as well, but it's
not really necessary since you can just dig into the DOM of the iframe.

Ojan