GB2554697A

GB2554697A - Method and device for safely executing a web application in a web runtime environment

Info

Publication number: GB2554697A
Application number: GB1616856.9A
Authority: GB
Inventors: Bellessort Romain; Ruellan Hervé; Ouedraogo Naël
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-10-04
Filing date: 2016-10-04
Publication date: 2018-04-11
Anticipated expiration: 2036-10-04
Also published as: GB2554697B; GB201616856D0

Abstract

A method of executing a web application in a web runtime environment (e.g. a web API) running on a first device (e.g a smartphone or a laptop) comprises receiving from a second device (e.g. a multi-function printer, a scanning device or a camera) a Uniform resource Locator (URL) and a security indication. The URL enables loading of the web application (e.g. an adapted execution context) and the security indication is associated with the web application. The method further comprises determining, based on the received security indication, a set of features to be enabled during execution of the web application, and executing the web application in the web runtime environment according to the determined set of features, thereby enabling the use of the determined set of features by the web application. The method may further comprise a step of determining a checking procedure that requires a user input on the first device, based on the determined set of features. The checking procedure may require a physical interaction between the first and the second device, or checking a list of forbidden or authorized URLs.

Description

(54) Title of the Invention: Method and device for safely executing a web application in a web runtime environment

Abstract Title: Determining features required for the execution of an application in a web runtime environment (57) A method of executing a web application in a web runtime environment (e.g. a web API) running on a first device (e.g a smartphone or a laptop) comprises receiving from a second device (e.g. a multi-function printer, a scanning device or a camera) a Uniform resource Locator (URL) and a security indication. The URL enables loading of the web application (e.g. an adapted execution context) and the security indication is associated with the web application. The method further comprises determining, based on the received security indication, a set of features to be enabled during execution of the web application, and executing the web application in the web runtime environment according to the determined set of features, thereby enabling the use of the determined set of features by the web application. The method may further comprise a step of determining a checking procedure that requires a user input on the first device, based on the determined set of features. The checking procedure may require a physical interaction between the first and the second device, or checking a list of forbidden or authorized URLs.

Fig. 1

100

110

120

190

1/5

100

110

120

190

Fig. 1

215

Fig. 2

315

Fig. 3

4/5

Fig. 4

515

Fig. 5

Application No. GB1616856.9

RTM

Date :23 March 2017

Intellectual

Property

Office

The following terms are registered trade marks and should be read as such wherever they occur in this document:

Bluetooth

Eddystone

JavaScript

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

METHOD AND DEVICE FOR SAFELY EXECUTING A WEB APPLICATION IN A WEB RUNTIME ENVIRONMENT

FIELD OF THE INVENTION

The present invention relates in general to web applications and in particular to a method of safely executing a web application in a web runtime environment, as well as a device for implementing such a method.

BACKGROUND OF THE INVENTION

As usage of electronic devices for accessing web services is always increasing, there may be an interest for a user of a device to be suggested a web resource, for instance a web page or a web application.

For these purposes, nowadays technologies allow a device to advertise a URL (Uniform Resource Locator), i.e. the web address of a resource, in order to enable another device to obtain the resource. Thus, when a URL is loaded on a device, this device can access the resource, i.e. for instance execute the web application.

In some contexts, the web application may require access to personal data or to sensitive/secured functions of the device executing said web application, such as local storage (e.g. of user data) on the device or a network connection.

This may cause security issues in particular with malicious web applications trying to steal information or spy the behaviour of a user on its personal device.

Consequently, there is a need for improving the security of URL loading, i.e. execution of web applications.

SUMMARY OF THE INVENTION

The present invention has been devised to address one or more of the foregoing concerns.

According to a first aspect of the invention, there is provided a method of executing a web application in a web runtime environment running on a first device, the method comprising, at the first device:

receiving, from a second device, a URL and a security indication, the URL enabling loading of the web application and the security indication being associated with the web application;

determining, based on the received security indication, a set of features to be enabled during execution of said web application; and executing the web application in the web runtime environment according to the determined set of features, thereby enabling use of the determined set of features by the web application.

