A Spectrum White Paper:

Thoughts on Google Android

February 2008

Page 1 of 17
 spectrum data technologies

Contents
1.1.1 The Red Layer ....................................................................................................................................3
1.1.2 The Green Layer................................................................................................................................4
1.1.2.1 Open Source Libraries shipped standard with Android ............................................4
1.1.2.2 The Android Runtime .............................................................................................................4
1.1.2.2.1 Available Java API Packages .............................................................................................4
1.1.2.2.2 The Dalvik Virtual Machine...............................................................................................5
1.1.3 The Blue Layer (Application Frameworks) .............................................................................5
1.1.4 The Blue Layer (Applications) ......................................................................................................6
3.0 Sample Architecture for Secure data storage with Google Android ........................................8
5.0 Are all Applications Created Equal?................................................................................................... 12
6.0 Stability of the Current Android SDK ................................................................................................ 12
7.0 Tradeoffs...................................................................................................................................................... 13
Works Cited......................................................................................................................................................... 15

Page 2 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

1.1 Google Android

Google Android is a new mobile handset platform based on Linux, Apache Harmony1 and a
proprietary, for the moment at least2, custom virtual machine named Dalvik.

Figure 1 Overview of the Android Application Stack3

1.1.1 The Red Layer

The red layer from figure 1 represents the services offered by the Linux kernel and associated
GNU utility packages ported to the ARM4 architecture. These components are licensed under
the GNU General Public License, the GPL5, or the GNU Lesser General Public License, the LGPL6.
Being subject to the GNU GPL and LGPL licenses, these components are licensed with all
source code included. Furthermore, due to the viral nature of the GPL license, any
modification to this layer or derived work must be distributed as source to any 3rd parties
using the same licensing terms. The GNU/Linux ARM port is mature, stable, and used in
many embedded projects both in and outside of Google7.

Page 3 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

1.1.2 The Green Layer

The green layer consists entirely of open source libraries available under various licenses.
Some of the libraries come from the GNU project8 itself. The licenses here vary from the LGPL,
BSD9, MIT10 and are completely in the public domain11 in the case of the SQLite12 database.
However, even if the licenses of some of the components found in this layer are more
permissive and could allow a hardware vendor for customizations not found in other Android
handsets, Google has created the Open Handset Alliance13 that owns the Android trademark.
As part of this effort, any phone that wishes to be branded as an Android handset must meet
the non-fragmentation rule14. As such, any phone that would customize the libraries found in
this layer, add libraries or remove them altogether would no longer be able to brand itself as
an Android phone. Furthermore, under this same pledge, its license to the proprietary Dalvik
virtual machine found at the core of the Android platform would be considered null and void.

1.1.2.1 Open Source Libraries shipped standard with Android

Notable software included in this layer, but not limited to, are:
1. Webkit15. The Web browser engine found at the heart of the Apple Safari16,
iPhone17 and Konqueror18 web browsers. Providing an Acid219 compliant web
browser featuring HTML 4, JavaScript and CSS. This browser is now also used on
high end Nokia phones20.
2. SQLite. This database is the de facto database for embedded products and is now
most likely the most widely used database in the world21. It is incredibly small; the
library fits comfortably in less than 500KB on disk and yet offers most features
found in the SQL-9222 standard.
3. OpenSSL23. The SSL/TLS24 security library used in all Mozilla25 based products,
Apple Mac OS X26, Linux 27 and many commercial UNIX28 operating systems.
4. OpenGL ES29. OpenGL is a 3D graphics library used by many games, operating
systems and applications to achieve high performance 3D graphics. Android’s use
of such a library allows application providers to tap into a well-known pool of
experts on this technology. OpenGL ES is the embedded version of the OpenGL
library and features a subset of the OpenGL API. Additional functionality specific
to low powered environments such as phones is also provided by the ES variant of
OpenGL.

1.1.2.2 The Android Runtime

