Chromium Blog

News and developments from the open source browser project

Extensions Status: On the Runway, Getting Ready for Take-Off

Wednesday, September 9, 2009

dev channelsample extensionsour launch processbe cautiousa few APIsdocumentationthis post about some recent changesPosted by Aaron Boodman, Software Engineer

Google

A New FTP Implementation Goes Live

Thursday, September 3, 2009

Starting in the Dev channel release 4.0.203.2, we are using our new FTP implementation by default on Windows. (It was already enabled by default on Linux and Mac.) This switchover is an important milestone in the development of our network stack. We'd like to acknowledge two Chromium contributors who made this possible.
The new FTP implementation was initially written by Ibrar Ahmed single–handedly. It was a long journey for him because he worked on it in his spare time. Ibrar has a master's degree in computer science from International Islamic University. After working as software engineer and associate architect at other companies, he recently started his own tele-medicine company. We thank Ibrar for his contribution to the Chromium network stack!
Paweł Hajdan Jr. started to work on the new FTP code in July as one of his summer intern projects at Google. Paweł added new unit tests, fixed bugs and compatibility issues, and is taking the lead in bringing the new FTP code to production quality.
Finally, we used Mozilla code for parsing and formatting FTP directory listings (ParseFTPList.cpp), which was originally written by Cyrus Patel.
In the near term, the original WinInet-based FTP implementation will still be available as an option on Windows. Specify the --wininet-ftp command-line option to enable it. (The original --new-ftp option is now obsolete and ignored.) During this period we will fix FTP bugs only in the new FTP implementation. When we're happy with the quality of the new FTP code, we will remove the original WinInet-based implementation, finally eliminating our dependency on WinInet.
Please help us achieve that goal by testing FTP with a Dev channel release and filing bug reports. Follow these guidelines when reporting bugs:

Please don't add a comment like "Here is another URL that doesn't work for me" to a bug. Always open a new bug, and give a link to another bug if you think they are similar.
Make the steps to reproduce as detailed as possible, and always include the version number of Chrome.
Check if the problem can be reproduced with --wininet-ftp on Windows and include that information in the bug report.

Posted by Wan-Teh Chang, Software Engineer

Google

Bookmarks Here, Bookmarks There, Bookmarks Everywhere

Monday, August 17, 2009

As of today's dev channel build, we're adding a brand new feature to Google Chrome: bookmark sync. Many users have several machines, one at home and one at work for example. This new feature makes it easy to keep the same set of bookmarks on all your machines, and stores them alongside your Google Docs for easy web access.
To activate this feature, launch Google Chrome with the --enable-sync command-line flag. Once you set up sync from the Tools menu, Chrome will then upload and store your bookmarks in your Google Account. Anytime you add or change a bookmark, your changes will be sent to the cloud and immediately broadcast to all other computers for which you've activated bookmark sync (using the same XMPP technology as Google Talk).
For more information on this, please see this email to chromium-dev.
Happy syncing!
Posted by Tim Steele, Software Engineer

Google

Chromium Memory Usage

Thursday, August 6, 2009

There's been some public discussion lately about memory usage in Google Chrome. We think about our memory usage quite a bit so we're happy to see other people paying attention too. This has been a topic of discussion before, but our multiprocess architecture makes measuring memory utilization difficult with the standard set of tools. The crux of the problem is that Chromium goes to great lengths to share memory between processes. However, that shared memory is difficult to account for in the Windows Task Manager. On Windows XP, using the default Task Manager measurement of memory leads to double counting. On Vista, using the default view leads to under counting.
There are a couple of more accurate ways to measure memory utilization in Chromium (or Google Chrome). The easiest is to crack open the task manager that is built into Chromium which tries to account for our memory usage more holistically. If you want even more detail, you can click on "Stats for nerds" which is a link to about:memory.

If you don't fully trust Chromium's task manager or about:memory, the gold standard for measuring memory usage is to look at the system's total commit charge before, during, and after using Chromium. It's a little tricky to get right because you'll need to shut down other services that may kick in while you are running your test. Here's the basic procedure:

Shut down any unnecessary services
Reboot your computer
Using the windows task manager, measure the Total Commit Charge of the system*
Run the application you are seeking to test, in this case, Chromium
Measure the Total Commit Charge again
Close the application
Measure the Total Commit Charge one more time
Subtract your first measurement from your second, and you should have the memory used by Chromium
To validate your test, make sure that the first and last measurement are nearly identical

