These forums are currently read-only due to receiving more spam than actual discussion. Sorry.

It is currently Sat Dec 02, 2017 4:06 pm Advanced search

proposal: framing attribute in HTML element

Do you think the HTML spec should do something differently? You can discuss spec feedback here, but you should send it to the WHATWG mailing list or file a bug in the W3C bugzilla for it to be considered.

Should an HTML 5 page be able to disable framing?

Yes
1
50%
No
1
50%
Yes, but the proposal should be changed before it is accepted
0
No votes
 
Total votes : 2

proposal: framing attribute in HTML element

Postby ahagen » Sun Apr 19, 2009 9:53 pm

Introduction

Site authors should have the ability to prevent other sites from using their sites' content in a frame. While this can already be accomplished using a scripting language like Javascript, it should be possible to implement using plain HTML 5.

It is not right to force site authors to rely on Javascript or other scripting languages to break out of frames. Many browsers have Javascript disabled. Running Javascript also has a performance cost, even if it is very slight.

Under the current HTML 5 specification, web pages that are not compliant with HTML 5 can place an HTML 5 page in a frame. Nothing currently in the HTML 5 specification prevents an HTML 5-compliant browser from displaying an HTML 5 page in a frame set by a different, non-HTML 5 page. This situation should not stand.

Proposal

Thus is proposed for HTML 5 a new attribute for the HTML tag: framing. The default for the attribute would be set to "allow."

When the attribute is set to "allow", browsers must display an HTML 5 page as stated elsewhere in the HTML 5 spec. The web page would be frameable. For example,

Code: Select all
<html framing="allow">


Code: Select all
<html>


Both do the same. If an HTML 5 page is so coded, and the page is framed, a browser should display the page in the frame.

If an HTML 5 page's HTML element has framing="deny", a browser must not display the page within a frame. This includes an iframe. Instead of the framed page, browsers may show either a blank page or an explanatory message.

Code: Select all
<html framing="deny">


A browser must not frame an HTML 5 page with the above tagging. Instead the browser must show either a blank page or an explanatory message.

The third and final possible value for the attribute is next. If an HTML 5 page's HTML element has the attribute framing="takeover", a browser must not display the page within a frame. Instead of the framed page, the browser must treat the frame src call as an href that has been selected. All frames on the current page should be dropped and the browser should proceed to the "framed page" in an unframed manner.

Code: Select all
<html framing="takeover">


A browser must not frame an HTML 5 page with the above coding. Instead the browser must display this page unframed, taking over the browser window.

There is slightly different behavior for iframe. A page in an iframe with framing="takeover" should be treated the same way as framing="deny". The reason is that an iframe is usually small and meant only for a specific purpose. Therefore taking over the entire page would not be appropriate.

Notes

At this point, error handling should be addressed. If framing is set to anything other than "allow", "deny", or "takeover", that is an error. In such a case, a browser should treat the page as if framing were set to "allow."

If a framing web page frames multiple web pages while more than one has framing="takeover", the first such page listed will "takeover" the page. The other "takeover" pages will not be displayed.

For reason of ease of implementation, a browser may briefly display a page with framing="deny" or "takeover" in a frame if the browser quickly switches to a blank page, the explanatory message, or the takeover page, as appropriate.

Site authors may wish for additional complexity. For example, "allow framing by certain domains but not others," or "if the page is framed, don't display the content but instead display a link to my site." Such cannot be accomplished using only the framing attribute. For site authors desirous of such complexity, there are many useful tools available, including Javascript.

Why

Framing is controversial because it often breaks page navigation and bookmarking. It tends to confuse people about who owns what web page. In some cases, framing can lead to intellectual property concerns. Links to framing pages may give search engine rank to the framing site instead of the content site. It is difficult to print framed pages. It is difficult for a screenreader to handle framed pages. Many site authors do not want their sites framed for aesthetic reasons. If one does not want one's content to be used to publicize another site, one should have that right. If a web developer does not want his site framed for any reason, browsers should honor that decision.

Implementation

I believe the framing attribute would be relatively simple for browsers to implement. Once browsers begin to implement it, many HTML 5 developers are likely to quickly adopt it. Web site authors will have a useful new tool that saves time and headaches, is simple to use, and does not require a scripting language.

As browsers begin to support HTML 5 and the framing attribute, the control of site authors will be increased. Site authors may nevertheless still see a need to use scripting to dispose of frames, because there will still be browsers that do not recognize the framing attribute. Yet, over time, the number of such browsers should decrease as HTML 5 flourishes.

Summary

The attribute 'framing' to the HTML element would be a useful addition to the HTML 5 specification.

If there is some mistake in this proposal, it is my responsibility. Thank you.
Last edited by ahagen on Tue May 19, 2009 12:43 am, edited 1 time in total.
ahagen
<h5>
 
Posts: 19
Joined: Sat Apr 18, 2009 6:58 pm

Postby zcorpan » Mon Apr 20, 2009 6:12 am

Check out Microsoft's X-Frames-Options proposal.
zcorpan
<article>
 
Posts: 807
Joined: Tue Feb 06, 2007 8:29 pm
Location: Sweden

Postby ahagen » Sat Jun 06, 2009 12:41 am

Thanks. I have done some more research taking that as a starting point.

Michal Zalewski posted a message to the WHATWG list about a how HTML 5 might stop a CRSF attack involving an iframe. A long thread of conversation took off.

http://lists.whatwg.org/htdig.cgi/whatw ... 16284.html

Microsoft's blog post about x-frames-options detailed their approach to this threat. http://blogs.msdn.com/ie/archive/2009/0 ... enses.aspx

Sigbjørn Vik posted a long message on the subject. I found it interesting particularly because he says the solution should not involve a meta element. That would be different from Microsoft's proposal.

http://lists.whatwg.org/pipermail/whatw ... 18609.html

The framing attribute proposal, above, could solve the part of the problem involving how to completely insulate a web site from iframes. As an attribute to the HTML element, it runs counter to Microsoft's meta element proposal.

What options should there be for a web site that wants to use some iframes, but insulate itself from foreign, malicious iframes?

Would a framing="sameorigin" value be useful here? My reaction to this is not enthusiastic. HTML has created this security problem with the iframe element, and HTML should solve it. HTML should not require help from DNS, IP, HTTP, Javascript or other technology to solve the problem. A framing="sameorigin" attribute would have HTML invade territory not its own. I can't think of anything else in HTML that limits communication like this. A "sameorigin" value doesn't seem to fit with the World Wide Web.

As Tim Berners-Lee has said:

The success of the World Wide Web, itself built on the open Internet, has depended on three critical factors: 1) unlimited links from any part of the Web to any other; 2) open technical standards as the basis for continued growth of innovation applications; and 3) separation of network layers, enabling independent innovation for network transport, routing and information applications.


The various proposals leveraging HTTP or DNS in creative ways impinge on factor 1 and factor 3. Therefore, they should not be implemented.

The end result is likely to be that sites that accept input, such as through form submit buttons, will have to have a site-wide no iframes policy.
ahagen
<h5>
 
Posts: 19
Joined: Sat Apr 18, 2009 6:58 pm


Return to Feedback on the Specs

Who is online

Users browsing this forum: No registered users and 1 guest