Patent Publication Number: US-8990399-B2

Title: Resource sharing in multi-principal browser

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of and claims priority under 35 U.S.C. 120 to U.S. patent application Ser. No. 12/550,293, filed on Aug. 28, 2009, titled “Resource Sharing in Multi-principal Browser,” which is incorporated by reference herein. This application is also related to U.S. patent application Ser. No. 12/550,263, filed on Aug. 28, 2009, titled “Access Control In A Multi-Principal Browser”, which is incorporated by reference herein for all that it teaches. 
    
    
     BACKGROUND 
     A wide range of conventional network services are being offered to users by service providers or through software applications. The conventional network services offered may allow users to access these services via a web browser. These web browsers were originally designed and built as single web site platforms on which a principal, namely a web site, is viewed one at a time and the browser resources are devoted to that web site principal. 
     Problems occur, however, when the web browsers evolve into principal operating environments, where mutually distrusting web site principals share the underlying system resources. To avoid depriving users access to multiple web sites, some service providers have proposed to architect the web browser as a multiple principal operating system. However, there is no management of resources available in the multiple principal operating system browsers. 
     The problem with the multiple principal operating systems is that it does not manage resource sharing for today&#39;s existing browsers. In particular, the problem is a lack of managing resource sharing for computing processing units (CPUs), memory, or network bandwidth for web applications. This lack of resource management impacts capabilities and quality of the web applications. 
     In an attempt to manage these resources, one technique maps web site principals onto commodity operating system&#39;s user principals (e.g., putting different web site principals into separate processes and labeling each process with a unique identifier). However, this technique has been found to be insufficient for the web applications, particularly because the web applications embed content. This problem occurs when web applications embed different content from several different principals. 
     Without resource management available, a web site principal is given the ability to obtain arbitrary amounts of resources. There is no fairness of the resources across the contending principal instances. The principal instances are an independent execution instance of the same web site. Thus, there is no resource management across the web site principals in today&#39;s operating systems, especially for the web applications&#39; recursive cross-principal service composition. 
     SUMMARY 
     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 to limit the scope of the claimed subject matter. 
     This disclosure describes resource management services that, for example, manage resource sharing among two or more contending web entities (e.g., web sites or web applications) in a multi-principal browser. Managing resources includes determining how to divide the resource to share between the different web entities and dividing the resource for sharing among authorized web entities. The resources may include a central processing unit (CPU), a memory, a network bandwidth, and devices (e.g., a camera, a Global Positioning System navigation device, etc.). 
     In an implementation, the resource sharing services include sharing the resources that are in contention among the principal instances. This implementation applies a Document Object Model-recursive resource allocation policy. With this policy, the resources may be divided recursively along a principal-embedding hierarchy of a web entity to provide a balanced and a proportional share of the resources among the web entities. The resources may be divided equally among contending principal instances. Furthermore, the resource sharing services may include identifying resource allocation mechanisms based on a resource type. 
     In another implementation, an application-specified resource allocation policy specifies a resource share for the web entity and embedded content. The resource share is granted based on a priority assigned for the web entity and the embedded content. This process allows web programmers to explicitly influence resource management based on web entity semantics. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The Detailed Description is set forth 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 figures indicates similar or identical items. 
         FIG. 1  is a schematic showing an illustrative environment for resource sharing using a multi-principal browser. 
         FIG. 2  is a block diagram showing an architecture for the multi-principal browser in the environment of  FIG. 1 . 
         FIG. 3  is a block diagram showing an illustrative computing device usable with the environment of  FIG. 1  and the architecture of  FIG. 2 . 
         FIG. 4  is a block diagram showing illustrative resources by identifying resource types, illustrating resource examples, and showing resource sharing mechanisms. 
         FIG. 5  is a flowchart showing an illustrative process of a Document Object Model (DOM)-recursive resource allocation policy. 
         FIG. 6  is a block diagram showing an illustrative DOM-recursive resource allocation policy usable with the flowchart of  FIG. 5 . 
         FIG. 7  is a block diagram showing illustrative resource allocation mechanisms. 
         FIG. 8  is a flowchart showing an illustrative process of an application-specified resource allocation policy. 
         FIG. 9  is a block diagram showing illustrative mechanisms for the application-specified allocation policy. 
     
    
    
     DETAILED DESCRIPTION 
     Overview 
     As discussed above, conventional operating systems may not always provide an effective way of managing resources in today&#39;s existing browsers. For example, in some instances (e.g., in instances where a browser operates multiple web applications from mutually distrusting web sites), it may be difficult to manage which resources to share and to determine how much resource to allocate for a web entity. Moreover, conventional operating systems may not be able to readily distinguish when the web entity obtains arbitrary amounts of resources (i.e., web applications may embed content from several, different principals). This lack of resource management impacts the capabilities and quality of today&#39;s web entity, making them less rich and less robust than desktop counterparts. This disclosure describes various illustrative ways of managing resources by, for example, identifying the resources to be shared and determining how to allocate the resources fairly among the web entities. Fairness may be defined as allocating a balanced and a proportional share of the resource or a predetermined allocation of the resource to the contending web entity. Thus, the techniques described in detail below provide the web entity with superior service quality, fairness, and security, and enable the web entity to perform as richly as corresponding desktop applications. 
     In an implementation, the techniques for resource sharing are to manage resources by determining how to share the resources between contending authorized principals or their principal instances. For example, in a browser, a principal may be a web site. The techniques allow a user with a computing device to access a principal operating systems-based browser with a resource module to determine how to divide the resources fairly to enable the web entities to perform to their capabilities. By way of example and not limitation, the resources may include a computer processing unit (CPU), a memory, a network bandwidth, and devices like a camera, a microphone, or a global positioning system (GPS) navigation unit. Depending on the resources, there are different resource allocation mechanisms applicable for each type. 
     In an implementation, the techniques employ a Document Object Model (DOM)-recursive resource allocation policy to manage resource sharing for certain types of resources. With this policy, a resource is divided recursively among a principal embedding hierarchy of a web entity. For instance, the resources may be divided equally among the top-level principals. A top-level principal may be the web entity that is opened within a browser tab. In an example, if the top-level principal embeds three other principals, the resource share may be split into four by dividing among the top-level principal and each of the embedded principals. These four would equal a total share granted to another top-level tab. Thus, the DOM-recursive resource allocation policy provides fairness across the contenting principal instances at a same level of the principal embedding hierarchy. 
     In another implementation, the resource management service manages resource sharing using an application-specified resource allocation policy for web entities. This technique is used when a web entity itself may know how to optimally allocate resources among itself and embedded content. This technique enables web programmers to explicitly influence resource management based on the web entity semantics. In particular, a prioritizing order may be identified for the resources based on the embedded content. The prioritizing order of the resource may be determined based on a level of a parent or a child. Furthermore, the application-specified resource allocation policy may also allow a predetermined network bandwidth to be expressed, which indicates the bandwidth needed for optimal service quality. 
     While aspects of described techniques can be implemented in any number of different computing systems, environments, and/or configurations, implementations are described in the context of the following illustrative computing environment. 
     Illustrative Environment and Architecture 
       FIG. 1  is a block diagram of an illustrative environment  100  in which resource management services may be accessed from a web browser or other client application on a computing device. The environment  100  includes an illustrative computing device  102 , which may take a variety of forms, including, but not limited to, a desktop computer, a portable handheld computing device (e.g., a personal digital assistant, a smart phone, a cellular phone), a thin client, a laptop computer, a media player, or any other device capable of connecting to one or more network(s)  104  to access network services, a network service provider, a web site, web entity, and the like. A user  102  may employ the illustrative computing device  102  to connect to the one or more network(s)  104 . 
     The one or more network(s)  104  represents any type of communications network(s), including multiple different types of networks, interconnected with each other and functioning as a single large network (e.g., the Internet or an intranet). The network  104  may include wire-based networks (e.g., cable), wireless networks (e.g., cellular, satellite, etc.), cellular telecommunications network(s), and IP-based telecommunications network(s) (e.g., Voice over Internet Protocol networks). The network  104  may use any number of protocols and configurations to enable the computing device  102  to access other devices, content, information, and resources. 
     The computing device  102  may include a “standard” or “conventional” operating system identified as OS  108 . In some implementations, this OS  108  may be a commercially available product, such as the WINDOWS® family of operating systems. The OS  108  is the interface between hardware and the user  106 , handles details of the operation of the hardware, manages services and application programs. Typically, the application programs may request service from the OS  108  by system calls. 
     The computing device  102  also includes a multi-principal browser  110 . The multi-principal browser  110  manages resources and sharing of resources between various web site principals. The multi-principal browser  110  includes a browser kernel. More discussion follows in  FIG. 2  on this architecture. The OS  108  recognizes the user  106  as a principal and the multi-principal browser  110  recognizes web entity as a principal. The web entity includes, but is not limited to, a web application, a web page, a web site, a web service, a process of a web service, and the like. The web entity may be accessible through a web browser over the Internet or an intranet. The web entity may have embedded content associated with it. 
     In the illustrated example, the browser kernel may include a resource sharing module  112  to implement resource management, specifically the resource sharing services. The resource sharing module  112  provides resource sharing services to manage the resources and to determine how the resources may be shared among the principals that are in contention. As mentioned previously, the resources may include a computer processing unit (CPU), a memory, a network bandwidth, display, and devices like a camera, a microphone, or a global positioning system (GPS) navigation unit. Furthermore, the resource sharing module  112  may incorporate functionality to provide resource management services to the computing device  102 , including identifying the resources to be shared, assigning resource allocation, terminating allocation of the resources, giving absolute priority of resource use, and the like. Furthermore, the resource sharing module  112  may split resources equally among the top-level contending principal instances, assuming there is a principal embedding hierarchy of a web application. The web entity may include a web site or a web application as a first-class principal in the multi-principal browser  110  with the resource module  112 . 
     The environment  100  includes one or more web site servers  114 ( 1 ),  114 ( 2 ), . . . ,  114 (S) which may be a representative set of servers that is accessible via the network(s)  104 . The servers  114  may be independent servers, or a collection of servers that are configured to perform larger scale functions (e.g., a server farm or a datacenter), or a set of servers configured to host one or more sites (e.g., web sites) accessible by the network  104 . In the illustrated example, the servers  114  may represent private servers that serve content and programming (e.g., operating system, principal operating system-based browser) to the computing device  102 , the thin client, and the like. Alternatively, the servers  114 ( 1 )- 114 (S) may represent a wireless services provider that provides content to wireless devices. In still other implementations, the servers  114 ( 1 )- 114 (S) may be configured to host a service provider, such as a web site accessible by the computing device  102  via the Internet. 
     These various arrangements exhibit examples of environments where a resource sharing module  112  may be employed, working in operation with the browser kernel and the principal operating system-based browser  110 . In the illustrated example shown in  FIG. 1 , the user  106  operates the computing device  102  to connect via the network(s)  104  to the servers  114 . In this example, the resource sharing module  112  in operation with the browser kernel, the principal operating system browser  110 , are capable of applying a resource allocation policy or of receiving application-specified allocation from a web programmer or web applications. The resource sharing module  112  may determine how to share the resources in response to the policies, web programmer instructions, web applications, or may manage the resources on a pre-determined basis, such as custom allocations adjusted programmatically at runtime or absolute priority granted for web entities that are considered critical. 
     In an implementation, a resource sharing module may be located on a server or may be part of an operating system browser on the server accessible by a computing device. In some instances, the resource sharing module may be executed with a server-side resource sharing module to manage resources by monitoring ongoing resource sharing and activities between the computing device and the principal operating system browser servers. 
       FIG. 2  is a block diagram showing an illustrative architecture  200 , for the principal operating system-based browser  110  that supports web applications or web sites as first-class principals. In particular, the multi-principal browser  110  in operation with the resource sharing module  112  are to manage resource sharing. As mentioned previously, a principal may be a web site. A principal instance may be illustrated as representing the web site. 
     The principal may be labeled with a triple notation of &lt;protocol, domain name, port&gt;, as in a same-origin policy that is found in today&#39;s browsers, which are not constructed as multi-principal operating systems. The principals (web sites) may have different origin tuples, and each principal&#39;s content is put into a separate principal instance for that origin tuple. 
     Shown are two web site principals, web site A and web site B. Web site A may include principal instance A  202  and LibWeb  204  while Web site B may include principal instance B  206  and LibFlash  208 . These are runtime libraries for a particular kind of web content, (i.e., LibWeb is used for web content of HTML/JavaScript and LibFlash is used for Flash content) that utilize the browser kernel&#39;s system calls to access resources. The web site principals, web site A and web site B, may embed other principals through frame and object tags. 
     The principal may be a unit of protection. Principals may be completely isolated in resource access and usage. Any type of resource sharing may be made explicit in the process. Similar to desktop applications, where instances of an application are run in separate processes for failure containment and independent resource allocation, the principal instance may be a unit of failure containment and a unit of resource allocation. For example, navigating to the same URL in different tabs corresponds to two instances of the same principal; when a.com embeds two b.com iframes, the b.com iframes correspond to two instances of b.com. However, the frames that share the same origin as the host page may be in the same principal instance as the host page by default. Though the host page may be allowed to designate an embedded same-origin frame or object as a separate principal instance for independent resource allocation and failure containment. Principal instances may be isolated for all runtime resources, but principal instances of the same principal may share persistent state, such as cookies and other local storage. Protection unit, resource allocation unit, and failure containment unit may each have a different mechanism depending on the system implementation. Because the implementation of the principal instances may contain native code, the operating system processes may be used for all three purposes. 
     The multi-principal browser  110  may include a browser kernel (BK)  210 , the operating system  108  now operating as a commodity operating system (OS)  212 , and the resource sharing module  112 . The BK  210  runs in a separate protection domain and interposes between the browser principals and the commodity OS  212  (i.e., the OS  108  may be customized). The BK  210  mediates the principals&#39; access to system resources by functioning as an operating system to the browser principals. For example, the BK  210  handles principal operating system calls  214  from the principal instances A  202  and B  206  and utilizes the commodity OS  212  to manage the resources. The logic for processing the web entity (e.g., libweb, libflash, other plug-ins) may reside in the principal space, and the BK  210  may be agnostic to web entity semantics. The resource management functionality may be mostly handled in the BK  210  with guidance from the resource sharing module  112  and with some customization of the OS  108 , now operating as the commodity OS  212 . In an implementation, the process may customize a CPU scheduling in Windows® in order to manage resources. 
     The process may restrict the principal instance&#39;s process where the principal instance A  202  and B  206  issues a system call  214  by inter-process communication (IPC) to the browser kernel  210 . The process operates without interacting with the underlying operating system  108 , now referred to as the commodity operating system  212 , and may issue system calls  214  to the browser kernel  210 . The browser kernel  210  runs as a separate process in the commodity OS  212 , and in combination with the resource sharing module  112  manages system resources for the web principals, web sites A and B. As indicated by the arrow on the left, each principal instance, principal instances A  202  and B  206 , may execute in a restricted operating system process  216  for the browser runtime. 
     Implementation of the browser kernel  210  and separating the principals into principal instances A  202  and B  206  may enforce several beneficial results: First, communication and sharing across the protection boundaries of each principal may be explicit and may use the browser kernel  210 . Second, least privileges (that is, giving no more privileges than necessary for operation) for each principal are maintained, so compromise of a principal will not give the principal more capabilities than already permitted by the browser kernel  210 . Third, security policies may be enforced for plug-ins. Fourth, the browser kernel  210  provides a central point to implement security decisions, resulting in a simpler and more robust architecture. Thus, security policies may be consistent across all resources, including memory, Document Object Model (DOM) objects, script objects, persistent state objects such as cookies, display, and network communications. 
     Illustrative Computing Device 
       FIG. 3  is a schematic block diagram showing details of an illustrative computing device or server, such as the computing device  102  of  FIG. 1 . The computing device or the server may be configured as any suitable system capable of managing resources, which includes, but is not limited to, identifying, tracking, detecting, allocating, assigning, sharing, and splitting the resources. 
     In one illustrative configuration, the computing device  102  includes at least one processor  302  and a memory  304 . The computing device  102  may also include additional removable storage  306  and/or non-removable storage  308 . 
     Turning to the contents of the memory  304  in more detail, the memory  304  may store the operating system  108 /commodity OS  212 , the multi-principal browser  110 , the browser kernel  210 , the resource sharing module  112 , and one or more applications for implementing all or a part of the resource management services. 
     The memory may include an allocation resource logic  310 , or this may be included as part of the multi-principal browser  110 , or the functionality may be included as part of the resource sharing module  112 . The allocation resource logic  310  may provide a policy to determine how much of a resource each contending principal instance receives based on the policy. In an implementation, a Document Object Model (DOM)-recursive resource allocation policy may be used by default. 
     The DOM-recursive policy is fair and prevents an embedded, misbehaving principal from monopolizing resources. The fairness includes assigning a balanced and a proportional share of the resources or a predetermined amount of resource allocation to the web entities. This DOM-recursive policy corresponds to a Hypertext Markup Language (HTML) DOM tree&#39;s hierarchical relationship between involved principals. The DOM-recursive policy may be used for divisible resources, such as CPU, network bandwidth, and for transactional resources. The resources like a photo camera, a GPS navigation unit, and an accelerometer are considered transactional. Transactional in the sense that each device interaction takes just one synchronous system call, for a short transaction (rather than a long session). With this policy, the resource may be divided recursively along the principal embedding hierarchy of a web entity. In an implementation, the resource sharing module  112  in operation with the multi-principal browser  110  may divide the resource into equal fractions among the top-level contending principal instances (each of which runs in a separate browser tab). The fraction of the resource assigned to the principal instance may then be split fairly among the principal instance itself and all of its embedded principal instances that are actively contending for the resource. One key property of the DOM-recursive policy is that it provides fairness, such as a balanced and a proportional share of the resources across all the contending principal instances at the same level of the principal embedding hierarchy, but not across all the principal instances. 
     The allocation resource logic  310  in operation with the resource sharing module  112  may identify different resource allocation mechanisms for different types of resources. In an implementation, the allocation resource logic  310  may identify the resource allocation as a scheduler used with the DOM-recursive policy for allocating computing processing unit and transactional resources. In another implementation, the allocation resource logic  310  may identify the resource allocation as bandwidth shapers for allocating network bandwidth. In yet another implementation, the allocation resource logic  310  may identify the resource allocation as the browser kernel  210  for allocating memory to principal instances. In one instance, the allocation resource logic  310  may identify a parent allocating display to its children. Also, the allocation resource logic  310  and resource sharing module  112  may identify the browser kernel  210  as the resource allocation for dynamic principal embedded principals. The principals are ones that are created and embedded by another principal dynamically during the rendering/execution in the browser. Thus, for resources scheduled with the DOM-recursive policy, the browser kernel  210  may recalculate the resource shares for the schedulers. The resource options described may allow the multi-principal browser  110  to insulate resource usage of a web page from untrusted content it embeds and to allocate resources fairly among multiple web entities or applications embedded on the same web page. 
     In some implementations, memory  304  may include an application-specified allocation logic  312 , or this may be included as part of the multi-principal browser  110 , or the functionality may be included as part of the resource sharing module  112 . The application-specified allocation logic  312  may be used when a web entity itself may know how to optimally allocate resources among itself and embedded content associated with the web entity. In an example, a web entity such as a.com may embed an untrusted ad, the web entity itself might want to restrict the ad&#39;s CPU and memory usage. In another example, if a.com embeds a video application, the web entity might indicate that this video may best be viewed with a bandwidth of 200 Kbps. To support such scenarios, the application-specified allocation logic  312  may enable web programmers to provide application-specified resource allocation policy for their web entities. This logic does not violate hierarchical fairness. 
     The application-specified allocation logic  312  may be based on different attributes or policies that are determined by the web entity, a web programmer, or in combination with the service provider. In some implementations, the application-specified allocation logic  312  may identify priority levels for the web entity to determine the resource allocation. 
     For example, the web entity or the web programmer may assign a higher priority or give more weight for a particular attribute to determine whether to grant resource allocation. In some instances, the attribute assigned with the higher weight may be a parent level associated with the embedded content (e.g., such as parent web site embedded with child of untrusted ads). In another example, the web entity or the web programmer may assign a lower priority or less weight for an embedded application or web content to terminate the application (e.g., web site associated with embedded ads). The application-specified allocation logic  312  may monitor changes to the embedded content or web applications or to a change in the parent-child level, on a pre-determined time interval, such as every x milliseconds, or in response to receiving notification from the web content (i.e., web sites or web applications). 
     The allocation resource logic  310  and the application-specified allocation logic  312  in operation with the resource sharing module  112  may determine suitable resource allocation mechanisms for the web entity based at least in part on the type of resource or on the priority of the entity, respectively. The allocation resource logic  310  may manage resource options for the web entity, such as the web applications from the web sites. The resource sharing actions provide superior service quality, fairness, and security, as this enables the web entities to operate to capabilities similar to desktop applications. 
     The computing device  102  may also contain communications connection(s)  314  that allow the processor  302  to communicate with other computing devices, other network servers, network storage, and/or other devices on the network(s)  104 . 
     The computing device  102  may also include one or more known input device(s), such as a keyboard, mouse, pen, voice input device, touch input device, etc., and output device(s), such as a display, speakers, printer, etc. All these devices are well known in the art and are not discussed at length here. 
     Any memory described herein may include volatile memory (such as RAM), nonvolatile memory, removable memory, and/or non-removable memory, implemented in any method or technology for storage of information, such as computer-readable storage instructions, data structures, applications, program modules, emails, and/or other content. Also, any of the processors described herein may include onboard memory in addition to or instead of the memory shown in the figures. The memory may include storage media such as, but not limited to, random access memory (RAM), read only memory (ROM), flash memory, optical storage, magnetic disk storage or other magnetic storage devices, or any other medium which may be used to store the desired information and which may be accessed by the respective systems and devices. 
     The computing device  102  as described above may be implemented in various types of systems or networks. For example, the computing device may be a part of, including but is not limited to, a client-server system, a peer-to-peer computer network, a distributed network, an enterprise architecture, a local area network, a wide area network, a virtual private network, a storage area network, and the like. 
     Illustrative Resources and Approaches 
       FIG. 4  is a block diagram showing illustrative resource characterization  400  for identifying a resource type, providing resource examples, and determining the resource sharing mechanisms that may be performed based on at least in part of the resource type. 
     In the first column on the left, the resources types  402  may be divided into runtime resources  404  and persistent resources  406 . The runtime resources  404  may only be available when the browser is on, while the persistent resources  406  like storage may survive browser restarts. 
     In the second column, the runtime resources  404  may be further subdivided into divisible resources  408  and non-divisible resources  410 . A divisible resource  408  may allow fractions of the resource (whether in time dimension or space dimension) to be shared or allocated among the contending principal instances. Typically, non-divisible resources  410  may not be divided in time or space. 
     In the next column, shown are three kinds of resource examples  412 : divisible resource examples  408 , non-divisible resource examples  410 , and persistent resource examples  406 . The divisible resource examples  408  include but are not limited to, CPU, memory, display, data network bandwidth, and transactional resources. The multi-principal browser  110  treats the resources like a photo camera, a GPS navigation unit, and an accelerometer as transactional, in the sense that each device interaction takes just one synchronous system call; each use is a short transaction (rather than a long session). Transactional resources are also divisible resources  408  since their system call invocations (along the time dimension) may need to be fairly processed for contending principal instances. 
     The non-divisible examples  410  may include session-based resources, such as, a telecom network, a microphone, a speaker, and a video camera. 
     Note that, an allocated fraction of certain resources may be accessible to only one authorized principal instance or principal at a time. For example, a CPU time slice or a piece of memory allocated for the principal instance may only be used by that principal instance. On the other hand, resources like the speaker, the microphone, and the video camera may support simultaneous access from multiple principal instances. For example, several principal instances may be fine with outputting to the speaker concurrently and having their audio data mixed together; audio and video streams from the microphone, and the video camera may be received simultaneously by multiple principal instances for various recording purposes. 
     The persistent resource examples  406 , include storage resources, such as disk and flash. In some instances, the persistent resource examples  406  may be the browser&#39;s storage resources, which include cookies and local storage. 
     Based on the resource types  402 , the resource sharing mechanisms  414  may be determined from each type of resource. Described are possible resource sharing mechanisms  414 , which include: DOM-recursive resource allocation policy  416 , an application-specified resource allocation policy  418 , and two based on user-arbitrated sharing approaches  420 ,  422 . For divisible resources  408 , the DOM-recursive resource allocation policy  416  and the application-specified resource allocation policy  418  may be applied when under resource contention. 
     For non-divisible resources  410 , the user-arbitrated sharing  420  may be applied when under resource contention. As mentioned, the non-divisible examples  410  may include session-based resources, such as, the telecom network, the microphone, the speaker, and the video camera. When such resources are under contention, the user  106  may need to determine a winner based on their needs. For example, the user  106  may be on a phone using the telecom network through one application; if another application needs to make a phone call, the browser kernel may prompt the user  106  to make a decision to either staying on the current call or making a new call. 
     For persistent resources  406 , the browser&#39;s storage resources may also include cookies and local storage. Only the user  106  may be responsible for reclaiming and arbitrating the storage space among principals when storage is under contention (e.g., running out of disk space)  422 . In an example, the user  106  may prefer all of their address book to be present at all time, even if the address book for web applications has exceeded a fair share of the storage space. 
     For illustrative purposes, a table below shows summarizes exclusive-use and concurrent-use resources. For concurrent-use resources, web applications may be allowed to choose between concurrent and exclusive use. The multi-principal browser  110  provides defaults for all such devices, and web applications may be allowed to change the default later. For example, the multi-principal browser  110  permits concurrent use for the speaker by default, but not for the microphone for privacy reasons. 
     
       
         
           
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 Exclusive Use vs. Concurrent Use For Allocated Fraction 
               
               
                 of a Resource 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                 Exclusive use for principal 
                 CPU, memory, display, network 
               
               
                 instance 
                 bandwidth, camera, GPS, dialer 
               
               
                 Exclusive use for principal 
                 Storage 
               
               
                 Concurrent use 
                 Speaker, microphone, video camera 
               
               
                   
               
            
           
         
       
     
     Illustrative Processes and Mechanisms 
       FIGS. 5 and 8  are flowcharts showing illustrative processes for determining resource sharing and determining how to allocate the resources.  FIG. 5  is a flowchart based on at least in part on the DOM-recursive resource allocation policy and  FIG. 8  is a flowchart based on at least in part on the application-specified resource allocation policy. The processes for the policies are illustrated as a collection of blocks in logical flowcharts, which represent a sequence of operations that may be implemented in hardware, software, or a combination. For discussion purposes, the processes are described with reference to the computing environment  100  shown in  FIG. 1 , the architecture shown in  FIG. 2 , the computing device  102  shown in  FIG. 3 , and the resources shown in  FIG. 4 . However, the processes may be performed using different environments and devices. Moreover, the environments and devices described herein may be used to perform different processes. 
     For ease of understanding, the methods are delineated as separate steps represented as independent blocks in the figures. However, these separately delineated steps may not be construed as necessarily order dependent in their performance. The order in which the process is described is not intended to be construed as a limitation, and any number of the described process blocks maybe be combined in any order to implement the method, or an alternate method. Moreover, it is also possible that one or more of the provided steps will be omitted. 
     DOM-Recursive Resource Policy and Mechanisms 
       FIGS. 5-7  illustrate resource allocation and resource allocation mechanisms.  FIG. 5  is an illustrative process of the DOM-recursive resource allocation policy,  FIG. 6  are examples of allocating the resource using instructions from the DOM-recursive resource allocation policy, and  FIG. 7  illustrates examples of resource allocation mechanisms. 
       FIG. 5  is a flowchart illustrating the illustrative process  500 , describing in details the instructions for the DOM-recursive resource allocation policy. The resource sharing in the multi-principal browser  110  is performed on principal instances, which form the unit of resource allocation. In the discussion that follows for resource sharing, the resources identified may include the divisible resources  408  and the transactional resources. 
     In the face of resource contention, fairness across contending principal instances (e.g., round-robin CPU scheduling for desktop applications in a commodity OS) may not be possible for the web entities. Unlike desktop applications, the web entity may embed content from other principals; enabling the web entity to acquire an arbitrary amount of resources. 
     Referring to  FIG. 5  illustrates the process for resource sharing, which includes determining the amount of resource that each contending principal instance receives  502 . Thus, resource sharing is possible in the multi-principal browser  110  where the resource sharing module  112  may help determine the amount of resource for the principal instances, which form the unit of resource allocation. As mentioned previously, some of the principal instances are contending for resources. 
     The process identifies whether the application-specified resource allocation policy is used  504 . If the application-specified allocation policy is used, the process proceeds to the right side to block  506 . Application-specified resource allocation policy is used when the web entity itself may know how to optimally allocate resources among itself and embedded content. More discussion on the application-specified resource allocation policy follows in  FIGS. 8 and 9 . 
     Returning to block  504 , in the absence of application-specified resource allocation policy, the process proceeds down to evaluating resource allocation with the DOM-recursive resource allocation policy. This policy may be used by default for CPU, network bandwidth, and transactional resources to decide how much of a resource each contending principal instance receives. The process evaluates the policies at each level, so that application-specified semantics may not violate hierarchical fairness. For example, after dividing a resource equally among top-level principals (tabs), the process initially determines whether to apply application-specified resource allocation policies to the top-level principal. If the application-specified resource allocation policy is available, it may be used. However, if it is not available, the DOM-recursive resource allocation policy may be used by default. For each embedded principal on the second level, third level, and other levels, the process may be repeated. While application-specified resource allocation policy may be used for efficiency, it may not be specified, so DOM-recursive policy is used. 
     With DOM-recursive policy, the resource may be divided recursively along the principal embedding hierarchy of a web entity  508 . Namely, the multi-principal browser  110  in operation with the resource sharing module  112  may divide the resource into equal fractions among the top-level contending principal instances  510  (each of which runs in a separate browser tab). 
     Next, the process may assign a fraction of the resource to a principal instance  512 . The assigned fraction may then be split fairly among the principal instance itself and all of its embedded principal instances that are actively contending for the resource  514 . Two examples are described for  FIG. 6  on how the fraction may be assigned. 
     Then, the process may advance to providing a pseudo code for the DOM-recursive policy. The process calculates the resource share for each contending principal instance using the pseudo code  516 . The pseudo code is shown below: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 allocate(null, top_level_principal_instances,1); 
               
               
                   
                 function allocate(parent, children, amount) { 
               
               
                   
                    numChildren = |children|; 
               
               
                   
                    if (parent != null) { 
               
               
                   
                     numChildren++; 
               
               
                   
                     share[parent] = amount/numChildren; 
               
               
                   
                  } 
               
               
                   
                  foreach principalInstance in (children) { 
               
               
                   
                    share[principalInstance] = amount/numChildren; 
               
               
                   
                    if (hasChildren(principalInstance)) 
               
               
                   
                      allocate (principalInstance, 
               
               
                   
                           principalInstance.children, 
               
               
                   
                           share[principalInstance]); 
               
               
                   
                   } 
               
               
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     Turning to  FIG. 6  is a block diagram of an illustrative allocation  600  of assigning the fraction. Shown in a first example on the top portion are four web sites, a.com  602 , embedded content b.com  604 , embedded content c.com  606 , and embedded content d.com  608 . One web site, a.com  602  is the only top-level web page (i.e., only one tab is opened). In this example, initially, there may be three principal instances such as a.com  602 , b.com  604 , and c.com  606 , which may be actively contending for the resource. If there are three active principal instances contending, each principal instance, a.com  602 , b.com  604 , and c.com  606  may each receive equal shares, ⅓ of a resource. However, if d.com further competes for the resource, c.com  606  may splits its ⅓ share with the embedded content, d.com  608 . Thus, c.com  606  may split its ⅓ among itself and d.com  608 , so that each may get ⅙ of the resource. 
     Shown in a second example in the lower half of the diagram, assumes b.com  604  is not contending for the resource, that there are initially two principal instances contending for the resource, a.com  602  and c.com  606 . The process may divide recursively along the principal embedding hierarchy and divide into equal fractions among the top-level. Based on the DOM-recursive policy, a.com  602  and c.com  606  each may receive ½ of the resource. Assume that d.com  608  further competes for the resource. Then c.com  606  may split its share of ½ resource among itself and the embedded content d.com  608 . The ½ is split among c.com  606  having ¼ and with d.com  608  having ¼ resource. 
       FIG. 7  illustrates resource allocation mechanisms  700 , which are separate from resource allocation policy. The same DOM-recursive resource allocation policy applies for all the relevant resources, but resource allocation mechanism is different from each resource. 
     In block  702 , the resource allocation mechanisms identified from each resource is shown. In block  704 , for both CPU and transactional resources&#39; allocation mechanism, existing proportional scheduling mechanisms, such as a lottery scheduling  704 (A) or a hierarchical scheduling  704 (B) may be used and fed with the DOM-recursive policy. 
     In block  706 , various bandwidth shapers may be used to fair-share bandwidth across contending principal instances for the data network bandwidth allocation mechanism. Bandwidth contention may happen when the last-hop bandwidth is limited. For example, 3G networks offer an average of only 841 Kbps. 
     Web content is very complex and requires significant memory resources for processing. In an application-specified resource allocation policy, a web site may designate embedded content as “unimportant”. If this occurs, the browser kernel  210  may terminate the embedded content under memory contention. 
     For example, a script on a web page (or in an embedded gadget) could exhaust the host&#39;s available memory, causing thrashing or denying memory allocation to scripts in concurrently executing web content. In block  210 , the browser kernel  210  may manage memory to prevent such scenarios. It may be plausible for the browser kernel  210  to terminate an embedded untrusted ad that is stealing memory from a parent page and other top-level pages. However, this becomes difficult. Memory may be difficult to reclaim once allocated, yet denying a memory allocation ultimately denies execution. Thus, to improve memory management, the browser kernel  210  should have more information about a web page&#39;s resource usage semantics. 
     Block  708  illustrates display is typically allocated by a parent principal instance to its children through explicit position and dimension specifications, such as width and height attributes of frames and object tags. A balanced and a proportional sharing (i.e., fair sharing) of the display do not really impact web applications and is not discussed at length here. 
     Block  710  illustrates dynamic principal embedding to share resources. The principals change or customize content dynamically and/or frequently based on certain criteria. The embedded principals (e.g., through JavaScript&#39;s document.createElement) may be easily incorporated into the resource sharing schemes. Such dynamically spawned principal instances result in new processes created by the browser kernel  210 . For resources that are scheduled with DOM-recursive policies, the BK  210  recalculates the resource shares for the schedulers. Adding new principal instances does not change memory allocations of existing ones. 
     Application-Specified Resource Allocation Policy 
       FIG. 8  is an illustrative process of the application-specified resource allocation policy and  FIG. 9  illustrates examples of resource allocation mechanisms. 
       FIG. 8  is a flowchart illustrating an illustrative process  800 , describing in details application-specified resource allocation policy. The web application itself may know how to optimally allocate resources among itself and embedded content. For example, if a.com embeds an untrusted ad, it might want to restrict the ad&#39;s CPU and memory usage; if a.com embeds a video application, it might indicate that this video may be best viewed with a bandwidth of 200 Kbps. To support such scenarios, web programmers are enabled to provide application-specified resource allocation policy for their web applications. Note that this does not violate hierarchical fairness: as shown in  FIG. 6 , c.com&#39;s  606  resource policies may influence c.com  606  and d.com  608 , but the policies may not affect resources granted to a.com  602  or b.com  604 . 
     As mentioned, previously, there may be two policies to evaluate resource allocation for the principal instances. One implementation is the DOM-recursive resource allocation policy, discussed in detail in  FIGS. 5-7 . 
     The other implementation is to apply the application-specified resource allocation policy  802 . This is used when the web application itself may know how to optimally allocate resources among itself and embedded content. 
     In block  804 , the process may decide whether to specify a resource share for each of its embedded content. If the application specifies the resource share, the process proceeds to the right to block  806 . The application specifies the resource share for the web entity (i.e., parent and child) for CPU, network bandwidth, and transactional resources  806 . This allows the application to grant relative priorities among its children and itself. 
     Returning to block  804 , the process may proceed to decide whether to customize priority level of the embedded content or embedded application  808 . If the application customizes the priority level of the embedded content or embedded application, the process proceeds to the right to block  810 . The process may customize the priority level by giving a weight or assigning a level to the web entity. For example, for memory, the application may customize a priority level of the embedded application to “disposable” or “parent”. The former, “disposable” indicates that the embedded application may not be critical for parent&#39;s functionality and may be terminated when in memory contention; the latter, “parent” promotes its importance and memory usage priority to that of its parent. 
     Returning to block  808 , the process may proceed to express a predetermined network bandwidth  812 . If the web entity is expressed with the predetermined network bandwidth, the process proceeds to the right to block  814 . Here, the predetermined network bandwidth may be expressed with a “preferredBW” attribute, which indicates the network bandwidth needed for optimal service quality  814 . The embedded content with this specification will receive higher priority in receiving its predetermined bandwidth amount or the available bandwidth, whichever is smaller. When multiple embedded applications are given preferred bandwidth specifications and when the system may not satisfy all their needs, the bandwidth allocation will follow their relative proportions. 
     Returning to block  812 , the process proceeds to absolute priority that is granted  816 . This is one last consideration for the web entity that is considered critical by the user  106 . Such as entities like these are granted absolute priority in resource use. For example, the web entity considered critical by the user  106  may be one that uses a telecom network or a top-level user interface. 
       FIG. 9  illustrates illustrative application-specified allocation mechanisms  900 . In block  902 , the application-specified resource allocation is specified by web entity, web programmers, and the like. In block  904 , for CPU, network bandwidth, and transactional resources, the web entity may specify a resource share for each of its embedded content. This allows the web entity to grant relative priorities among its children and itself. 
     In block  906 , for memory, the web entity may customize a priority level of an embedded content to “disposable” or “parent”. This helps identify whether an embedded content may be terminated when in memory contention. Alternatively, the process may promote memory usage priority to that of the parent. 
     In block  908 , the predetermined network bandwidth may be expressed with a “preferredBW” attribute, which indicates the bandwidth needed for optimal service quality. The embedded content with this specification will receive a higher priority in receiving the network bandwidth amount or the available bandwidth, whichever is smaller. 
     In block  910 , custom allocations may also be adjusted programmatically at the runtime. These custom allocations result in system calls to the browser kernel  210 ; the BK  210  then sets these policies for resource allocation mechanisms. 
     In block  912 , a last consideration is the web entity that is considered critical by the user  106 . For example, the web entity like a telecom network may be considered critical by the user  106 . The web entities that are considered critical are granted absolute priority in resource use. 
     As discussed above, certain acts in processes  500  and  800  need not be performed in the order described, may be modified and/or may be omitted entirely, depending on the circumstances. The DOM-recursive resource allocation policy, the resource allocation mechanisms, and the application-specified resource allocation policy described manage resource sharing in the principal browser-based operating system. 
     CONCLUSION 
     Various instructions, methods, techniques, applications, and modules described herein may be implemented as computer-executable instructions that are executable by one or more computers, servers, or telecommunication devices. Generally, program modules include routines, programs, objects, components, data structures, etc. for performing particular tasks or implementing particular abstract data types. These program modules and the like may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. The functionality of the program modules may be combined or distributed as desired in various implementations. An implementation of these modules and techniques may be stored on or transmitted across some form of computer-readable media. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter 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 illustrative forms of implementing the claims.