Chromium Blog
News and developments from the open source browser project
Cloud Coding and Beyond: Web Development Apps in the Chrome Web Store
2011年6月29日水曜日
When we talk
Chromebooks
with our developer friends, a common reaction we get is “I can see why my [insert-relative-here] would use it, but I need my PC for coding”. Over the last few years, browser-based coding has grown from a research topic to a viable practice. You can already find many development apps on the
Chrome Web Store
today. Some are conventional code editors and IDEs, built right into the browser. Others are oriented more around prototyping and design. There are also many tools for project management.
First up, IDEs. You can now code, debug, and deploy real programs from the browser. A popular example at Google IO was
Cloud9
, an IDE for JavaScript, Python, PHP, and Ruby. Cloud9 uses the HTML5
FileSystem
capability and AppCache to sync files, so you can even code offline. There are many other IDEs in the web store too, such as
Kodingen
,
Codey
,
Akshell
,
eXo Cloud IDE
, and
PHPAnywhere
.
It’s not all about coding though. There are also apps focusing on web design, for people who want to make a web page without coding or perhaps experiment with a few concepts early on. Being able to edit and design web pages inside the tool that will display them is a very powerful concept.
BuildorLite
and
BuildorPro
let you construct a web page via a graphical user interface, and publish it straight on their servers.
Handcraft
and
Mockingbird
are two apps aimed at design and prototyping. And if you want a scratchpad to try a few coding experiments, check out
JSFiddle
.
Launching software isn’t just about designing and coding your apps; it’s also about managing the entire workflow, from planning release schedules to triaging bug reports. One example is
GitHub Issues
, providing a quick, app-like, way to track project issues. Another is
Launchlist Pro
, a checklist you can use to launch your website.
Chrome aims to bring simplicity, speed, and security to all users, and that includes developers. Being cloud-based means these tools are always up to date, and running inside the browser’s sandbox minimises the security risk to your machine. There’s no complicated install process and the only dependency is Chrome itself, which is automatically kept up to date. Just install the app and get coding.
We’re especially excited about what this means for new developers, as programming tools have never been more accessible to everyone. So whether you’re a seasoned veteran or just looking to get started, visit the
Chrome Web Store
today and build something awesome in your browser!
Posted by Michael Mahemoff and Paul Kinlan, Chrome Developer Relations
Introducing Non-Admin Chrome Frame
2011年6月20日月曜日
We
released
Google Chrome Frame in September 2009 to expand the reach of modern web technologies and help developers take advantage of HTML5's capabilities. Since then, we've seen great adoption of the plug-in by end users and developers. Even more exciting, we’ve heard from developers that Google Chrome Frame is enabling them to create legacy-free apps that are easier to build, maintain, and optimize.
However, there was one remaining obstacle to making Chrome Frame accessible to users of older browsers - users needed to have administrative privileges on their machines to install Chrome Frame. At this year's Google I/O we
announced
this obstacle has finally been removed.
Non-Admin Chrome Frame runs a helper process at startup to assist with loading the Chrome Frame plug-in into Internet Explorer. The helper process is designed to consume almost no system resources while running. Once installed, non-admin users will have the same no-friction experience that admin users of Chrome Frame have today.
You can try it yourself by installing the new non-admin version of Chrome Frame
here
. This is now available in our developer channel and is coming to stable channel very soon.
For more technical details, please see the
Chrome Frame FAQ
. Please share your feedback in our
discussion group
and if you encounter any bugs while using Chrome Frame, please file them on Chromium's
issue tracker
. We’ll be working hard to bring Non-Admin Chrome Frame up to the beta and stable channels over the coming weeks. You can help us move this up to stable as quickly as possible by trying out the current release and sending us your feedback!
Posted by Robert Shield, Software Engineer
Testing Chromium: AddressSanitizer, a fast memory error detector.
2011年6月15日水曜日
Valgrind
is a great tool for detecting memory errors. We are running many Chromium tests under Valgrind and it has helped us find
hundreds of significant bugs
. However, when we run binaries under Valgrind, testing becomes at least 10 times slower. This huge slowdown costs us more than just machine time; our trybots and buildbots can’t provide fast feedback and some tests fail due to timeouts.
A month ago we released
AddressSanitizer
(aka ASan), a new testing tool. ASan consists of two parts:
A compiler which performs instrumentation - currently we use a modified
LLVM
/
Clang
and we're trying to contribute our code to the core LLVM package.
A run-time library that replaces
malloc()
,
free()
and friends.
The custom
malloc()
allocates more bytes than requested and “poisons” the redzones around the region returned to the caller. The custom
free()
“poisons” the entire region and puts it into quarantine for some time. The instrumented code produced by the compiler checks if the address being accessed is poisoned and if so, reports an error. The compiler also inserts poisoned redzones between objects on stack to catch stack buffer overrun/underrun.
ASan helps us find a subset of bugs that are detectable by Valgrind like heap buffer overrun/underrun (out-of-bounds access) and “Use after free.” It can also detect bugs that Valgrind can not find, such as stack buffer overrun/underrun. Last month alone, ASan helped us find more than 20 bugs in Chromium including some that could have potentially led to security vulnerabilities.
What makes ASan even more powerful than other comparable tools is its speed. On
SPEC CPU2006
benchmarks the
average slowdown
is about 2x. On Chromium’s “browser_tests”, the slowdown is about 20%. If you are curious to learn why ASan is faster than comparable tools read this
article
.
Today ASan works only on Linux (x86 and x86_64) and ChromiumOS, but we're planning to port it to other platforms in the near future. In the coming months we also plan to setup various ASan buildbots and trybots for Chromium.
The
AddressSanitizer home page
has the instructions for running it with your favorite project outside of Chromium. If you are working on Chromium, refer to this
page
for instructions. If you have any questions or suggestions, feel free to contact address-sanitizer@googlegroups.com
Posted by Kostya Serebryany, Software Engineer
New Chromium security features, June 2011
2011年6月14日火曜日
When the Google Chrome Security Team isn’t busy giving prompt attention to finding and fixing bugs, we’re always looking for new security features to add and hardening tweaks to apply. There are some changes worth highlighting in our current and near-future Chromium versions:
Chromium 11: strong random numbers for the web
We added a new Javascript API for getting access to a good source of system entropy from a web page. The new API is
window.crypto.getRandomValues
. Web pages should not currently be using Math.random for anything sensitive. Instead of making a round-trip to the server to generate strong random numbers, web sites can now generate strong random numbers entirely on the client.
Chromium 12: user-specified HSTS preloads and certificate pins
Advanced users can enable stronger security for some web sites by visiting the network internals page: chrome://net-internals/#hsts
You can now force HTTPS for any domain you want, and even “pin” that domain so that only a more trusted subset of CAs are permitted to identify that domain.
It’s an exciting feature but we’d like to warn that it’s easy to break things! We recommend that only experts experiment with net internals settings
.
Chromium 13: blocking HTTP auth for subresource loads
There’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img> tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance.
To resolve this, we’ve blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. We also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy applications which require the old behavior.
Chromium 13: Content-Security-Policy support
We added an initial implementation of
Content Security Policy
, which was first introduced in Firefox 4. You can use the X-WebKit-CSP header to experiment with our implementation. We’re working with Mozilla and others through the W3C to finish the standard. Once that’s done, we’ll remove support for the X-WebKit-CSP header and add support for the final header name. Please feel encouraged to kick the tires and let us know how we can improve this feature!
Chromium 13: built-in certificate pinning and HSTS
We’re experimenting with ways to improve the security of HTTPS. One of the sites we’re collaborating with to try new security measures is Gmail.
As of Chromium 13, all connections to Gmail will be over HTTPS. This includes the initial navigation even if the user types “gmail.com” or “mail.google.com” into the URL bar without an https:// prefix, which defends against
sslstrip-type
attacks.
The same HSTS technology also prevents users from clicking through SSL warnings for things such as a self-signed certificate. These attacks have been seen in the wild, and users have been known to fall for such attacks. Now there’s a mechanism to prevent them from doing so on sensitive domains.
In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against
recent incidents
where a CA has its authority abused, and generally protects against the proliferation of signing authority.
Chromium 13: defenses for self-XSS via javascript URLs
Working together with Facebook and other browser vendors, we’re trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they are tricked into pasting javascript: URLs into the omnibox.
This is an interesting area because it’s hard to know what detail of instruction it is possible to trick a user into following. It is also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).
Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents for both Chrome and ChromeOS. 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 of the Google Chrome Security Team. With thanks to Adam Barth, Adam Langley, Cris Neckar and Tom Sepez for implementing the above features.
Prerendering in Chrome
2011年6月14日火曜日
Google.com's new Instant Pages feature,
announced earlier today
, makes some sites appear to load almost instantly when you click on them from the search results page. The feature is enabled by prerendering, a technology that we built into the upcoming version of Chrome, currently in the Dev channel. You can see Instant Pages in action in this video:
What is prerendering? Sometimes a site may be able to predict with reasonable accuracy which link the user is most likely to click on next--for example, the 'next page' link in a multi-page news article. In those cases, it would be faster and better for the user if the browser could get a head start loading the next page so that when the user clicks the page is already well on its way to being loaded. That's the fundamental idea behind prerendering. The browser fetches all of the sub-resources and does all of the work necessary to display the page. In many cases, the site simply seems to load instantly when the user clicks.
Although Google.com is the most high profile site to use prerendering, it's a technology that is available to any site. Triggering prerendering well, however, is challenging to do correctly and will only be useful to a handful of sites that have a high degree of certainty of where their users will click next. Triggering prerendering for the wrong site could lead to the link the user
did click on
loading more slowly.
The vast majority of sites will automatically work correctly when a third party like Google.com asks Chrome to prerender them. If you're interested in testing how your page behaves when being prerendered you can use
this sample page
. If you want your page to behave differently, you can use Chrome's new experimental page visibility API to detect prerendering.
The
page visibility API
- which is in the early stages of standardization in the webperf working group - can help developers understand the visibility status of their page: whether it's in a foreground tab, a background tab, or being prerendered. This is still an experimental implementation and it may change or even be removed in the future, which is why for the time being we've prefixed the property names with "webkit.” Although the page visibility API is useful for detecting prerendering, it also has many other applications--for example, allowing a site to pause expensive physics calculations when the page isn't visible.
To learn more about the page visibility API and prerendering, check out the
Using the Page Visibility API
and
Web Developers' Guide to Prerendering in Chrome
articles.
Posted by Alex Komoroske
ラベル
$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
23
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
Archive
2024
12月
8月
6月
5月
4月
3月
2月
2023
11月
10月
9月
8月
6月
5月
4月
2月
2022
12月
9月
8月
6月
5月
4月
3月
2月
1月
2021
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2020
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2019
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2013
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2012
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2011
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2010
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2009
12月
11月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2008
12月
11月
10月
9月
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
