Content script blacklisting for use with browser extensions

A rendering engine may be configured to execute, within a execution environment, a page script of a page to be rendered within a browser interface, the page script configured to interact with a page model to implement the rendering. An extension manager may be configured to execute an extension file which modifies a functionality of a browser application in association with the rendering of the page, including detecting a content script associated with the extension file which, during execution, interacts with the page model. An environment manager may be configured to evaluate the page, for example using a blacklist, prior to execution of the content script by the rendering engine.

TECHNICAL FIELD

This disclosure generally relates to security features for applications, and more particularly to content script blacklisting for browser extensions.

BACKGROUND

Browsers typically enable users to interact with and experience many different types of content, usually over a computer network, and often in a visual or graphical manner. For example, users may install one or more internet browsers on a local computing device, and may thereafter utilize the internet browser to access content and/or functionality provided by a remote computing device.

Many browser applications provide a user with an ability to customize or personalize an appearance or functionality of the browser application in a manner desired by the user. In this way, the user may be more likely to enjoy, or benefit from, a use of the browser application. In particular, many browser applications support the use of discrete programs or files which are designed to provide a specific addition and/or alteration of one or more functionalities of an associated browser application. Such programs may be referred to using various, well-known terminologies, such as, for example, extensions, add-ons, or web apps (or just apps).

As referenced above, such programs generally operate to provide some additional, specific functionality for a user's local browser application. For example, such programs may cause an icon, image, or other content to be available within the context of the browser application, which would not normally be available to the user in that context. In such examples, such extension programs merely supplement already-present features and functionalities of the browser application.

In some cases, however, such extension programs may utilize a content script or other executable code which is designed to interact with content that is being remotely accessed by the browser application for loading and rendering thereof. For example, in the case where the browser application accesses a remote webpage over the internet, such content script or other executable code associated with an extension program may be configured to interact with (e.g., read or make changes to) the webpage itself. Content scripts are JavaScript files that run in the context of web pages. By using a standard Document Object Model (DOM), content scripts can read details of a webpage that a web browser visits, or make changes to webpages. Web browser extensions with content scripts often want to inject in every page that a user browses to, as a way of adding a general functionality to the browser. For example, browser extensions may apply a spellchecker, an address finder, or any generic functionality that could apply to any webpage.

In some cases, such interactions between content scripts and webpages may pose a security risk, such as when the interactions enable the webpage or the content script to access confidential or other privileged data of the user that may be stored on the local computing device of the user, or that the user enters into the web browser when visiting a webpage, for example. As a result, users' use and enjoyment of extension programs utilizing such content scripts or other similar types of executable code may have undesirable results. Another potential security issue with extensions that use content scripts is that a user has to trust each extension with access to all webpages that the user visits.

SUMMARY

According to one general aspect, a computer system includes instructions stored on a computer-readable medium and executable by at least one processor to execute a browser application and thereby provide a browser interface. The computer system includes a rendering engine that may be configured to execute, within a execution environment, a page script of a page to be rendered within a browser interface, the page script configured to interact with a page model to implement the rendering. An extension manager may be configured to execute an extension file which modifies a functionality of a browser application in association with the rendering of the page, including detecting a content script associated with the extension file which, during execution, interacts with the page model. An environment manager may be configured to evaluate the page, for example using a blacklist, prior to execution of the content script by the rendering engine.

In some implementations, the content script manager is configured to evaluate the page using page analysis logic. Further, the page analysis logic may be stored at a remote server. The content script manager may be configured to prevent the content script from accessing the execution environment if the content script manager determines that the page is associated with a blacklist. The content script manager may be configured to allow the content script to access the execution environment if the content script manager determines that the page is not associated with a blacklist. Alternatively or additionally, the content script manager may be configured to cause the at least one processor to evaluate the page using a whitelist. The content script manager may be configured to prevent the content script from accessing the execution environment if the content script manager determines that the page is not associated with the whitelist. The content script manager may be configured to allow the content script to access the execution environment if the content script manager determines that the page is associated with the whitelist. The content script manager may be configured to evaluate the page using a combination of page analysis logic, a whitelist, or a blacklist. The content script manager may include a messenger configured to send a message between the content script and the extension file. The content script may be configured to interact with the page model to modify objects of the page model and thus modify the rendering of the page. The page model may include a Document Object Model (DOM) and the page script and the content script include Javascript.

In some implementations, the blacklist may be stored at a remote server, and/or in a memory of the computer system. The blacklist may be modifiable by a user of the computer system. The blacklist may include specified universal resource locators (URLs) and/or types of pages. The types of pages may include a page that requests a password from a user. The blacklist may be established without input from a user of the computer system. The extension file and the blacklist may be synchronized with a second computer system based on an account of a user of the computer system. The blacklist may include at least one of a uniform resource identifier, uniform resource name, domain name, name space, or path.

According to another general aspect, a non-transitory computer program product is tangibly embodied on a computer-readable medium and includes executable code that, when executed, is configured to cause a data processing apparatus to execute, within a execution environment, a page script of a page to be rendered, by a rendering engine, within a browser interface of a browser application. The page script is configured to interact with a page model to implement the rendering. The computer program product is configured to execute an extension file which modifies a functionality of the browser application in association with the rendering of the page, including detecting a content script associated with the extension file which, during execution, interacts with the page model, and evaluate the page using a blacklist prior to allowing execution of the content script by the rendering engine.

According to yet another general aspect, a computer-implemented method includes executing instructions stored on a computer-readable medium. The method includes executing, within a execution environment, a page script of a page to be rendered, by a rendering engine, within a browser interface of a browser application. The page script is configured to interact with a page model to implement the rendering. The method includes executing an extension file which modifies a functionality of the browser application in association with the rendering of the page, including detecting a content script associated with the extension file which, during execution, interacts with the page model. The method also includes evaluating the page using a blacklist prior to allowing execution of the content script by the rendering engine.

DETAILED DESCRIPTION

FIG. 1Ais a block diagram of a system100afor providing stable, secure use of content scripts associated with browser extensions. In the example ofFIG. 1, a local computing device102is illustrated as communicating with a remote computing device104in order to provide, using a display106, a browser window108which contains a page110that is stored at the remote device104. As described in detail below, the local device102may be configured to provide the browser window108and/or the page110in a manner which is highly customizable to a user of the system100a, without providing a risk to the stable operation and display of the page110and/or the browser window108itself, and in a manner which minimizes a security risk to a user of the system100a, or other users.

As may be appreciated by one of skill in the art, a local device102may generally represent virtually any computing device which may be configured to execute an otherwise conventional browser application112, and to communicate with the remote device104. For example, the local device102may include any standard desktop or personal computing device, any laptop, notebook, or netbook computer, any tablet computer, or any Smartphone or other mobile computing device. Such computing devices, and other computing devices, may be configured to access the remote device104over one or more computer networks, in any conventional manner. For example, many local devices102may include various types of network-related hardware/software which enable the local device102to communicate over the public internet, private intranet, or other network, to thereby access the remote device104. Consequently, the display106may be understood to represent virtually any conventional type of display, e.g., monitor, touch-screen, or any other type of visual or auditory display.

In the examples that follow, it is generally assumed that the local device102and the browser application112communicate with the remote device104over the public internet, therefore typically using standard and conventional protocols for identifying, accessing, and rendering the page110, e.g., from a web server represented by the remote device104. However, it will be appreciated that such examples are provided merely for the sake of clarity and conciseness, and, as just referenced above, are not intended to be limiting of the various manners in which the local device102may obtain, process, or provide content in association with the browser application112and the browser window108.

Thus, in the types of examples just referenced, it may generally be assumed that the page110represents any of the many types of webpages which are available over the public internet. For example, in a simple scenario, the page110may represent a substantially static page which includes text, sound, images, or other content which may be desired by a user of the system100aand which may be displayed within the browser window108. In other well-known examples, the page110may include many types of dynamic or interactive content, which often may be manipulated by the user within the context of the browser window108. In many scenarios, the page110and/or associated executable code may be understood to represent an application which may execute partially or completely at the remote device104(e.g., may utilize the processor, memory, and other hardware/software resources of the remote device104), while providing associated functionality and features to the user via the browser window108(and perhaps executing at least partially locally at the local device102). As just referenced, such webpages and associated functionalities and applications are well-known to be implementable using various, conventional programming languages and techniques, such as, for example, hypertext markup language (HTML), Asynchronous Javascript (AJAX), eXtensible Markup Language (XML), JavaScript, JavaScript object notation (JSON), and many other types of code which may be executed.

Thus, in the example ofFIG. 1A, the page110at the remote device104is illustrated as including, or being associated with, a page model114and a page script116. The use of such page models and scripts is well known, including the specific examples of such use that are provided herein. Generally speaking, the page model114is known to provide a data structure which defines the structure, content, and appearance of the page110with respect to a programming language in which the page110is written. Meanwhile, the page script116is generally known to be configured to, when executed, traverse the data structure of the page model114in a particular, specified manner, so as to thereby enable the browser application112to render the page110in a desired manner.

In specific examples described herein, the page model114may represent a document object model (DOM) data structure. Such a DOM, as just referenced, represents a data structure (typically, a tree-like data structure) that itself represents HTML of the page110. Meanwhile, the page script116in such examples may be represented by JavaScript code which, when executed, is configured to traverse the DOM tree of the page model114to thereby render the page110, as is well-known and as referenced above. Specific examples of the page model114and the page script116would be apparent, and are provided in more detail below, e.g., with respect toFIG. 1B.

Thus, during a conventional rendering of the page110by the browser application112, a temporary memory, (e.g., a cache memory) at the local computing device102may be used to temporarily store the page model114and the page script116. Of course, this is merely an example, and it may be appreciated that the browser application112may partially or completely access the page model114and/or the page script116remotely at the remote device104. In this way, the browser application112may utilize the page model114and the page script116, e.g., in a conventional manner, so as to thereby render the page110within the browser window108provided by the browser application112.

As described herein, browser extensions may be utilized in the system100ato provide additional features or functionalities in association with the browser application112, and thus with respect to the browser window108. In the example ofFIG. 1A, an icon120represents an icon which is provided in conjunction with the browser application112and the browser window108, so as to provide an example of such extended features/functionalities. More specifically, as shown, the extension icon120may be produced by, or in conjunction with, various extension files122.

In this regard, as may be understood from the above description, or as would be apparent to one of skill in the art, extensions defined by the extension files122may generally refer to browser extensions, add-ons, active X controls, web applications (web apps, apps) or any other program code which is designed to augment an appearance or functionality of the browser application112in providing the browser window108and/or the example page110. As such, the extension files122may include one or more of various types of files, such as, for example, HTML files, cascading style sheets (CSS) files, JavaScript files, image files, audio files, text files, or virtually any other type of code or content that may be used to extend the features and functionalities provided by the browser application112.

For example, some or all of the extension files122may be understood to be essentially indistinguishable in appearance, structure, and function with respect to otherwise conventional web pages which might be rendered by the browser application112, and, as such, can use all the functionality of the browser application112with respect to the rendering of webpages. For example, the extension files122representing webpages may use the various application program interfaces (APIs) that the browser application112provides to external webpages such as the page110(e.g., XML HTTP requests, JSON, or HTML 5 local storage, to name a few examples).

In additional examples of the extension files122, associated extensions may provide functionality to the browser application112, such as browser actions to be implemented by the browser application112when the extension in question is relevant to most or all pages to be rendered by the browser application112within the browser window108. In other examples, extensions may include a page action which is associated with an execution which is dependent upon (or executed in conjunction with) a particular page or pages being rendered by the browser application112.

Thus, with respect to the simplified example of the system100aof FIG.1A, a browser action of the extension files122may cause the extension icon to appear within the browser window essentially independently of the page110, while, conversely, a page action associated with the extension icon120may cause the extension icon120to appear or disappear depending on its relationship to the page110. Further, as is known, the extensions may be implemented automatically in conjunction with an operation of the browser application112, e.g., in conjunction with the loading and rendering of the page110. In other examples, extensions may interact programmatically with browser features, such as, e.g., bookmarks and tabs. That is, for example, an extension may be configured to execute in a manner that is dependent upon a user's selection (i.e., may execute only if such selection occurs) of a bookmark, tab, or other provided feature of the browser application112.

In the simplified example of the system100aofFIG. 1A, the extension files122are illustrated as being stored locally to the local computing device102. For example, a user of the local computing device102may program and store the extension files122for use by the browser application112. In additional or alternative examples, however, it may be appreciated that some or all of the extension files122may be accessed remotely. For example, in many cases, a particular extension may be packaged within a single folder or archive which may then be accessed by the browser application112. For example, a provider and/or distributor of the extension files122(not specifically illustrated in the example ofFIG. 1A) may construct and package the extension files122, and a user of the system100amay thereby download and install a desired extension, including accessing, downloading, and installing the extension files122at the local computing device102, as shown.

In some scenarios, e.g., when the extension files122are stored locally to the local computing device102as shown, and because the extension files122may be associated with a personalized or customized modification of the browser application112which is unique or particular to a user of the system100a, it may occur that the extension files122may have access to privileged data124of the user which may be stored at the local computing device102, as shown. Although access to the privileged data124by the extension files122may thus enable such particular customization/personalization of the browser112, such access also may represent a security risk with respect to a desired confidentiality level of the privileged data124. For example, the privileged data124may include credit card information, social security number, or other private information associated with the user. In such cases, the extension files122may utilize such privileged data124in order to facilitate a user's interaction with the browser application112(e.g., by limiting a number of times that the user is required to enter credit card information into the browser window108). However, as just referenced, and as described in detail below, such access to the privileged data124may represent a security risk to the confidentiality thereof. Specific examples of functions and features of the system100ain mitigating or eliminating such security risks are provided in detail, below.

Thus, during normal operation, the browser application112may include a rendering engine126which is configured to render the browser window108and the page110within the display106. As shown, the browser application112also may include an extension manager128which may be configured to facilitate operations of the rendering engine126with respect to the extension files122, so as, for example, to facilitate the rendering engine126in rendering the extension icon120, and in executing actions and other features associated with the rendering of the extension icon120.

Of course, it may be appreciated that the browser application112may include, or be associated with, various features, functions, operational modules, or other elements which are not specifically illustrated in the context ofFIG. 1A, but which would be apparent to one of skill in the art. Similarly, it may be appreciated that the terminology used in association with the rendering engine126and the extension manager128is merely for the sake of example, and that the various types of browser applications112which exist, or which may exist in the future, may use different terminology when referring to the various concepts described herein.

As referenced above, the extension files122may include various different types of files. For example, the extension files122may include a manifest file which gives information about the extension, such as, for example, the most important files and the capabilities that the extension might provide. In another example, as illustrated in the example ofFIG. 1A, the extension files122may include a background file or background page which is generally known to represent an invisible page which holds the main logic of the extension, and which may thus run in the background so as to be always-available in case of some initiation of a relevant extension action. For example, for an extension installed on the local device102which includes the extension files122, a browser action may be defined which have some affect on the rendering of the page110via the browser window108. Thus, for example, the extension icon120may represent or be associated with such a browser action, and the background file130associated therewith may be defined by an HTML file which has JavaScript code that controls a behavior of the browser action associated with the extension icon120. It may be appreciated that, as referenced above, the extension files122may include various other types of files. For example, the extension files122may include other types of HTML pages, such as, for example, an HTML page associated with the browser action providing a pop-up window in association with the browser window108.

Thus, as described, HTML pages and associated code within the extension files122may include a background page associated with the background file130, as well as a pop-up page associated with a corresponding pop-up file (not specifically illustrated in the example ofFIG. 1A). In as much as such the files include HTML pages (webpages) which may otherwise be standard HTML/webpages but that are implemented in the context of extension files122, it may occur that each such page itself, much like the page110at the remote device104, may include corresponding page model (e.g., DOM), and associated page script (e.g., written in JavaScript). Generally speaking, such extension files and associated pages may have complete access to each other's DOMs, and may invoke functions on one another. As a result, such shared functions and other content may minimize the need to duplicate code within and among the various extension files/pages, since, as just referenced, a particular extension file may simply invoke or otherwise utilize desired code or other content from another extension file of a given extension.

Somewhat similarly, since the extension files may include web pages, the extension files122, e.g., the background file130, may execute in their own rendering process, analogous to the rendering engine126. More specifically, with respect to the execution of the extension files122, other than the content script file132as described below, execution thereof may proceed similarly to, but in a separate process than that of, the rendering engine126of the browser application112. Thus, the extension manager128may represent, or be associated with, a separate process execution environment from that of the rendering engine126, and thereforeFIG. 1Amay be said to provide a multi-process architecture for the execution of extension files122. Such a multi-process architecture may help ensure, for example, that disruptions to execution of the extension files122do not affect operations of the browser application112as a whole, e.g., of the rendering engine126. Moreover, such process separation helps protect the privileged data124and other confidential information of the user. For example, although not specifically illustrated inFIG. 1, such an extension process may occur within a sandbox or other known security/restricted execution realm, and may communicate with the rendering engine126using various message exchanges via associated APIs, rather than directly accessing or initiating relevant browser actions and related information.

As illustrated in the example ofFIG. 1A, and as referenced above, the extension files122may include, or be associated with, a content script file132. As is known, the content script file132may represent, or include, a content script which enables an associated extension to interact with webpages, e.g., the webpage110. For example, the content script of the content script file132may be implemented as JavaScript that executes in the context of the page110as loaded into the browser application112, as described in more detail herein. Thus, the content script132may be considered to be, in effect, part of a given loaded page, as compared to being considered to be part of an extension with which the content script was packaged. In other words, within the multi-process architecture described above, the content script132may be considered to be part of the process of the rendering engine126, rather than the process of the extension itself within the extension manager128. Consequently, as a matter of terminology, such an extension having packaging which includes the content script may be referred to as a parent extension of the content script file132.

Content scripts can find unlinked URLs in web pages and convert them into hyperlinks, increase font size to make text more legible, and find and process microformat data in the DOM114. Content scripts can indirectly use .* APIs, get access to extension data, and request extension actions by exchanging messages with their parent extension. Content scripts can also make cross-site XMLHttpRequests to the same sites as their parent extensions, and they can communicate with web pages using the DOM114.

The content script132's code may always be injected in a website, or may only sometimes be injected depending upon how the content script is written. Further, an extension122can insert multiple content scripts into a page, and each of these content scripts can have multiple JavaScript and CSS files.

Content scripts, generally speaking, may be configured to, for example, read details of webpages visited by the browser application112, and may be further configured to make changes to such pages. For example, as described in detail herein, the content script may be configured to read and/or modify the page model (e.g., DOM)114of the page110. In example implementations, however, the content script may be restricted from accessing or modifying the page model (e.g., DOM) of the background page of the background file130associated with the parent extension of the content script file132(e.g., as part of the multi-process architecture described herein).

