Google "Less Secure Apps" Explained

Google has a security setting in your account for enabling or disabling "Less Secure Apps".  What is a "Less Secure App" exactly doing or not doing to make it less secure?  Google's answer is relatively vague, and mentions "modern security standards".  You can read Google's description here.

Less Secure Apps:

Google considers apps that directly use your account email address and password less secure.  Many older apps request your login details in order to access Google's services on your behalf.  This is not ideal from a security perspective for several reasons:

1. You must trust that app to not be dishonest.
2. You are also trusting these apps to adequately protect the password information from being compromised by 3rd parties. For example, storing the password un-encrypted in the registry or a file on your hard drive would leave it open to easily being compromised should someone or some malicious software gain access to your computer.
3. Finally, you are also giving that app access to all of your Google account's features, including e-mail, contacts, calendar, drive, etc.  If that app only needs to access your contacts, giving it permission to access all your other services opens up permissions more than necessary.

There is a better method for authentication available...

More Secure Apps:

Google supports an improved method to give apps access to your Google services with a protocol called OAuth2.  Using this authentication method allows apps to access only the Google services within your account that they need.  OAuth2 also eliminates the need for the user to provide the app with an account password.  Instead you get an access code, specific to that app, your account, and needed permissions. The details of how you obtain this access code vary depending on the platform of the app.  The basic idea is that the app directs you to a Google website where you log into your Google account and view the permission request from this app.  The permission request lists all the specific services this app will be able to access.  If you approve, you will be given an access code to enter into the app.  (Some apps can accept this access code automatically, behind the scenes, once you approve the request.)

OAuth2 eliminates the need for users to enter their Google account password.  It also solves the issue of only providing permissions to the necessary services, instead of your whole account.  Also, the access code can only be used by the requesting app.  To use the access code the app must also provide a clientID and client secret, which are registered with Google by the app developer.  Therefore, even if the access code were compromised the malicious party couldn't use it unless it knew the clientID and client secret.  If the malicious party had the access code, clientID, and client secret it could use this, but then it would at least be restricted to the services approved.  Access codes can also be easily revoked when desired.

Case Study: Google Ranking Results During HTTP to HTTPS Transition

I recently decided to transition several websites for my company from HTTP to HTTPS.  My main concern was to not cause any detrimental effects on my ranking in Google's search results.  I used the data available to me in Google Webmaster to monitor the impressions and clicks my sites were getting during this transition. My hope was to not see any drop-off in site traffic.  I transitioned my lowest traffic sites first and watched them to confirm nothing bad happened, before I transitioned my higher traffic sites.  I've plotted the results for 4 sites that I transitioned.

My highest traffic site is fundmanagersoftware.com, and that was transitioned last, on Sep 4, 2014.  The yellow "Change Date" point graphically shows the date where the site was changed from HTTP to HTTPS. I'm plotting both the "HTTP Impressions", as well as the "HTTPS Impressions", plus the sum of these two as "Combined Impressions".  You can see shortly after the change date, the HTTP impressions drop off quickly, while the HTTPS impressions take over.  Their combined sum stays relatively consistent with impressions before the HTTPS transition.  The "Combined Clicks" are also shown, and you can see these also stay relatively consistent with pre-transition values.

My next highest traffic site is beiley.com.  This site was transitioned on Aug 31, 2014.  Again you can see how quickly the impressions transition from HTTP to HTTPS after the change date.  For some unknown reason there happened to be a spike in impressions shortly after the transition, but the clicks remained relatively consistent with pre-transition values.

The site automsw.com has less traffic, and was transitioned on Aug 21, 2014.  Looking at the combined impressions and combined clicks the data looks relatively consistent with pre-transition values.  It does look like there might have been a slight drop in impressions after the conversion, but it is hard to say, as there started to be some lower impression counts right before the transition as well.

My lowest traffic site is email-announcer.com, and it was also transitioned to HTTPS on August 21, 2014. This site's results also indicate impressions/clicks remained relatively constant through and after the transition.

Conclusions:

From examining the impressions and clicks on these 4 sites during the transition from HTTP to HTTPS I have concluded there were no detrimental or positive effects from the transition.  Any slight changes are most likely due to random variations, and not the HTTPS transition.  I'm glad I made the change.

Poor Bank Online Security Practices

You would think of all the businesses that would work hard on getting security correct, banks would be at the top of the list.  As of right now, Bank Of America's homepage has both secure and insecure content. This same page asks the user for their Online ID (not the password though).  How is the average user supposed to know for sure that this Online ID can't be observed by anyone else if all the content is not secure?  Here is a screen shot of Bank Of America's homepage right now as viewed in Chrome:

Measured Power Usage of Various Light Bulbs

Power Measurements:
In our house we have migrated from incandescent to CFLs, and now partly to LEDs.  I was curious to verify if the power consumption of these newer light bulbs was really as good as advertised.  I borrowed a Kill A Watt meter from our local electric company (SRP) through the library.  I measured a variety of different bulbs in a regular lamp (non-dimmable).  Here are the results:

I was pleasantly surprised to see all of the measurements were less than the advertised wattage.  It was also interesting to see that CFLs have the lowest power factor, and on average the LED bulbs had a better power factor.  As expected the incandescent have the best, as they're pretty much just a resistor.  Our electric company meters Watt-Hours, and bills us by the same, so the lower power factor numbers don't really matter to my electric bill.

LED versus CFL:
LEDs have recently come down in price so they are more cost effective.  I've started only buying LEDs for replacements instead of CFLs.  We never had great luck with CFLs.  My biggest complaint was that they didn't last nearly as long as advertised on the package.  The other problem with CFLs is their turn-on delay, and warm-up time.  Lastly the fact that they contain mercury isn't attractive.  The LEDs I've purchased so far have a much better turn-on time, and don't require time to warm up to their full brightness like CFLs do.  They also do not contain any mercury.  The jury is still out on their longevity, but I'm hopeful they will perform better here too.

First Test Post

Just testing a new personal blog.  Go here instead if you're looking for Beiley Software.

Mark