Also found in the green layer of the Android application stack are the Dalvik virtual machine
and the core Java libraries that are used to run and create applications respectively.

1.1.2.2.1 Available Java API Packages

The core Java packages that are used to create applications come from two different sources:

1. Google Android specific packages. These packages were created by

Google for its Android initiative. They are currently closed source, but
Google has committed to making these packages Open Source30. The

Page 4 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

packages range from user interface construction to hardware specific

functions such as camera control, Bluetooth support, and location
services.

2. Java packages that are part of the Java SE 5 specification, these packages
represent the bulk of the Android SDK. In other words, regular Java SE 5
developers can leverage their existing skills to write Android
applications. Google obtained these packages from the Apache Harmony
project. As such, these packages are licensed under the Apache
Software Foundation License version 231. This license is one of the most
liberal available today. Companies can use, modify, and commercially
exploit code under this license without the need to re-contribute
changes back to the original source or any 3rd parties. However, the
Android pledge from the Open Handset Alliance still applies at this layer
of the software stack meaning that any changes here will disallow the
use of the Android brand and Dalvik virtual machine. That being said,
not all existing Java SE 5 knowledge applies. The user interface toolkits
from Java SE i.e., Swing32 and AWT33, have been stripped in favor of an
Android only specific toolkit.

1.1.2.2.2 The Dalvik Virtual Machine

The Dalvik virtual machine is an interpreter only machine optimized for use on low powered,
low memory devices like phones. Notably, Dalvik does not make use of just in time (JIT)
compilation to improve the performance of an application at runtime. Furthermore, Dalvik is
not a Java virtual machine. This is because Dalvik is unable to read Java bytecode34, instead it
uses its own bytecode format called “dex”. Google claims this format allows battery power to
be better-conserved at all different stages of execution of an application. This means that
standard Java SE applications and libraries cannot be used directly on the Android Dalvik
virtual machine.

Dalvik however stands at the center of the Android value proposition. Its low electrical power
consumption, rich libraries, and unified, non-fragmented application programming interfaces
make it stand out, or so Google hopes, over the fragmented ecosystem that is Java ME35
today.

Furthermore, since Dalvik uses the Java programming language but not the Java execution
environment (JVM), Google is free to develop Android without the need to license or obtain
certification from Sun Microsystems Inc, the legal owner of the Java trademark and brands.

1.1.3 The Blue Layer (Application Frameworks)

In this layer, the application developer has access to what Android refers to as “service”
processes. These services are invisible to the user of the handset. Application developers can
communicate with these services via a message bus. For example, a contact application
might instigate a phone call at the behest of a user request by calling on the services of the
telephony manager.

Page 5 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

All code found in this section is currently closed source, is written in Java specifically for the
Dalvik virtual machine. It is not yet clear under what license these modules will be made
available in the future.

1.1.4 The Blue Layer (Applications)

These are all the applications hosted on the handset. Google or any other 3rd party may have
written these applications. Unlike other phone platforms, Android has support for
applications that do not have a user interface. The main application types are:

i. User interface applications. Consisting of views that know how to draw themselves
on screen.
ii. Intent listeners. Intents are messages that are carried over the message bus of the
handset. This allows for different applications on the phone to talk to each
other.
iii. Services. Similar to Windows services or UNIX daemon processes. A body of code
that runs in the background. The application runs without a user interface but
may be essential to an application that does have a user interface.
iv. Content providers. A data storehouse that provides access to data on the device.
On Android, unlike all other mobile platforms, all data and files that are created
by an application are invisible to all other installed applications. In order to
make data visible to other applications, the application or service must make
the data available via content providers. Alternatively, an application may only
interact with a content provider for its data needs and forego the creation of
data and files completely. Unlike other platforms, Android already has a
generic, standard way of accessing data in a uniform and standard fashion.

1.2 Security Model

The security model in Android is considerably more locked down than other handset
platforms. Each application runs in its own instance of the Dalvik virtual machine. Each
instance of the Dalvik virtual machine represents a Linux kernel process; hence each instance
is completely isolated from the other memory wise. As such it is not possible for an
application to steal information from another running application.

Files and data held by an application are completely isolated from all other applications. This
is enforced by the system by the use of the Linux kernel and traditional UNIX file permissions.
For applications to access data from another application, it must first be exposed via a
content provider and accessed by the message bus by sending “intents” between the two
applications.

That being said, it’s still necessary to be careful when handling sensitive data. Memory that
was allocated to a now defunct process is not zeroed out. The old tried and true technique of
allocating memory only to observe its contents for sensitive information, could still be used by
a potential hacker to break into a secure content provider service.

Page 6 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

2.0 Sample Architecture for Android within a Federated SSO System

Figure 2 Android and a potential use of single sign on

Using figure 2, we have the following workflow:

1. Login to the local service data storehouse located directly on the phone.
2. This is an Android service application. The application was deployed with the SSL
certificate of the SSO36 service.
3. Using mutual key authentication37. The user’s credentials are validated. Upon
successful login, a SSO token of at least 64 bit in length is returned to the local
Android storage service.
4. The user facing application requests data from the local storehouse.
5. If the data is cached locally, it is returned immediately; otherwise, it is requested
from web services. The username and password of the user are not sent to the
web service. Instead the SSO token is sent to the web service.
6. The web service requests authorization for the requested operation by the handset
using the SSO token.
7. Data is returned to the Android local storehouse service from the web service if the
SSO token was valid.
8. The data could be saved locally here.

Return the data to user facing application using the local data storehouse. To make the role of
the SSO system clear, some aspects of the architecture were omitted for brevity. We will
further expand on this architecture in section 3 of this paper. The main limitations of the
current architecture presented here is that the local data storehouse does not validate the SSO
token with the SSO service nor does it encrypt the data locally. Furthermore, the username
and password is sent over the network to the SSO service. This can also be avoided.

Page 7 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

3.0 Sample Architecture for Secure data storage with Google Android

Figure 3 Android and Secure Local Data Storage

We now present a secure data storage solution that could potentially be deployed on Android.
It is based on the design presented in section 2 of this document. However, many
shortcomings of the design have been addressed. Additional security highlights will be
presented at the end of the section.

Using figure 3, we have the following workflow:

1. The user enters his credentials on the handset.
2. The credentials are not sent to the SSO service over the network. Instead, the
credentials are used as the passphrase to decrypt the local public/private key pair
of the user. We define the public/private key pair to be of type RSA and of at least
4096 bits in size. Already we gain the advantage that the user’s password is not
sent over the network.
3. The private key is used to decrypt the symmetric cipher key. The symmetric cipher
key is used to encrypt/decrypt any locally cached data. A strong symmetric cipher
like 3DES is used.
4. All data found in the local cache is encrypted with the symmetric cipher key
defined in step #3.
5. If the requested data is not locally cached or expired. We must communicate with
the SSO service again to be able to receive fresh data from the Restful web
services. However, unlike the architecture presented in section 2 of this document,
we login to the SSO server using a hostile challenge based on the private key of the
user. As such, we login with the SSO system using public/private key

Page 8 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

infrastructure. The user name and the password are never sent over the network.
The SSO system can identify the user based on this challenge and returns a 496 bit
alpha numeric token.
6. The tokens generated by the SSO system are set to automatically expire after a
given period of time.
7. On reception of the SSO token. The Android background application can now
communicate with any Restful web services that adhere to the same SSO
federation. Public/private key infrastructure is once again used to setup a secure
communication channel between the phone and the server. The certificates of the
servers that host the web services are procured from the same certificate authority
that shipped with the phone.
8. On reception of a request, the SSO token is extracted from the request. The web
service calls upon the SSO system to authorize the operation.
9. On reception of the data, the symmetric cipher described in bullet #3 above is
used to encrypt the data before it reaches any local persistent storehouse.
10. Data is returned to the user facing application.

Additional security notes:

1. The public/private key pair of the user is generated directly on the handset at
install time. As such, the private key has never left the phone nor has it been
transferred over any network.
2. The certificate of the user must at least be registered once in the SSO application.
This could be done at install time of the handset application.
3. “Man-in-the-middle”38 attacks are not possible since the application is deployed
with the CA certificate of the company that will be hosting the web services.
4. If the device is lost, all the locally cached data is completely unreadable. The
symmetric key that encrypted this data is also unreadable. The public/private keys
that are central to the security architecture are protected by a passphrase.
5. The passphrase is the weakest link in the chain. If the user enters an overly simple
password, access could be gained to the private key and hence the locally cached
data.
6. That being said, it would be possible to further extend this architecture to store
the encrypted symmetric key on the server. This way, even if the passphrase of
the private key is compromised, the locally cached data still cannot be accessed.
This is because the encrypted strong symmetric cipher key is stored on the server.
By the time the passphrase has been cracked, there has been ample time to report
the stolen phone and revoke this key from this user account on the server.
Furthermore, under this scheme, the key stored on the server is still encrypted.
Even if this key is intercepted in transit it is useless without the user’s private key.
7. It is also possible to enforce a strong password policy directly from the handset
application.

Page 9 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

8. Even if this design is significantly more secure than the previous iteration, to the
user, the experience is the same. The user must enter a username and password
to prove his identify.
9. We could augment the architecture in yet another direction. The local caching
system could also require an SSO token and subsequently request authorization
from an SSO system. Such a design would prevent terminated employees, i.e., an
individual who already knows what the local credentials are, from accessing the
locally cached data.

4.0 Execution Environment

Figure 4 Regular Java Execution Process

Page 10 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

Figure 5 Android Execution Environment

Figures 4 and 5 represent the regular Java and Android execution paths respectively. It is
interesting to note here however is that the Android compilers do not operate on Java
language code. Instead, the Android translators work on the resulting Java bytecode emitted
from a traditional Java compiler.

As such, it is possible to reuse existing Java libraries, even if the original source code is not
available. Such libraries must meet stringent requirements however, they need to:
1. adhere to the Java SE 5 dialect
2. not use any Java classes or packages found in Java SE 5 not found in the Android
platform
3. not use any packages or classes specific to the Sun Microsystems platform
4. still behave in a predictable manner under the Apache Harmony Java environment

Following these guidelines, it’s possible to integrate existing Java source code, packages and
libraries piecemeal. Special care will be needed in the integration phase of such code but the
potential savings offered by such integration far outweighs the cost of rewriting well-coded,

Page 11 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

well-documented and well-tested libraries ready for use. Furthermore, it is expected that has
Apache Harmony matures, more and more compatibility issues will be resolved further
increasing the pool of available Java code that will be able to execute unmodified under the
Android platform.

5.0 Are all Applications Created Equal?

One of the promises made by Google about its Android platform is that all applications are
created equal, meaning that the user can replace bundled applications if he so desires with
Google or non-Google alternatives. However, it’s certainly true that Google’s Android
platform is more open than the traditional application environment usually found on mobiles
today; but it is not a completely open platform.

First and foremost, even if the majority of the Android application stack is written in C and
C++, Google does not allow writing applications for Android in those languages. All
applications written for Android by 3rd parties must be written for the Dalvik virtual machine.
Currently, the only officially supported programming language is the Java SE 5 dialect.
This also means that custom libraries written in the C or C++ language available for the Linux
operating system cannot be deployed to an Android handset, such libraries can only be
shipped as part of the base Android image which is under the complete control of Google. As
a result, a huge number of already available, potentially useful libraries are cut off from the
Android developer.