Nonetheless, as also described in detail herein, the content script132may be enabled to communicate with the background page of the relevant parent extension, or with other files/pages associated with the parent extension. For example, as described in detail below with respect toFIGS. 3 and 4, the content script may be enabled to exchange messages with its parent extension. For example, the content script might send such messages to the background page in response to some detected event, so as to thereby trigger a browser action or page action on the part of the background page. Additionally, the background page may be enabled to send a message to the content script, e.g., to request the content script to change the appearance of the relevant browser page, (e.g., the page110) in a desired manner.

In more specific examples, the content script may include JavaScript files running in a context of the page110being rendered. Consequently, for example, the content script may be configured to identify unlinked uniform resource locators (URLs) within the webpage110, and to convert them into hyperlinks. The content script may be configured to increase or decrease a font size of the page110, and/or to identify and process specific types of data include within, or in association with, the page model114. Of course, such potential functionalities of the content script file132are intended merely as non-limiting examples, and inasmuch as various functionalities of content scripts are well known in the art, they are therefore not described in additional detail herein, except as may be necessary or helpful in understanding operations of the system100aofFIG. 1A.

In some example implementations, a given content script is by default injected into the page110to be loaded. For example, such a content script may be registered in the manifest file with the corresponding extension. On the other hand, it may be desirable to inject or implement the content script based on a particular action or choice of the user in interacting with the browser window108(e.g., selecting a bookmark feature, a toolbar feature, or tab feature associated with the browser application112). For example, the content script may be executed only in response to a selection of a particular bookmark functionality associated with the browser application112. Such selective implementation of the content script may be referred to as programmatic injection or dynamic injection of a content script.

Further, it may be appreciated that although in the example ofFIG. 1Aonly a single content script file132is illustrated, in fact, a given extension may be configured to insert multiple content scripts into the page110during the rendering thereof, where each such content script may have multiple JavaScripts, or other types of content script content. Additionally, or alternatively, a given content script may be configured to be injectable to a set of pages, but limited by the browser to work only in response to the user clicking on a browser action or page action button. For example, a given domain name may be associated with the web page110and may also be associated with a number of sub-domain web pages, and all of these related web pages may be associated with the extension icon120(or some other browser action or page action icon). Then, if and when the user navigates to a particular web page (e.g., the page110) of this group and selects the extension icon120, the content script may be injected into the web page110at that point (e.g., may interact with an associated DOM114at that point in the manner described herein). Such user-controlled dynamic content script injection may provide an additional aspect of security, since the user is provided with control over which web pages are actually accessible by a given content script.

It may be observed from the above description that, in the system100aand similar systems, the content script may be loaded into the rendering engine to interact with the DOM114at a variety of times relative to the loading of the actual page110itself. For example, the content script may be loaded before the page itself is loaded, and/or in conjunction with (e.g., simultaneously with) the page in question. In such examples, functionality of the content script may be immediately and/or automatically available to the user. In other examples, the content script may be loaded/injected after the page110has already been loaded, where again such loading may be automatic or by default, or, as in the examples above, may be in response to some pre-specified user action performed with respect to the browser window108and/or the displayed page110.

In additional examples, it may occur that the rendering engine126, during normal operation thereof, may experience various idle times (or at least, times of relatively lower activity) during its rendering processes. For example, the rendering engine126may begin loading the page110, but may be idle while waiting for a particular page portion or related data to be retrieved from the remote device104. During such an idle time(s), the content script may be injected in a manner which is highly efficient and which optimizes the use of resources available at the local computing device102. Further, such injection during available idle time enables injection of the content script into pages which have already been loaded or otherwise exist at a time when the content script is installed. Therefore, in the latter example, it is not necessary to require that the page be reloaded in order for the content script to be operable with respect thereto.

During operation, the rendering engine126may be configured to render the browser window/display108and/or the page110using an execution environment134. Generally speaking, in a conventional setting, the rendering engine126may include an execution environment into which the page110(e.g., the page model114and the page script116) may be loaded for execution of the page script116with respect to the page model114, e.g., to thereby render the page110. For example, as described in detail herein, the execution environment134may conventionally create a namespace associated with the page110, where the created namespace may be associated with defined variables and associated values.

As also shown in the example ofFIG. 1A, the browser application112may include an extension manager128which may be configured to implement some or all of the functionality of a particular extension, such as an extension associated with the extension files122. For example, the extension manager128may be configured to cause the rendering engine126to execute or otherwise render particular files or pages associated with the extension of the extension files122.

For example, as referenced above, the extension manager128may cause the rendering engine126to execute functionalities associated with the background file130. In this context, as described and as is well known, the rendering engine126may thus execute or otherwise render the extension files, e.g., the background file130, in a manner which causes the background file130to implement a browser, e.g., a browser action or page action. That is, such actions may be understood to represent supplemental or alternative actions associated with the rendering of the browser window108and/or the page110by the rendering engine126, yet without requiring or permitting access to the page110by the background file130.

For example, the background file130may be configured to modify the browser window108to include the extension icon120. However, as may be appreciated, such an action, and associated actions, does not rely on an interaction between the background file130and the page model114of the page110. Consequently, the background file130poses little or no risk to the stable or secure operation of the rendering engine126in rendering the browser window108, the page110, and/or the extension icon120. That is, the background file130does not interact with the page110(e.g., with the page model114), and therefore does not disrupt an operation thereof. Similarly, the lack of interaction between the background file130and the page110implies little or no access of the page110to the privileged data124.

In contrast, as referenced above, the content script of the content script file132may be configured to interact with the page110(e.g., to interact with the page model114thereof). As a result, it is possible that such interactions between the content script and the page model114may lead to disruption of the rendering of the page110(e.g., by improperly removing or modifying a node object of the data structure of the page model114). Moreover, as described herein, simultaneous loading and execution of the content script with the loading and execution of the page110may theoretically present a possibility that access of the content script to the privilege data124may be compromised, e.g., by malicious action on the part of the page110.

