Tech Roots » Mobile http://blogs.ancestry.com/techroots Ancestry.com Tech Roots Blogs Tue, 22 Apr 2014 23:35:02 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.2 Why Have a Browser Support Policy?http://blogs.ancestry.com/techroots/browser-support-policy/ http://blogs.ancestry.com/techroots/browser-support-policy/#comments Mon, 06 Jan 2014 21:21:44 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=1649 With the growing number of web browsers and mobile devices being used to access content on the internet, it has become increasingly important for organizations to solidify a browser/device support policy. Internally, this type of policy can help with the development and testing of new features and pages by focusing time, effort, and resources on… Read more

The post Why Have a Browser Support Policy? appeared first on Tech Roots.

]]>
With the growing number of web browsers and mobile devices being used to access content on the internet, it has become increasingly important for organizations to solidify a browser/device support policy. Internally, this type of policy can help with the development and testing of new features and pages by focusing time, effort, and resources on a select set of browsers and devices. Externally, users will have a clear understanding of expected functionality and the adjustments they can make to ensure the best experience possible when using the site.

With approximately 2.7 million subscribers and hundreds of thousands of unique visitors a day all using their preferred browsers and devices to access our site, Ancestry needed to define where our teams should focus and prioritize their time. To accomplish this, a committee of development, product, and QA representatives was organized and tasked to develop a browser support policy that accurately reflected the latest industry standards, as well as our particular users’ preferences.

As a result, the following tier system is based not only on the latest global web browser and mobile device usage statistics, but also specific analytics and percentages for our own unique users.

 

browser

Tier 1 – Both Functionality and Visual Design
Browsers accounting for at least 10% or more of unique visitors for two consecutive months will be fully supported. This includes basic functionality as well as proper visual design behavior. These browsers will be tested during regular regression and when pages are changed. All bugs will also be triaged and fixed in the indicated timeframe. Browsers in this category will continue to be fully supported until they account for less than 10% of visitors for two consecutive months. Those browsers will then receive Tier 2 support (until/unless their usage drops below 5% for two consecutive months).

Tier 2 – Functionality
Browsers accounting for 5-10% of unique visitors will receive Tier 2 support. This means visual elements on the site need not appear perfectly, but all features must be functional. Basic testing is required, and major bugs will be triaged and fixed in the indicated timeframe. A browser whose traffic falls below 5% for two consecutive months will receive Tier 3 support.

Tier 3 – No Support
Browsers accounting for less than 5% of unique visitors in two consecutive months will not be individually supported. This group will be separated into two groups: uncommon browsers, and out of date browsers. Since the majority of uncommon browsers tend to follow web standards, they will generally receive an adequate experience on Ancestry.com and therefore shouldn’t be prompted to download a supported browser. Visitors using out of date browsers who can upgrade to a supported browser, however, should be prompted to do so.

As for mobile devices, we have designed a majority of our pages to be responsive to the width of the browser. Pages that have been converted receive Tier 1 support, with all other pages receiving Tier 2 support.

The hope is that with this policy in place, it will save time and effort internally, while providing customers and users with the best experience possible on the browsers and devices they use the most.

The post Why Have a Browser Support Policy? appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/browser-support-policy/feed/ 0
Exposing APIs to Your Clientshttp://blogs.ancestry.com/techroots/exposing-apis-to-your-clients/ http://blogs.ancestry.com/techroots/exposing-apis-to-your-clients/#comments Wed, 27 Nov 2013 18:55:55 +0000 Seng Lin Shee http://blogs.ancestry.com/techroots/?p=1583 So, you want to share your super awesome system with the world. You have it all figured out. You implemented it as a web service, and you have exposed the necessary APIs as HTTP endpoints. Your hope is that people will start to leverage those endpoints and begin to build awe-inspiring apps that will further… Read more

The post Exposing APIs to Your Clients appeared first on Tech Roots.

]]>
So, you want to share your super awesome system with the world. You have it all figured out. You implemented it as a web service, and you have exposed the necessary APIs as HTTP endpoints. Your hope is that people will start to leverage those endpoints and begin to build awe-inspiring apps that will further increase the value of your web service API.

Of course, there are decisions you need to make, such as protocols to use, security concerns, documentations, tutorials, support and the whole shebang.

There is one contentious decision that you as a developer have to make: Should a client library be provided for developers to use your web service? Or is exposing an endpoint sufficient for developers to start building applications?

We can go on for hours debating the pros and cons for providing and omitting client libraries. The argument is very similar to Amazon proving that REST doesn’t matter for Cloud APIs. There are standards that we can follow and that are backed by an army of proponents. However, as with most of my blog articles, I came to the conclusion that the decision depends on

  1. How the APIs are used.
  2. How you want to govern the APIs.
  3. Who uses it?