*On XP, Commit Charge shows up on the bottom of the Windows Task Manager. On Vista, look at the Performance tab of the Windows Task Manager and use the "Memory" number.
For more information on memory usage and how to measure it, check out the Memory Usage Backgrounder on chromium.org.
Posted by Brian Rakowski, Product Manager

Google

Google Chrome Developer Tools for Eclipse Users

Tuesday, August 4, 2009

We recently announced the availability of developer tools for Google Chrome. We are now releasing ChromeDevTools, which enables JavaScript debugging using Eclipse.
You can set breakpoints, inspect variables and evaluate expressions all from within Eclipse. The screenshot shows the debugger in action stopped at a breakpoint.

The project is fully open sourced on a BSD-license and consists of two components, an SDK and a debugger. The SDK provides a Java API that enables communication with Google Chrome over TCP/IP. The debugger is an Eclipse plugin that uses the SDK and enables you to debug JavaScript running in Google Chrome from the Eclipse IDE.
We hope this project will help web app developers and welcome feedback as well as contributions.
Posted by Alexander Pavlov, Software Engineer

Google

Careful! Extensions Can Bite!

Wednesday, July 22, 2009

Since we began work on an extensions system for Chromium, we've received a lot of positive feedback. While the system is not yet complete, we've noticed that a lot of you have started creating and installing extensions for daily use. This is really encouraging, and it motivates us to quickly finish things up, to enable extensions by default on all Google Chrome releases.
If you're using extensions now, you should keep in mind that they are powerful software. Extensions integrate with your browser, so they can access and change everything that happens in it. For example, the same technology that enables an extension to periodically check the number of messages in your Gmail inbox could also be used to read all your personal mail and tweet it to your mom! This can happen because of malicious intent or simply because of a bug.
To help protect your experience when using extensions, we recently enabled auto-update for extensions on the dev channel release. Like Chrome's auto-update mechanism, extensions will be updated using the Omaha protocol, giving developers the ability to push out bug fixes and new features rapidly to users of their extensions. This is an important step towards a v1 release of extensions for all users, so we're pretty excited.
In addition, when we turn the extension system on, we plan to offer a gallery with ratings and comments that you can use to judge whether you want to install a particular extension. We will also have processes in place that, combined with reports from users, should help limit the number of malicious extensions that get uploaded and distributed to users. These processes will include removal of extensions that we have reason to believe are malicious. Until these things are in place and the extension system is officially launched, we recommend that you only install extensions that you built yourself.
Posted by Aaron Boodman, Software Engineer

Google

Smaller is Faster (and Safer Too)

Wednesday, July 15, 2009

We have just started using a new compression algorithm called Courgette to make Google Chrome updates small.
We have built Google Chrome to address multiple factors that affect browser security. One of the pillars of our approach is to keep the software up to date, so we push out updates to Google Chrome fairly regularly. On the stable channel these are mainly security bug fixes, but the updates are more adventurous and numerous on developer channel.
It is an anathema to us to push out a whole new 10MB update to give you a ten line security fix. We want smaller updates because it narrows the window of vulnerability. If the update is a tenth of the size, we can push ten times as many per unit of bandwidth. We have enough users that this means more users will be protected earlier. A secondary benefit is that a smaller update will work better for users who don't have great connectivity.
Rather then push put a whole new 10MB update, we send out a diff that takes the previous version of Google Chrome and generates the new version. We tried several binary diff algorithms and have been using bsdiff up until now. We are big fans of bsdiff - it is small and worked better than anything else we tried.
But bsdiff was still producing diffs that were bigger than we felt were necessary. So we wrote a new diff algorithm that knows more about the kind of data we are pushing - large files containing compiled executables. Here are the sizes for the recent 190.1->190.4 update on the developer channel:

Full update: 10,385,920 bytes
bsdiff update: 704,512 bytes
Courgette update: 78,848 bytes

The small size in combination with Google Chrome's silent update means we can update as often as necessary to keep users safe.
More information on how Courgette works can be found here.
Posted by Stephen Adams, Software Engineer

Google

Labels

