Throwing some more info here, this is the NaCl whitelist, looks like it was originally added Feb last year [1]. There's a discussion on Chromium Code Reviews here [2], and an issue on the project itself here [3]

The original commit includes the comment 'We should remove this code when PNaCl ships' which got removed somewhere along the way.

[1] http://src.chromium.org/viewvc/chrome/trunk/src/chrome/rende...

[2] https://codereview.chromium.org/9368046

[3] https://code.google.com/p/chromium/issues/detail?id=113668

There was a brief discussion about this code on Twitter a few weeks back and I asked for extra clarification from engineering. Erik Kay explained on that bug ticket [3] a bit more:

"We don't enable NaCl on the web at large because we don't want to see a particular instruction set baked into the web. We enable it for apps that are in the Chrome Web Store (even hosted apps which are in the web) because it's a place where over time we can get developers to migrate to PNaCl. For this whitelist, we have similar controls to what we have on the Chrome Web Store, and our goal is to eventually remove the need for it altogether."

Does anybody know why (variations on copies of) leokun's comment are automatically marked as dead?

The comment seems perfectly valid so I can't figure out why that would happen...

The shortened link seems to do it.

I believe it means his account has been banned, for some reason.

I would be curious to find out who removed that comment 'We should remove this code when PNaCl ships'

Looks like it was done in this commit: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/rende...

Why would they check if Adblock is installed or not?

https://code.google.com/p/chromium/codesearch#chromium/src/c...

  bool ChromeContentRendererClient::IsAdblockInstalled() {
    return g_current_client->extension_dispatcher_->extensions()->Contains(
        "gighmmpiobklfepjocnamgkkbiglidom");
  }

  bool ChromeContentRendererClient::IsAdblockPlusInstalled() {
    return g_current_client->extension_dispatcher_->extensions()->Contains(
        "cfhdojbkjhnklbpkdaibdccddilifddb");
  }

They were apparently trying to understand performance issues with adblock, so they can fix them...

  // TODO(mpcomplete): remove the extension-related histograms after we collect
  // enough data. http://crbug.com/100411
  
  const bool use_adblock_histogram =
      ChromeContentRendererClient::IsAdblockInstalled();

https://code.google.com/p/chromium/issues/detail?id=100411

Very uncool. Google's association with Chromium is why I still recommend FireFox over Chromium, even though they are both open source. Now that I see this, I'm glad I do.

I mean. Google is so large it will always be making mistakes like this. A lot of people look at Google as a whole like it is the greatest set of technical minds in any room on the planet. Sure they have lots of smart people etc.etc but with >10,000 engineers it's impossible.

Also, with >10,000 engineers (even assuming they are the best 10k in the world), mistakes will be made which is why vulnerabilities exist in the real world.

I guess what I'm trying to say is. Don't act surprised. We've seen it before and we will see it again.

I agree, but lets also be sure they don't get a pass just because they are large. In Google's case, being a behemoth corporation is in itself a business risk that they need to manage, and one way to motivate them self-police is by holding them accountable for bad decisions.

What whitelist?

JS Execution? No popup blocking? Something else?

Did a bit of digging - it lets NACL apps downloaded from those whitelisted Google apis have access to "dev interfaces". Brief search shows that these dev interfaces would have the ability to access the user's PC outside of the Chrome sandbox.

In effect, this gives Google remote code execution rights from their domains on anybody running Chromium.

> Brief search shows that these dev interfaces would have the ability to access the user's PC outside of the Chrome sandbox.

Aren't they just the APIs in https://code.google.com/p/chromium/codesearch#chromium/src/p...? By the looks of it they're just things that aren't ready for primetime, not things that are special dev-only debug tools or whatever.

Well there is

https://code.google.com/p/chromium/codesearch#chromium/src/p...

and

https://src.chromium.org/chrome/trunk/src/ppapi/c/extensions...

I haven't looked deeply, but both seem to allow for access outside the sandbox. Maybe a chromium committer could give more detail on the safety of the dev interfaces. They are blocked from public usage for a reason though.

They don't enable access outside the sandbox and should be pretty safe.

PPB_Testing_Dev is a set of helpers for writing tests: querying status of the plugin; running nested message loop to wait for results of async operations; simulate input events which are received only by the plugin itself.

PPB_Ext_Events_Dev is for registering/unregistering events provided by Chrome apps apis (http://developer.chrome.com/apps/api_index.html). It will only be accessible when the NaCl module is included in a Chrome app. This interface hasn't been implemented yet.

which parts of the above code/api allow access outside of the sandbox?

Eh, using structs for namespacing in C. I hadn't seen that in a while.

> In effect, this gives Google remote code execution rights from their domains on anybody running Chromium.

If you're running Chrome, you've already given them code execution rights – the only thing this does is make it slightly harder to detect.

With DNS hijack, everyone can remote execute.

No, HTTPS only. So probably only Google or the NSA, I guess.

Well, it's not like you can't buy a valid certificate for google.com from a turkish CA that is trusted by all browsers... This has happened before, the only question is how much you're willing to pay.

There's also hardcoded HSTS pining for Google certificates, preventing this.

How does HSTS deal with expired certs?

Firefox is more performant on my Ubuntu box than Chromium, even for things like Gmail and Google Docs.

To me, it looks like they are allowing https @ plus.google.com, plus.sandbox.google.com, ssl.gstatic.com, talk.google.com, talkgadget.google.com, and ssl.gstatic.com to use WebUIs (most likely Dart web apps) [1] and NaCl [2].

  // Temporarily allow these whitelisted apps and WebUIs to use NaCl.

> Google Native Client (NaCl) is a sandboxing technology for running a subset of Intel x86 or ARM native code in a sandbox. It is proposed for safely running native code from a web browser, allowing web-based applications to run at near-native speeds,[2] which aligns well with Google's plans with Chrome OS. It may also be used for securing browser plugins, and in the future parts of other applications or full applications. [2]

[1] https://www.dartlang.org/articles/web-ui/

[2] http://en.wikipedia.org/wiki/Google_Native_Client

Just a guess but there's a comment:

// Temporarily allow these whitelisted apps and WebUIs to use NaCl.

And it's in a function called "IsNaClAllowed"

I am not 100% familiar with NaCL but it this a download / install whitelist then for NaCL programs?

[EDIT] answered by https://news.ycombinator.com/item?id=6723930

Looks like it's a whitelist for Native Client.

      // Temporarily allow these whitelisted apps and WebUIs to use NaCl.

For NaCl, presumably.

The function name is "bool ChromeContentRendererClient::IsNaClAllowed", so I guess that.

Apparently not patched out in Debian either (according to apt-get source chromium-browser). I've got a bit of a mongrel system, so I can't rebuild from source -- but it looks like it should be easy to patch that line to read:

      bool is_whitelisted_url = false;

(If one should be so inclined).

Code never lies, comments sometimes do.

        — Ron Jeffries

From the source: Allow Chrome Web Store extensions, built-in extensions and extensions under development (for calls from whitelisted apps amongst others)

That, and give Google special treatment.

An important comment in the code

    // Whitelisted apps must be served over https.

Security issues aside, it still reeks bad taste though.

Google is saying that everyone on the internet has to dump plugins, dump Flash and create pure HTML solutions. HTML should be good enough for everyone! Everyone except themselves, apparently.

They can just jump to native code on their websites whenever they like. So much for their credibility when it comes to web-standards, eh?

Isn't it entirely possible they want to dog food their own new code via Chrome before they open up the API to the world?

If they were genuinely interested in dogfooding their own stuff to ensure it works properly, they should also be dogfooding the process of white-listing plugins and websites, not to mention handling graceful fallback when the user cant or wont do that.

That's a big part of getting the end-user experience to work well and can't just be "tacked on" later.

You're just adding things that probably aren't within the scope of the project.

For instance graceful fallback is a 'nice to have' but not necessary. If you deny flash or javascript, essentially most sites simply break. I imagine a native client plugin would have the same results if you don't enable it.

As for white listing, why can't it simply be handled with the same dialogs used for whitelisting all the other existing extensions per site?

As of yesterday(?), everyone is allowed to use PNaCl.

So it's a... Backdoor

A lot of things are hodecoded into chrome/chromeium. For example the font types and sizes of the tab area. Their browser is practically unusable on a 4k monitor at full resolution.

be evil