Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

Per process networking capability techniques are described. In one or
more implementations, a determination is made as to whether access to a
network capability is permitted for a process that is executed on the
computing device based on a token that is associated with the process.
The token has one or more security identifiers that reference one or more
network capabilities described in a manifest. The access to the network
capability is managed based on the determination.

Claims:

1. A method implemented by a computing device, the method comprising:
determining whether access to a network capability is permitted for a
process that is executed on the computing device based on a token that is
associated with the process, the token having one or more security
identifiers that reference one or more network capabilities described in
a manifest; and managing the access to the network capability based on
the determination.

2. A method as described in claim 1, wherein the manifest is stored on
the computing device as part of installation of executable code that,
when executed, implements the process.

3. A method as described in claim 2, wherein the description of the
network capabilities is stored in the tamper-resistant location as part
of installation of the executable code on the computing device.

4. A method as described in claim 1, wherein the token is formed by
accessing a description of the capabilities stored in a tamper-resistant
location of the computing device that is not accessible to the process.

5. A method as described in claim 1, wherein the determining and the
managing are performed through execution of an operating system on the
computing device.

6. A method as described in claim 1, wherein at least one said network
capability described in the manifest indicates whether loopback by the
process is permitted.

7. A method as described in claim 1, wherein at least one said network
capability described in the manifest indicates whether an outgoing
connection over a network is permitted for use by the process.

8. A method as described in claim 1, wherein at least one said network
capability described in the manifest indicates whether incoming and
outgoing connections over a network is permitted for use by the process.

9. A method as described in claim 8, wherein the incoming connection
permits the process to accept an unsolicited connection.

10. A method as described in claim 1, wherein at least one said network
capability described in the manifest indicates whether private network
access is permitted for use by the process.

11. A method as described in claim 1, wherein: one said capability
involves access to specific network traffic described by ports and IP
addresses; or another said capabilities involves access to a remote
network when traffic is guaranteed to arrive at such remote network
securely.

12. A method as described in claim 1, wherein at least one said
capability is configured to enforce changing network traffic over
different periods of time dynamically.

13. A method implemented by a computing device, the method comprising:
probing a network to identify proxy servers or subnets; and managing
access of a process executed on the computing device to network
capabilities of the network based on the identification of the proxy
servers or subnets and an examination of a token that is associated with
the process, the token having one or more security identifiers that
reference network capabilities, described in a manifest, that are
permitted for use by the process.

14. A method as described in claim 13, wherein the token is formed by
accessing a description of the network capabilities stored on the
computing device during installation of executable code that, responsive
to execution, implements the process.

15. A method as described in claim 13, wherein the probing and the
managing are performed as part of execution of an operating system by the
computing device to define, consume, and store boundaries that are to be
enforced.

16. A method as described in claim 13, wherein the probing includes
proving of local subnets, active directories, http proxies, or
administrative settings to pre-specify entities.

17. One or more computer-readable storage media comprising instructions
stored thereon that, responsive to execution on a computing device,
causes the computing device to execute an operating system to form a
token having one or more security identifiers that reference network
capabilities described in a manifest that corresponds to a process formed
through execution of executable code by the computing device, the
executable code and the manifest installed on the computing device from a
package, the token usable by the operating system to manage access of the
process to the network capabilities.

18. One or more computer-readable storage media as described in claim 17,
wherein at least one said network capability described in the manifest
indicates whether loopback by the process is permitted.

19. One or more computer-readable storage media as described in claim 17,
wherein at least one said network capability described in the manifest
indicates whether an outgoing connection over a network is permitted for
use by the process.

20. One or more computer-readable storage media as described in claim 17,
wherein at least one said network capability described in the manifest
indicates whether incoming and outgoing connections over a network is
permitted for use by the process, the incoming connection permits the
process to accept an unsolicited connection.

Description:

BACKGROUND

[0001] The ways in which users may gain access to executable code (e.g.,
software) for execution by a computing device is ever increasing. For
example, users traditionally ventured to a "bricks-and-mortar" store to
locate and purchase applications that were then installed manually by the
users. Consequently, the users could typically trust the software due to
the reputation of the store itself as well as the reputation of the
developers of the software.