$200K 1
10th birthday 4
abusive ads 1
abusive notifications 2
accessibility 3
ad blockers 1
ad blocking 2
advanced capabilities 1
android 2
anti abuse 1
anti-deception 1
background periodic sync 1
badging 1
benchmarks 1
beta 83
better ads standards 1
billing 1
birthday 4
blink 2
browser 2
browser interoperability 1
bundles 1
capabilities 6
capable web 1
cds 1
cds18 2
cds2018 1
chrome 35
chrome 81 1
chrome 83 2
chrome 84 2
chrome ads 1
chrome apps 5
Chrome dev 1
chrome dev summit 1
chrome dev summit 2018 1
chrome dev summit 2019 1
chrome developer 1
Chrome Developer Center 1
chrome developer summit 1
chrome devtools 1
Chrome extension 1
chrome extensions 3
Chrome Frame 1
Chrome lite 1
Chrome on Android 2
chrome on ios 1
Chrome on Mac 1
Chrome OS 1
chrome privacy 4
chrome releases 1
chrome security 10
chrome web store 32
chromedevtools 1
chromeframe 3
chromeos 4
chromeos.dev 1
chromium 9
cloud print 1
coalition 1
coalition for better ads 1
contact picker 1
content indexing 1
cookies 1
core web vitals 2
csrf 1
css 1
cumulative layout shift 1
custom tabs 1
dart 8
dashboard 1
Data Saver 3
Data saver desktop extension 1
day 2 1
deceptive installation 1
declarative net request api 1
design 2
developer dashboard 1
Developer Program Policy 2
developer website 1
devtools 13
digital event 1
discoverability 1
DNS-over-HTTPS 4
DoH 4
emoji 1
emscriptem 1
enterprise 1
extensions 27
Fast badging 1
faster web 1
features 1
feedback 2
field data 1
first input delay 1
Follow 1
fonts 1
form controls 1
frameworks 1
fugu 2
fund 1
funding 1
gdd 1
google earth 1
google event 1
google io 2019 1
google web developer 1
googlechrome 12
harmful ads 1
html5 11
HTTP/3 1
HTTPS 4
iframes 1
images 1
incognito 1
insecure forms 1
intent to explain 1
ios 1
ios Chrome 1
issue tracker 3
jank 1
javascript 5
lab data 1
labelling 1
largest contentful paint 1
launch 1
lazy-loading 1
lighthouse 2
linux 2
Lite Mode 2
Lite pages 1
loading interventions 1
loading optimizations 1
lock icon 1
long-tail 1
mac 1
manifest v3 2
metrics 2
microsoft edge 1
mixed forms 1
mobile 2
na 1
native client 8
native file system 1
New Features 5
notifications 1
octane 1
open web 4
origin trials 2
pagespeed insights 1
pagespeedinsights 1
passwords 1
payment handler 1
payment request 1
payments 2
performance 20
performance tools 1
permission UI 1
permissions 1
play store 1
portals 3
prefetching 1
privacy 2
privacy sandbox 4
private prefetch proxy 1
profile guided optimization 1
progressive web apps 2
Project Strobe 1
protection 1
pwa 1
QUIC 1
quieter permissions 1
releases 3
removals 1
rlz 1
root program 1
safe browsing 2
Secure DNS 2
security 36
site isolation 1
slow loading 1
sms receiver 1
spam policy 1
spdy 2
spectre 1
speed 4
ssl 2
store listing 1
strobe 2
subscription pages 1
suspicious site reporter extension 1
TCP 1
the fast and the curious 28
TLS 1
tools 1
tracing 1
transparency 1
trusted web activities 1
twa 2
user agent string 1
user data policy 1
v8 6
video 2
wasm 1
web 1
web apps 1
web assembly 2
web developers 1
web intents 1
web packaging 1
web payments 1
web platform 1
web request api 1
web vitals 1
web.dev 1
web.dev live 1
webapi 1
webassembly 1
webaudio 3
webgl 7
webkit 5
WebM 1
webmaster 1
webp 5
webrtc 6
websockets 5
webtiming 1
writable-files 1
yerba beuna center for the arts 1

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

Chromium Blog

Extensions Status: On the Runway, Getting Ready for Take-Off

A New FTP Implementation Goes Live

Bookmarks Here, Bookmarks There, Bookmarks Everywhere

Chromium Memory Usage

Google Chrome Developer Tools for Eclipse Users

Careful! Extensions Can Bite!

Smaller is Faster (and Safer Too)

Labels

Archive

Feed