[whatwg] iframe sandbox allow-bottom-navigation

[Nick Vidal]

Instead of using the navigation bar from the browser, use one created
by the Webtop. This would allow you to go back and forth or bookmark
the current website displayed within the iframe.

By bookmark, I mean the Webtop being able to read the current location
of the website and saving that to the server-side. By save a session,
I mean the Webtop being able to read the location of all iframes it
created and saving that to the server-side for later retrieval.

This is comparable to the browser's own bookmark or session manager
[note 1]. But the advantage of this approach is that it's not tied to
a browser. Thus, one could retrieve a bookmark or a session simply by
loading the Webtop wherever s/he had access to the Web. Plus, it opens
up possibilities to the development of new UIs.

Notes:
1) One example: https://addons.mozilla.org/en-US/firefox/addon/2324/


On Mon, Sep 6, 2010 at 1:42 PM, Adam Barth <w3c at adambarth.com> wrote:
> What do you mean by access to the iframe's browsing context?  Is that
> access you would have if the iframe were not sandboxed?
>
> Adam
>
>
> On Mon, Sep 6, 2010 at 7:31 AM, Nick Vidal <nick at iss.im> wrote:
>> In addition to allow-top-navigation for the iframe's sandbox
>> attribute, I propose the opposite: allow-bottom-navigation. This would
>> allow a parent document to have access to the iframe's
>> browsing-context (even when the user has navigate to a different
>> domain).
>>
>> I'm building a Webtop (a Desktop Environment on top of the Web) that
>> allows users to navigate websites securely through iframes [note 1].
>> An iframe is necessary to protect the Webtop from being compromised by
>> an untrusted website.  However, this also restricts the Webtop from
>> accessing the browsing-context of the iframe.
>>
>> The allow-bottom-navigation would permit the Webtop:
>>
>> a) to provide independent navigation controls for each iframe [note 2];
>> b) to bookmark a website;
>> c) to save a session (i.e. to save all opened task windows, including
>> those that have an iframe).
>>
>> I don't see any security risks, since the parent document would have
>> access only to the browsing context of the iframe. No other access
>> would be granted.
>>
>> Best regards,
>> Nick
>>
>> Notes:
>> 1) More information here: http://itop.iss.im/
>> 2) As previously discussed here:
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027884.html
>>
>