Posts tagged ‘apps’

December 16, 2011

Google Cloud Print one year later

A few days ago, Google Cloud Print was rolled out to more users, with new features. One of the more interesting is the ability to embed a cloud print button on one’s website. Read on to learn the reason this cloud print button is important.

Reverse colors in 2011

Google Cloud Print's new logo

The Google Cloud Print landing page now offers complete instructions for registering a printer that is not connected to a PC or other computer. There is also a detailed user tutorial, which wasn’t available a year ago.

The full list of operating systems, device types and browsers from which one can access Cloud Print is extensive.  This seems to be the easiest way to decide whether Cloud Print will work with a user’s current “configuration”:

On any web page, if you see a “Print” button with the Google Cloud Print logo, you can print without leaving your browser.

As I wrote this article, I found a few user tips. Profiles and Cloud Print for Any Page has good instructions for embedding the Cloud Print button, and for using it with multiple Google profiles in Chrome 16.

Variety of services

Google Cloud Print offers versatility

Implementation and strategy thoughts

The level of detail required to specify device (mobile/ tablet/ PC/ Mac/ Chromebook), operating system (Android/ iOS/ Windows/ Mac/ Chrome OS) and print app makes one think about the project management complexity. I can only imagine the hardware and data integration challenges!

It is worth noting that Google chose to expend this effort on printing, which is one of the least interesting computing services, for marketing and developers alike. This is a reality, despite the importance of print functionality to those who need it.

In Beta

A certain problem URL, described in my  Cloud Print post last year, still returns the same 400 error. I don’t fault Google for that. Google Cloud Print remains is in beta. It is more prudent to keep the beta designation until a product is ready. Avoid the sort of headaches Google recently had with the still-buggy Gmail for Apple iPhone mess a few weeks ago.

September 15, 2011

Google Apps discontinues support for old web browsers

As of August 1, 2011, Google Apps will support modern browsers ONLY

Users of Firefox 3.5, IE7 and Safari 3 (and their predecessors) take note! Gmail, Google Calendar, Talk, Docs and Sites will not work correctly on these older versions. Eventually they will stop working at all if you do not upgrade your browser to a more up to date version.

What is a modern browser according to Google Apps?

For Google Apps, “modern browser” has two parts. “Modern” refers to current and prior major releases. Support will be maintained on a rolling basis going forward.

Opera browser

The second part is “browser”, specifically, one of the following:

  • Chrome
  • Firefox
  • Internet Explorer
  • Safari

Opera is conspicuously absent, which may irk some European users.

Web browser market share

The following is a chart of desktop browser usage rates. Data was provided by StatCounter.

Desktop browser usage, Oct 2010 - Sep 2011

Safari is twice as popular as Opera, though a 4.26% market share is small compared to the top three. Safari is part of the larger Apple product line. Maybe that is the justification for Google’s decision to include Safari but not Opera.

Conjecture

The modern browser support announcement was specifically for Google Apps, though it may include all Google accounts at some point. I am uncertain. Perhaps Opera is not as often used by Google Apps and enterprise customers as Safari?

March 7, 2011

Authentication and Authorization

Access control has two components, referred to collectively as auth.

Third-party applications often require limited access to a user’s Google Account… all requests for access must be approved by the account holder.

via Authentication and Authorization for Google APIs.

Authentication services

Authentication refers to the process of allowing users to sign in to websites. In the context of this blog, it also refers to sign in to applications using a Google Account, or an OpenID 2.0 based protocol. When Google authenticates a user’s account, it returns a user ID to the web application. This allows user information to be stored and collected. Open ID also allows access to certain user account information, with the user’s approval.

Authorization services

OAuth Logo

OAuth

Authorization is often confused (by me, maybe others) with authentication. Authorization lets a user authorize access by applications to specific data associated with the user’s Google account.

OAuth 2.0 Protocol

The OAuth 2.0 open-standard protocol allows users to authorize access to their data, after successful authentication. Google supports the OAuth 2.0 protocol with bearer tokens for web (and installed) applications. Regular Google account data and Google Apps account data are accessible with OAuth 2.0. OAuth 2.0 relies on SSL for security instead of direct cryptographic signing that would otherwise be necessary for such access.

Note that OAuth 2.0 has not been finalized, according to IETF (version 13). Google cautions that it’s OAuth 2.0 support is in an early preview and may change at any time, or as the final specifications evolve. Google considers OAuth experimental.  However, “experimental” does not have the same tentative connotation associated with Google Labs projects.

OAuth 1.0 Protocol

There is also an OAuth 1.0 for web applications. OAuth 1.0 can be used for authorization to user data by all Google API’s. Google continues to support OAuth 1.0.*

* OAuth 1.0 is sometimes referred to in documentation without version number, only as OAuth.

Other protocols

The OpenID-OAuth hybrid protocol provides authentication and authorization in a single-step process. Open ID provides authentication services, and OAuth provides authorization to Google APIs.

AuthSub API is Google’s proprietary protocol. It is mostly used for Google APIs. AuthSub is similar to OAuth. OAuth is more generally applicable and Google recommends that developers use OAuth instead of AuthSub API.

Registration

Registering a web application is optional. It is also free and straightforward. Web applications that are not registered with Google can still use OAuth 1.0 or AuthSub interfaces. However, registered web applications are recognized by Google and receive a correspondingly higher level of trust designation. This is communicated to users on the login screen.

Example of access request screen for OAuth or AuthSub web app

Sample Google access request screen for unregistered web application

Summary

These are the three levels of registration:

  1. Unregistered These applications conduct transactions at a lower security level.  Google flags the user login page with a precautionary message.  See image above with yellow-shaded advisory.
  2. Registered and recognized but not configured for secure requests
  3. Registered with enhanced security These applications have a security certificate and can use secure tokens.
Follow

Get every new post delivered to your Inbox.

Join 527 other followers