The security indication may be a single value (e.g. an integer) or a set of values (e.g. a set of integers or a set of Booleans).

The method of the invention makes it possible to improve security of URL loading (and web application execution).

This is achieved thanks to the addition of a security indication associated with the URL that indicates which features should be enabled to load the URL and execute the associated web application.

The web application is thus executed in an execution context limited to its authorized features, which avoid security matters caused by a malicious web application trying to overstep its rights.

Optional features of the invention are further defined in the dependent appended claims.

According to embodiments, communications over the communication network may be performed according to the Bluetooth Low Energy (BLE) standard and the advertising of the URL and the security indication may be performed according to the Eddystone specification.

In a variant, the communication network may be an IP network and broadcasting over it may be performed according to mDNS or SSDP protocols.

According to embodiments, the method also comprises a step of determining a checking procedure to be performed based on the security indication.

Such a checking procedure allows increasing the safety of web application execution.

According to embodiments, determining a checking procedure is based on the determined set of features.

According to embodiments, the checking procedure requires a user input on the first device.

According to embodiments, the checking procedure requires a physical interaction involving the first device and the second device or another device.

According to embodiments, the checking procedure comprises checking a list of forbidden or authorized URLs.

According to embodiments, the checking procedure is based on a token.

According to embodiments, the checking procedure comprises verifying the association between the received URL and the received security indication.

According to embodiments, the method comprises a step of performing the determined checking procedure, the step of executing the web application according to the determined set of features being performed based on the result of the checking procedure.

According to embodiments, executing the web application according to the determined set of features comprises creating an adapted execution context and loading said URL in this execution context such that only features of the determined set are accessible to the web application thus executed.

According to embodiments, the step of determining a set of features to be enabled and/or the step of executing the web application is/are performed upon dedicated user authorization.

According to embodiments, the URL and the associated security indication are received in a same advertisement message.

In a variant, they may be encoded in two different messages.

According to embodiments, the set of features to be enabled during execution of said web application comprises at least one of: network access, loading of other URLs on the first device, local data storage on the first device, access to discovery API, HTTP request performance, history access, camera/micro access, access to geo-tracking features of the first device, control of vibrate or audio features of the first device.

According to a second aspect of the invention, there is provided a first device for executing a web application in a web runtime environment configured to be run on the first device, the first device being configured to communicate with a second device over a communication network, the first device being configured for:

receiving, from a second device, a URL enabling the loading of the web application and a security indication associated with the web application;

According to embodiments, the first device comprises a discovery agent configured to determine the set of features to be enabled during execution of said web application.

The second aspect of the present invention has optional features and advantages similar to the first aspect above-mentioned.

The invention also concerns a method substantially as described herein with reference to, and as shown in Figures 1, 2 and 3, a system substantially as described herein with reference to, and as shown in Figure 4, and a device substantially as described herein with reference to, and as shown in Figure 5.

Since the present invention may be implemented in software, the present invention may be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium, and in particular a suitable tangible carrier medium or suitable transient carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device or the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 is a flowchart illustrating steps of a method of safely executing a web application according to first embodiments;

Figure 2 is a flowchart illustrating steps of a method of safely executing a web application according to second embodiments;

Figure 3 is a flowchart illustrating steps for determining a checking procedure based on a URL and a security indication according to embodiments;

Figure 4 illustrates an example of context in which embodiments of the invention may be implemented; and

Figure 5 represents a block diagram of the first and/or second device according to embodiments.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In the context of an embodiment of the invention, a web runtime environment, such as a web browser, running in a first device, executes a web application and enables it to use a set of features determined based on a security indication sent by a second device together with a URL enabling the loading of the web application.

For these purposes, the security indication which is associated with the URL enables determining which features should be allowed when executing the web application in the web runtime environment.

For instance, the web application associated with the URL may simply provide textual and visual information regarding a device or a place. In this case, the web application does not need any network access, nor to store any data on the first device. Therefore, there is no need to enable such features, which drastically reduces security risk. However, if the web application is a remote control application which requires network access (e.g. through Bluetooth), the security risks are much more significant.

