May 31, 2014

The mobile revolution in numbers..

I'll be honest. I didn't know who or what "Mary Meeker" was until last year. The data I saw then and what I saw in her latest post is beyond fascinating. She (and her team) has put a lot of effort in collecting and analyzing interesting trends from all around the world. The end result is a deck like this one. I'm sure different people see different things in the deck... I picked the two slides below as the ones most interesting to me.

The first one is about tablet growth. If you had time to see just one slide, this one would be the one. It shows the trend around what people are buying. Its very clear that notebooks took over desktops in 2009, but what I didn't know was that tablets are exploding in a way no one anticipated.

It should be noted that average lifetime of the desktop is way longer than notebooks, and tablets/smartphones probably have the shortest lifespan. But even if you take that into account, the growth of tablets/phones is nothing short of a revolution.
Screen Shot 2014-05-31 at 9.01.01 PM

The second slide shows the distribution of time spent on various forms of information consumption devices. Its fascinating to see that in Indonesia people spend 6 hours in front of a computer of some kind. People in US on the other hand spend only 5 hours. Japan has the least.. only about 3.6 hours on some form of computer. But Germany and South Korea shocked me. Do they hate tablets ? Im puzzled as to why tablet use is so low.

Screen Shot 2014-05-31 at 8.59.26 PM

 

 

May 10, 2014

The end of spring..

IMG_20140505_195129 Took this shot a couple of weeks ago using my Nexus 5.

 

 

 

May 04, 2014

Share Quickly: Taking screenshots of a chrome tab and publishing it online

It has been a while since I got my hands dirty writing code. So here is a tool I cooked up last night.

Share Quickly is a chrome extension which takes a screenshot of the active tab Screen Shot 2014-05-04 at 9.31.41 AMand uploads it to a public website which makes screenshot sharing a one click task. I plan to make these images disappear from cache after some time to save on storage... haven't figure out how to expose that yet.

The files are hosted on Google's App engine using cloud storage and the front end for that service is on Google Compute engine. I choose to write this in PHP instead.

Interestingly the backend storage is not limited to images only. You can actually use http://sharequickly.appspot.com/ to save and share arbitrary pieces text. Note that none of this is pretty, so be warned.

Feature requests and general comments are welcome.

April 27, 2014

Chrome devices for everyone...

I compiled a list below of all the chrome devices which are sold today or were sold in the past. I did this primarily to understand the device trend.

  • Interestingly the average price for a chrome device is around $340 US on Amazon

  • 16 GB Flash is most common, but some devices have 32 GB option

  • There is only one device I know off which comes with a real harddisk, but that's not listed in this chart.

  • 2GB RAM is still popular, but more of the recent devices come with 4GB

  • Average weight is around 3 pounds

  • Average screen size is just over 12 inches for laptops

  • Average battery duration is around 7.5 hours on single charge


Note: This information was collected from various sources (including wikipedia and chromium.org and Amazon website) and may have unintentional errors.

URL: http://goo.gl/zyTBqN

The trouble with ubiquitous computing

The idea of "ubiquitous computing" most people dream about doesn't usually include the troubles of patching them every week. It doesn't even mention that there would be new bugs found daily and that most of the fixes would be available weeks if not months after they were discovered.

Windows XP

Windows XP has been in news recently because Microsoft has finally pulled support for this aging OS. 30% of all active desktops are still on XP and now we know of a new security bug, which would never get fixed for these users.

XP may eventually become the epitome of unpatched buggy software because of the visibility this issue got, but I feel this may just be the tip of the iceberg. For every XP out there, I bet there is one or more unpatched networking device just waiting for someone to exploit it, and this number is growing very fast. Some of these bugs are just that... bugs, but I suspect most of them are due to less then reputable code/design quality.  Its a wild-wild-west out there and this has to stop.

The other problem with ubiquitous computing is that the number of devices per house hold is growing rapidly and doing manual updates to every single one is getting close to impossible. We need to get to a place where users won't have to worry about manually updating the devices. The industry as a whole needs to do a better job at promoting a type of automation and testing which requires significantly higher levels of investment in resources (by manufacturer) to make it happen. Apple with its iOS update infrastructure and Google with its Chrome updates has shown that its possible to do it at scale.

So what can we as users do ? For a start we may have an obligation to ask about auto-updates when we buy new devices. For connected devices at least, shipping updates shouldn't be "optional". Vote for the right manufacturer with your wallet.

 

 

April 22, 2014

March 12, 2014

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.

Debugging

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 "trialdevices.com"
    • If the "Device policies" box is missing, it probably means that the device is not enrolled.
  • The signed in user is rkt@blogofy.com
    • 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.




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.

Debugging

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 "trialdevices.com"
    • If the "Device policies" box is missing, it probably means that the device is not enrolled.
  • The signed in user is rkt@blogofy.com
    • 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.




March 04, 2014

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:  http://cros-omahaproxy.appspot.com/. 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
      <request protocol="3.0" version="ChromeOSUpdateEngine-0.1.0.0" updaterversion="ChromeOSUpdateEngine-0.1.0.0" installsource="scheduler" ismachine="1">
          <os version="Indy" platform="Chrome OS" sp="4319.96.0_i686"></os>
          <app appid="{9D137383-EB72-4BA9-A523-91AC0853F8AD}" version="4319.96.0" track="stable-channel" lang="en-US" board="parrot-signed-mp-v3keys" hardware_class="PARROT RAIL A-D 3974" delta_okay="true" fw_version="Google_Parrot.2685.37.0" ec_version="00BE107A00" >
              <updatecheck targetversionprefix=""></updatecheck>
              <event eventtype="3" eventresult="2" previousversion=""></event>
          </app>
      </request>
    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/083519:INFO:omaha_request_action.cc(717)] Omaha request response: <?xml version="1.0" encoding="UTF-8"?><response protocol="3.0" server="prod"><daystart elapsed_days="2516" elapsed_seconds="23720"/><app appid="{9D137383-EB72-4BA9-A523-91AC0853F8AD}" status="ok"><updatecheck status="noupdate"/><event status="ok"/></app></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.




    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.

    https://youtube.googleapis.com/v/QtavfiBOv_g&source=uds

    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:  http://cros-omahaproxy.appspot.com/. 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/083519:INFO:omaha_request_action.cc(717)] 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.




      March 03, 2014

      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.

      Caveats

      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

      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.

      Caveats

      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