[0002] However, with the advent of application marketplaces users may have
access to thousands of different types of applications from hundreds and
even thousands of different developers. Therefore, a user may install a
multitude of applications on a computing device from a wide variety of
sources, some of which may even result in one application compromising
another application. Consequently, it may be difficult to determine by
the user and even by the marketplace itself as to whether the
applications are trustworthy and therefore should be permitted to access
functionality of a user's computing device. This difficulty may be
further exacerbated by malicious parties that may attack the applications
to access functionality supported by the application, such as access to
sensitive data, even for applications that originated from a trustworthy
source.

SUMMARY

[0003] Per process networking capability techniques are described. In one
or more implementations, a determination is made as to whether access to
a network capability is permitted for a process that is executed on the
computing device based on a token that is associated with the process.
The token has one or more security identifiers that reference one or more
network capabilities described in a manifest. The access to the network
capability is managed based on the determination.

[0004] In one or more implementations, a network is probed to identify
proxy servers, subnets, or remote accessible networks. Access of a
process executed on the computing device to network capabilities of the
network is managed based on the identification of the proxy servers or
subnets and an examination of a token that is associated with the
process. The token has one or more security identifiers that reference
network capabilities, described in a manifest, that are permitted for use
by the process. This may be performed in a secure fashion that is not
configured to be affected by the process.

[0005] In one or more implementations, one or more computer-readable
storage media comprise instructions stored thereon that, responsive to
execution on a computing device, causes the computing device to execute
an operating system to form a token having one or more security
identifiers that reference network capabilities described in a manifest
that corresponds to a process formed through execution of executable code
by the computing device, the executable code and the manifest installed
on the computing device from a package, the token usable by the operating
system to manage access of the process to the network capabilities.

[0006] This Summary is provided to introduce a selection of concepts in a
simplified form that are further described below in the Detailed
Description. This Summary is not intended to identify key features or
essential features of the claimed subject matter, nor is it intended to
be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The detailed description is described with reference to the
accompanying figures. In the figures, the left-most digit(s) of a
reference number identifies the figure in which the reference number
first appears. The use of the same reference numbers in different
instances in the description and the figures may indicate similar or
identical items.

[0008] FIG. 1 is an illustration of an environment in an example
implementation that is operable to perform per process networking
capability techniques.

[0009] FIG. 2 is an illustration of a system in an example implementation
showing example implementation of per process networking capability
techniques.

[0010] FIG. 3 is another illustration of a system in an example
implementation showing example implementation of per process networking
capability techniques.

[0011] FIG. 4 is a flow diagram depicting a procedure in an example
implementation in which a package having executable code and a manifest
are installed on a computing device and used to form a token responsive
to initiating execution of the executable code.

[0012] FIG. 5 is a flow diagram depicting a procedure in an example
implementation in which access to capabilities is managed by a computing
device using the token formed in FIG. 4.

[0013] FIG. 6 is a flow diagram depicting a procedure in an example
implementation in which probing is used along with a token to manage per
process access to network capabilities.

[0014] FIG. 7 illustrates an example system that includes the computing
device as described with reference to FIG. 1.

[0015] FIG. 8 illustrates various components of an example device that can
be implemented as any type of computing device as described with
reference to FIGS. 1-3 and 7 to implement embodiments of the techniques
described herein.

DETAILED DESCRIPTION

[0016] Overview

[0017] Traditionally, applications that were executed on a computing
device were given access to most if not all of the functionality of the
computing device, even regardless of whether this access was desired.
This may include unfettered access to a network. However, in some
instances these same applications may be exploited by malicious parties.
The unfettered access may therefore be used by these malicious parties to
access resources on an internet, receive unsolicited connections, access
web-connected functionality, and so on. Consequently, the broad access
given to these applications may now present a significant risk to the
user's computing device as well as to devices that are accessible to the
computing device.

[0018] Per process network capability techniques are described. In one or
more implementations, a capabilities model is utilized to ensure that
applications have access to developer-defined network resources and
cannot access other network resources that are not defined by the
developer. The capabilities model may therefore prevent exploited
applications from taking advantage of network resources that are not
normally utilized by the application. In this way, the model may be used
to ensure that compromised applications are limited to access the defined
network capabilities and limit exploitation of network capabilities that
were defined by the developer as inaccessible to the application. A
variety of other examples are also contemplated, further discussion of
which may be found in relation to the following sections.