Thus, according to general embodiments, the first device receives a URL enabling the loading of the web application and a security indication associated with the web application from the second device. Then, based on the security indication, the first device determines a set of features to be enabled during execution of said web application. Then, the web application may be executed in the web runtime environment according to the determined set of features, i.e. only the determined features are enabled.

According to particular embodiments, the first device may perform different kinds of checks (checking procedure) depending on the security indication, i.e. depending on the security risks. This enables, for instance, it to be ensured that the second device (advertising device) is indeed allowed to require the corresponding features to be enabled. The execution of the web application may further depend on the result of the checking procedure.

Figure 1 shows general steps of a method of executing a web application in a web runtime environment running on a first device according to first embodiments. These steps are for instance performed by the first device 410 shown in Figure 4.

First, at step 100, a URL and a security indication associated with said URL are received. For instance, they may be received together in a same advertising message. In a variant, the URL and the security indication may be encoded in two different messages. In this case, assuming the security indication is comprised in the second message, said second message is explicitly associated with the first message comprising said URL. For instance, this may be achieved by having both messages have sequence numbers such that the second message refers to the sequence number of the first one, or such that the second message has a sequence number which is an increment by one of the sequence number of the first message.

The security indication may be provided as a single value (e.g. an integer) or as a set of values (e.g. a set of integers or a set of Booleans). For illustration purposes, the following security indications may be defined:

security indication ALLOW_MINIMAL may be encoded as value “0”; security indication ALLOW_STORAGE may be encoded as value “1”; security indication ALLOW_NETWORK may be encoded as value “2”; security indication ALLOW_ALL may be encoded as value “3”.

At step 110, a set of features to be enabled during the execution of the web application is determined based on the received security indication.

For instance, if the security indication is encoded as a single value, the set of features is determined based on this single value. For illustrative purposes, the features for the exemplary security indications described above are:

security indication ALLOW_MINIMAL: all features but the ones providing network access (e.g. XML Http Request, Fetch API, WebSocket) and ability to store data (local storage, caching, cookies) security indication ALLOW_STORAGE: all features but the ones providing network access;

security indication ALLOW_NETWORK: all features but the ones enabling data storage;

security indication ALLOW_ALL: all features, including connection with advertising device (second device) without dedicated user authorization.

Thus, in practice, a standard or proprietary specification may describe which features are allowable for each given value.

Similarly, if the security indication is provided as a set of values, each value may be associated with a set of features. If each value is a Boolean, each value may indicate whether a corresponding set of features is allowed or not for executing said URL. In a specific case, a given Boolean value may indicate whether a specific feature is allowed or not (e.g. access to discovery API, ability to perform HTTP request, ability to load another URL, ability to store some data, to access history, to access local camera or other sensors information such as luminosity or geolocation, to generate vibrations or sounds, etc.).

At step 120, the URL is loaded by the web runtime environment, i.e. the web application is executed and the determined features are enabled. To do so, the considered URL and the set of allowed features are provided to the web runtime environment. This may for instance be done through a specific API.

In practice, the web runtime environment creates an execution context according to the enabled features. Once this execution context has been created, the URL is loaded in this execution context such that only allowed features are accessible to the web page or application that has been loaded based on the URL.

Typically, features are enabled/disabled by making them accessible or not through JavaScript APIs. For instance, while the “I oca I Storage” JavaScript object generally allows a web application to store data locally in a web browser, it may be decided that this feature should not be allowed. In this case, said object would no more be defined in the corresponding execution context.

Finally, the process ends at step 190.

Advantageously, these general steps allow safely executing an advertised URL and avoiding undue access to personal data or to sensitive/secured functions (e.g. local storage of user data) of the first device by the corresponding web application. Also, thanks to the security indication, the first device can quickly evaluate the level of security required by the web application.

It should be noted that different implementations of these steps may be considered. According to a first implementation, all the steps of Figure 1 are performed by a web browser. In this case, the web browser obtains the URL and the security indication at step 100. There is no need for the web browser to provide an API enabling another software component to request the loading of a URL with a specific set of allowed features.

