Chromium Blog: July 2011
COLLECTED BY
Organization:
Internet Archive
These crawls are part of an effort to archive pages as they are created and archive the pages that they refer to. That way, as the pages that are referenced are changed or taken from the web, a link to the version that was live when the page was written will be preserved.
Then the Internet Archive hopes that references to these archived pages will be put in place of a link that would be otherwise be broken, or a companion link to allow people to see what was originally intended by a page's authors.
The goal is to
fix all broken links on the web .
Crawls of supported "No More 404" sites.
A daily crawl of more than 200,000 home pages of news sites, including the pages linked from those home pages. Site list provided by
The GDELT Project
The Wayback Machine - https://web.archive.org/web/20181021050112/https://blog.chromium.org/2011/07/
Extensions are powerful pieces of software in modern browsers, and as such, you should help ensure that your extensions are not susceptible to security exploits. If an attacker manages to exploit a vulnerability in an extension, it’s serious business because they may gain access to the same privileges that the extension has.built-in protections to make it more difficult to introduce exploitable code, but certain coding patterns can still open up the risk of exploits like a cross-site scripting (XSS) attack. Many of these mistakes are common to web programming in general, so it wouldn’t be a bad idea to check out one of the many good articles on the net about XSS bugs. Here are some of our recommendations for writing healthier extensions.Minimize your permissions (*/*) permissions for hosts if you only need to access a couple, and don’t copy and paste your manifest from example code blindly. Review your manifest to make sure you’re only declaring what you need. This applies to permissions like tabs, history, cookies, etc. in addition to host permissions. For example, if all you’re using is chrome.tabs.create , you don’t actually need the tabs permission.Use content_security_policy in your manifest Content Security Policy in extensions via the content_security_policy manifest field. This allows you to control where scripts can be executed, and it can be used to help reduce your exposure to cross-site scripting vulnerabilities. For example, to specify that your extension loads resources only from its own package, use the following policy:"content_security_policy": "default-src 'self'" Don’t use <script src> with an HTTP URL Don’t use eval() function displayAddress(address) { // address was detected and grabbed from the current page '); dosomethingevil(); Don’t use innerHTML or document.write() function displayAddress(address) { // address was detected and grabbed from the current page <script>dosomethingevil();</script> Beware external content few more examples of the issues discussed here in our extension docs. We hope these recommendations help you create better and safer extensions for everyone.Posted by Erik Kay, Software Engineer
In Chrome 13, we added some new capabilities to content scripts and proxy management.sample extension which demonstrates the old way a content script could make a cross domain request. As you can see, the extension required a background page to route the cross-origin calls through a chrome.extension.onRequest listener. Using the new content script cross-origin capabilities, we were able to successfully rewrite the extension to completely eliminate the background page requirement. This reduces the memory required to run the extension, and reduces code complexity as well. This also means that Greasemonkey scripts that use GM_xmlhttpRequest - such as the classic Book Burro - will now work in Chrome.match patterns work. Until this release you could specify a matches array for your content script - the URLs over which it should operate. In Chrome 13 you can now also specify an exclude_matches array, where you can indicate the pages in which your content scripts should not work. This should allow more precise targeting of your content script.@run-at command for imported Greasemonkey scripts, so you can control when your script is loaded in the same way you’ve been able to do for content scripts. Running scripts at different points in a page's lifecycle can enable additional functionality. For example, we've written a script which runs at "document-start" and lists all of the HTTP resources included in the current page.Proxy Extension API , you can now configure proxy settings by choosing from several options including auto detection, the host OS’s system default, PAC scripts or fixed ProxyRules .Proxy Anywhere and Proxy SwitchyPlus . Posted by Tessa MacDuff and Mihai Parparita, Software Engineers
A few weeks ago, we became aware of a security issue with WebGL: shaders could be used to indirectly deduce the contents of textures uploaded to the GPU. As a result, the WebGL specification was updated to be more restrictive when it comes to using cross-domain images and videos as WebGL textures.CORS .CORS support for MediaElements has also been fully implemented in WebKit by setting a new .crossOrigin attribute. This means that sophisticated applications that were using cross-origin textures before, can continue to do so, assuming the hosting image server grants the necessary cross-origin permission using CORS. If you want to enable CORS request on an image, all you have to do is add one line of code:var img = document.createElement('img'); ctx.drawImage() ) flips the origin-clean flag to false. Attempting to read back the pixels using ctx.toDataURL() or ctx.getImageData() throws a SECURITY_ERR. This is to prevent information leakage. However, when .crossOrigin is set (and the remote server supports CORS), the read is possible. For example:var img = document.createElement('img');var url = canvas.toDataURL(); // Read succeeds, canvas won't be dirty. use of CORS on their images.Chrome dev channel .Posted by Eric Bidelman, Developer Advocate