In support of Client Libraries

Popular APIs include Google, Flickr, YouTube, Twitter and Amazon as they provide developer SDKs that make it really easy to implement these APIs in application across a myriad of platforms and languages. The motivation for this is to actually provide a lower learning curve to developers to get onboard the API platform.  Evidently, the underlying API calls which have been abstracted are pretty complex.

Another argument for client libraries would be to provide a control point; a programmable interface that provides a logical abstraction to represent the actions that will be performed. A client library acts as a proxy between the application and the actual endpoint. By mediating traffic between the application and the endpoint, the proxy is able to address cross cutting concerns such as analytics collection, traffic control and even access rights. As Sam Ramji pointed out, API clients are necessary for the sustained growth of web and cloud API usage.

Without a client library or an SDK, a developer is required to provide extra logic to communicate with a service endpoint. There is no forcing function for a standard or common way to access the endpoint (unless documented explicitly). This becomes extremely critical in an enterprise that is comprised of a multitude of web services that as a whole represent the entire company asset. The absence of a framework allows developers the freedom to implement his or her own way of addressing the same concerns; leading to a plethora of different coding styles. The existence of an SDK allows the service to establish a common programming pattern and model that are part of the nature and identity of the service.

Argument against Client Libraries

If different systems require a different client library or SDK, then a  client that uses a multitude of services would eventually be overwhelmed with the sheer number of different models and programming patterns (e.g. imagine forcing a developer to use Unity just for instantiating an object, when the developer has no interest in using IoC pattern).

If an API endpoint is simple, with straightforward message formats, a common tool/library could be built to provide a communication mechanism for accessing and parsing messages to and from API endpoints.

Also, SDKs and client libraries are usually maintained by the endpoint developers. Resources have to be dedicated to support the development toolset (aka SDKs/client libraries) every time a new iteration of service is rolled out. The team needs to evaluate if such a commitment can be maintained over a long period of time. Furthermore, this maintenance may include updating SDKs/client libraries across multiple languages and environments.

Following the above reason, from the perspective of the client, each library coded for a service is written by someone else. A great trust is needed to rely on the skills and experience of the library developer. It is also possible that the client libraries may not even be properly maintained, updated or tested.

Conclusion

The current trend is to architect your system into tiers, so that you can distinguish business logic, processing and storage implementations. This calls for abstraction of services behind service client APIs, or the usage of SDKs. However, this should not always be the de facto solution for abstraction services. Over engineering only complicates matters, and sometimes the simplest solution is the most viable answer.

Using all of the above arguments, I hope you are able to make the right decision for your service, which would also attract the right developer for your project.

The post Exposing APIs to Your Clients appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/exposing-apis-to-your-clients/feed/ 2
Untangling Authentication and Authorizationhttp://blogs.ancestry.com/techroots/untangling-authentication-and-authorization/ http://blogs.ancestry.com/techroots/untangling-authentication-and-authorization/#comments Fri, 27 Sep 2013 19:40:39 +0000 Seng Lin Shee http://blogs.ancestry.com/techroots/?p=1239 When designing web service APIs, a decision has to be made to protect the usage of such APIs. If you are working within a protected firewall, and you trust every single user or machine on the network, this article does not apply to you – you are in API heaven. For the rest of us,… Read more

The post Untangling Authentication and Authorization appeared first on Tech Roots.

]]>
When designing web service APIs, a decision has to be made to protect the usage of such APIs. If you are working within a protected firewall, and you trust every single user or machine on the network, this article does not apply to you – you are in API heaven.

For the rest of us, please read on. This post is meant to provide a sufficient overview, or answer questions that have been puzzling fellow developers and architects who are new to this field. I use Federated Identity as an example of an authentication mechanism, and OAuth, a standard for web service authorizations.

Within the latest Ancestry App for the new iOS 7 operating system, we introduced a new way of building family trees by integrating with Facebook. The integration allows users to identify themselves via Facebook (authentication) and provides permissions for Ancestry.com to retrieve limited Facebook information (authorization). These distinctions are crucial to fellow developers, as well as program/project managers in order to avoid over-engineering any user flows within an application.

API Security

A common misconception is that security is viewed as one single solution and implementation. In fact, the security work can mostly be categorized into two phases:

  1. Authentication identifies the participant of the session. You have probably used Windows, Forms and Basic (username/password) Authentication; these are protocols to verify your identity to the web service. WS-Federation is one such protocol that facilitates Single Sign-On (SSO) and brokering of identity between federation partners. This allows an individual to use a resource in a partner company if there is a trust established between the individual’s company and the partner company.
  2. Authorization deals with access rights of the identity that is associated with the current session or context of the request. For example, Microsoft SharePoint uses role-based authorization, whereas WS-Federation utilizes claim-based authorization to evaluate the rights of a user session. The popular authorization method for web service APIs today revolves around OAuth, which allows third-party applications to perform operations on behalf of users.

By separating out the responsibilities, interesting applications and scenarios can arise when different parties (internally/externally) innovate on the different responsibilities. For example, Google is a major identity provider that authenticates the user; however, any application can re-utilize Google logins without the need to require users to create new account credentials for the new application/website. Essentially, you are delegating authentication to a trusted third-party. More details on this to come in the next section.

Authentication

Sears.com's social login experience

Sears.com allows you to login via Facebook, Google or Yahoo! without the need to create a separate, new account at sears.com.

What is Federated Identity?

Let’s skip standard authentication mechanisms such as Basic, Forms, Windows and Certificate authentications. These mechanisms are apparent when logging into browser-based applications. Native applications may also utilize these mechanisms when prompting for credentials, as the backend API calls may require similar authentication schemes.

Federated Identity is a mechanism to link up an individual’s identity and attributes across different identity management systems. Examples of such applications include foursquare.com and sears.com (implementation may differ). Other non-obvious examples would be when you try logging in to outsourced applications such as insurance, paystub and 401(k) management sites through your corporate firewall. These are perfect examples of applications from different systems that utilize identity information from a completely separate identity repository.

With Federated Identity, after selecting your ‘home’ system (or automatically identified), you may proceed to authenticate using conventional mechanisms such as Basic (aka username/password), Forms, Windows, Certificate or other protocols on your ‘home’ system. A ‘trust’ is established between the ‘home’ system and the ‘application’ system, which is utilized by the user. This allows the application system to identify and authorize the user session.

The advantage of federated system is that the website/application can easily extend to support different identity providers that use the same type of federation protocol (e.g. WS-Federation, SAML-P, OpenID etc).

When is Federation Used?

Like all features, you would need to assess the protocol before adopting it as part of your security strategy. A Federated Identity system opens up your system to users who would like to use their existing credentials to use your application (single single-on). A resource protected behind a federation system could perform authorization based on information from the identity provider.

Similar to what is written in a Layer7 blog, utilizing social logins dramatically improves the login experience of the user on a mobile device. This is especially true when an integration library exists that makes use of stored credentials in the system. Note that social login also encompasses a small portion of delegation (covered in the OAuth topic below).

The core questions that should be asked regarding this kind of implementation include:

  1. Is this the user experience that is desired?
  2. How does this affect external developers that are developing against your application APIs?
  3. How easy is it to establish a trust between an identity provider and the resource (web services/API endpoints)?
  4. Does this meet your security requirements?

It should also be pointed out that there are similar identification mechanisms which are not federation protocols, but rather delegation protocols, i.e. Facebook Login.

Authorization

What is OAuth?

One should not confuse OAuth with other Federation Identity protocols. OAuth is an authorization protocol and is not primarily used to identify a user. OAuth provides a simple way to verify the access level of a request for a web (service). It provides a mechanism for application users to delegate access to a third-party (application backend services, which will perform actions in the background) to work on behalf of the user.

The confusion arises when OAuth is used as a social login by many sites. For example, you can login to sites that use social logins via Facebook and LinkedIn. What’s happening on the backend is a call back to the Facebook/LinkedIn endpoint, using a pre-established access token, to retrieve specific identity/profile information. This endpoint is not part of the protocol, but actually a regular API endpoint established by the individual corporations.

Ancestry iOS application Facebook Login experience

The new Ancestry iOS application utilizes Facebook Login to provide seamless login to the application, and to provide delegated access to friends and family information from the user’s Facebook Profile.

As we have already established, OAuth is an authorization protocol, so it makes sense that OAuth can be combined with any authentication protocols as well. While Vittorio Bertocci blogs about the inadequacy of OAuth as a Federated Identity protocol, there are Federation protocols that utilize OAuth. OAuth alone does not provide the mechanism for a user to login through different identity providers (Yahoo!, Google, Microsoft etc.).

When is OAuth Used?

As more scenarios require the unobtrusive behavior of applications to perform in the background, there is a need for a protocol that should not frequently prompt a user to enter credentials (due to password expiring or simply an application reboot).  Such applications include desktop widgets, mobile applications and background daemons running on servers.