[0019] In the following discussion, an example environment is first
described that may employ the network capability techniques described
herein. Example procedures are then described which may be performed in
the example environment as well as other environments. Consequently,
performance of the example procedures is not limited to the example
environment and the example environment is not limited to performance of
the example procedures.

[0020] Example Environment

[0021] FIG. 1 illustrates an operating environment in accordance with one
or more embodiments, generally at 100. Environment 100 includes a
computing device 102 having a processing system 104 that may include one
or more processors, an example of computer-readable storage media
illustrated as memory 106, an operating system 108, and one or more
applications 108. Computing device 102 can be embodied as any suitable
computing device such as, by way of example and not limitation, a desktop
computer, a portable computer, a handheld computer such as a personal
digital assistant (PDA), mobile phone, tablet computer, and the like.
Different examples of a computing device 102 is shown and described below
in FIGS. 6 and 7.

[0022] The computing device 102 also includes an operating system 108 that
is illustrated as being executed on the processing system 104 and is
storable in memory 106. The computing device 102 further includes
applications 110 that are illustrated as being stored in the memory 106
and are also executable on the processing system 104. The operating
system 108 is representative of functionality of the computing device 102
that may abstract underlying hardware and software resources for use by
the applications 110. For example, the operating system 108 may abstract
functionality of how data is displayed on the display device 112 without
the applications 110 having to "know" how this display is achieved. A
variety of other examples are also contemplated, such as to abstract the
processing system 104 and memory 106 resources of the computing device
102, network resources, and so on.

[0023] The computing device 102 is also illustrated as including a process
manager module 114. The process manager module 114 is representative of
functionality of the computing device 102 to manage access of executable
code to capabilities of the computing device 102. For example, the
computing device 102 may receive a package 116 having executable code 118
(e.g., an application) for installation on the computing device 102. The
package 116 may also include a manifest 120 generated by a developer of
the executable code 118 that describes one or more capabilities 122 of
the computing device 102, which may include an ability of the computing
device 102 to access a network 124. Thus, this description may describe
which capabilities of the computing device 102 a process formed through
execution of the executable code 118 is permitted and/or not permitted to
access. For example, the manifest 120 may list a capability that is to be
made accessible to the process and/or may list a capability that is to be
made inaccessible to the process. In this way, a developer of the
executable code 118 may specify capabilities in the manifest 120 to help
reduce and even eliminate an ability of a malicious party to compromise
the application to access capabilities that are not typically accessed by
the executable code 118.

[0024] The process manager module 114, for instance, may leverage firewall
functionality as part of the module itself or in communication with
another module, e.g., a dedicated firewall module. This functionality may
be used to permit or deny access to the network 124 as specified by the
manifest of the package 116. Thus, the executable code 118 may function
as contemplated by a developer of the code and thereby help reduce an
opportunity to compromise the code by malicious parties.

[0025] The package 116 may be received for installation on the computing
device 102 from a variety of different sources. For example, an
application service 126 (e.g., an application store) may be access by the
computing device 102 via the network 124, e.g., the Internet. Upon
purchase, the package 116 that includes the executable code 118 and the
manifest 120 may be communicated via the network 124 for installation on
the computing device 102. In another example, a user may obtain
computer-readable storage media (e.g., an optical disc) that contains the
package 116. Further discussion of installation of the package 118
including the executable code 118 and the manifest on the computing
device 102 may be found in relation to FIG. 2.

[0026] Generally, any of the functions described herein can be implemented
using software, firmware, hardware (e.g., fixed logic circuitry), or a
combination of these implementations. The terms "module,"
"functionality," and "logic" as used herein generally represent software,
firmware, hardware, or a combination thereof. In the case of a software
implementation, the module, functionality, or logic represents program
code that performs specified tasks when executed on a processor (e.g.,
CPU or CPUs). The program code can be stored in one or more computer
readable memory devices. The features of the techniques described below
are platform-independent, meaning that the techniques may be implemented
on a variety of commercial computing platforms having a variety of
processors.

[0027] For example, the computing device 102 may also include an entity
(e.g., software) that causes hardware of the computing device 102 to
perform operations, e.g., processors, functional blocks, and so on. For
example, the computing device 102 may include a computer-readable medium
that may be configured to maintain instructions that cause the computing
device, and more particularly hardware of the computing device 102 to
perform operations. Thus, the instructions function to configure the
hardware to perform the operations and in this way result in
transformation of the hardware to perform functions. The instructions may
be provided by the computer-readable medium to the computing device 102
through a variety of different configurations.

[0028] One such configuration of a computer-readable medium is signal
bearing medium and thus is configured to transmit the instructions (e.g.,
as a carrier wave) to the hardware of the computing device, such as via a
network. The computer-readable medium may also be configured as a
computer-readable storage medium and thus is not a signal bearing medium.
Examples of a computer-readable storage medium include a random-access
memory (RAM), read-only memory (ROM), an optical disc, flash memory, hard
disk memory, and other memory devices that may use magnetic, optical, and
other techniques to store instructions and other data.

[0029] FIG. 2 is an illustration of a system 200 in an example
implementation showing installation of a package 116 on the computing
device 102 and formation of a token to manage process access to network
capabilities of the computing device. As previously described, when a
developer creates executable code 118, a manifest 120 may also be created
that contains a set of capabilities 122 that are declared for processes
implemented through execution of the code. These capabilities 122 may be
registered during installation, which is illustrated as package
deployment 202 in FIG. 2.

[0030] For example, the executable code 118 may be installed for access
via an applications directory 204. The capabilities 122 described in the
manifest may be installed in a capabilities store 206 and associated with
an identity of the package 116 and/or executable code 118 itself. In one
or more implementations, the capabilities store 206 is configured to be
tamper resistant (e.g., physically and/or electronically) such that
malicious code cannot gain access to or modify the capabilities 122
described therein, such as to prevent access by the processes themselves.

[0031] During process creation 208 that results from execution of the
executable code 118, an identifier is obtained that is usable by the
process manager module 114 to locate capabilities described for the
process 210, e.g., an identifier of the package 116, the executable code
118, and so on as described above. These capabilities 122 are then used
as part of the process creation 208 to form a token 212 that may be used
by the process manager module 114 to control access to the capabilities
of the computing device 102.

[0032] The token 212, for instance, may include one or more security
identifiers 214 that correspond to one or more of the capabilities 122
described in the capabilities store 206 for that process. In other words,
the token 212 is populated with the relevant capabilities associated with
the package 116, as security identifiers 214. Thus, the process manager
module 114 may utilize the token 212 when access to a capability is
requested by a process 210 to determine whether that access is to be
permitted for that process 210.

[0033] In one or more implementations, the token 212 cannot be manipulated
by the process 210. The token 212 may also allow the process 210 to
participate in access verification checks for a capability (e.g., ACLs
for a resource). Further, the process manager module 114 may also
implement techniques that involve decisions based on the presence of a
capability (or combination of capabilities) before granting access to a
capability. Because the process 210 does not have direct access to the
token, the process manager module 114 may function as a broker that
leverages the immutability of the token 212 to ensure that appropriate
access is granted to the process 210.

[0034] A variety of different capabilities 122 may be referenced by the
security identifiers 214. Additionally, the security identifiers 214 may
reference these capabilities in a variety of ways. For example, a
developer may create executable code 118 (e.g., an application) and a
manifest 120 that contains a set of declared capabilities for each of the
processes in a package 116 that are implemented through execution of the
executable code 118. This package 116 may also have a "strong identity,"
in which network capabilities are registered with an operating system 108
using this identity when the package 116 is installed.

[0035] Therefore, when the process 210 is subsequently launched (and
includes the package identity as a process creation parameter), the token
212 may be populated with a process identity and network capabilities may
be populated as security identifiers 214. Further, the operating system
108 may prevent the process 210 from modifying the token 212. In one or
more implementations, child processes may inherit the identity and a
subset of the network capabilities, in which the subset is defined by the
parent.

