157 captures
29 Apr 2017 - 10 Apr 2026
Jun
JUL
Aug
25
2017
2018
2019
success
fail
About this capture
COLLECTED BY
Collection:
Twitter Outlinks
This is a Collection of URLs (and Outlinked URLs) extracted from a random feed of 1% of all Tweets.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20180725084420/https://blog.chromium.org/2011/03/
Chromium Blog
News and developments from the open source browser project
UA String Changes Coming In Chrome 11
Thursday, March 31, 2011
When websites want to know what browser you're using, they often examine the "user agent", or "UA" string. This is a string that provides information about what browser and operating system you're using. Beginning with Chrome 11, we're making some changes to our UA string, which can affect website compatibility.
For reference, here is what the current (Chrome 10) UA string looks like on a few different platforms:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
And in comparison, here are the UA strings for Chrome 11 on the same platforms:
Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24
Let's break down the differences in detail. We've made four changes, two of which are Windows-specific:
On Windows, the initial "
Windows
;
" platform identifier has been removed. This was redundant with the subsequent OS version identifier, and makes us more compatible with Internet Explorer, whose UA string doesn't have this initial token.
The "
U
" SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are "
U
" (for "USA" 128-bit encryption support), "
I
" (for "International" 40-bit encryption support), and "
N
" (for "None", no encryption support). These days, every browser ships with 128-bit SSL support everywhere, so it's not necessary to advertise it.
On 64-bit versions of Windows, tokens have been added after the OS version. For 32-bit Chrome builds running on 64-bit Windows, we've added "
WOW64
". (
WOW64
" stands for "Windows 32-bit On Windows 64-bit" and is the name Microsoft gives its 32-bit compatibility subsystem.) In our source code, we've also added identifiers for 64-bit native builds, specifically "
Win64
; x64
" for x64-based processors and "
Win64; IA64
" for Itanium systems. (However, we don't currently ship such builds, or have any immediate plans to.) These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses.
The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP
Accept-Language
header instead, which can supply multiple locales. In fact, websites that relied on the UA string locale probably had some very unhappy visitors, because Chrome always had a bug where the UA string locale was reported as "
en-US
", regardless of the user's desired locale(s)!
One more question remains: why are we making these changes now? Because websites tend to use common pieces of code to check all browsers' UA strings, it's important for browsers to stay in sync with each other. Mozilla has made the above changes in Firefox 4 (and more; see
http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/
for details), which was released recently, and we wanted to change Chrome to match as soon as possible, to minimize the disruption to web authors.
As the changes above have trickled into our Canary and Dev builds, we've already found and fixed some problems in Google's UA string parsing libraries that have caused compatibility issues with Google sites (though not all of the affected sites have updated yet). If you see problems on other sites you think might be caused by the new UA string, try running Chrome with an alternate UA string using the
--user-agent="<Put older UA string here>"
command line flag. (You can double-check the UA string Chrome sends to websites by typing
about:
in your address bar and hitting <enter>.) If that fixes the problem, please let us know by filing a bug in our bug tracker at
http://crbug.com/
.
Posted by Peter Kasting, Software Engineer
Getting smoother animated web content while reducing CPU usage
Tuesday, March 29, 2011
The web is becoming more interactive and animated day by day. Many web pages use the
Canvas
element to draw rich 2D content via the
2D context
or modify DOM elements on the fly. These pages generally use the
setTimeout
or
setInterval
APIs to receive frequent callbacks, allowing them to redraw their content periodically, or use DHTML to move elements on the page. As 3D content drawn using the
WebGL API
increases in popularity, it will use similar animation techniques.
Unfortunately, setTimeout and setInterval don’t take into consideration whether the destination element, or even the tab that contains it, is actually visible. So, pages with high-frequency timers will consume CPU resources even if the tab is in the background. On laptops, netbooks, and mobile devices of all kinds, reducing CPU consumption is essential in order to prolong battery life. Additionally, excess CPU consumption by background tabs reduces the smoothness of animations on the foreground tab.
Excessive CPU consumption by timers on web pages is not a theoretical problem. We have measured web sites containing mostly static text content firing timers at a rate of over two hundred per second.
Mozilla recently introduced the experimental
mozRequestAnimationFrame API
, which has different semantics than setTimeout or setInterval. Instead of the developer specifying a target frame rate, the browser runs the given callback when it is ready to produce the next animated frame. The callbacks are specifically known to be relevant to the animation of the page, and don’t run too often.
An experimental webkitRequestAnimationFrame API has been upstreamed to WebKit, and is available starting in Chrome 10. This is essentially the same as mozRequestAnimationFrame, but supports an optional second argument which is the element that the callback intends to animate. This additional information will allow the browser to avoid animating elements that are not visible to the user. See this
bug report
for more details. Chrome doesn’t run requestAnimationFrame callbacks for background tabs at all, which dramatically reduces CPU consumption when multiple tabs containing animated content are in the same window.
The
WebGL samples
project contains a three dimensional graphics library that has been modified to use requestAnimationFrame rather than setTimeout or setInterval. Take a look at this library for a good example of how to convert existing timeout based animations to the new style, while preserving compatibility with browsers that don’t support requestAnimationFrame.
In the forthcoming Chrome 11 release, we plan to reduce CPU consumption even for pages that are using setTimeout and setInterval. For background tabs, we intend to run each independent timer no more than once per second. This change has already been implemented in the Chrome dev channel and canary builds. While there may be some compatibility impact for web pages, we believe that improving the user experience for the foreground tab, and increasing battery life, are problems needing to be addressed. Please
send us your comments
on this planned change.
Posted by Kenneth Russell, Software Engineer
A Mini-Newsletter From Your Google Chrome Security Team
Tuesday, March 8, 2011
We’re always working hard to enhance the Chrome browser with bug fixes, new defenses and new features. The
release of Chrome 10
is no different, and there are some items worth highlighting:
Chrome 10: Flash sandboxing
With Chrome 10, our first cut of the previously announced
Flash sandboxing initiative
is now enabled by default for the Windows platform on Vista and newer. Additionally, because we automatically update Flash to the latest and most secure version, this should provide useful defense in depth.
Chrome 10: Out-of-date plug-in warnings
As we
previously mentioned
, we believe that some of the most significant opportunities to increase user security revolve around plugins. We’ve made a number of improvements in this area, including actively encouraging users to update their plug-ins to the most secure version. Chrome now detects when a plug-in is out of date and blocks it with a simple infobar. This infobar helps guide the user towards updating their plug-in with the latest security fixes.
Chrome 10: Plug-in blocking enhancements
Some of our more advanced users prefer fine-grained control over which plug-ins they wish to run -- which can have security and privacy benefits. Chrome has long had a feature which blocks plug-ins by default (Wrench menu -> Preferences -> Under the hood -> Content Settings -> Plug-ins). We’ve improved this feature by adding a context menu to the blocked plug-in placeholder. This menu lets users control which plug-ins do and do not run. Using a context menu helps prevent clickjacking attacks that try to bypass the block. Plug-in placeholders can also be hidden (for example, if they are floating over and obscuring real content), and the actual plug-in that wishes to run is made apparent.
Chromium Security Rewards program still going strong
We mentioned in passing in the
9.0.597.107 release notes
that our
rewards program
has passed $100,000 of rewards. We’d like to re-iterate our thanks to all the named researchers in our
Hall of Fame
. We’re continually delighted with the stream of interesting and clever bugs that we receive, so it will be exciting to see what the rest of 2011 brings. Remember, we love giving out money!
Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at
our job posting
?
Posted by Chris Evans, Google Chrome Security Team, Bernhard Bauer, Software Engineer, and Carlos Pizano, Software Engineer
GPU acceleration + old drivers = :(
Tuesday, March 1, 2011
Over the last few months, we’ve made a lot of progress using graphics hardware (commonly referred to as the GPU) to make Chrome faster and more power-efficient. However, as we’ve rolled out features like WebGL and GPU-accelerated HTML5 video, we noticed a troubling trend: users with old graphics drivers experienced a significant increase in crashes when using these features. Because stability is one of Google Chrome’s core principles, we’ve recently become stricter about requiring up-to-date drivers and graphics hardware by adding ranges of old drivers to Google Chrome’s software rendering list.
Developers should continue to ensure that the software-rendered version of their sites work properly for users without GPU-accelerated browsers, so we expect most content to continue to function normally for Google Chrome users with out-of-date drivers -- albeit, without the same performance you might expect from Chrome. WebGL content on out-of-date systems will currently not display, but we are working to provide a software path so that these systems can run basic 3D applications.
As our ability to determine whether a machine can reliably use GPU features improves, we hope to extend hardware acceleration support to more and more users. Here are some steps you can take to maximize the chances that Chrome will run fully hardware-accelerated on your computer:
Use the latest major version of your operating system (such as Windows 7 or Mac OS 10.6)
Install
all system updates and driver updates
that are available for your system.
Posted by Henry Bridge, Product Manager
Labels
accessibility
1
benchmarks
1
beta
8
blink
1
chrome apps
3
Chrome Frame
1
chrome web store
26
chromeframe
3
chromeos
3
chromium
3
cloud print
1
dart
8
devtools
11
extensions
23
gdd
1
googlechrome
12
html5
11
incognito
1
javascript
3
linux
2
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
2
releases
2
rlz
1
security
30
spdy
2
ssl
2
v8
5
web intents
1
webaudio
3
webgl
7
webkit
5
webp
5
webrtc
4
websockets
5
webtiming
1
Archive
2018
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Google
on
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