A delegation mechanism is required, which allows the application to perform tasks on behalf of the user, without compromising the full privacy of the user. An example includes the user posting to a social network. Your service/application can exploit this to further increase fame and notoriety in public.

Secondly, the delegation mechanism of OAuth allows you to open your API endpoints to third-party developers, while still providing confidence to your end user base that the third-party developers’ scope is restricted.

OAuth provides the end user with control over specific actions the application can actually perform, by approving a given set of permissions.

Conclusion

The complexity of implementing security, and the relevancy to the business goals should not be overlooked. If there is a business model that harnesses an open API, then it is necessary a strategy exists to create/manage a community of developers, and to maintain relevant and up-to-date documentation.

If it makes sense to allow anyone access to a website via any identity provider (Google, Yahoo!, Microsoft, Facebook), then a plan for some kind of Federated Identity should be in the works.

As different sites use different protocols to perform authorization/authorization, or even both at the same time, implementation becomes more complex and more confusing. Couple this with the effort to support multiple social logins, it’s no wonder you get lost in the protocol web. Let the dominant standard prevail!

Last but not least, it is imperative that the user experience is not bogged down due to the many standards in authentication and authorization protocol. Identify the standard patterns in the marketplace and incorporate the protocol with the most intuitive user experience. Have fun!

The post Untangling Authentication and Authorization appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/untangling-authentication-and-authorization/feed/ 2
Android is fragmented – and that’s OK!http://blogs.ancestry.com/techroots/android-is-fragmented-and-thats-ok/ http://blogs.ancestry.com/techroots/android-is-fragmented-and-thats-ok/#comments Wed, 15 May 2013 14:31:20 +0000 Matt Peterson http://blogs.ancestry.com/techroots/?p=662 Much has been written about fragmentation in Android – the fact that there’s a practically limitless variety of screen sizes, shapes and resolutions available on devices running the Android operating system as well as many different versions of the Android OS running on those devices. In addition there are devices running highly-customized versions of Android… Read more

The post Android is fragmented – and that’s OK! appeared first on Tech Roots.

]]>
Much has been written about fragmentation in Android – the fact that there’s a practically limitless variety of screen sizes, shapes and resolutions available on devices running the Android operating system as well as many different versions of the Android OS running on those devices. In addition there are devices running highly-customized versions of Android such as the Amazon Kindle and Barnes & Noble Nook tablets adding further diversity to the landscape.

Every argument about which mobile platform is “better” or easier to develop for will inevitably evoke fragmentation as a major hurdle to be overcome in Android development. However, in our experience developing the Ancestry app this has just not been the case. Working with a diverse set of device requirements requires a different approach than one would take with a monoculture like iOS, but it’s not necessarily a more difficult approach. By following a few basic principles, fragmentation has become for us a minor issue at worst.

Don’t reinvent the wheel

The version of Android OS that is most prevalent on currently active devices is 2.3, and it saw its last major update about two years ago. Since then there have been multiple new versions of the OS released adding significant functionality through a number of new APIs. Do not presume that you have to ignore these new features merely because they are only present in a newer API or that you’ll have to write your own equivalent features from scratch in order to get them on older devices. Google provides a Support Library that encapsulates many of the most useful additions to the Android SDK, such as fragments and View Pagers. The Ancestry app uses fragments heavily and with the Support Library we are able to provide that functionality on devices running Android OS versions as old as 2.1.

In addition, several intrepid developers have built additional libraries for areas that Google doesn’t already support. Jake Wharton’s ActionBarSherlock is the marquee example of this; it’s a drop-in replacement for the native ActionBar API that cleverly uses the native Action Bar on devices that are new enough to support it while creating its own Action Bar for older devices that is indistinguishable from the native one. Another useful library, also written by Jake Wharton (we owe that guy a fruit basket or something), is NineOldAndroids. This library brings many of the new animation features introduced in Android 3.x to older versions.

Google also makes all of the Android source code freely available so if a library is not yet available to support the new API feature that you want, it’s often possible to copy the source code for that feature into your project and get it running on all of your supported platforms with minimal tweaking.

If there’s just no practical way to duplicate the functionality you desire across all device versions, it’s a simple matter to create a code path that only executes on devices with the new feature you would like to use using the Build.VERSION.sdk_int constant to detect the version of Android running on the user’s device. This allows you to still provide the optimal experience for newer devices while degrading gracefully on older ones.

Varying OS versions is not the only fragmentation issue; there are also concerns about supporting multiple screen sizes, and how to test all of these various configurations. In upcoming posts I’ll discuss these issues and how we manage them at Ancestry.com.

The post Android is fragmented – and that’s OK! appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/android-is-fragmented-and-thats-ok/feed/ 0