According to a second implementation, a specific discovery agent may be used to perform step 100. In this case, the process of step 110 may either be performed by said agent or by a considered web browser. If performed by said agent, the web browser provides an API allowing said agent to request the loading of a URL with a given set of allowed features. On the other hand, if performed by the web browser, an API is provided to said agent to request the loading of a URL with an associated security indication.

In some cases, prior to loading a URL obtained through an advertising technology, it is preferable to request a user interaction. As an example, after receiving an advertisement message broadcasted over BLE (e.g. with Eddystone), the discovery agent running on a smartphone (possibly integrated into a web browser running on the same smartphone) may display a notification to the user so that he/she may decide to request the loading of said URL. Generally speaking, this user authorization step may be performed between steps 100 and 110, or between steps 110 and 120.

Figure 2 shows steps of a method for safely executing a web application according to second embodiments. These steps are for instance performed by the first device 410 shown in Figure 4. The second embodiments comprise optional steps in addition to the steps of the first embodiments. The purpose of these additional steps is to increase security even more.

In these second embodiments, steps 200 and 210 are respectively similar to steps 100 and 110 shown in Figure 1. Thus, they are not described again here.

After these steps, step 220 is performed. It comprises determining a checking procedure to be performed based on the received security indication. Said checking procedure may comprise different steps. A detailed example of determination of a checking procedure is described with reference to Figure 3.

For example, a specific procedure may be determined among a list of possible checking procedures depending on the security indication. For illustration purposes, the following checking procedures may be defined for the security indications mentioned above:

for the security indication ALLOW_MINIMAL: URL check;

for the security indication ALLOW_STORAGE: URL check and strong authentication;

for the security indications ALLOW_NETWORK and ALLOW_ALL: URL check, strong authentication and physical pairing.

As another example, the specific procedure may be determined based on the allowed features (which are themselves determined based on the security indication).

In general terms, different types of checks may be considered.

User consent: In practice, this kind of check relies on a user’s authorization for executing the web application. The advantage of this kind of check is that it is very easy to implement. In practice, a user may be able to define this check as his/her default checking procedure through an options menu.

URL check: in practice, this kind of check consists in checking whether a given URL belongs to a list of allowed or forbidden URLs. This can be done for global URLs, but it is more difficult to do it for local URLs as local URLs are generally not associated with domain names but only IP addresses which are dynamically allocated.

User credentials: access to certain URLs may be restricted to certain users. In such a case, prior to attempting to load a URL, a user may be requested to provide credentials, typically a username and a password.

Physical pairing: in this case, a physical interaction between the first device (e.g. a smartphone) and the second device or another device (e.g. a Bluetooth-enabled device) is required. For illustrative purposes, a specific code may be displayed on the Bluetooth-enabled device and the physical pairing may be achieved by inputting the same code on the smartphone. Such pairing enables it to be ensured that a user has identified the two devices involved in an interaction. Physical pairing may be added to a checking procedure when the purpose of loading a URL is to interact with a nearby device.

Strong authentication: in practice, the device advertising the URL (second device) may provide a token along with said URL (possibly in a distinct message) so that a discovery agent running on the first device may verify said token using an authentication service associated with the URL. To be secure, this token is preferably periodically modified by the advertising device, and said advertising device should be synchronized with the authentication service. For illustrative purposes, such authentication allows the discovery agent to check that a device advertising the URL http://example.org is actually associated with the URL example.org. Thanks to this means, only allowed devices may advertise such URL and the discovery agent can determine whether the device is actually associated with the URL example.org. However, it should be noted that this strong authentication check is optional and in many cases, it is not necessary to ensure the security. In particular, this depends on the features to be enabled that are determined based on the received security indication.

Security indication check: this kind of check consists of verifying the association between the received URL and the received security indication. For illustrative purposes, an advertising device (second device) may advertise a URL with a security indication different from the expected one for said URL (e.g. a minimal set of allowed features is requested even though the corresponding web application requires network access and service discovery capability). In this case, the URL (which is safe) will not be suitable for interaction with the advertising device (but with the service of the URL), but it would be even better for the URL owner (company/service) to prevent the advertising of its URL by devices that it does not control. A security indication check aims at solving this issue by enabling a discovery agent to query a service in order to check that a given URL can be loaded with a given security indication. For instance, this can be achieved by adding a specific header to an HTTP request for said URL (e.g. ‘security-indication’ header, with a value based on the security indication). Then, when receiving this request, a dedicated server can determine whether the URL can be loaded with said security indication. If a strong authentication is needed for said URL but a lower security indication is provided, a response indicating that URL should not be loaded with said security indication can be returned (e.g. by adding a dedicated header to the response, for instance ‘security-indication-check’ with the value ‘failure’ in case of failure, or ‘success’ in case of success).

Thus, a checking procedure may comprise one or more different kinds of checks or, in a variant, a “by-default” checking procedure may be set, in particular when the security indication is not associated with any risky feature (i.e. the URL can be loaded in an execution context where all features representing a threat for security are disabled). For instance, the by-default checking procedure is such that it is always considered to be successful (at next step 230).

A detailed example of determination of a checking procedure is described with reference to Figure 3.

The checking procedure is then executed and it is determined at step 230 whether it is successful or not. For instance, the checking procedure is successful if a user’s authorization for executing the web application is provided.

If the checking procedure is successful, step 230 is followed by step 250, which is similar to step 120 of Figure 1.

Otherwise, if the checking procedure is not successful, the execution of the web application according to the determined set of features is rejected at step 240.

Optionally, the user may be allowed to retry running the checking procedure, especially if user inputs are needed (e.g. a user may have input an invalid password). Steps 240 and 250 are followed by the end of the process (step 290).

Advantageously, these second embodiments allow improving the safety of URL loading in a simple way. For instance, they allow preventing the advertisement of an authorized URL, e.g. from a well-known company, by a device which is not authorized to do so (by said well-known company). This situation is problematic since if the URL is loaded and a connection is established with the non-authorized device (i.e. if the establishment of a connection with this device is a feature accessible to the authorized URL), the latter may then obtain user data.

Fortunately, an appropriate checking procedure makes it possible to detect when the second device oversteps its rights and requires undue access to critical data/functions of the first device.

As mentioned above, a notification may be displayed to enable a user to request the loading of the URL and thus the execution of the corresponding web application. When doing so, different checking procedures may be contemplated.

According to a first example, the checking procedure does not require a user input (e.g. an authorization or authentication is necessary, but it can be performed automatically). In this case, step 160 is advantageously performed prior to displaying such notification. This is because, in the case of a failure at step 230 (i.e. the security requirements are not met), the URL should not be loaded (i.e. the corresponding web application should not be executed). Hence no notification should be displayed to the user.

According to a second example, if a user input is required (e.g. to input credentials or to perform a physical pairing), corresponding steps are advantageously performed after the user has requested the loading of said URL by interacting with said notification.

Preferably, in the case where the checking procedure comprises some steps that can be performed automatically and others that require a user input, the first ones may be performed prior to displaying a notification and the second ones only after user has requested the loading of the URL through said notification.

Figure 3 shows exemplary steps for determining a checking procedure based on a URL and a security indication according to embodiments. These steps are for instance performed by the first device 410 shown in Figure 4.

At step 300, a URL and a security indication are obtained. In this example, the considered security indication is a Boolean indicating whether all features should be enabled or not. If not, all risky features should be disabled. In this case, the corresponding web application cannot access the network, load other URLs, change the page location, store data locally, and discover devices and/or services on the network.

At step 310, it is checked whether the URL is local or not. It is recalled that a local URL is a URL that can be resolved locally only. For instance, this is the case of the URLs the “host” portion of which is associated with a local IP address. Among all the possible IP addresses, some ranges are reserved to this usage, for instance addresses starting by 192.168.

If the URL is local, it is checked at step 320 whether all features should be enabled or not. This is determined based on the security indication. If not all features should be enabled, the checking procedure is set to the by-default procedure (step 370) and the process ends (step 390). On the other hand, if all features should be enabled, the checking procedure is set to a physical pairing (step 330) and the process ends (step 390).

As a matter of fact, with a local URL, it is generally not possible to perform a URL check or to perform a strong authentication procedure or a security indication check. However, performing a physical pairing is possible. It is assumed that if the security indication is associated with all available features including sensible features, the purpose is that the loaded URL may connect to the advertising device to enable e.g. remote control. Therefore, a physical pairing is useful in this context.

If the URL is not local, a URL check is added to the checking procedure (step 340).

Next, at step 350, it is determined whether all features should be allowed or not (based on the security indication). If so, strong authentication is added to the checking procedure at step 360 and if not, a security indication check is added to the checking procedure at step 380. In the first case, the strong authentication allows it to be ensured that the advertising device is actually associated with the URL it advertises. In the second case, the security indication check procedure allows it to be ensured that the URL is not intended to be executed with a different security indication.

After steps 360 and 380, the process ends (step 390).

The above description provides an exemplary implementation of the determination of a checking procedure. In particular, the security indication is considered to be only a Boolean. However, the possible embodiments are not limited to this and additional different values may be considered regarding the security indication, as described above.

Figure 4 illustrates an example of context in which embodiments of the invention may be implemented.

The represented system 400 comprises a first device 410 (personal device), a second device 420 (advertising device), and a communication network 430 over which these devices may communicate.

The communication network 430 is for instance a BLE network or an IPbased local or wide area network (LAN, WAN).

The first device 410 may be an end-user device such as a mobile device, a smartphone, a micro-computer (laptop), a workstation, a desktop computer or a light portable device. According to embodiments, it is configured to run a web application, for instance for controlling the second device 420. However, this is not compulsory.

The second device 420 is for instance a multi-function printer, a scanning device, a camera or a fax machine. It may be configured to be controlled remotely by the above-mentioned web application.

For illustrative purposes, it is assumed that the second device 420 is a printer that relies on URL advertising to enable the first device 410 to load a user guide. For instance, this user guide simply consists of a web page with text, images and possibly videos. Therefore, once the page is loaded, there is no need for network access, local data storage or device discovery. Consequently, when such a URL is advertised, the associated security indication is preferably ALLOW_MINIMAL (introduced above). Indeed, there is no reason to select another security indication: ALLOW_STORAGE, ALLOW_NETWORK and ALLOW_ALL (introduced above) make more features available to the web application, but these features are not required in this case, and they also require a more complex checking procedure. Performing such procedure would be more complex for the printer manufacturer (since a more complex infrastructure has to be set up) and/or for the user (e.g. more complex user experience in case of physical pairing).

This example may be extended to other cases where URL advertising is used to provide complementary information. This may be the case for a user guide explaining how to use a device or how to solve an issue on a device, and especially for providing contextual information about something (e.g. providing details about a place, an object, a painting, etc.).

In another example (not shown), a camera which provides a remote control feature through a web application is considered. This web application needs to connect to a considered camera in order to enable remote control. For instance, the user can set various optical parameters of the camera as well as trigger image capture. In this case, the corresponding URL may for instance be advertised with ALLOW_ALL. A more complex checking procedure will be needed when compared to the previous example, but this is necessary as some features that require specific security checks are supposed to be used by the web application associated with the advertised URL.

This example may be extended to other cases where URL advertising is used to enable interactions with a remote device.

Figure 5 represents an exemplary architecture 500, for instance for the first device 410 (e.g. smartphone) or the second device 420 (advertising device) shown in Figure 4.

The device 500 comprises a communication bus 502 to which there are preferably connected:

- a central processing unit 504, such as a microprocessor, denoted CPU;

- a read only memory 506, denoted ROM, for storing computer programs for implementing the invention;

- a random access memory 508, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention;

- at least one communication interface 512 each connected to a communication network 514 over which communications can be implemented. A communication interface is provided to send and receive messages, for instance according to BLE, mDNS or SSDP protocol, over the communication network 400 shown in Figure 4. Another communication interface may be provided to exchange HTTP or HTTPS requests/responses, e.g. for the loading of a URL; and

- a data storage means 510 such as a hard disk, for storing computer programs for implementing steps of one or more embodiments of the invention and for storing data, during the implementation of one or more embodiments of the invention.

The device 500 also includes a user interface 516 to display information to, and/or receive inputs from, a user. For instance, it may be a screen for displaying data such as the user interface of a web application and/or serving as a graphical interface with a user, by means of a keyboard or any other pointing means.

The communication bus provides communication and interoperability between the various elements included in the device 500 or connected to it. The representation of the bus is not limiting and in particular the CPU 504 is operable to communicate instructions to any element of the device 500 directly or by means of another element of the device 500.

The disk 510 can be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the device, possibly removable, and adapted to store one or more programs whose execution enables a method according to the invention to be implemented.

Instructions relating to the software application may be loaded to the main memory 508 from a hard-disk (HD) 510 or the program ROM 506 for example. According to a variant, the executable code of the programs can be received by means of the communication network 514, via the interfaces 512, in order to be stored in one of the storage means of the device 500, such as the hard-disk 510, before being executed. Such software application, when executed by the CPU 504, causes the steps described with reference to Figures 1 to 3 to be performed in the device 500.

The CPU 504 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard-disk 510 or in the ROM 506, are transferred into the RAM 508, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In this embodiment, the device is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). It can consist of one or more dedicated integrated circuits that are capable of implementing the method as described with reference to Figures 1 to 3.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive, the invention being not restricted to the disclosed embodiment. Other variations to the disclosed embodiment can be understood and effected by those skilled in the art in putting into practice (i.e. performing) the claimed invention, from a study of the drawings, the disclosure and the appended claims.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. Any reference signs in the claims should not be construed as limiting the scope of the invention.

Claims

1. A method of executing a web application in a web runtime environment running on a first device, the method comprising, at the first device:

2. The method of claim 1, comprising a step of determining a checking procedure to be performed based on the security indication.

3. The method of claim 2, wherein determining a checking procedure is based on the determined set of features.

4. The method of claim 2 or 3, wherein the checking procedure requires a user input on the first device.

5. The method of any one of claims 2 to 4, wherein the checking procedure requires a physical interaction involving the first device and the second device or another device.

6. The method of any one of claims 2 to 5, wherein the checking procedure comprises checking a list of forbidden or authorized URLs.

7. The method of any one of claims 2 to 6, wherein the checking procedure is based on a token.

8. The method of any one of claims 2 to 7, wherein the checking procedure comprises verifying that the received URL and the received security indication can be associated.

9. The method of any one of claims 2 to 8, comprising a step of performing the determined checking procedure, the step of executing the web application according to the determined set of features being performed based on the result of the checking procedure.

10. The method of any one of claims 1 to 9, wherein executing the web application according to the determined set of features comprises creating an adapted execution context and loading said URL in this execution context such that only features of the determined set are accessible to the web application thus executed.

11. The method of any one of claims 1 to 10, wherein the step of determining a set of features to be enabled and/or the step of executing the web application is/are performed upon dedicated user authorization.

12. The method of any one of claims 1 to 11, wherein the URL and the associated security indication are received in a same advertisement message.

13. The method of any one of claims 1 to 12, wherein the set of features to be enabled during execution of said web application comprises at least one of: network access, loading of other URLs on the first device, local data storage on the first device, access to discovery API, HTTP request performance, history access, camera/micro access, access to geo-tracking features of the first device, control of vibrate or audio features of the first device.

14. A computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 13.

15. A first device for executing a web application in a web runtime environment configured to be run on the first device, the first device being configured to communicate with a second device over a communication network, the first device being configured for:

determining, based on the received security indication, a set of features to be enabled during execution of said web application; and

5 executing the web application in the web runtime environment according to the determined set of features.

16. The first device of claim 15, comprising a discovery agent configured to determine the set of features to be enabled during execution of said web application.

17. A method substantially as described herein with reference to, and as shown in Figures 1,2, 3.

18. A system substantially as described herein with reference to, and as 15 shown in Figure 4.

19. A device substantially as described herein with reference to, and as shown in Figure 5.

Intellectual

Property

Office

Application No: Claims searched: