Creating your first chrome app on a Chromebook

Doing development on Chromebook usually means developing online. There are a lot of sites around for that. But with the APIs getting more mature, its just a matter of time before someone builds a kick-ass Screenshot 2015-05-09 at 2.26.09 PMIDE which runs natively on Chromebooks without network connectivity.

One such tool which I’ve been exploring for a last few weeks is from Google and called “Chrome Dev Editor” If you have never built and run a chrome app or extension, I’ll show you how to do this in 3 easy steps.



Step 1

Launch the app and click on the “+” button to add a new project. Pick a project name and select “JavaScript Chrome App” in the drop down menu.Screenshot 2015-05-09 at 2.33.38 PM




Step 2

Notice how it automatically adds the minimum code required for it to run. This will be the template you are going to work with. You are almost done, but lets review the files in there to understand why they are there.Screenshot 2015-05-09 at 2.36.14 PM


  1. manifest.json – This is the most important file. Modify the app name, version number, capabilities, permissions, scripts using this file. This is the only filename which cannot be modified. Everything else can be controlled using this file.
  2. background.js – Noticed that manifest file mentions this script in it. This is the script which will start up first when the app comes up.
  3. index.html – background.js requests a window to be created using “” and this is the file it points to for the contents of the window.
  4. main.js – This script is called from index.html. It won’t start up until the window is created
  5. style.css – index.html declares this as a stylesheet
  6. assets – The icons for your project are kept in there


Step 3 

Thats it. Click on the play button on the top left corner of your editor to launch the app.Screenshot 2015-05-09 at 2.47.43 PM

Final steps – “Chrome Dev Editor” can upload and publish the app for you with a single click. Since you are on a chromebook, you should know that you can save your code on Google Drive as well, which will just sync across multiple devices automatically. And if you’d like to revision control your code, know that the editor has built in support for syncing code to git as well.

Debugging user and device policies for Chrome OS

If you have used Chrome OS in a school or an enterprise network, you would have noticed how helpful the management piece can be. Using this tool you can quickly setup and deploy policies to make things easier for your users.

This is the authoritative source of all policies available on Chrome today. Pay special attention to the “Supported on” section. If it mentions “Google Chrome OS”, then the policy is supported on devices and most of them can be set using Admin console UI.

There are essentially two different types of policies one can set on Chrome OS.

User policies

The “user policies” are those policies which can be set for an individual, regardless of which machine they are using Chrome from. A good example of a user policy is the “Screen Lock”. An enterprise admin could enforce users to have an idle screen lock enabled automatically to protect internal company data. Similarly, there may be organizations which may want to disable “Browser History” across all users.

These “User policies”  will follow the user on all platforms, which means that in addition to working on Chrome OS these policies will also take effect on Chrome for Windows and Linux if the user signs into them with the organization’s credentials.

Device policies

The “device policies” are policies applied to the machine irrespective of the user on it. For Chrome OS the policies which can be applied on the device are clearly defined in the policy list.

Examples of these policies are shown on the right. If a device is used in a lab environment which doesn’t need data persistence, its simple to set “User Data” policy to “Erase all local user info, setting… after each sign-out”. Note that these policies take effect only on devices which are enrolled into the domain.


One of the first things an admin should learn is how to debug if the policies are setup correctly. The quickest way to do this is by going to the “chrome://policy” page. If there are any policies on your device, it will show up there.

There are two boxes on the top. The first one is labeled as  “Device policies” and the second one is labeled as “User policies”. There are few different things you can quickly find out by looking at it:

  • The device is enrolled to “”
    • If the “Device policies” box is missing, it probably means that the device is not enrolled.
  • The signed in user is
    • If the “User policies” box is missing, it probably means that the user is not part of a domain pushing policies.
  • Both policies were fetched in last 6 seconds (if this is too old, try to “Reload policies” to see if it can get a fresher version)
  • Status for both is “Policy cache OK”