As a result, as illustrated in the example ofFIG. 1Aand discussed in detail herein, the execution environment134may include separate, distinct, and/or isolated execution environments or sub-environments138,140. Specifically, as shown, the extension manager128may include or be associated with an environment manager136which may be configured to create and manage the separate execution environments138,140. That is, as shown, the environment manager136may be configured to segregate an execution environment138associated with execution of the content script132from an execution environment140associated with rendering of the page110. By utilizing such separate and distinct execution environments, the environment manager136may be configured to minimize or eliminate the risks associated with the above referenced scenarios in which interaction of the content script with the page model114may cause a disruption to the stable and secure operation of the rendering engine126and rendering of the page110. Specific examples of the separate, distinct environments138,140are provided in detail below, e.g., with respect toFIG. 1B.

The extension manager128may include or be associated with a content script manager136which may be configured to evaluate the page110prior to allowing content script file132to be executed by rendering engine126, for example. That is, as shown, the content script manager136may be configured to, in some cases, prevent the content script132from modifying or accessing the rendering of the page110, for example based on the evaluation. By evaluating the page110and preventing the content script132from execution, the content script manager136may be configured to minimize or eliminate the risks associated with the above referenced scenarios in which interaction of the content script with the page model114may cause a disruption to the stable and secure operation of the rendering engine126and rendering of the page110.

To evaluate the page110, content script manager may utilize at least one of a content script whitelist152, a content script blacklist154, and/or page analysis logic156, which may, in some implementations, be stored at a remote server150as shown inFIG. 1A. Of course, in some implementations, any or all of the content script whitelist152, content script blacklist154, and/or page analysis logic156may be stored at local device102, for example in computer readable storage medium102b, or at another remote server or database accessible by local device102.

Content script whitelist152may include a predetermined set of at least one web page, type of web site, URL, portion of URL, uniform resource identifier (URI), uniform resource name (URN), domain, domain name, name space, or path for which content scripts may inject in, modify, and/or access. Content script blacklist154may also include a predetermined set of at least one web page, types of web site, URL or portion of URL, uniform resource identifier (URI), uniform resource name (URN), domain, domain name, namespace, or path for which content scripts should not inject in, modify, and/or access.

In some implementations, URLs in content script whitelist152or content scrip blacklist154may contain “wildcards” such as asterisks and question marks. The asterisk (*) matches any string of any length (including the empty string); the question mark (?) matches any single character. For example, “http://???.example.com/foo/*” matches any of the following: “http://www.example.com/foo/bar” or “http://the.example.com/foo/”; however, it does not match the following: “http://my.example.com/foo/bar”; “http://example.com/foo/”; or “http://www.example.com/foo.”

As one example, content script blacklist154may include [“https://*”], so that a content script would not be injected into any HTTPS-based web site. Further, a system may use a combination of content script whitelist152and content script blacklist154. For example, if content script whitelist152includes: [“http://*.nytimes.com/*”], but content script blacklist154includes, [“*://*/*business*”], then the content script would be injected into “http://www.nytimes.com/health” but not into “http://www.nytimes.com/business.” As another example, if content script blacklist154includes [“*science*”], then the content script would be injected into “http://www.nytimes.com” but not into “http://science.nytimes.com” or “http://www.nytimes.com/science. As yet another example, if content script whitelist152includes [“*nytimes.com/???s/*”], then the content script would be injected into “http:/www.nytimes.com/arts/index.html” and “http://www.nytimes.com/jobs/index.html” but not into “http://www.nytimes.com/sports/index.html”.

Content script whitelist152and content script blacklist154may be established without any end-user input, for example by an administrator of a digital marketplace or by a company. As one example, a company may have an enterprise policy regarding which web pages may utilize content scripts. In the case of an enterprise policy, company employees might be allowed to download or install browser extensions, but the content scripts associated with those browser extensions would only be allowed to access certain allowable web pages or domains, such as those associated with the content script whitelist152.

In some implementations, content script whitelist152and content script blacklist154may be automatically personalized for a user, for example based on a user profile, user settings, usage data, or user-entered preferences. Such personalization may be performed with user permission, on an opt-in basis. In some implementations, content script whitelist152and content script blacklist154may be established by a user and/or editable by a user. For example, a parent may establish a whitelist of specific sites that an extension can access when a child is using a computer. Further, when content script whitelist152and blacklist154are stored on remote server150, a user may access and edit the lists from different devices, and may access the lists using a user account and password, for example. In some implementations, content script whitelist152and blacklist154may be synchronized across all devices associated with a user account, so that no matter what device the user is using, the same whitelist152and blacklist154apply to limit content scripts.

Instead of or in addition to contents script whitelist152or content script blacklist154, page analysis logic156may also be used to aid in analyzing which pages may be modified or accessed by content scripts. Page analysis logic156may be used to determine which web pages a content script may inject in using predetermined rules. In some implementations, page analysis logic156may be used to determine that a web page (e.g., page110) requires a password. In that case, page analysis logic156may therefore prevent a content script from accessing the web page. In other implementations, page analysis logic156may be used to determine that a web page is associated with private financial data (e.g., the web page is part of a bank website), and page analysis logic156may therefore prevent a content script from accessing the web page. In some implementations, page analysis logic156may be used to determine that a web page has an expired Secure Socket Layer (SSL) certificate, and page analysis logic156may therefore prevent a content script from accessing the web page. In some implementations, companies may establish policies (e.g., using page analysis logic156) to prevent extensions from accessing particular servers or networks.

As with content script whitelist152and content script blacklist154, as discussed above, page analysis logic156may be predetermined for all users, or may be automatically personalized for a user, for example based on a user profile, user settings, usage data, or user-entered preferences. Such personalization may be performed with user permission on an opt-in basis. In some implementations, page analysis logic156may be established by a user and/or editable by a user, or users may modify settings that affect page analysis logic156.

In some implementations, users may override content script whitelist152, content script blacklist154, and/or page analysis logic156, for example to allow a content script to access a specific web page. For example, a user may wish to allow a spell-checking extension to spell-check entries for an e-mail program web page whose URL, uniform resource name (URN), domain, or portion of a domain name is associated with content script blacklist154. For example, content script blacklist154may include [“http://*.gmail.com/*”]. In this example, the user may opt to override the content script blacklist154for the e-mail program web page (i.e., [“http://*.gmail.com/*”]. In some implementations, for example when enterprise policies exist in a company, only users with certain privileges may override, access, or modify content script whitelist152, content script blacklist154, and/or page analysis logic156.

As shown inFIG. 1A, extension manager128may include a messenger142, which may be configured to execute message exchanges between various extensions, and between the content script and its associated parent extension. As described, this layer of separation between the content script file132and the background file130may be instrumental in reducing or eliminating possibility that the execution of the content script may be associated with potential compromise of the privilege data124. Specific example operations of the messenger142are provided in detail below, e.g., with respect toFIGS. 3 and 4.

In the example ofFIG. 1A, the browser application112is illustrated including discrete functional modules. However, it may be appreciated that such illustration is merely for the sake of example, and that other implementations are possible. For example, a single element of the browser application112may be implemented by two or more elements. Conversely, two or more components of the browser application illustrated inFIG. 1Amay be executed using a single component.

Further, in the example ofFIG. 1A, the local computer device132is illustrated as including at least one processor102a, as well as computer readable storage medium102b. That is, for example, the local computing device102may rely on two or more processors executing in parallel to achieve a desired result. Meanwhile, the compute readable storage medium102bmay represent any conventional type of computer memory which may be used, for example, to store instructions which, when executed by the at least one processor102a, cause the browser application112to perform various functions, and other relevant functions described herein. Additionally, in some implementations, the computer readable storage medium102bmay store content script whitelist152, content script blacklist154, and/or page analysis logic156. Additional or alternative example implementations of the system100aofFIG. 1Aare described herein, or would be apparent to one of skill in the art.

FIG. 1Bis a block diagram illustrating an example implementation of the system100aofFIG. 1A. In the example ofFIG. 1B, a simplified example with webpage144is illustrated as including an HTML file “hello_world” which is designed to display the message “hello world.”

As shown, in this example, the page model114may be implemented as a DOM which includes nodes or node objects146which represent the structure and content of the webpage144.

In the example ofFIG. 1B, the node objects146may be directly accessed in by the page script116within the execution environment140, as represented by node objects146b.

FIG. 1Billustrates that the DOM114may, in this manner, be shared among all relevant scripts that have permission (e.g., the page script116as well as the content script132if it is not prevented access by a blacklist, for example), while execution of the scripts themselves may nonetheless be isolated from one another. In this environment, therefore, for example, if not prevented by a blacklist or page analysis logic, or if allowed by a whitelist, the content script132may modify the DOM114(e.g., by adding or removing a node), and all other scripts (e.g., the page script116) may thus observe such a change.

If the content script132is not prevented from accessing the DOM114, for example by a content script blacklist154or page analysis logic156, and/or if content script132is permitted to access the DOM114by content script whitelist152, content script132has access to the DOM114of the page144into which the content script132is injected, but does not have access to any page script (e.g., JavaScript), variables or functions created by, or associated with, the page script116. Consequently, with respect to the content script132, or other content scripts injected into the webpage144, it may be impossible for each such content script to determine whether and how any other script is executing on the page in question. Conversely, the page script116may be unable to call any functions or access any variables defined by the content script132or other injected content scripts.

The structure of the isolated worlds138,140may thus enable the content script132to make changes to its individual, e.g., JavaScript, environment without concern regarding conflicts with the page script116or with other content scripts. For example, as illustrated in the example ofFIG. 1B, the content script132may be associated with, or may implement, a library file148that is used by the content script132as part of its injection into the page144. For example, the library file148may represent a Jquery library file, or, more specifically, may represent a first version thereof. Meanwhile, the page script116may utilize or be associated with a second library file160, which may represent a second or different version of the type of library file used in the content script132. For example, the library file160may represent a second version of a Jquery library. Nonetheless, in the context of the example ofFIG. 1B, it may be appreciated that the use of such different versions will not lead to inconsistencies, interference, or other conflicts. As a result, the content script132may be injected into many different webpages, which may or may not use the same version of the library file148, without concern for such conflicts.

Another advantage provided by the use of the isolated worlds of the execution environments138,140is that the page script116may be completely separated from the content script132, as a result, extra functionality may be offered by way of the content script132that may not be desirable for access thereof by the page script116.

Although the execution environments138,140are isolated and separated from one another, they may, as shown inFIG. 1B, share access to the DOM114of the page144. Therefore, the page script116may communicate with the content script132, (or with the parent extension via the content script132), and the page script116may do so through the shared DOM114.

For example, custom DOM events and data stored in a known or defined location may be used to accomplish such communication. For example, a page which is not part of an extension may create a custom event which may be fired by setting event data to a known location in the DOM114and by dispatching the custom event. Consequently, the content script132may listen for the name of the custom event on a known element and handle the event by inspecting the data of the element, so that the message may be posted to the extension process. In this way, the page script116may establish a line of communication to the extension. Reverse examples of such communication may be implemented using similar techniques.

Many specific techniques may be available for implementing the examples ofFIGS. 1A and 1B. For example, in conventional webpage JavaScripts, such as the page script116, there may be a hierarchy of objects under a single global object (also referred to as a window object in a web browser context) of a webpage. In such settings, the global object represents a parent object for every child object and associated variables associated with the page script116. Specifically, for example, all of the code of the page script116may execute in a single name space represented, and defined by, the global object or window object. For example, all such code may be represented or named using the format “window object/ . . . ”. Consequently, all associated page elements (e.g., the DOM114, associated functions, and associated html nodes) depend from the global object and execute in a particular JavaScript context associated with an execution environment thereof.

In the examples ofFIGS. 1A and 1B, the isolated world of the execution environment138may be created by the environment manager136including the creation of a parallel/shadow global window object which may be used as a wrapper to the conventional global object of the page script116. Consequently, the content script may be provided with its own independent name space which is defined with respect to the parallel/shadow global window object. For example, a variable named X in the name space of the content script132may be associated with a value of 3, while a variable may have the same name X within the separate, distinct name space of the page script116, and may therefore have a separate value (e.g., 5). As may be appreciated, the use of such distinct name spaces, as referenced above, may reduce or eliminate the possibility that operations of the scripts132,116may conflict with one another.

In the example, due to the creation of the parallel/shadow global window object of the content script132being formed as a wrapper object with respect to the conventional global window object of the page script116, the content script132may be enabled to access and effect the DOM114. On the other hand, the page script116may be unable to affect the operation of the content script132. Such one-way interaction between the isolated world138and the isolated world140is represented in the context ofFIG. 1Bby the one-way arrow162there between. Further, the one-way dashed arrow162represents that in some implementations, content script132is prevented from affecting the operation of page script116, for example when the page110(associated with DOM114) is associated with content script blacklist152. In such an example, content script132may not affect the operation of page script116.

As referenced above, the examples ofFIGS. 1A and 1Bprovide techniques for implementing the content script, and other content scripts, in a manner which ensures stable, secure operation of the content script132and of the page script116. For example, such stable operation of the page script116, and thus of the webpage144, may be ensured by the use of whitelists, blacklists, and/or page analysis logic by evaluating webpages and potentially preventing content script132from injecting into every webpage which is downloaded for display on the browser window108.

From a security standpoint, as referenced above, it may be appreciated that the content script132and/or a parent extension thereof may have access to privileged information, (e.g., privileged APIs and/or privileged data), as represented in the example ofFIG. 1Aby the privilege data124. However, as described, the page script116is not enabled to access the content script132, and therefore may be prevented from obtaining unauthorized access to, or use of, such privileged information.

FIG. 2is a flowchart200illustrating example operations of the system100ain the examples ofFIGS. 1A and 1B. In the example ofFIG. 2, operations202-206are illustrated as discrete operations occurring in a sequential manner. However, it may be appreciated that the operations202-206may execute in a partially or completely overlapping (e.g., parallel) manner. Further, the operations202-206may occur in an order different than that shown or may include additional or different operations not specifically illustrated with respect toFIG. 2.

In the example ofFIG. 2, a page script of a page to be rendered by rendering engine within a browser interface of a browser application may be executed within a first execution environment, where the page script may be configured to interact with the page model to implement the rendering (202). For example, the rendering engine126may execute the page script116within the execution environment140, so as to thereby render the page110within the browser window108.

An extension file which modifies the functionality of the browser application in association with the rendering of the page may be executed, including a detection of a content script associated with the extension file which, during execution, interacts with the page model (204). For example, during an execution of the extension files122, e.g., the background page130, the extension manager128executing in conjunction with the rendering engine126may detect presence of the content script file132.

The content script may be evaluated prior to allowing execution of the content script by the rendering engine (206). For example, a combination of at least a blacklist, whitelist, page analysis logic may be used to evaluate the content script.

FIG. 3is a block diagram illustrating example messaging techniques which may be implemented in the examples ofFIGS. 1A and 1B. Specifically, as referenced above, content scripts may be configured to execute in a different execution environment from the rest of the extension file (e.g., the parent extension file including the background page file thereof). As referenced herein, the execution environment138, similarly to the execution environment140of a page script of a webpage in question, may generally be unprivileged. On the other hand, other portions associated with the parent extension files may be privileged (e.g., may have access to privileged data and/or APIs).

As also referenced above, such privileged information may be protected through the use of messages sent between a content script and its parent extension, or between the parent extension and other known extensions. For example, inFIG. 3, an extension icon302is illustrated which is associated with an extension304. Specifically, as shown, a parent extension308may include a background page file310, as well as various other pages312. The extension304may be associated with a content script306which may be configured to interact with and/or modify a webpage to be displayed within the browser display108.

For example, the content script306may be written to examine any page loaded in the browser application112for rendering within the browser window108in order to detect a presence of a specific type of content (e.g., a non-linked webpage, or an RSS feed). That is, the content script306may execute such techniques on content of a webpage loaded and rendered within the browser window108if the content script306is not prevented from execution based on a content script blacklist154or page analysis logic156, for example. In the event that the content script306detects the specified type of content, the content script306may pass a message314to the parent extension308so as to notify the parent extension308of the detected presence of the specified type of content. In the example, the background page file310, unlike the content script file306itself, may have access to perform an actual modification of the browser window108, (e.g., to execute a page action with respect to browser window108, such as displaying the extension icon302).

For example, the content script306may use a “call to send request” to send the message314to a listener of the background page file314which is configured to detect such a send request. Upon detection and identification of the exact type of content as provided by the content script306via the message314, the listener of the background page file310may be configured to execute a corresponding page action, e.g., display the extension icon302(and associated activities, such as detection of selection of the extension icon and performance of resulting responses thereto).

Thus, through the use of the messenger142and/or associated message APIs, the content script306may send the message314to a parent extension308, to thereby trigger a desired action on the part of the parent extension308. By enabling such communication, while restricting access of the content script306to APIs and data accessible by the parent extension308, the example ofFIG. 3illustrates that any such data or other information which may be privileged may be protected from improper or undesired use thereof via the content script306.

Further, in addition to the parent extension as just described, other privileged extension APIs may be made available to the content script from within the execution environment138, as well, while also keeping such privileged extension APIs isolated from the page110itself. For example, the messaging techniques ofFIG. 3may be used to grant access to cross origin requests by the content script (specifically, as is known, “origin” in this context refers generally to the concept that page scripts of pages of a given site may cross-access one another, while page scripts of different sites may not). In general, extensions may communicate with remote servers that are not in their respective origins (if cross-original permission is granted), and, using the methods ofFIG. 3, the content script306also may do so (indirectly) by sending a message such as the message314to the parent extension308that asks the parent extension308to make the cross-origin request on its behalf. In another example, the content script306may access a context menu API associated with the parent extension308, which may, e.g., provide additional items within a pop-up window provided in response to a “right-click” of the mouse (or corresponding action for other human interface devices) by the user while viewing the page110.

FIG. 4is a flowchart400illustrating more detailed example operations of the system100aofFIG. 1A, in the context of the examples ofFIGS. 1B,2, and3. In the example ofFIG. 4, in a first instance, a page action extension file may be stored which includes the ability to display (and perform other activities associated with) a detection icon (402). For example, the extension file122may include a background page file130(represented by the files308,310, ofFIG. 3), for a potential resulting page action of display of the detection extension icon302.

A detection content script for performing a defined detection of specific content within loaded webpages also may be stored (404). For example, the content script file132ofFIG. 1A, represented by the content script306in the example ofFIG. 3, may be configured to examine the page model, (e.g., DOM)114of a page110to be loaded, to thereby inspect content thereof for inclusion of the desired content (e.g., for inclusion of an RSS feed).

Subsequently, a particular page and associated page script may be loaded into an associated browser, including, for example, an associated DOM and page script (406). For example, the page110may be loaded by the browser application112into the rendering engine126for a display within the browser window108, while the DOM114and the page script116may be loaded from temporary memory118and/or from remote device104(406).

In some implementations, content script manager136causes the processor102ato evaluate the page110prior to allowing execution of a content script (e.g., content script306). For example, if the page110is associated with a blacklist, such as content script blacklist154(407, yes), the process ends, and the content script is not injected into the page. If the page is not associated with a blacklist (407, no), the process continues. In some implementations, a whitelist, page analysis logic, or combination of blacklist, whitelist and page analysis logic may also be used to evaluate page110.

In the example ofFIG. 4, in conjunction with anticipated execution of the content script, e.g., the content script306, a new global object and name space for the content script may be created (408). For example, as described, upon loading of the page110by the rendering engine126, the extension manager128may determine a presence and desired use of the extension files122/304, as well as the associated inclusion of the content script132,306. In response, the environment manager136may create the above-referenced new global/window object to thereby create a name space for the detected content script which is independent from the name space of the page script116.

Consequently, the content script execution environment138may be executed including providing direct access to the nodes of the DOM114, within the newly created name space (410). In an overlapping or simultaneous context, a separate page execution environment140may be implemented in which the page script116may execute (412). In the example, specifically, the page execution environment may be associated with an otherwise conventional global/window object associated with the page script116, which may execute within a wrapper defined by the new global object previously described and created with respect to the environment manager136.

Consequently, the content script306may execute to detect a presence of a RSS feed within the webpage110(414). As a result, as described above with respect toFIG. 3, the content script306may send the message314to a corresponding extension file associated with a page action desired to take place in response to the detection of the RSS feed (416). For example, as described, the message314may be sent to the background page file310.

Therefore, the receiving extension file (e.g., the background page file310) may perform its configured page action. For example, as illustrated with respect toFIG. 3, the background page file310may execute a page action designed to modify the browser window108to include the icon302representing an extension icon (418) (e.g., a detection icon in the present example, which is designed to indicate the presence of the RSS feed within the content of the page110to the user of the browser window108). In addition, other steps may be provided, or steps may be eliminated from the described flow shown inFIG. 4. For example, step404may be performed after step407.

As a result of the systems and methods described herein, developers of extensions may be enabled to utilize and leverage familiar page structures such as, for example, the DOM114and associated page script116, when developing extensions which include, or are associated with, injectable content scripts. Further, within such familiar and convenient environments, the extension developer is nonetheless assured of being provided with an ability to create and execute a desired functionality of the content script, without significant concern for disrupting the stable operation of virtually any webpage which may later be loaded by the browser application112for the rendering engine126. Companies may be able to provide policies to allow employees to securely download browser extensions without fear that those extensions may access internal human resources servers or production networks.

Further, in the systems and methods described herein, content script blacklists and whitelists may be implemented to minimize or eliminate the ability of extensions to modify or access loaded webpages, for example to prevent unauthorized or undesired access to privileged data124. As described herein, through the use of content script whitelists, blacklists, and page analysis logic, extension developers and programmers may be enabled to develop, create, and provide desired extension functionality and features in a stable, secure manner. As a result, potential users of such extensions may be provided with a wide variety thereof, and may utilize a desired extension in a manner with which the user is comfortable, with respect to the stable and secure operation thereof.

FIG. 5is a flowchart500illustrating more detailed example operations of the system100aofFIG. 1A, in an example context of evaluating a page prior to allowing execution of a content script. In the example ofFIG. 5, a user may navigate to a web page, such as “http://www.example.com/”. System100, for example using at least one processor102a, may determine if a whitelist is associated with the user (502). To determine if a whitelist exists for the user, processor102amay check remote server150, computer readable storage medium102b, or other storage mediums to determine if a whitelist is associated with the user. If the whitelist exists (502, yes), the processor may determine if the page (in this example, “http://www.example.com/”) is associated with the whitelist (504). If no whitelist exists (502, no), the method proceeds to the next step. The processor102amay determine if a blacklist is associated with the user (506). If so, (506, yes), the processor102adetermines if the page is associated with the blacklist. If the page is not associated with the blacklist, the processor102adetermines if page analysis logic (e.g., page analysis logic156) prevents access to the web page (510). For example, page analysis logic may prevent a user from accessing a page that requires a password. If the page is associated with the blacklist (508, yes), or if the page analysis logic prevents access (510, yes), or if the page is not associated with the existing whitelist (504, yes), then processor102aprevents execution of the content script (512). Otherwise, the process ends and the content script may be allowed to inject in the page. It will be appreciated that in some implementations, a processor (not shown) of server150may perform some or all of method500. Further, other steps may be provided, or steps may be eliminated from the described flow shown inFIG. 5. For example, steps502and506may be deleted, for example in implementations where whitelists and blacklists are not user-specific. As another example, step510may be deleted if no page analysis logic is stored, for example at remote server150.

FIG. 6is a block diagram showing example or representative computing devices and associated elements that may be used to implement the systems ofFIGS. 1 and 3.FIG. 6shows an example of a generic computer device600and a generic mobile computer device650, which may be used with the techniques described here. Computing device600is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device650is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations described in this document.

The memory604stores information within the computing device600. In one implementation, the memory604is a volatile memory unit or units. In another implementation, the memory604is a non-volatile memory unit or units. The memory604may also be another form of computer-readable medium, such as a magnetic or optical disk.

The processor652can execute instructions within the computing device650, including instructions stored in the memory664. The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor may provide, for example, for coordination of the other components of the device650, such as control of user interfaces, applications run by device650, and wireless communication by device650.

Processor652may communicate with a user through control interface658and display interface656coupled to a display654. The display654may be, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display) or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface656may comprise appropriate circuitry for driving the display654to present graphical and other information to a user. The control interface658may receive commands from a user and convert them for submission to the processor652. In addition, an external interface662may be provided in communication with processor652, so as to enable near area communication of device650with other devices. External interface662may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.

The memory664stores information within the computing device650. The memory664can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory674may also be provided and connected to device650through expansion interface672, which may include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory674may provide extra storage space for device650, or may also store applications or other information for device650. Specifically, expansion memory674may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory674may be provided as a security module for device650, and may be programmed with instructions that permit secure use of device650. In addition, secure applications may be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory664, expansion memory674, or memory on processor652, that may be received, for example, over transceiver668or external interface662.

It will be appreciated that the above embodiments that have been described in particular detail are merely example or possible embodiments, and that there are many other combinations, additions, or alternatives that may be included.