Google's Chrome Team Mulls Local File RestrictionsGoogle's Chrome Team Mulls Local File Restrictions

Google engineers are looking at extending Chrome's restrictions on local Web pages to further tighten the Web browser's security across a broader set of protocols.

Thomas Claburn, Editor at Large, Enterprise Mobility

December 5, 2008

2 Min Read
information logo in a gray background | information

Insider attacks tend to pose a greater computer security risk than external ones because insiders tend to be trusted with greater systems access privileges than outsiders, not to mention physical access to systems.

The situation is similar with local files on computers, which tend to be accorded greater privileges than remote files.

The engineers working on Google's Chrome browser have been wrestling with this very issue. The Chrome beta build released on Nov. 24 included a security fix for a vulnerability that allowed downloaded HTML files to read other local files and send them out to the Internet.

Part of the fix included preventing local files from connecting to the Web with an XMLHttpRequest(), a widely used means of sending text data from Web browsers to Web servers.

And Google is looking at extending this sort of restriction to further tighten browser security.

In a post on the Chromium Blog on Thursday, Google engineer Adam Barth suggested that Google is considering additional restrictions on local Web pages, such as directory-based restrictions or preventing local Web pages from sending information to the Internet across a broader set of protocols.

Different browsers approach local file rights in different ways. Microsoft Internet Explorer, for example, restricts local Web pages so they can't run JavaScript by default. However, Microsoft provides Internet Explorer users with the option to override this restriction through a yellow "infobar" that restores JavaScript functionality for local Web pages.

Google disagrees with this approach and takes a more paternalistic stance in Chrome. "We chose not to disable JavaScript with an 'infobar' override (like Internet Explorer) because most users do not understand the security implications of re-enabling JavaScript and simply re-enable it to make pages work correctly," Barth explained in his post.

One consequence of Google's disinclination to provide users with an override option in this instance is that Web developers may be inconvenienced in the future, as one of the comments on Barth's post suggests, by Chrome's potential inflexibility. Another consequence is that offline Web applications, like the open source TiddlyWiki, which relies on local HTML pages, could become less functional under a stronger set of restrictions.

Chrome, however, is a work in progress, and it remains to be seen how Google's security decisions will affect the browser's usability and security in future releases. Because Chrome comes from the open source Chromium project, those concerned about such issues may wish to participate in the development process, if they're not doing so already.

Read more about:

20082008

About the Author

Thomas Claburn

Editor at Large, Enterprise Mobility

Thomas Claburn has been writing about business and technology since 1996, for publications such as New Architect, PC Computing, information, Salon, Wired, and Ziff Davis Smart Business. Before that, he worked in film and television, having earned a not particularly useful master's degree in film production. He wrote the original treatment for 3DO's Killing Time, a short story that appeared in On Spec, and the screenplay for an independent film called The Hanged Man, which he would later direct. He's the author of a science fiction novel, Reflecting Fires, and a sadly neglected blog, Lot 49. His iPhone game, Blocfall, is available through the iTunes App Store. His wife is a talented jazz singer; he does not sing, which is for the best.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights