U.S. patent application number 13/350541 was filed with the patent office on 2012-05-03 for methods and systems for rating privacy risk of applications for smart phones and other mobile platforms.
Invention is credited to Rohyt Belani, Aaron Higbee.
Application Number | 20120110674 13/350541 |
Document ID | / |
Family ID | 45818949 |
Filed Date | 2012-05-03 |
United States Patent
Application |
20120110674 |
Kind Code |
A1 |
Belani; Rohyt ; et
al. |
May 3, 2012 |
METHODS AND SYSTEMS FOR RATING PRIVACY RISK OF APPLICATIONS FOR
SMART PHONES AND OTHER MOBILE PLATFORMS
Abstract
Methods and systems for evaluating and rating privacy risks
posed by applications intended for deployment on mobile platforms.
Validating the "intent" of a mobile platform application vis-a-vis
its impact on user privacy, as viewed from an end-user's
perspective allows those end-users to make better-informed
decisions concerning the downloading, installation and/or operation
of mobile platform applications. In making such assessments user
preferences can be taken into account. Privacy scores are provided
through sales channels for the applications, thereby affording
potential users the opportunity to assess whether they wish to
incur the associated privacy risk, before purchasing a subject
application.
Inventors: |
Belani; Rohyt; (New York,
NY) ; Higbee; Aaron; (Leesburg, VA) |
Family ID: |
45818949 |
Appl. No.: |
13/350541 |
Filed: |
January 13, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13229512 |
Sep 9, 2011 |
|
|
|
13350541 |
|
|
|
|
61385200 |
Sep 22, 2010 |
|
|
|
Current U.S.
Class: |
726/25 |
Current CPC
Class: |
H04W 4/60 20180201; H04W
12/08 20130101; H04L 67/34 20130101; H04W 4/50 20180201; H04W 12/02
20130101 |
Class at
Publication: |
726/25 |
International
Class: |
G06F 11/00 20060101
G06F011/00; G06F 15/16 20060101 G06F015/16 |
Claims
1. A method, comprising: receiving, by a host computer system, a
copy of a mobile platform application designed for execution on a
mobile platform; determining, by the host computer system, (i) an
intended purpose of the mobile platform application, (ii) one or
more files stored on or included in the mobile platform or
functionalities afforded by the mobile platform that are accessed
by the mobile platform application during its operation on the
mobile platform, (iii) whether said accesses are consistent with
the intended purpose of the mobile platform application, and (iv)
an overall score for the mobile platform application based upon
said determinations; and presenting the overall score to a
potential user of the mobile platform application.
2. The method of claim 1, wherein the intended purpose is
determined from information regarding said intended purpose of the
mobile platform application received in conjunction with the copy
of the mobile platform application.
3. The method of claim 2, further comprising: determining a
weighted rating for each of the discrepancies; calculating a
weighted average based upon the weighted rating assigned to each of
the discrepancies; and calibrating the weighted average to
determine the overall score.
4. The method of claim 3, wherein the determination of at least one
of the actual purpose and the weighted rating for a subject
discrepancy is based upon at least one of a privacy criterion and a
technical criterion.
5. The method of claim 3, wherein determining the weighted rating
for a subject discrepancy includes at least one of: determining a
probability that the subject discrepancy poses a risk to the
potential user's privacy; determining a type of risk the subject
discrepancy poses to the potential user's privacy; and determining
a degree of severity for a risk the subject discrepancy poses to
the potential user's privacy.
6. The method of claim 1, wherein at least one of the
determinations are user configurable.
7. The method of claim 1, wherein the mobile platform application
is received by the host computer system from the mobile
platform.
8. The method of claim 7, wherein the mobile platform application
is received by the host computer system from the mobile platform as
part of an installation or execution process for the mobile
platform application on the mobile platform.
9. A method, comprising evaluating, by a first computer system, a
risk to privacy of a user of a second computer system, when said
second computer system executes an application, said risk to
privacy determined according to an evaluation of the application's
intended purpose in light of functionality provided by the second
computer system to be accessed by the application when executing on
the second computer system; and presenting results of said
evaluating to potential users of the application through sales
channels for the application prior to installation of the
application on the second computer system.
10. The method of claim 9, wherein evaluating said risk to privacy
comprises determining discrepancies between the intended purpose of
the application and an actual purpose thereof, said actual purpose
determined through evaluation of kinds and natures of files stored
on or included in the second computer system that are to be
accessed by the application during its operation.
11. The method of claim 1, further comprising: evaluating the copy
of the mobile platform application according to a criterion; and
determining the overall score responsively to the evaluation.
Description
RELATED APPLICATIONS
[0001] This application is a Continuation of U.S. application Ser.
No. 13/229,512 filed 9 Sep. 2011 which is a Nonprovisional of and
claims priority to U.S. Provisional Patent Application No.
61/385,200, filed 22 Sep. 2010, incorporated herein by
reference.
FIELD OF THE INVENTION
[0002] The present invention relates to methods and systems for
evaluating and rating privacy risks posed by applications intended
for deployment on mobile platforms such as so-called smart phones
(i.e., mobile phones that include computing capabilities and/or
advanced connectivity capabilities), tablet computers (e.g., Apple
Inc's. iPad.TM. and similar devices), and the like.
BACKGROUND
[0003] Smart phones, tablet computers and similar devices have for
some time been provided with the capability to download, install
and execute various application programs. Apple Inc.'s iPhone.TM.,
iPod Touch.TM., and iPad.TM., smart phones based on Google Inc.'s
Android.TM., Nokia Corporation's Symbian.TM. or Microsoft
Corporation's Windows Mobile.TM. operating systems, and Research In
Motion Limited's Blackberry.TM. devices are all examples of such
platforms. To varying degrees, such applications exploit features
and functionalities of these platforms in order to provide services
to their respective users. In addition, some applications require
access to personal information of the users, such as the user's
location, the camera on the smart phone, contact lists and the
like. In the remaining discussion, the term "mobile platform" will
be used to mean all such devices.
[0004] So long as applications are well-behaved, that is operating
in accordance with their stated or implied intentions, users retain
control of their personal information. However, not all
applications are well-behaved. Some applications may, whether for
malicious reasons or simply due to sloppy programming, expose or
seek access to a user's personal information for reasons seemingly
unconnected with the stated or perceived purpose of the
application. Often, users are unaware of such risks.
SUMMARY OF THE INVENTION
[0005] Methods and systems for evaluating and/or rating privacy
risks posed by applications intended for deployment on mobile
platforms. Validating the "intent" of a mobile platform application
vis-a-vis its impact on user privacy, as viewed from an end-user's
perspective allows those end-users to make better-informed
decisions concerning the downloading, installation and/or operation
of mobile platform applications. In making such assessments user
preferences can be taken into account. Privacy scores are provided
through sales channels for the applications, thereby affording
potential users the opportunity to assess whether they wish to
incur the associated privacy risk, before purchasing or executing a
subject application.
[0006] A variety of embodiments of the invention are discussed
below. In brief, the present method and systems allow a host
computer system to be provided with a copy of a mobile platform
application designed for execution on a mobile platform for
purposes of fashioning a rating of that application. Together with
the application itself, the host may be provided information
regarding an intended purpose of the mobile platform application.
This allows for assessments of the intended purpose and the actual
purpose or operation of the application in order to evaluate the
privacy risk. Such risk may be calculated in any number of ways,
for example by determining which files stored on or included in the
mobile platform or functionalities afforded by the mobile platform
are accessed by the mobile platform application during its
operation (or its intended operation) on the mobile platform, and
whether said accesses are consistent with the intended purpose of
the mobile platform application. Based on such determinations, an
overall score for the mobile platform application may be determined
and presented to potential users of the mobile platform
application.
[0007] Determining whether accesses are consistent with the
intended purpose of a mobile platform application may involve
determining discrepancies between the intended purpose of the
mobile platform application and its actual purpose, for example as
determined through examination of the files or functionalities
afforded by the mobile platform that are accessed by the mobile
platform application during its operation. In some instances, the
present methods and systems may determine a weighted rating for
each discrepancy so observed, calculate a weighted average based
upon the weighted rating assigned to each of the discrepancies; and
calibrate the weighted average to determine the overall privacy
score for the application. Other procedures discussed in greater
detail below may also be used.
[0008] The determination of an application's actual purpose and/or
the weighted rating for a subject discrepancy between an intended
purpose and an actual purpose may based upon privacy and/or
technical criteria. In some cases, the privacy risk assessment may
involve determining a probability that the subject discrepancy
poses a risk to the potential user's privacy, the type of risk so
posed, and/or the degree of severity of the risk. Some or all of
these determinations may be made according to user-defined
preferences or risk tolerances, thereby affording a "personalized"
risk threshold for mobile platform applications of various
kinds.
[0009] These and further embodiments of the present invention are
described in greater detail below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The present invention is illustrated by way of example, and
not limitation, in the figures of the accompanying drawings, in
which:
[0011] FIG. 1 is a flow diagram illustrating a method of evaluating
the intent of an application intended for a mobile platform and
assigning one or more scores according to the subject application's
respect for the user's privacy, and trustworthiness with respect to
observed or determined differences between requested levels of
access to components of the mobile platform and the stated intent
of the application, in accordance with an embodiment of the present
invention; and
[0012] FIG. 2 illustrates an example of a mobile platform on which
embodiments of the present invention may be instantiated.
DETAILED DESCRIPTION
[0013] Described herein are methods and systems for evaluating and
rating privacy risks posed by applications intended for deployment
on mobile platforms. These methods and systems are useful for
validating the "intent" of a mobile platform application vis-a-vis
its impact on user privacy, as viewed from an end-user's
perspective. In making such assessments user preferences can be
taken into account, thereby allowing users to make better-informed
decisions concerning the downloading, installation and/or operation
of mobile platform applications.
[0014] Before describing the present invention in detail it is
helpful to understand some of the risks to user privacy that are
involved with operation of mobile platform applications. As
indicated above, so long as mobile platform applications are
well-behaved, users retain control of their personal information.
For example, an application that delivers restaurant
recommendations to a user based on the user's location might
reasonably be expected to require access to information that
reveals that user's location. The user can consciously choose to
use the application or not, knowing that if he/she uses the
application, such location information will be exposed. There may
well be significant benefit in allowing that information to be
exploited. For example, the user may receive a welcome restaurant
recommendation in return for providing transient location
information which will soon be stale anyway. Or the user may deem
the invasion of the user's privacy to be too great in exchange for
the perceived value of the information (for example where a user is
required to divulge his or her entire contact list in order to
receive a restaurant recommendation). In either case, the
well-behaved nature of the application means that the release of
personal information does not take place without the user's
knowledge and consent (manifest through use of the application for
its intended purpose).
[0015] However, not all applications are well-behaved. Some
applications may, whether for malicious reasons or simply due to
sloppy programming, expose or seek access to a user's personal
information for reasons seemingly unconnected with the stated or
perceived purpose of the application. For example, suppose the
restaurant recommendation application did surreptitiously access a
user's contact list and use it to spread a computer virus or simply
transmit all of the contact information back to a server without
the user's knowledge while purporting to look up and provide
restaurant recommendations. This masquerading of the underlying
theft of personal information would be considered by most users as
an invasion of privacy.
[0016] Recognizing this potential for mobile platform application
to mask or conceal their true functionality behind supposedly
useful features, the present inventors have developed systems and
methods to validate the "intent" of mobile applications, assign
these applications a score, and report that score to the users (or
potential users) of the mobile applications, thereby allowing the
users to be better informed about the true risk to the user's
privacy connected with the installation and/or execution of the
application. By validating the "intent" of an application, we mean
making an assessment of the impact on the user's privacy, as
measured by the application's access to personal information of the
user (e.g., personal information stored on the mobile platform or
accessible there-through) in light of it's stated or implied
purpose. This is a user-centric view of the application's intent,
which may in fact be different from a developer-centric view.
[0017] The score assigned to the application in accordance with the
present invention may be based on a variety of factors. For
example, personal preferences of the user may be accounted for in
generating the score. So too may social network considerations,
such as preferences of groups to which the user belongs or which
have previously downloaded and used the application, be accounted
for. Of course, the application's respect for the user's privacy,
trustworthiness of the application developer (e.g., as measured
through evaluations of other applications produced by the
developer) and the differences, if any, between the reported or
stated intent of the application and that determined through
analysis in accordance with the present invention may also be
factored into the score (or scores) associated with the subject
application.
[0018] Assessing the intent of an application may be done in a
variety of ways. In essence, the goal is to determine what the
application is actually doing when it executes on the mobile
platform and evaluate the results against what the application
should be doing in order to fulfill its stated purpose. Such an
analysis may include both static and dynamic components, or may be
entirely static in nature or entirely dynamic in nature. By static,
we mean an assessment of information concerning the application in
its static state (i.e., not executing on the target mobile
platform). By dynamic, we mean the application in its run time
state, executing either on the target mobile device or an emulation
environment instrumented to determine operating characteristics and
activities of the application as it executes. Such dynamic
evaluation may require a human user to activate certain features or
functions of the application in order to assess the impact thereof,
or, in some cases, such actions may be triggered by running the
application under the control of a test application configured to
act as a human user.
[0019] Determining what an application should be doing requires an
exercise of judgment. In embodiments of the present invention,
experienced professionals make such a determination based on a
variety of factors. These factors may include a review of the user
documentation provided with the application (e.g., documentation
describing the purported purpose and functions of the subject
application), a review of a running instantiation of the subject
application, discussions with the application's developers, and
discussions with users of the subject application, etc. By way of
example, if the user documentation for the restaurant
recommendation application discussed above indicates that the
application will provide restaurants near a user's current
location, then one would expect to see the application access
information on or through the mobile platform that would reveal
that location.
[0020] Understanding the purported function of an application can
help in understanding the permissions that the application requires
in order to deliver a user experience consistent with that
function. For example, an application that purports to allow users
to send and receive messages to the user's friends, likely requires
access to information about those friends, such as email addresses
or mobile phone telephone numbers, etc. Therefore, one could expect
to see the application requesting access to a user's contact list
or similar store of contact information. If such behavior were
observed when analyzing the application, then this behavior would
be deemed to be consistent with the reported function of the
application and even though it impacts the user's privacy or
private information, this behavior would not result in a score that
indicates significant risk. Thus, by assigning a score that is
based on an assessment of the difference between requested levels
of access to a user's private information and that expected by the
stated intent of the application, the present invention facilitates
sound decision making by users contemplating whether or not to
download and/or install and run an application on their mobile
devices.
[0021] The static component of the application analysis may vary
according to the type of application and target mobile platform
involved. By way of example, consider an application intended for
use on a mobile platform that runs the Android operating system.
Such applications include a manifest file (e.g., labeled
AndroidManifest.xml) in a root directory. The manifest provides
information about the application including a description of the
activities, services, broadcast receivers, and content providers
that the application is composed of. The manifest also declares
which permissions the application must have in order to access
and/or interact with other software components installed on the
mobile platform, libraries that the application must be linked
against, and permissions that other applications must have in order
to interact with its components. The precise structure of the
manifest file is not critical to the present invention, but is
described in various support literature for software developers
seeking to write application to run on Android devices.
[0022] In accordance with an embodiment of the present invention,
before an Android application is executed on a mobile device, the
manifest for that application is examined to determine the
permissions and library calls required by that application. These
permissions and calls define the accesses that would be made by the
application when running on a mobile device and so an assessment
can be made regarding what, if any, personal or private information
of a user would be impacted by these accesses. This information is
then assessed against the expected accesses that would be required
to fulfill the purported functions of the application and a
resulting score (perhaps normalized to a particular scale)
determined and reported.
[0023] The examination of the manifest may occur at any of several
times. For example, the application may be submitted for evaluation
by its developer prior to, commensurate with or sometime after the
application is made available for download by users (e.g., via an
"app store" or the like). Or, the application may be assessed when
encountered for the first time by an evaluation service that
employs the systems and methods of the present invention. This may
occur, for example, as part of an audit of an app store or other
facility through with users may download applications to their
mobile devices.
[0024] In other instances, the examination may be triggered by a
user's attempted download of the subject application to or
execution of the subject application on the user's mobile device.
For example, the mobile device may be configured with an evaluation
application running in the background, which evaluation application
is configured to detect attempted downloads of new applications and
upon such detection to seek an evaluation score (e.g., from a
rating service) or make its own evaluation in accordance with the
above-described procedure. In one embodiment of the invention, the
rating service may operate a server or other host where evaluation
scores (computed in accordance with the invention) are maintained
and, upon being contacted by the evaluation application running on
the mobile device (e.g., by way of a data channel or other
communication channel) may return an evaluation score for the
application which the user wishes to download if one exists. For
example, the mobile device may provide the name and version number
or other identifying information for the subject application being
downloaded and this information may be used by the rating service
server to consult a table or other data structure to determine
whether the subject application being downloaded has been
previously evaluated. If so, the server may return the previously
determined evaluation score to the mobile device and that score may
be presented to the user via a display on the mobile device. In
conjunction with displaying the score, the evaluation application
may provide the user with an option to continue with the download
of the application or abort same.
[0025] Where the rating service does not have an evaluation score
for the subject application being downloaded, the evaluation
application may perform an on-the-fly analysis of the subject
application being downloaded. For example, in the case of an
Android application, the evaluation application on the mobile
device may permit the subject application (or portions or files
thereof) to be downloaded, examine the manifest accompanying the
application, and assess the information derived from the manifest
against other information accessible to the evaluation application
concerning the purported function or intent of the subject
application. Such function or intent application may be available
from the server operated by the rating service (even if the subject
application itself has not yet been evaluated), from the app store
or other host from which the subject application is being
downloaded (e.g., in a separate file maintained by the app store or
simply by parsing an information page regarding the application),
or from the user (e.g., the user may be asked to categorize the
application as one that involves messaging, location services, etc.
so that a determination as to the kinds of accesses which the
subject application will require can be made).
[0026] In lieu of or in addition to the static assessment process
discussed above, a dynamic assessment of a subject application may
also be employed. Such an assessment involves running the subject
application in a controlled environment, such as a mobile platform
emulator or a mobile platform configured as a test environment, and
determining, as the subject application is executing, the calls and
accesses which it makes to other components of the mobile platform.
Such testing may require that an operator interact with the subject
application in the test environment so that all of the features and
functions of the subject application are subjected to the
evaluation. By monitoring the calls, accesses and outputs of the
subject application, a determination as to the risks presented by
the operation of the subject application to a user's private
information and/or privacy can be made and this information used
(perhaps in conjunction with information derived from a static
evaluation of the subject application) to determine a score.
[0027] The scores discussed herein, whether produced as a result of
static and/or dynamic evaluations, are, in effect, ratings of the
subject applications from the standpoint that the scores a relative
assessments of the risks presented by the applications vis-a-vis a
user's personal or private information. Of course, other
assessments could also be made.
[0028] The scores may, and likely will, be weighted scores so that
user's can make rapid determinations regarding the risks presented
by applications. For example, the scores may be weighted according
to accesses made by an application to a mobile device's file
system, hardware features, user private information, mobile device
configuration information, and so on. Scores may be reported in any
convenient fashion, for example through the use of letter grades,
numbers, colors, etc., any of which may be calibrated to reflect an
assessed level of risk by a rating service operating in accordance
with the present invention. Highly risky applications may, for
example, be coded Red, or assigned scores that reflect the
concomitant risk. Less risky applications, may be coded Green, or
assigned scores that reflect their rather benign impact on a user's
privacy. Applications with risk profiles that fall in-between these
extremes may be coded or assigned scores accordingly, and uses may
be advised of the meaning behind a color code or a particular
score, for example though collateral materials provided with an
evaluation application or through a help screen or other
information mechanism associated with the application or the
service.
[0029] In one embodiment of the invention, a single score is
presented for the user. However, in other instances, multiple
scores, each associated with a particular category, facility or
other profile may be provided. In some cases, scores may be
examined by a user to determine how they were computed. That is, a
user may be provided the ability to obtain information regarding
various evaluations which went into determining an overall score
(or risk profile) for a subject application.
[0030] The score or scores may be provided to a user in advance of
downloading an application, after downloading but before
installation of an application, after installation but prior to
execution of an application, upon launch of an application, or at
some other time. In the case of applications already installed on a
mobile platform, an overall assessment of the risk posed to a
user's privacy by some or all of those applications may be
provided, e.g., as part of an audit by an evaluation service or an
evaluation application when the evaluation application is first
installed on the mobile device or periodically as requested by the
user.
[0031] FIG. 1 is a flow diagram illustrating a method 100 of
evaluating the intent of an application intended for a mobile
platform and assigning one or more scores, which may be adapted
based on a user's specified preferences, according to the subject
application's respect for the user's privacy, and trustworthiness
with respect to observed or determined differences between
requested levels of access to components of the mobile platform and
the stated intent of the application, in accordance with an
embodiment of the present invention. As indicated above the
score(s) allow(s) a user to make an informed decision regarding
downloading and/or use of the subject application.
[0032] At the outset, a copy of the subject mobile application,
either in an executable format or source code format, and
information regarding the intent of that application (e.g., as
supplied by its developers or understood from the application's
proposed functionality) are obtained 102. Next, the application is
evaluated to determine what accesses it makes to the mobile
platform and/or the user's information on that platform 104. The
evaluation may include a review of any or all of the following:
[0033] system-level and/or file system permissions requested and/or
required by the application to function; [0034] access to user
location information; [0035] access to network connections; [0036]
access to the users' inbound and/or outbound messaging applications
(e.g., email, text messaging, etc.) and/or contact lists used or
accessed by those applications; and [0037] access to hardware
resources (e.g., microphones, speakers, cameras, displays, storage,
removable storage, etc.).
[0038] As evaluated, the application is then assessed against its
purported intent, as understood from its proposed functionality
and/or as determined from information provided by the application
developer 106, and any differences are noted 108. For example, if
the application's stated functionality is to identify restaurants
near you, then it accessing your location data is expected and
there is no identified discrepancy if the application is observed
requesting same. However, if the application is purportedly a
recipe finder, and it is observed attempting or requesting access
to the user's location data, this is determined to be a likely
violation of the user's privacy in conflict with the stated intent
of the application. This discrepancy is noted.
[0039] Any and all such discrepancies between the application's
intended functionality, and concomitant required accesses and
permissions, and the observed accesses and/or requests are then
weighed 110 according to the impact on the user's privacy and/or
based on the user's preferences. In some cases, the weight of a
particular category and/or criterion may be user configurable. For
example, some user's may specify a very high level of tolerance for
revealing personal information (such as location data), while other
user's may prefer to forbid any revelation of such information.
These kinds of user preferences can be accounted for through such
weightings.
[0040] Next, at step 112, a weighted average of all the
discrepancies discussed above is calculated and that weighted
average may be calibrated 114 to a pre-determined scale to produce
an overall score. In some cases, the calibrated values may be
affected by user community input (not shown in detail in FIG. 1).
The score is then presented to the user 116, thereby allowing the
user to make an informed determination regarding downloading and/or
use of the subject application. Where desired, the user may be
provided the ability to reveal details regarding how the score was
impacted by the various discrepancies noted during the evaluation.
As indicated above, the evaluations may be applied to mobile
applications resident on a mobile platform as well as those that
are being downloaded or copied to the platform. Additionally the
mobile platforms may communicate with a server or other host that
can enforce policy restrictions regarding the downloading of
applications that fail to meet certain score criteria. This may
especially useful in the case of enterprises that wish to provide
users the ability to download applications to mobile platforms,
provided those applications do not pose security risks for the
users and/or the enterprise.
[0041] Table 1 provides an example of how ratings scores for mobile
platform applications may be computed. The mobile platform
applications (designated App #1 and App #2) used for this example
may be games, social media applications, lifestyle applications,
financial applications, or any other mobile platform applications.
In the example provided, both App #1 and App #2 are designed to
operate using the Android operating system however, it should be
understood that a similar analysis might be performed for
applications operating on any available mobile platform operating
system. In the examples of Table 1, the scores of both applications
are determined based on a scale of 0-100 however, any scale, or
order of magnitude (e.g., 10, 1000, 10000, etc.) for scoring the
applications may be used.
TABLE-US-00001 TABLE 1 App #1 App #1 App #2 App #2 No. Criteria
Weight Rating Score Rating Score P1 Trusted Source 5 0 0 1 5 P2
Source Rating 5 0.5 2.5 1 5 P3 Number Of Other 2.5 1 2.5 0.5 1.25
Mobile platform applications By Developer P4 Developer's 2.5 0.75
1.875 1 2.5 Average User Rating P5 Application's 3 1 3 0.5 1.5 Time
In Marketplace P6 Developer's 2.5 1 2.5 0.5 1.25 Time In
Marketplace P7 Number Of 1.5 1 1.5 1 1.5 Comments P8 Developer's
1.5 0.8 1.2 1 1.5 Location P9 Category 1.5 1 1.5 1 1.5 Associated
With Application T1 Permissions 40 0.2 8 1 40 Requested T2
Interfaces 3 0.5 1.5 1 3 T3 Imported Classes 10 0.2 2 1 10 T4
Services 3 0.75 2.25 1 3 T5 Use Of Third 5 0.75 3.75 0.5 2.5 Party
Code T6 Excessive 1 0.75 0.75 0.75 0.75 Log Writing T7 Executive
Calls 2.5 1 2.5 1 2.5 T8 Reading/Writing 3 0.75 2.25 1 3 Network
Interface Info T9 Interesting IP 5 0 0 1 5 Addresses/ Domains T10
Code Obfuscation 2.5 0 0 0 0 Overall Score 100 39.575 90.75
[0042] The criteria used to evaluate the mobile platform
applications shown in Table 1 are examples. More, fewer or other
criteria may be used, and individual application evaluation
criteria may vary across application domains. For example,
financial applications may be evaluated using more, fewer or
different criteria than games. Thus, the specific criterions shown
in Table 1 should not be read as limiting the present
invention.
[0043] In this example, the evaluation criteria are separated into
two main categories: market based or privacy criteria and technical
criteria. In the example provided in Table there are nine market
based/privacy criteria (indicated as P1-P9) and ten technical
criteria (indicated as T1-T10). Of course, any number of criteria
may be used to evaluate a mobile platform application in varying
embodiments of the present invention. In some cases, evaluation
under one or more market based or privacy criteria and/or technical
criteria may be performed by a computer system other than a mobile
platform prior to or commensurate with an installation of the
application on a mobile platform, by the mobile platform itself as
part of or following installation of the application, or by some
combination thereof.
[0044] The relative importance of these evaluation categories and
criterion within these categories to one another and the overall
score of a mobile platform application may be reflected by a
relative weight as shown in the "weight" column of Table 1. For
example, the importance of the "Permissions Requested" criterion
(T1) is assigned a relatively high weight (in this case 40), which
indicates the relatively high importance of the "Permissions
Requested" of an evaluation result of the mobile platform
application according to this criterion relative to the other
criteria listed in Table 1. In contrast, the "Developer's Location"
criterion (P8) is assigned a relatively low weight (1.5) which
indicates the relatively low importance of an evaluation result of
the mobile platform application according to this criterion.
[0045] Evaluation of a mobile platform application under the first
market based/privacy criterion, "Trusted Source" (P1) indicates a
degree to which the source of the mobile platform application is
trusted or has a trustworthy reputation. A mobile platform
application provided by a trusted source typically receives a
higher rating when evaluated according to the P1 criterion than an
application provided by an unknown, or untrustworthy, source.
Evaluations according to this criterion may be based on, for
example, an evaluation of a past history, or reputation, of a
source. Typically, commercial marketplaces for mobile platform
applications (e.g., the Android Marketplace or Apple's App Store)
receive a high rating when evaluated under this criterion even
though, at times, they allow users to download applications with
privacy-related and other issues. This is due, at least in part, to
a commercial marketplace's ability to, for example, track a source
of a mobile platform application, monitor user complaints regarding
a mobile platform application, and remotely remove unwanted
applications from a it's marketplace or a mobile platform.
[0046] In the example provided in Table 1, the App #1 mobile
platform application received rating of 0 because upon evaluation
of the mobile platform application under the "Trusted Source"
criteria, it was determined that the source of App #1 is not
trusted. In contrast, evaluation of the App #2 mobile platform
application indicated that its source is trusted. Therefore, App #2
received the full amount of points available (1) as its rating
under this criterion.
[0047] Evaluation of a mobile platform application under the second
market based/privacy criterion, "Source Rating" (P2), indicates a
source's rating (e.g., a 5-star rating) of the application. In
cases where a particular source does not have a rating for a mobile
platform application, the mobile platform application may be
matched to a mobile platform application available on a different
source. For example, a manifest file or signature of a mobile
platform application may be analyzed and then matched to a manifest
file or signature of the mobile platform application available from
a different source that includes a rating of the mobile platform
application. On some occasions, fuzzy logic, such as close matches,
synonyms, or homonyms, for the mobile platform application's name
may be used.
[0048] Upon evaluation of App #1 under the "Source Rating"
criterion, it was determined that its rating from a particular
source was 2.5 stars out of 5. Therefore, it was assigned a rating
of 0.5, or half, which when multiplied by the weight assigned to
this criterion (5), yielded a score of 2.5. The source rating for
App #2 was determined to be 4.5 out of 5 stars and was therefore
assigned a value of 1, which when multiplied by the weight assigned
to this criterion, yielded a score of 5.
[0049] Evaluation of a mobile platform application under the third
market based/privacy criterion, "Number Of Other Mobile platform
applications By Developer" (P3), indicates a how many other mobile
platform applications are associated with a developer of the mobile
platform application at issue. Evaluation of a mobile platform
application under this criterion takes into account the probability
that a developer who has developed more applications also has more
software development knowledge and potentially a stronger
reputation and is therefore considered less likely to create an
application with a privacy-related risk.
[0050] The developers of App #1 have developed 20 additional mobile
platform applications, which is a relatively high number when
compared with other software developers. Therefore, App #1 was
assigned a rating of 1 under the P2 criterion, which when
multiplied by the weight assigned to this criterion, yields a score
of 2.5. In contrast, the developers of App #2 have developed only
three additional mobile platform applications, which is a
relatively low number when compared with other software developers.
Therefore, App #2 was assigned a rating of 0.5, which when
multiplied by the weight assigned to this criterion, yields a score
of 1.25.
[0051] Evaluating the mobile platform application according to any
of the remaining market based criteria (P4-P9) may be performed in
a manner similar to the processes described above with regard to
criteria numbers P1-P3. For example, evaluation of the mobile
platform application under a "Developer's Average User Rating" (P4)
criterion incorporates a developer's average user rating into the
scoring of a mobile platform application associated with the
developer.
[0052] Evaluation of a mobile platform application under an
"Application's Average Time In Marketplace" (P5) criterion
incorporates how long the mobile platform application has been
available for downloading by a user into the scoring of the mobile
platform application. Typically, the longer an application has been
available, the higher it's rating, when evaluated according to this
criterion, will be.
[0053] Evaluation of the mobile platform application under a
"Developer's Average Time In Marketplace" (P6) criterion
incorporates how long the developer of the mobile platform
application has been know to develop mobile platform applications
user into the scoring of the mobile platform application.
Typically, the longer a developer has been known to develop mobile
platform applications, the higher it's rating, when evaluated
according to this criterion, will be.
[0054] Evaluation of the mobile platform application under a
"Number Of Comments" (P7) may include, for example, doing a keyword
search of, for example, websites known to provide mobile platform
application ratings for in order to count ratings or other opinions
regarding the evaluated mobile platform application. In some
embodiments, the valuation of the mobile platform application under
the P7 criterion may also include determining an overall indication
of the comments (e.g. positive or negative). Typically, the more
comments found regarding a mobile platform application and/or
positive ratings of the mobile platform application, the higher
it's rating, when evaluated according to this criterion, will
be.
[0055] The mobile platform application may also be evaluated
according to a "Developer's Location" (P8) criterion. This
evaluation may include determining a country of origin associated
with the developer, wherein mobile platform applications associated
with countries known to be a source of mobile platform applications
with privacy related problems might receive a relatively low rating
when evaluated under this criterion.
[0056] The category or type of a mobile platform application may
also be evaluated as indicated by the "Category Associated With
Mobile platform application" (P9) criterion. Some types of
applications are inherently more of a privacy concern than other
applications. For example, a mobile platform application included
in the category of a "contact manager" typically accesses a user's
contact information, which poses an inherent privacy risk. While
access to this information may be legitimate for a specific
category of mobile platform application, it inherently has a higher
a privacy risk than applications in other categories and may
receive a relatively lower score when evaluated under this
criterion.
[0057] Scores based upon evaluation of the technical criteria
listed in Table 1 may be generated based upon, for example, a
technical analysis of a mobile platform application. The first
technical criterion, "Permissions Requested" (T1) is the most
heavily weighted criterion listed in Table 1. Evaluation under the
"Permissions Requested" criterion may involve, for example,
determining what, if any, files stored on a mobile platform the
mobile platform application requests permission to access during,
for example, installation and/or operation. For example, when the
mobile platform application is operable on the Android platform,
evaluation of the mobile platform application according to the
"Permissions Requested" criterion may include analyzing the mobile
platform application's manifest file, for example, prior to,
during, and/or after installation on a mobile platform in order to
determine any data files resident on the mobile platform that it
may request permission to access.
[0058] When evaluation of a mobile platform application indicates
that it requests permission to access a data file that is deemed
risky to a user's privacy, the mobile platform application's rating
may be decreased according to a perceived privacy risk. Exemplary
permissions that may be deemed risky to a user's privacy include
permissions for accessing a user's contact information,
geo-location position, SMS messages, voice mails, emails, stored
bookmarks, and other personal information.
[0059] For example, upon evaluation of the App #1 application
according to the "Permissions Requested" criterion indicates that
it will seek permission to access a relatively high number of data
files and/or will seek permission to access data files that are
likely to risk a user's privacy. Therefore, the App #1 application
received a relatively low rating (e.g., 0.2) when evaluated
according to this criterion which, when multiplied by it's weight
(40), yields a score of 8. In contrast, the App #2 mobile platform
application makes relatively few, or no, request to access data
files on a mobile platform that raise privacy concerns. Therefore,
when analyzed according to the "Permissions Requested" criterion,
the App #2 application received a relatively high rating (e.g.,
0.1) which, when multiplied by it's weight (40), yields a score of
40.
[0060] Technical criteria T2-T8 may be used to evaluate the mobile
platform application in order to determine potential privacy risks
to a user caused by how the mobile platform application was develop
and/or coded. For example, evaluation of the mobile platform
application according to the "Interfaces" criterion (T2) determines
whether the mobile platform application allows any other
applications to communicate with the subject mobile platform
application through its interfaces. Evaluation of the mobile
platform application according to the "Imported Classes" criterion
(T3) determines whether the application code of the mobile platform
application loads any system code (e.g., imported classes) onto the
mobile platform and evaluation according to the "Imported Classes"
criterion (T4) indicates whether the mobile platform application
includes any imported classes that are deemed to be adverse to a
user's privacy.
[0061] Evaluation of the mobile platform application according to
the "Use of Third Party Code" criterion (T5) determines if the
mobile platform application includes, or operates with, any
software code associated with a third party as occurs with, for
example, third party advertising used by the mobile platform
application. When the mobile platform application includes, or
operates with, the software code of a third party, the evaluation
according to criterion T5 may include determining if the third
party code could be a privacy concern to the user.
[0062] Evaluation of the mobile platform application according to
the "Excessive Log Writing" criterion (T6) determines whether data
stored on the mobile platform could be leaked to a third party via
excessive data written to the system logs. Evaluation of the mobile
platform application according to the "Executive Calls" criterion
(T7) determines whether the mobile platform application is know to
attempt or is likely to attempt execution unmanaged code on the
mobile platform that may lead to security or privacy risks, such as
buffer overflows.
[0063] Evaluation of the mobile platform application according to
the "Reading/Writing Network Interface Info" criterion (T8)
determines whether there is an indication that the mobile platform
application may read or write to the mobile platform's network
interfaces as this type of activity has been linked to malicious
mobile platform applications that charge a user for additional
services or usage. Exemplary network interface information that may
be read or written includes a mobile platform's access point name
(APN) or mobile directory number (MDN).
[0064] Evaluation of the mobile platform application according to
the "Interesting IP Addresses/Domains" criterion (T9) determines
whether the mobile platform application is attempting to
communicate with an IP address and/or domain with a reputation for
presenting risks to a user's privacy.
[0065] Evaluation of the mobile platform application according to
the "Code Obfuscation" criterion (T10) determines whether the
mobile platform application attempt to obfuscate the code that
makes up some, or all, of the mobile platform application. The
obfuscation of code may be indicate that the application is
performing an action which it wishes to hide from a user may
therefore pose a risk to the user's privacy. When a mobile platform
application does not attempt to obfuscate its code, it may receive
a high rating (e.g., 1) under the "Code Obfuscation" category
which, when multiplied by the weight for this category, may yield a
score of 2.5.
[0066] Upon completion of the evaluation of a mobile platform
application under one or more evaluation criteria, such as those
set forth in Table 1 for example, an overall score may be
calculated. The overall score may be an arithmetic sum of the total
points scored to an application, a weighted average score for the
mobile platform application based upon its ratings and/or scores,
or another computed total. In the example of Table 1, the App #1
mobile platform application received an overall score of 42.075 and
the App #2 mobile platform application received an overall score of
93.25.
[0067] As should be evident from the foregoing discussion, various
embodiments of the present invention may be implemented with the
aid of computer-implemented processes or methods (a.k.a. programs
or routines) that may be rendered in any computer-readable
language. An example of a mobile platform on which embodiments of
the present invention may be instantiated (e.g., in the form of
computer-readable instructions stored in one or more
computer-readable storage mediums such as, but not limited to, any
type of disk including floppy disks, optical disks, compact disk
read only memories (CD-ROMs), and magnetic-optical disks, read-only
memories (ROMs), flash drives, random access memories (RAMs),
erasable programmable read only memories (EPROMs), electrically
erasable programmable read only memories (EEPROMs), flash memories,
other forms of magnetic or optical storage media, or any type of
media suitable for storing electronic instructions) is shown in
FIG. 2.
[0068] Mobile platform 200 includes a bus 202 or other
communication mechanism for communicating information, and a
processor 204 coupled with the bus 202 for processing information.
Mobile platform 200 also includes a main memory 206, such as a RAM
or other dynamic storage device, coupled to the bus 202 for storing
information and instructions to be executed by processor 204. Main
memory 206 also may be used for storing temporary variables or
other intermediate information during execution of instructions to
be executed by processor 204. Mobile platform 200 further includes
a ROM 208 or other static storage device coupled to the bus 202 for
storing static information and instructions for the processor 204.
A storage device 210, such as a flash drive, is provided and
coupled to the bus 202 for storing information and
instructions.
[0069] Mobile platform 200 may also include a display 212 for
displaying information to a user. An input device 214, including
alphanumeric and other keys, may be provided as well (e.g., for
communicating information and command selections to the processor
204). Another type of user input device is cursor control 216, such
as a trackball or cursor direction keys, may be provided for
communicating direction information and command selections to
processor 204 and for controlling cursor movement on the display
212. In other instances, the alphanumeric and cursor inputs may be
provided via a touch-sensitive display.
[0070] According to one embodiment of the invention, the forgoing
methods and data structures are instantiated in computer software
executed by mobile platform 200, that is by processor 204 executing
sequences of instructions contained in main memory 206. Such
instructions may be read into main memory 206 from another
computer-readable medium, such as storage device 210. Execution of
the sequences of instructions contained in the main memory 206
causes the processor 204 to perform the process steps described
herein.
[0071] Mobile platform 200 may also include a communication
interface 218 coupled to the bus 202. Communication interface 208
provides for two-way data communication to and from the mobile
platform 200. For example, communication interface 218 may include
a wireless radio configured to operate with a telecommunication
carrier's network and/or a computer communication network (e.g., a
WiFi or other such network). In any such implementation,
communication interface 218 sends and receives electrical,
electromagnetic or optical signals which carry digital data streams
representing various types of information. For example, two or more
mobile platforms 200 may be networked together with each using a
respective communication interface 218. Also, a mobile platform 200
may communicate with a server or other host 220 (e.g., one which
provides the evaluation service discussed above) via communication
interface 218 and a network 222.
[0072] Thus, methods and systems for evaluating and rating privacy
risks posed by applications intended for deployment on mobile
platforms and the like have been described.
* * * * *