[0036] A variety of different capabilities 122 may be specified by the
manifest 120 for use in managing access of the process 210, e.g., from
pre-defined network capabilities to rich firewall-type rules. For
example, an "internet-client" capability may be defined to manage access
to outgoing connections to the network 124 (e.g., internet) by the
process 210. In another example, an "internet client/server" capability
may be defined to permit both incoming and outgoing network 124
connections. This capability, for instance, may be used to permit the
process to accept unsolicited connections from the Internet as well as
send and receive data through a firewall. In a further example, a
"PrivateNetworkClientServer" capability may be defined to permit
communication to or from computing devices on a same defined network 124,
e.g., a home network, work network, intranet, and so on. A variety of
other examples are also contemplated, such that rich firewall rules may
be created that reference capabilities that may become even more specific
and richer, e.g., access to specific ports. In this way, use of the
security identifiers 214 in the token 212 may permit the process manager
module 114 to manage access of the process 210 to network capabilities,
an example of which is described in relation to the following figure.

[0037] FIG. 3 depicts a system in an example implementation showing
management of access of a process to network capabilities by a process
manager module of FIG. 1. When a process 210 requests access to the
network 124, the process manager module 114 verifies an application
identity (e.g., a package ID 302), and ensures that the network
capabilities 304, 306 specified by the token 212 are a subset of the
network capabilities registered at installation in the capabilities store
206. If the remaining capabilities are sufficient for the network
communication, the communication is allowed. Otherwise, it is blocked.
Thus, the process manager module 114 may function as part of a firewall
to permit and/or deny access to the network capabilities of the computing
device 102.

[0038] In one or more implementations, an application may be permitted to
access a full set of capabilities that are registered in the capabilities
store 206. However, it may also be possible for a process 210 to create a
child process where that is not to have the full set of access rights
that are available to the parent.

[0039] As previously described, a variety of different capabilities may be
declared. Further, the capabilities may be combined to give the process
210 internet and intranet (e.g., private network) access, for either
outbound (e.g., client) or inbound and outbound connections (e.g., client
& server).

[0040] The internet capability may also allow access to HTTP proxies. For
example, the process manager module 114 may actively probe the network to
determine if there are proxy servers or subnets, so networking
capabilities that are tied to a private network (e.g., intranet) or
internet may be leveraged correctly. If an Active Directory server
contains specific information on the subnet definitions, the process
manager module 114 may also leverage this information to help determine
the edge of the subnet. Mechanisms may also be employed in which subnets
and proxies are pre-specified through administrative management tools and
thus probing is not involved. Without such specification through probing
and/or use of the administrative management tools, some devices could be
assigned to the incorrect network type, and therefore the process manager
module 114 could then incorrectly allow or deny access. Thus, the process
manager module 114 may correctly manage capabilities based on this
identification, e.g., whether available via an intranet or Internet.

[0041] In one or more implementations, ports that are deemed critical are
blocked from unsolicited inbound access to prevent common attack vectors
using the same mechanisms. These setting may also be manually configured
via policy. Loopbacks (e.g., connections to same machine, using
127.0.0.1) may also be protected, thereby preventing a process 210 from
"working around" the capabilities defined for that process. For example,
loopback may be tied to a "PrivateNetworkClientServer" capability
described above, but it should be readily apparent that in another
example this may be specified as a separate capability using the model.

[0042] Thus, these techniques may be used to support a mechanism to
restrict network access per-process and offer varying degrees of
granularity as described. As described above, per-process networking
capabilities may be tied to a strong identity for the process. This
identity may also be inherited by child processes, which ensures that a
process is not able to circumvent the networking capabilities that have
been granted to the process by a parent process. High-fidelity networking
capabilities, which have the same flexibility as firewall rules may also
be supported by the process manager module 114. The networking
capabilities, for instance, may be registered at installation with a
firewall, and can have flexibility as can be found for a firewall rule,
which may include network type, connection type, and inbound/outbound
connections. Traffic direction may also be associated with network
profiles as fined by a firewall.

[0043] Further, declared networking capabilities may be combined, to
provide access that is a union of the different capabilities. For
example, network capabilities can be combined for a process 210 to
provide a combination of different network access, such as private
network (e.g., intranet) access, and outbound internet access. A variety
of other examples are also contemplated, further discussion of which may
be found in relation to the following procedures.

[0044] Yet further, firewall rules used to enforce capabilities may be
modified or enforced or tweaked dynamically at run time, e.g., by a "high
integrity" system to provide capabilities that may have increased
usefulness. Capabilities that are defined may be isolated and/or passed
to other firewall components in the system to also further manage the
application in the network correctly.

[0045] Example Procedures

[0046] The following discussion describes per process networking
capability techniques that may be implemented utilizing the previously
described systems and devices. Aspects of each of the procedures may be
implemented in hardware, firmware, or software, or a combination thereof.
The procedures are shown as a set of blocks that specify operations
performed by one or more devices and are not necessarily limited to the
orders shown for performing the operations by the respective blocks. In
portions of the following discussion, reference will be made to the
environment 100 of FIG. 1 and the systems 200, 300 of FIGS. 2 and 3,
respectively.

[0047] FIG. 4 depicts a procedure 400 in an example implementation in
which a package having executable code and a manifest are installed on a
computing device and used to form a token. A package is received at a
computing device that includes executable code and a manifest that
describes capabilities of the executable code (block 402). The package
116, for instance, may be stored on computer readable storage media,
downloaded from an application service 126 over a network 124, and so on.
As previously described, the manifest 120 may describe network
capabilities of the computing device 102 that are to be used during
execution of the code, as contemplated by a developer of the executable
code 122.

[0048] The executable code is installed on the computing device for
execution (block 404). The executable code 122, for instance, may be
configured as an application to be installed on the computing device for
access through an applications directory, a third-party plug-in module,
and so forth.

[0049] The network capabilities described for the executable code by the
manifest are saved in a capabilities store on the computing device, the
saved capabilities usable to form a token to manage access of one or more
processes, formed through execution of the executable code, to
capabilities of the computing device (block 406). The capabilities store
206, for instance, may be configured to be tamper resistant, e.g.,
physically and/or electronically. In this way, capabilities described
therein are not accessible by unauthorized entities, are not accessible
by processes that are executed on the computing device 102, and so on.
Thus, the description of the capabilities may be considered "trustworthy"
and therefore used to form a token that may be used to manage access by
the process.

[0050] An input may then be received to initiate execution of executable
code installed on the computing device (block 408). The input, for
instance, may be received through user selection of a representation of
the code, e.g., an icon, tile, and so on. The input may also originate
from the code itself (e.g., wake at predetermined intervals), from other
code executed on the computing device 102, and so on.

[0051] A token is formed having one or more security identifiers that
reference network capabilities described in a manifest for the executable
code (block 410). As previously described, the security identifiers 122
may enumerate capabilities that are described in the capabilities store
206. The token 212, for instance, may include an identifier that matches
an identifier of the executable code 118 and/or package 116, may be
passed by the executable code 118 itself when requesting access to a
capabilities (e.g., the token itself and/or an identifier usable to find
the token 212), and so forth. The token 212 may then be used to manage
access of the process 210 to one or more network capabilities of the
computing device 102, an example of which may be found in relation to the
following figure.

[0052] FIG. 5 depicts a procedure 500 in an example implementation in
which access to network capabilities is managed by a computing device
using the token formed in FIG. 4. A determination is made as to whether
access to a network capability is permitted for a process that is
executed on the computing device based on a token that is associated with
the process, the token having one or more security identifiers that
reference one or more network capabilities described in a manifest (502).
For example, a request may be received by the process manager module 114
from a process. The process 210 may be implemented through execution of
the executable code 118 by the computing device 102 as previously
described.

[0053] A token 212 may then be located by the process manager module 114,
e.g., using a package 116 identifier, "strong types," and so on as
previously described. The token 212 may be formed to describe access that
is permitted (e.g., reference the capabilities that are permitted) and/or
describe access that is not permitted, e.g., reference capabilities that
are not permitted to be access by a corresponding process 210.

[0054] Access to the network capability is managed based on the
determination (block 504). The process manager module 114, for instance,
may receive a request from the process 210 to access a network
capability, such as to use an outgoing network connection. The process
manager module 114 may then examine the token 212 to determine whether
this network access is permitted, such as to locate a security identifier
that references the outgoing network communication. Thus, the process
manager module 114 may readily determine what access is permitted and
reach accordingly. As previously described, a variety of other examples
are also contemplated, such as to determine which access is not permitted
based on enumeration by the token 212.

[0055] FIG. 6 depicts a procedure 600 in an example implementation in
which a network is probed to identify proxy servers or subnets, which is
used to aid management of network capability access given to a process. A
network is probed to identify proxy servers or subnets (block 602). This
may be performed by forming one or more communications to be sent to the
servers, detect of network settings, and so on.

[0056] Access of a process executed on the computing device to network
capabilities of the network is managed based on the identification of the
proxy servers or subnets and an examination of a token that is associated
with the process, the token having one or more security identifiers that
reference network capabilities, described in a manifest, that are
permitted for use by the process (block 604). As before, the access may
be managed by the process manager module 114 through use of the token
that "says" what capabilities are permitted to be access by a process
associated with the token. Further, the probing may be used to ensure
that access to a network is consistent with this enumeration, e.g., that
access accurately reflects whether a device is accessible via a subnet or
the Internet, and so on. A variety of other examples are also
contemplated.

[0057] Example System and Device

[0058] FIG. 7 illustrates an example system 700 that includes the
computing device 102 as described with reference to FIG. 1. The example
system 700 enables ubiquitous environments for a seamless user experience
when running applications on a personal computer (PC), a television
device, and/or a mobile device. Services and applications run
substantially similar in all three environments for a common user
experience when transitioning from one device to the next while utilizing
an application, playing a video game, watching a video, and so on.

[0059] In the example system 700, multiple devices are interconnected
through a central computing device. The central computing device may be
local to the multiple devices or may be located remotely from the
multiple devices. In one embodiment, the central computing device may be
a cloud of one or more server computers that are connected to the
multiple devices through a network, the Internet, or other data
communication link. In one embodiment, this interconnection architecture
enables functionality to be delivered across multiple devices to provide
a common and seamless experience to a user of the multiple devices. Each
of the multiple devices may have different physical requirements and
capabilities, and the central computing device uses a platform to enable
the delivery of an experience to the device that is both tailored to the
device and yet common to all devices. In one embodiment, a class of
target devices is created and experiences are tailored to the generic
class of devices. A class of devices may be defined by physical features,
types of usage, or other common characteristics of the devices.

[0060] In various implementations, the computing device 102 may assume a
variety of different configurations, such as for computer 702, mobile
704, and television 706 uses. Each of these configurations includes
devices that may have generally different constructs and capabilities,
and thus the computing device 102 may be configured according to one or
more of the different device classes. For instance, the computing device
102 may be implemented as the computer 702 class of a device that
includes a personal computer, desktop computer, a multi-screen computer,
laptop computer, netbook, and so on.

[0061] The computing device 102 may also be implemented as the mobile 704
class of device that includes mobile devices, such as a mobile phone,
portable music player, portable gaming device, a tablet computer, a
multi-screen computer, and so on. The computing device 102 may also be
implemented as the television 706 class of device that includes devices
having or connected to generally larger screens in casual viewing
environments. These devices include televisions, set-top boxes, gaming
consoles, and so on. The techniques described herein may be supported by
these various configurations of the computing device 102 and are not
limited to the specific examples the techniques described herein.

[0062] The cloud 708 includes and/or is representative of a platform 710
for content services 712. The platform 710 abstracts underlying
functionality of hardware (e.g., servers) and software resources of the
cloud 708. The content services 712 may include applications and/or data
that can be utilized while computer processing is executed on servers
that are remote from the computing device 102. Content services 712 can
be provided as a service over the Internet and/or through a subscriber
network, such as a cellular or Wi-Fi network.

[0063] The platform 710 may abstract resources and functions to connect
the computing device 102 with other computing devices. The platform 710
may also serve to abstract scaling of resources to provide a
corresponding level of scale to encountered demand for the content
services 712 that are implemented via the platform 710. Accordingly, in
an interconnected device embodiment, implementation of functionality of
the functionality described herein may be distributed throughout the
system 700. For example, the functionality may be implemented in part on
the computing device 102 as well as via the platform 710 that abstracts
the functionality of the cloud 708.

