Peter Beverloo

Even ignoring the google.com thing, estimates are they're spending at least $500 million a year on Chrome marketing for ads on other sites, various bundling deals (including pre-installs on new PCs and auto-installs with other software), etc.

As far as people on Chrome go, you're right that back in 2008 they likely did not have 1000+ people on it. The best data I can find for mid-2008 on the Internet says about 50 in mid-2008.

Looking for newer data, according to the last several updates on http://peter.sh/ at this point there are about 100 daily WebKit commits (not all by Google, obviously) and about 120 daily Chromium commits. That's not counting the parts of Chrome that aren't WebKit or Chromium. What fraction of the WebKit commits are from Google is an interesting question; as of early 2010 according to http://neugierig.org/software/chromium/notes/2010/02/webkit-commits.html it was around 40-45% and growing rapidly.

Now going from "number of commits" to "number of engineers" is hard. For comparison, as of today according to http://oduinn.com/blog/2012/09/04/infrastructure-load-for-august-2012/ Mozilla has about 200 commits per day, but about half of those are to the automated testing repository, not to the main code. So that's about 100 commits per day. Mozilla right now has around 700 employees, I believe. So if you assume similar commit patterns (which is an assumption, granted), Google certainly has 1000+ people on Chrome now.

But I'm also not sure you…

The truth is the reason they pointed to SQLite is because the proposed API was so obscenely complicated that it was easier to point to a reference implementation than to accurately specify a standard, which points to a rather fundamental problem with the proposed standard: SQL is too damn complicated, and embedding it in browsers is a bad idea.

For a web standard to succeed, you need either Mozilla or Microsoft support, preferably both. They have 75% of the browser market between them, so without either any standard is dead on arrival. Chrome, Safari and Opera individually do not have enough marketshare to be a significant influence on the takeup of web standards and still follow in the footsteps of the others. Incidentally, Chrome does support IndexedDB (http://peter.sh/2010/10/indexeddb-milestone-8-es5-strict-mode-and-progress-on-print-preview/).

Mozilla have made it clear they are supporting IndexedDB and not WebSQL. Microsoft have publicly posted remarks of support of IndexedDB on the IE blog (http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-the-html5-community.aspx) and Pablo Castro, an architect involved with web standards has publicly favoured IndexedDB over WebSQL (http://blogs.msdn.com/b/pablo/archive/2010/01/04/html5-does-databases.aspx). It's not always easy to judge the inner workings of Microsoft, but I think it's a pretty strong hint as to what they are working on.

The IndexedDB spec seems relatively well-specified to me, and much more detailed…

You should never use same profile for your VPN. You can create seperate profiles to use one for direct access and one only for your VPN connection. I would even recommend using different browser profiles for specific tasks. Like "shopping" for example.

Create Firefox Profile:
firefox -ProfileManager

Use Firefox Profile:
firefox --no-remote -private -P profile-name

Create & Use Chrome Profile:
chromium --incognito --user-data-dir=location/profile-name

On top of seperate browser profiles (at least in your VPN profiles), you need to do browser hardening and use something like uBlock/uMatrix to block everything by default. [1] I do not recommend using regular Google Chrome for VPN at all. Use something like Ungoogled-Chrome. [2] or similar security browser instead.

Also it is highly recommented if you use Linux/Unix OS, to properly firewall your VPN connection. So for example if your VPN connection suddenly stops working, it will not leak out any data. There is many tutorials on how to do this. I'm sure it is possible to do something similar on Windows too.

[1] firefox hardening; https://chrisx.xyz/blog/yet-another-firefox-hardening-guide/

[2] https://github.com/Eloston/ungoogled-chromium

[3] chrome hardening; https://peter.sh/experiments/chromium-command-line-switches/

Websockets are only useful to talk to a server. At last year google io presentation, they said people wanting to play an html5 game or do a voip call shouldn't have to use a server, especially if they are in the same room. They should be able to connect directly to each other.

More info here:

http://peter.sh/2011/03/css-quotes-mock-ups-of-the-html5-date-picker-and-the-p2p-api/

http://src.chromium.org/viewvc/chrome?view=rev&revision=76604

http://src.chromium.org/viewvc/chrome?view=rev&revision=76731

http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#peer-to-peer-connections

You don't need to support CoffeeScript natively. The answer is simple and is called source mapping: the output code carries comments that map each line to a line in the source file. This will also work for LESS and any other transpilers.

Work is underway since August to implement it in WebKit (http://peter.sh/2012/01/css-selector-profiler-source-mapping-and-software-rendering/) and Gecko (https://wiki.mozilla.org/DevTools/Features/SourceMap - the intern has gone back to school, really?)

It's apparently a feature:

"An issue that often pops up for mobile browsers is that text on the website may be too small to read properly. Where the Android Browser employs a text reflow algorithm to clarify the situation, Chrome for Android features a technique which we’ve called Font Boosting. It uses an algorithm to increase font sizes when necessary, aiming to make the text readable regardless of the zoom level."

(from http://peter.sh/2012/02/bringing-google-chrome-to-android)