[whatwg] cross-domain scrollIntoView on frames and iframes

[Ojan Vafai]

On Fri, Apr 3, 2009 at 10:46 PM, Cameron McCormack <cam at mcc.id.au> 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 <whatwg at adambarth.com> wrote:

> On Sun, Apr 5, 2009 at 1:09 AM, Giorgio Maone <g.maone at informaction.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090406/87d04ce3/attachment-0001.htm>