[0064] FIG. 8 illustrates various components of an example device 800 that
can be implemented as any type of computing device as described with
reference to FIGS. 1, 2, and 7 to implement embodiments of the techniques
described herein. Device 800 includes communication devices 802 that
enable wired and/or wireless communication of device data 804 (e.g.,
received data, data that is being received, data scheduled for broadcast,
data packets of the data, etc.). The device data 804 or other device
content can include configuration settings of the device, media content
stored on the device, and/or information associated with a user of the
device. Media content stored on device 800 can include any type of audio,
video, and/or image data. Device 800 includes one or more data inputs 806
via which any type of data, media content, and/or inputs can be received,
such as user-selectable inputs, messages, music, television media
content, recorded video content, and any other type of audio, video,
and/or image data received from any content and/or data source.

[0065] Device 800 also includes communication interfaces 808 that can be
implemented as any one or more of a serial and/or parallel interface, a
wireless interface, any type of network interface, a modem, and as any
other type of communication interface. The communication interfaces 808
provide a connection and/or communication links between device 800 and a
communication network by which other electronic, computing, and
communication devices communicate data with device 800.

[0066] Device 800 includes one or more processors 810 (e.g., any of
microprocessors, controllers, and the like) which process various
computer-executable instructions to control the operation of device 800
and to implement embodiments of the techniques described herein.
Alternatively or in addition, device 800 can be implemented with any one
or combination of hardware, firmware, or fixed logic circuitry that is
implemented in connection with processing and control circuits which are
generally identified at 812. Although not shown, device 800 can include a
system bus or data transfer system that couples the various components
within the device. A system bus can include any one or combination of
different bus structures, such as a memory bus or memory controller, a
peripheral bus, a universal serial bus, and/or a processor or local bus
that utilizes any of a variety of bus architectures.

[0067] Device 800 also includes computer-readable media 814, such as one
or more memory components, examples of which include random access memory
(RAM), non-volatile memory (e.g., any one or more of a read-only memory
(ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A
disk storage device may be implemented as any type of magnetic or optical
storage device, such as a hard disk drive, a recordable and/or
rewriteable compact disc (CD), any type of a digital versatile disc
(DVD), and the like. Device 800 can also include a mass storage media
device 816.

[0068] Computer-readable media 814 provides data storage mechanisms to
store the device data 804, as well as various device applications 818 and
any other types of information and/or data related to operational aspects
of device 800. For example, an operating system 820 can be maintained as
a computer application with the computer-readable media 814 and executed
on processors 810. The device applications 818 can include a device
manager (e.g., a control application, software application, signal
processing and control module, code that is native to a particular
device, a hardware abstraction layer for a particular device, etc.). The
device applications 818 also include any system components or modules to
implement embodiments of the techniques described herein. In this
example, the device applications 818 include an interface application 822
and an input/output module 824 that are shown as software modules and/or
computer applications. The input/output module 824 is representative of
software that is used to provide an interface with a device configured to
capture inputs, such as a touchscreen, track pad, camera, microphone, and
so on. Alternatively or in addition, the interface application 822 and
the input/output module 824 can be implemented as hardware, software,
firmware, or any combination thereof. Additionally, the input/output
module 824 may be configured to support multiple input devices, such as
separate devices to capture visual and audio inputs, respectively.

[0069] Device 800 also includes an audio and/or video input-output system
826 that provides audio data to an audio system 828 and/or provides video
data to a display system 830. The audio system 828 and/or the display
system 830 can include any devices that process, display, and/or
otherwise render audio, video, and image data. Video signals and audio
signals can be communicated from device 800 to an audio device and/or to
a display device via an RF (radio frequency) link, S-video link,
composite video link, component video link, DVI (digital video
interface), analog audio connection, or other similar communication link.
In an embodiment, the audio system 828 and/or the display system 830 are
implemented as external components to device 800. Alternatively, the
audio system 828 and/or the display system 830 are implemented as
integrated components of example device 800.

CONCLUSION

[0070] Although the invention has been described in language specific to
structural features and/or methodological acts, it is to be understood
that the invention defined in the appended claims is not necessarily
limited to the specific features or acts described. Rather, the specific
features and acts are disclosed as example forms of implementing the
claimed invention.