If you notice stale policies, you should start investigating using a tool like this to see if there are firewalls in the way which could be impacting it. If that doesn’t help, ask help from local networking admins who may know more.

Getting better over time : Troubleshooting Chrome OS updates

One of the salient features of Chrome OS is its ability to do transparent updates with little or no interaction from the user. This not only ensures the user is always protected, it also improves performance and features over time.

If you administer a fleet of chrome devices, I recommend you read this support on how to correctly configure this. It goes through all the autoupdate (AU) terminologies and suggests best practices which will help you in long run.

How to check if AU is properly working in your network

  1. I’ll strongly recommend to enable reporting using your admin console. This will allow devices to send its OS version to the reporting engine.
  2. Then use the Admin SDK APIs to generate reports for devices in your domain, grouped by major version. I recommend you write your own scripts, but you can try third party tools like these to understand what the APIs are capable of.
  3. If you have lots of different networks, try to generate separate reports for devices in different networks to see if any of them are further behind than others. 
  4. If you do notice some devices are not getting updates, look for the following failure patterns
    1. Check if the devices are being blocked from reaching update engine. White-list these domains if you need to implement ACLs.
    2. If you have enabled “scattered” updates, disable it for those users. “Scattered” updates is not good for devices which are not used every single day.
    3. If your devices never get updates, you may have to reach out to Google’s enterprise support team for deeper analysis.

    How to check what my devices should be at ?

    Google publishes all the version numbers for all of its chrome devices at this location: If you know what hardware you have, you should be able to find the latest stable, beta and dev version numbers there. Here is what it looks like for CR-48s and original Samsung chromebooks.

    Understanding AU Logs

    1. You can extract the AU logs from the device very easily using the following steps
      1. Go to chrome://net-internals#chromeos
      2. Click on “store debug logs”. This creates a compressed archive in the “Download folder”
    2. After exploding the compressed archive, look for files under “/var/log/update_engine” which has all the AU related logs
    3. Find the latest log file there and open it up in an editor
    4. The AU request would look something like this
    5. Interpretation of the request
      • Current version of the OS: 4319.96.0_i686
      • Hardware is : PARROT (find more info here)
      • Lang=”en-US” means its a US version of hardware
      • track=”stable-channel” means this is requested a stable update 
      • Lang=”en-US” means its a US version of hardware
      • track=”stable-channel” means its requesting a stable update 
    6. The AU response would look something like this
      [1121/] Omaha request response:
    7. Interpretation of response
      – status=”noupdate” means there are no updates available for this particular device
    8. If your device is getting “noupdate” even though its supposed to be on a newer version, something may be wrong. If this goes on for a few days, contact support to troubleshoot further.

    Putting Chrome OS behind SSL based webfilters

    Educational institutions, particularly the K12 are stuck between a rock and a hard place. They are always in search of ways to open up newer technologies to students, but don’t want to give up their ability to manage and filter what students can see or do. As a father of two I approve that.

    While Chrome OS does take security very seriously and tries very hard to discourage “man in the middle attack”, it does provide an industry tested feature to allow educators to filter web content for students in its recent version of Chrome OS. To understand how it works in Chrome OS, I’ll first explain how the Chrome OS works internally.

    Chrome OS devices, as most of you already know, has two distinct components. The Chrome browser is what provides most of the UI, but deep inside it also has an operating system built on top of linux. Among other things that OS is responsible for, auto-updates and security are two of the most important. 

    The web filtering feature which Chrome OS provides for our enterprise and schools users allows all “user session” traffic from the browser to be intercepted, but doesn’t allow any of the system requests to be intercepted in the same way.

    Network setup

    To get a chromebook to work correctly in an environment with webfilter, its important to let webfilter know which hosts chromebook would connect to for which it won’t tolerate SSL inspection. Google has published a set of domain names here which can be used for this purpose.

    Note that whitelisting by IP addresses (netblocks) is not good enough. The IP addresses mapped to these hosts keep changing and the only reliable way to whitelist them is by whitelisting the domain names as it is. Most webfilters (including some transparent webfilters) support this and if you are not sure, contact your proxy/webfilter provider to understand how to do it.

    Quick test

    Once the network is setup, import your custom root CA cert into the browser using certificate

    manager under “Authorities” and make sure you enable “Trust this certificate for identifying websites.” Then go to any website which you think should be intercepted and try to see if browser threw any error. Even if it didn’t throw an error, check at the certificate details and confirm that it was signed by your webfilter.

    Broader test

    Once the tests confirm that everything is working as expected, its time to do a broader test using management console. To prepare for this test, I would recommend picking a small set of users who are are ok with brief interruption (in case something goes wrong) and are willing to provide you with detailed feedback to help you debug the issue.

    In your admin panel, go to Chrome’s “Advance settings” section and then “Networks”. Pick the OU where all of your test users are and then click on “Manage Certificates” button on the

    top right corner. 

    Upload your certificate and check the box for “Use the certificate as an HTTPS certificate authority”. 

    The example on the right shows my setup where I’m using zscaler’s cloud based webfilter.

    The final test to make sure this is good, would be to move these users to a network where there is no direct network access.  Have them be forced to go through the proxy/webfilter and see if anything breaks. 

    Let this configuration stay like this for a few days/weeks and collect feedback on whether users noticed any other side effects. For example make sure devices are getting updates (which is critical) and that user users can be added any time.

    Complete the transition

    Once everything has been tested, apply the certificate to more and more OUs until the transition is complete.


    There are few caveats you should watch out for
    1. Even though this policy is being applied as a user policy, it will only work on devices which are enrolled to the same domain. This is one of the most common reasons for the feature not working.  This also means that if the device was unenrolled, it may cause network connectivity failures.
    2. Since this is a user policy, other users using the same device will not get this feature automatically. Each user has to be moved into an OU where this certificate is installed.

    More info

    Chrome device fleet reporting using APIs

    Chrome Devices have been a huge success in places like schools where students and teachers want the mobility and price point of a tablet but usability of a laptop. Like everything else Google focuses on scale and part of the Chrome Device offering to enterprises and schools are the tools around the devices to manage the fleet.
    Chrome Device management can be centralized which allows admins not only manage apps on the device, they can also push complex network and system settings with a touch of a few key strokes. And that works the same way for a customer with 10 devices and one with 20000.

    Recently Google released a new batch of APIs called the Admin SDK which includes some new APIs to discover and manage devices in the fleet. Using these APIs, admins can not only get a list of the active devices they have, they can also find out if the devices are having update issues. As an example of how to use this API, I’ve published a sample script called “ChromeOSDeviceStats” which I wrote for my own domain. This could be used to quickly get high level stats of devices in the domain, when they were enrolled, what version they are on, and what Orgs are they part off.

    The script could be further adapted to automatically send email reports like these when certain conditions are met. For example, if a school is interested in knowing about all recent “enrollments”, they could enhance this script to send that report.

    Total devices : 31
    Total active : 31
    Total in Dev mode : 1
    Total devices enrolled in last 2 days : 0
    Total devices enrolled in last 7 days : 1
    Total devices enrolled in last 1 month : 2
    Total devices enrolled in last 1 year : 6
    Distribution of devices across models: 
                              Alex : 5 
                              Google_Stumpy : 2 
                              Google_Link : 6 
                              Google_Snow : 1 
                              Google_Lumpy : 8 
    Distribution of devices across versions: 
                              24 : 1 
                              25 : 5 
                              26 : 2 
                              27 : 5 
                              21 : 6 
                              23 : 3 
    Distribution of devices across orgUnits: 
                              /Eng : 3 
                              /hack : 1 
                              / : 31 

    Openvpn in EC2 for Chromebooks : Part 2

    [ Update: take a look at this write up as well ]

    ChromeOS has a minimalistic design does a fairly good job at hiding the complex internals of the operating system. But deep inside it still runs linux and has a full blown openvpn client. In this post I’ll show you how to use “ONC” (Open Network Configuration) format to configure OpenVPN client inside ChromeOS. This file is very similar to an .ovpn file.

    The core scripts which did the cert conversion and created the sample ONC file was contributed by Ralph by reading the ONC documentations by himself. If there is a bleeding-edge user of chromebook.. he is the best example I can think off.

    These scripts are now published on github and here is a step by step guide of how to use it.

    Step 1: Launch a new amazon instance ( Based on Amazon Linux AMI )

    • Pick defaults for everything ( Use t1.micro for the cheapest instance )
    • If you don’t already have a keypair, create one yourself and upload your public key to amazon

    Step 2: Update security group you used. Allow UDP:1194 incoming.

    • Open 1194 UDP incoming 
    • Open 22 TCP incoming

    Step 3: Find the IP address of the new instance.

    • Find the “Public DNS” address. This is the address we will SSH to.

    Step 4: SSH into the server

    • If you only have a chromebook, use this extension to initiate ssh
    • Upload both private and public key to this extension.
    • Fill in the hostname and username (ec2-user)

    Step 5: Run the quick setup script

    curl >; 
    chmod +x;
    sudo ./
    • These three lines downloads the script and launches the setup script.
    • Remember to put in your email address instead of the one listed here
    • This step may take two to three minutes before it prompts you for anything

    Step 6: Select default values

    • When it does prompt you, just choose the defaults
    • If it asks you y/n questions… just select ‘y’ 
    • It will ask you for password a few times… just press enter (which sets no password on the keys)
    • Remember this is proof of concept and that you should customize it before you can use it for real stuff

    Step 7: Wait for the email. Download the ONC file attached.

    Step 8: Upload ONC file into chromebook

    • Make sure it says “ONC file successfully parsed” after the import.
    • [Advanced users: /var/logs/ui/ui.LATEST will have parse errors if you want to investigate a failed import]

    Step 9: Try to connect to the openvpn server

    • Just click on “Connect”

    Step 10: Connected

    • At this point you should see a solid (should not be blinking) VPN signal on the wifi icon. 

    Step 11: Verify if its traffic is being routed through amazon

    Patches: Pull or Push ?

    Most people prefer to disagree with the masses on whether they like sunny side up or scrambled eggs. And the form of getting patches is no different. If you ask an IT administrator (which is the person applying patches in most corporate organizations) they will tell you horror stories of how patches can go wrong and would be happy to give you examples of why every patch needs to be individually tested before deploying. 
    But my dad, for example, doesn’t care about patches, and while he won’t go out of the way to install a patch, he may be ok with patches being pushed to him automatically.  

    This debate  reminds me of another interesting debate in the Web-Operations world about “continuous deployment“. In that case the debate was whether applications should be deployed in scheduled releases (for example every quarter) or whether it should be released as things gets developed and pushed.

    If you think about this a little more it would be very clear that the developers who build the patches are the ones who first need to be ready to do “continuous deployment”. The confidence of every patch is directly proportional to the robustness of test infrastructure… and the unit-tests and integration-tests which are associated with it. For products where there are test-gaps it makes sense for IT administrators to constantly monitor and test every single patch before its deployed. 

    So that brings us back to “Pull or Push“. Because of the increase in number of recent attacks, I am now very conscious about what products I use on a daily basis and try very hard to pick those which can auto-update without nagging me. And they are usually the ones which have robust test infrastructure to allow “continuous deployment”… which in turn means that they are usually the ones which have better test coverage of their products and are the ones which can quickly patch something bad very quickly with confidence (like a 0-day).

    I do understand that mistakes in ‘Push’ based patches can be very expensive, but they are still more secure for end users when it comes to privacy and security.

    The reason why I was thinking about this is that Adobe released a patch today.. hope you noticed. I just wish it would auto-update devices where have it installed… its easy to forget to update devices, and in general not doing silent auto-update makes me worried that they are not super confident about their test infrastructure.