Google's Chrome Team Mulls Local File Restrictions - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Mobile // Mobile Applications
04:56 PM
Connect Directly

Google'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.

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
11 Things IT Professionals Wish They Knew Earlier in Their Careers
Lisa Morgan, Freelance Writer,  4/6/2021
Time to Shift Your Job Search Out of Neutral
Jessica Davis, Senior Editor, Enterprise Apps,  3/31/2021
Does Identity Hinder Hybrid-Cloud and Multi-Cloud Adoption?
Joao-Pierre S. Ruth, Senior Writer,  4/1/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Successful Strategies for Digital Transformation
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll