Enable nexe support for extensions installed via enterprise policy!

[Nate Tinkler]

As a developer, I'm trying to understand the public statement that you have made with regards to limiting nexe support to the Chrome Web store only.  To quote:

>>NaCl modules are only allowed for applications distributed through the Chrome Web Store (CWS) The CWS requirement is in place to prevent the proliferation of Native Client executables (nexes) compiled for specific architecures (e.g., x86-32, x86-64, or ARM).

Source: https://developer.chrome.com/native-client/devguide/distributing#non-portable-native-client

I can vaguely understand this concern with regards to webapps, and I can certainly respect the work taken to provide PNaCl as a portable alternative to architecture specific modules. However I cannot understand why this limitation exists with respect to extensions installed via enterprise policy.  By default, those machines are managed by the organization, they are of a known architecture, and the extension is never made public, so there is no proliferation.

That said, I suspect I would be ok with the limitation to using PNaCl, except for two problems:

1: About 1 in every 100 test machines fails to complete the translation step on extension install.

2: Translation takes too long.

To give more detail about both of the above...

Number 1: The mechanism chrome uses to detect a PNaCl pexe is present, install the PNaCl component (at the time of writing this, pnacl - Version: 0.1.0.14206) and then properly translate the pexe does not seem reliable enough for enterprise deployment.  Testing this process on about 200 machines, we saw failures on 3.  With a planned enterprise rollout to several hundred thousand users, a fail rate of 1.5% is not ok.  When a failure was encountered, in 1 case I was able to complete the process successfully after restarting the machine.  The other 2 machines both required admin support, where a user must open "chrome://components", find the entry for the PNaCl component, and manually hit the update button.  Then restarting the machine resolved the issue. 

Number 2: Translation takes too long.  On a modern developer machine running 8gbs of ram and a core i7, translation of our PNaCl component takes roughly 60 seconds.  This is right around the limit of what is acceptable, it's not great, but by itself it wouldn't really cause serious problems.  When run on a standard user machine with 2gbs of ram, and a core 2 duo or less, translation routinely takes longer than 10 minutes.  The worst case I have recorded so far was 48 minutes to complete translation (excluding wait times for translations that failed to complete after 5+ hours, which I have recorded above as failures).  The uncompressed size of our PNaCl component is roughly 6mb.  I can begin stripping components out of the pexe to reduce translation time, but that sort defeats the purpose of providing the tool in the first place. 

So given the above details, I'm just looking for information about why nexe support is disabled when the extension comes from enterprise policy (the official replacement for the CWS for deploying private enterprise extensions).  If the decision was an internal policy decision, I'm looking for something better than the bs quote above to take to my boss.  If the decision wasn't policy related and was instead related to deadlines or just not considering this use-case, then I'd like to offer support in implementing this feature.  

Finally, if I'm mistaken and there is some way to enable nexe support for extensions installed via enterprise policy (other than setting the "enable-nacl" experimental flag manually for every user...) then please, by all means, tell me I'm an idiot and point me in the right direction to find documentation on that process!

  

[Nick Bray]

Just to ask the easy question: have you tried installing running a nexe from an extension installed via an enterprise policy and did it not work?  To the best of my knowledge, the implementation just cares that the nexe is coming from an installed CRX.  I believe the text you are quoting is equating CWS with a CRX and does not take enterprise into account.  There may be some deeper technical or policy reason enterprise is disabled that I am not aware of, but I thought I'd cover the easy case before digging.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

[Elijah Taylor]

I actually think it does require install from the webstore[1].  There is a special "from_webstore" field for installed extensions that I think only gets set when the extension is truly from the webstore.  I don't know enough about enterprise policies to know if those policy extensions are maybe served from the webstore, in which case they may get this annotation.  My guess is that this is not set though.

[1] - https://code.google.com/p/chromium/codesearch#chromium/src/chrome/renderer/chrome_content_renderer_client.cc&q=from_webstore&sq=package:chromium&type=cs&l=1078

[Nate Tinkler]

Easy questions are never a bad thing :D

But, yes, unfortunately I have.  I've tried the following methods of installation to determine when the nexe is loaded, and when it is not.

Loading unpacked extensions from folder

Works as expected.

Side-loading (drag n drop) from crx

does not work by default, can be enabled with about:flags switch

chrome://flags/#enable-nacl

Extension can be installed before setting flag, but browser must be completely restarted after setting flag before it is applied. 

Enterprise policy

does not work by default, can be enabled with about:flags switch

chrome://flags/#enable-nacl

Enabling Nacl component can be done by editing chrome "local state" file while all chrome processes are stopped.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.

[Nate Tinkler]

So looking through the link to the code you posted, It looks like there's a flag on the extension object called "WAS_INSTALLED_BY_CUSTODIAN", Do either of you know whether this gets set as the result of installing an extension via enterprise policy (it's the closest looking flag I found while just skimming), and if it does, would simply adding a check for that extension flag in ChromeContentRendererClient::IsNaClAllowed work?

[Elijah Taylor]

I don't think the CUSTODIAN flag is the appropriate thing here.  I don't know about it, but would guess it has to do with supervised users: https://support.google.com/chrome/answer/3463947?hl=en

Where are your extensions hosted, on your own servers?  As a workaround, if you actually had them install from the Chrome Web Store, that might set the appropriate from_webstore flag when they are installed.  You can keep your extensions unlisted or publish only to trusted testers if it's meant to not be public.

I don't think it's unreasonable to allow non-webstore policy installed extensions to use NaCl, I'm assuming it was an oversight instead of a deliberate decision.  Can someone from the NaCl team chime in on this aspect?

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.

[Nick Bray]

+meacer

Did you intend to not allow .nexes in enterprise-installed CRXes with this CL?

https://chromiumcodereview.appspot.com/12512003

[Nate Tinkler]

Yeah, that documentation seems to fit the custodian flag, so you're right, that seems to be supervised users rather than enterprise policy.

We likely will host on the Chrome Web Store for the majority of our customers (eventually), however we have a few large enterprise customers that have their own enterprise policy deployment process in place, and refuse to move to the web store (which in this case, I can understand.  They have legal requirements to verify code related to crypto, and they expect their deliverable to be a simple CRX that they can unpackage, verify, re-package and then release internally).  

So while it's not ideal, it's probably not something we can change in the near future.  Personally, I'd love it if we could convince them the store is the way to go, sadly it's like fighting an elephant with a toothpick, they have all the leverage.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.

[Nick Bray]

Sounds like this was purely an oversight.  (Although we should probably talk to whomever is in charge of enterprise features to make sure there's not a trick we're missing.)

Is anyone interested in owning the fix?

On Tue, Mar 24, 2015 at 1:12 PM, Mustafa Emre Acer <mea...@google.com> wrote:

(sending again from @google.com as my previous message didn't go through)

On Tue, Mar 24, 2015 at 1:08 PM, Mustafa Emre Acer <mea...@chromium.org> wrote:

AFAIR It was a blanket block, I didn't particularly think about enterprise installed extensions at that time. Allowing that case sounds ok to me.

[Elijah Taylor]

Hi Nate,

It's been a while, but finally we landed support for this: https://chromium.googlesource.com/chromium/src.git/+/dea8f652a25ffa68e366529697caee1a5617cf23

It should be in Chrome 45+

-Elijah

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.

To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.

[Nate Tinkler]

Hey guys, thanks so much for the help!

I appreciate it.

-Nate

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.

To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.