Without such support, the openness of the platform is somewhat constrained. For example,
in a traditional handset, it’s not possible to replace the web browser that ships with the
phone. This is doable in theory under Android but considering that non-Dalvik libraries
cannot be deployed to the handset, it is almost impossible to do so. A user could easily
install an alternative web browser that uses the already present WebKit of the phone but could
not deploy a Mozilla based browser solution for example. Providing a Mozilla based browser
to the handset would require installing native Linux/ARM C++ libraries to the phone. To truly
replace the default based WebKit browser would require a 100% Java/Dalvik solution, a
massive investment to say the least. Replacing the browser with another one also founded
on WebKit now becomes a purely cosmetic exercise.

In summary, Google doesn’t impose any legal limits on the replacement of base applications
but does however rely heavily on this limitation and simple economics to ensure that it will
not be done in the field.

6.0 Stability of the Current Android SDK

We would be remiss if we did not mention that Android is currently very much a work in
progress. The first SDK39 released, version 0.3, had a large amount of bugs, missing
documentation and odd behavior. The use of Apache Harmony as a core technology is also
cause for some concern at this time. The Apache Harmony project has yet to release a stable
release of their code. It is also hard to quantify exactly how stable, or unstable, Android is
considering that Google didn’t host a public bug tracking system until very recently.

Page 12 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

The initial public Android SDK was updated to version “m5” on February 13th 2008. The
refreshed SDK features a large number of bug fixes... but also features many API changes.
Such changes include the addition, renaming and removal of classes, methods, XML elements
and packages thus invalidating all existing Android applications. Any Android application
written for the 0.3 SDK will not be able to function without at least some modifications under
the new “m5” SDK release.

7.0 Tradeoffs
Arguably, the Android platform has many advantages over other mobile platforms, both in
and out of the scope of security. There are also however, numerous shortcomings of the
platform as it exists today.
1. The developer tooling available for Android today is limited to an officially
supported module for the Eclipse40 IDE41 that offers very few features in terms of
developer support.
2. There are currently no visual user interface designers for Android. As such, the
upfront investment required to build a professional looking application is steeper
than other platforms that offer such tools.
3. The use of Apache Harmony for the provision of all Java SE 5 packages included in
Android is also a cause of concern. The Apache Software Foundation has been
unable to acquire a license of the Java Compatibility Kit (JCK) under acceptable
terms from Sun Microsystems42. As such, existing Java libraries used on Android
may behave differently then when run under Sun’s Java environment. This
difference in behaviour may prohibit a large number of libraries from working
correctly under Android. Apache Harmony as yet to reach version 1 status and as
such is very much a volatile target.
4. It is not yet clear how the Android platform will be upgraded to newer versions of
the platform once deployed. In fact, at this time, it is not known if this facility will
even be provided.
5. If the Android platform currently deployed on a handset is indeed updated, a large
number of bug fixes in Apache Harmony might break existing applications that
have been validated to work around these bugs.
6. The same applies for any security updates to the platform. Currently, Google has
not set any policies on how it intends to deploy security fixes to handhelds or if it
plans to even do so.
7. It is not yet known how applications will be remotely provisioned to handsets.
8. No support for SOAP43 based web services44 is part of the core platform. Many
service-oriented applications (SOA) will not be directly usable from Android. It
may be possible, using the technique discussed in section 4 of this paper, to
include Java libraries to gain this functionality. It is clear however that Google is
favouring a Restful45 approach to the consumption of web services on the Android
platform.

Page 13 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

9. Even if Google seems to be favouring Restful web services, there is no XML binding
framework shipped with Android out of the box. Again, the technique used in
section 4 of this paper might be used to gain this functionality.
10. Android, just like Java ME, does not mandate every possible hardware component
supported by the platform. For example, a camera or Bluetooth support may be
missing from the phone and yet still benefit from the Android brand.
11. Since it is not yet clear how applications will be deployed to the handsets, it is not
yet known what kind of digital signatures, if any, will be required for the proper
provisioning of applications to handsets.

Page 14 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

Works Cited
1. Apache Software Foundation. [Online] Apache Software Foundation, 2008. [Cited: February 13,
2008.] http://harmony.apache.org/.

2. Google. Open Source Licensing Questions - Android. Google Android Site. [Online] 2008.
http://code.google.com/android/kb/licensingandoss.html#timeline.

3. —. What is Android? Google Code. [Online] Google, 2008. [Cited: February 13, 2007.]
http://code.google.com/android/what-is-android.html.

4. Wikipedia. ARM Architecture. Wikipedia. [Online] January 5, 2008. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/ARM_architecture.

5. —. GNU General Public License. Wikipedia. [Online] Wikipedia, November 19, 2007. [Cited:
February 18, 2008.] http://en.wikipedia.org/wiki/GPL.

6. —. GNU Lesser General Public License. Wikipedia. [Online] February 18, 2007. [Cited: February
13, 2008.] http://en.wikipedia.org/wiki/LGPL.

7. Sun Microsystems. phoneME FAQ. phoneME. [Online] Sun Microsystems. [Cited: February 13,
2008.] https://phoneme.dev.java.net/phone_me_faq.html#cldc4.

8. Wikipedia. GNU Project. Wikipedia. [Online] July 23, 2003. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/GNU_project.

9. —. BSD licenses. Wikipedia. [Online] August 7, 2001. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/BSD_license.

10. —. MIT License. Wikipedia. [Online] May 21, 2001. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/MIT_license.

11. —. Public domain. [Online] November 5, 2001. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/Public_domain.

12. Hipp, D. Richard. SQLite Home Page. SQLite Web site. [Online] [Cited: February 13, 2008.]
http://sqlite.org/.

13. Google. Open Handset Alliance. Web site for the Open Handset Alliance. [Online] Google,
November 5, 2007. [Cited: February 13, 2008.] http://www.openhandsetalliance.com/.

14. Perez, Juan Carlos. Google demands non-fragmentation pledge for Android. Wireless IT
World. [Online] IDG News Service, Boston Bureau, November 6, 2007. [Cited: February 13, 2008.]
http://wireless.itworld.com/4269/071106googleandroid/page_1.html.

15. WebKit. The WebKit Open Source Project. Web site for WebKit. [Online] [Cited: February 13,
2008.] http://webkit.org/.

16. Apple Computer Inc. Safari. Apple Computer Inc. [Online] [Cited: February 13, 2008.]
http://www.apple.com/safari/.

Page 15 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

17. —. iPhone. Apple Computer Inc. [Online] [Cited: February 13, 2008.]
http://www.apple.com/iphone/.

18. KDE. Konqueror. Konqueror. [Online] [Cited: February 13, 2008.] http://konqueror.org/.

19. webstandards.org. Acid2 Browser Test. Site for the web standards group. [Online] July 21,
2006. [Cited: February 13, 2008.] http://www.webstandards.org/action/acid2/.

20. Nokia Corporation. S60WekKit. S60WekKit. [Online] [Cited: February 13, 2008.]
http://opensource.nokia.com/projects/S60browser/index.html.

21. Hipp, D. Richard. SQLite. Most Widely Deployed SQL Database. [Online] [Cited: February 13,
2008.] http://sqlite.org/mostdeployed.html.

22. Wikipedia. SQL-92. Wikipedia. [Online] July 19, 2005. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/SQL-92.

23. The OpenSSL Project. The Open Source toolkit for SSL/TLS. OpenSSL. [Online] [Cited: February
13, 2008.] http://openssl.org/.

24. Wikipedia. Transport Layer Security. Wikipedia. [Online] February 24, 2003. [Cited: February
13, 2008.]
http://en.wikipedia.org/w/index.php?title=Transport_Layer_Security&dir=prev&action=history.

25. Mozilla Corporation. Mozilla. Firefox web browser & Thunderbird email client. [Online] [Cited:
February 13, 2008.] http://www.mozilla.com/en-US/.

26. Apple Computer Inc. Mac OS X Leopard. Apple. [Online] Apple Computer Inc. [Cited: February
13, 2008.] http://www.apple.com/macosx/.

27. Linux.com. Linux.com. Linux.com. [Online] [Cited: February 13, 2008.] http://www.linux.com/.

28. Wikipedia Foundation. Unix. Wikipedia. [Online] December 8, 2001. [Cited: February 13,
2008.] http://en.wikipedia.org/wiki/Unix.

29. The Khronos Group. OpenGL ES. Khronos Group. [Online] [Cited: February 13, 2008.]
http://www.khronos.org/opengles/.

30. Google Code. Open Source Licensing Questions. Android. [Online] Google. [Cited: February 13,
2008.] http://code.google.com/android/kb/licensingandoss.html.

31. Apache Software Foundation. Licenses. Apache. [Online] [Cited: February 13, 2008.]
http://www.apache.org/licenses/.

32. Wikipedia Foundation. Swing (Java). Wikipedia. [Online] July 16, 2003. [Cited: February 13,
2008.] http://en.wikipedia.org/wiki/Swing_%28Java%29.

33. —. Abstract Window Toolkit. Wikipedia. [Online] September 13, 2002. [Cited: Ferbruary 13,
2008.] http://en.wikipedia.org/wiki/Abstract_Window_Toolkit.

Page 16 of 17 Spectrum Data Technologies,  2008

 spectrum data technologies

34. —. Java bytecode. Wikipedia. [Online] May 24, 2005. [Cited: February 13, 2008.]
http://en.wikipedia.org/wiki/Java_bytecode.

35. —. Java Platform, Micro Edition. Wikipedia. [Online] March 4, 2002. [Cited: February 14, 2008.]
http://en.wikipedia.org/wiki/Java_ME.

36. —. Single sign-on. Wikipedia. [Online] August 24, 2004. [Cited: February 14, 2008.]
http://en.wikipedia.org/wiki/Single_sign-on.

37. —. Public key infrastructure. Wikipedia. [Online] March 9, 2003. [Cited: February 14, 2008.]
http://en.wikipedia.org/wiki/Public_key_infrastructure.

38. —. Man-in-the-middle attack. Wikipedia. [Online] November 6, 2002. [Cited: February 14,
2008.] http://en.wikipedia.org/wiki/Man-in-the-middle_attack.

39. —. Software development kit. Wikipedia. [Online] January 6, 2003. [Cited: February 14, 2008.]
http://en.wikipedia.org/wiki/SDK.

40. —. Eclipse (software). Wikipedia. [Online] April 26, 2003. [Cited: February 14, 2008.]
http://en.wikipedia.org/wiki/Eclipse_%28software%29.

41. —. Integrated development environment. Wikipedia. [Online] December 2, 2001. [Cited:

February 14, 2008.] http://en.wikipedia.org/wiki/Integrated_development_environment.

42. Jr, Geir Magnusson. Open Letter to Sun Microsystems - JCK. The Apache Software Foundation.
[Online] April 10, 2007. [Cited: February 14, 2008.] http://apache.org/jcp/sunopenletter.html.

43. Wikipedia Foundation. SOAP. Wikipedia. [Online] December 12, 2001. [Cited: February 14,
2008.] http://en.wikipedia.org/wiki/SOAP.

44. —. Web service. [Online] September 27, 2002. [Cited: February 14, 2008.]
http://en.wikipedia.org/wiki/Web_services.

45. —. Representational State Transfer. Wikipedia. [Online] August 17, 2004. [Cited: February 14,
2008.] http://en.wikipedia.org/wiki/Representational_State_Transfer.

Spectrum Data Technologies

Website: www.spectrumdt.com
Email: info@spectrumdt.com
Phone: +1.877.800.9012
Copyright © 2008, Spectrum Data Technologies

Page 17 of 17 Spectrum Data Technologies,  2008