WO2019145601A1

WO2019145601A1 - Web browsing security threat control and protection

Info

Publication number: WO2019145601A1
Application number: PCT/FI2019/050033
Authority: WO
Inventors: Mikko KORTELAINEN
Original assignee: Suomen Kanuuna Oy
Current assignee: Suomen Kanuuna Oy
Priority date: 2018-01-24
Filing date: 2019-01-17
Publication date: 2019-08-01
Anticipated expiration: 2020-07-24
Also published as: FI20185066A1

Abstract

It is an objective to provide a device for mitigating privacy and security threats in web browsing. According to a first aspect, a device is configured to receive a request for web content from a client device, wherein a web server comprises the requested web content; initialise a mitigating web browser, wherein the initialisation removes history information from the mitigating web browser; retrieve the requested web content from the web server using the mitigating web browser; construct a representation of the requested web content from the retrieved web content using the mitigating web browser; and send a response to the client device, wherein the response comprises the representation of the requested web content. With these configurations, the device may, for example, mitigate privacy and security threats and reduce latency, bandwidth usage and power consumption of the client device. A device, a method,and computer program are described.

Description

WEB BROWSING SECURITY THREAT CONTROL AND

PROTECTION

TECHNICAL FIELD

[0001 ] The disclosure relates to an electronic device, and more particularly to a device for mitigating privacy and security threats in web browsing. Furthermore, the disclosure relates to corresponding methods and a computer program. BACKGROUND

[0002] Modern web browsing may introduce various privacy and security threats for both private individuals and corporations. For example, malicious web content, such as web sites or web applications, may target the browser of a user in order to obtain critical information. In the case of corporations, for example, this type of attack may be utilised for industrial espionage and data leaks. Furthermore, even without any malicious content, a third party may use the web browsing habits of a user to track and profile the user without their consent. For example, even simple search engine queries performed from a corporation’s internet protocol, IP, address may reveal information about a new product under development.

SUMMARY

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] It is an objective to provide a device for mitigating privacy and security threats in web browsing. The object is achieved by the features of the independent claims. Further implementation forms are provided in the dependent claims, the description and the figures. [0005] According to a first aspect, a device is configured to receive a request for web content from a client device, wherein a web server comprises the requested web content; initialise a mitigating web browser, wherein the initialisation removes history information from the mitigating web browser; retrieve the requested web content from the web server using the mitigating web browser; construct a representation of the requested web content from the retrieved web content using the mitigating web browser; and send a response to the client device, wherein the response comprises the representation of the requested web content. With these configurations, the device may, for example, mitigate privacy and security threats and reduce latency, bandwidth usage and power consumption of the client device.

[0006] In a further implementation form of the first aspect, the device is further configured to determine from the request if the device should load a previous web browser state to the mitigating web browser; load a previous web browser state from a state storage to the mitigating web browser, if the device should load a previous web browser state to the mitigating web browser and the previous web browser state exists in the state storage. This may, for example, enable stateful web browsing in situations where it may be necessary.

[0007] In a further implementation form of the first aspect, the device is further configured to configure a communication interface according to a document; and receive the request from the client device and send the response to the client device using the communication interface. For example, compatibility of the device with various types of client devices may be extended.

[0008] In a further implementation form of the first aspect, the device is further configured to remove from the request information that could be used to identify the client device. Thus, the device may, for example, further mitigate privacy threats targeting the client device.

[0009] In a further implementation form of the first aspect, the device is further configured to remove from the request information that could be used to track the client device. Thus, the device may, for example, further mitigate privacy threats targeting the client device.

[0010] In a further implementation form of the first aspect, the device is further configured to apply processing to the retrieved web content. Thus, the device may, for example, further mitigate privacy and security threats targeting the client device.

[001 1 ] In a further implementation form of the first aspect, the processing removes a harmful component from the retrieved web content. Thus, the device may, for example, further mitigate security threats targeting the client device.

[001 2] In a further implementation form of the first aspect, the processing removes an advertisement from the retrieved web content. Thus, the device may, for example, reduce unnecessary client device processing.

[001 3] In a further implementation form of the first aspect, the device is further configured to accept or reject the request based on access control rules. Thus, the device may, for example, prevent the client device from accessing content that could impose a security threat.

[001 4] In a further implementation form of the first aspect, the device is further configured to adapt the retrieved web content to be compatible with the client device. Thus, the device may, for example, adapt the content to be compatible with the client device regardless of the client device configuration.

[001 5] In a further implementation form of the first aspect, the device is further configured to save a current state of the mitigating web browser to the state storage. Thus, the device may, for example, load the state at a later time if stateful web browsing is requested.

[001 6] In a further implementation form of the first aspect, the device is further configured to send only a single response to the client device as a response to receiving a single request. Thus, the device may, for example, reduce the amount of bandwidth used by the client device. [001 7] In a further implementation form of the first aspect, the device is further configured to send a plurality of requests to the web server while retrieving the requested web content. Thus, the device may, for example, reduce the amount of bandwidth used by the client device.

[001 8] According to a second aspect, a method comprises receiving a request for web content from a client device, wherein a web server comprises the requested web content; initialising a mitigating web browser, wherein the initialisation removes history information from the mitigating web browser; retrieving the requested web content from the web server using the mitigating web browser; constructing a representation of the requested web content from the retrieved web content using the mitigating web browser; and sending a response to the client device, wherein the response comprises the representation of the requested web content.

[001 9] According to a third aspect, a computer program is provided, comprising program code configured to perform a method according to the second aspect when the computer program is executed on a computer.

[0020] Many of the attendant features will be more readily appreciated as they become better understood by reference to the following detailed description considered in connection with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

[0021 ] The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:

[0022] FIG. 1 illustrates a schematic representation of a communication system according to an embodiment;

[0023] FIG. 2 illustrates a schematic representation of a device according to an embodiment;

[0024] FIG. 3 illustrates a schematic representation of mitigating workload request handling according to an embodiment; [0025] FIG. 4 illustrates a schematic representation of mitigating workload request handling according to another embodiment;

[0026] FIG. 5 illustrates a schematic representation of mitigating workload request handling according to another embodiment;

[0027] FIG. 6 illustrates a schematic representation of a request process according to an embodiment;

[0028] FIG. 7 illustrates a schematic representation of a mitigation procedure that can be implemented in the mitigating workload of a device according to an embodiment;

[0029] FIG. 8 illustrates a schematic representation of a flow chart of a processing state according to an embodiment;

[0030] FIG. 9 illustrates a schematic representation of a flow chart of a construct state according to an embodiment;

[0031 ] FIG. 10 illustrates a schematic representation of a flow chart of a mitigation state according to an embodiment;

[0032] FIG. 11 illustrates a schematic representation of a flow chart of a return state according to an embodiment; and

[0033] FIG. 12 illustrates a schematic representation of a flow chart of a web content request process according to an embodiment.

[0034] Like references are used to designate like parts in the accompanying drawings.

DETAILED DESCRIPTION

[0035] The detailed description provided below in connection with the appended drawings is intended as a description of the embodiments and is not intended to represent the only forms in which the embodiment may be constructed or utilized. However, the same or equivalent functions and structures may be accomplished by different embodiments.

[0036] According to an embodiment, a device is configured to receive a request for web content from a client device, and a web server comprises the requested web content. The device initialises a mitigating web browser. The initialisation removes history information from the mitigating web browser. The initialisation may also remove other information from the mitigating web browser. The device retrieves the requested web content from the web server using the mitigating web browser, constructs a representation of the requested web content from the retrieved web content using the mitigating web browser, and sends a response to the client device. The response comprises the representation of the requested web content. Since the content is retrieved using the initialised mitigating web browser located on the device, no information may leak about the client device or about previous requests sent by the client device. Thus, privacy threats may be mitigated by the device, since profiling and tracking attempts of the client device may be hindered. Furthermore, since the retrieved content is processed by the mitigating web browser of the device, any security threats targeting the client device target the mitigating browser. Therefore, the mitigating browser of the device functions as a protective layer between the content and the client device, which mitigates security threats.

[0037] FIG. 1 illustrates a schematic representation of a communication system according to an embodiment. The communication system comprises client devices 100 1, 100 2, 100 3, mitigating workload processors 200 1, 200 2, 200 3, and web servers 300 1, 300 2, 300 3. It should be appreciated that the number of devices in FIG. 1 is only exemplary. Furthermore, the number of different types of devices does not need to be equal. The client devices 100 1 , 100 2, 100 3 may be connected to the mitigating workload processors 200 1, 200 2, 200 3 through an interconnecting bus 101. The workload processors 200 1, 200 2, 200 3, in turn, may be connected to the web servers 300 1, 300 2, 300 3 through a second interconnecting bus 102. The client devices 100 1, 100 2, 100 3 may be, for example, desktop computers, laptops, or mobile devices, such as mobile phones. The mitigating workload processors 200 1, 200 2, 200_3 may be implemented, for example, on servers, or any other devices that are able to process information. The term mitigating workload processor 200 1 , 200 2, 200 3 may refer to a functionality implemented by some device, or the term may refer to the device that implements the functionality. Therefore, the mitigating workload processors 200 1, 200 2, 200_3 may also be referred to by the term device. A single device may even comprise multiple mitigating workload processors 200 1, 200 2, 200 3. Furthermore, the mitigating workload processors 200 1, 200 2, 200 3 may be implemented, for example, on a proxy server, and the proxy server may control the mitigating workload processors 200 1, 200 2, 200 3 through an interface, such as the internet content adaptation protocol, ICAP. The web servers 300_l, 300_2, 300_3 may be any devices that are configured to provide web content to other devices using, for example, the interconnecting bus 102. Web content may be, for example, textual, visual, or aural content that may comprise, for example, text, images, sounds, videos, animations, web pages, and web applications.

[0038] Interconnecting bus 101 may be any connection that enables the client devices 100 1, 100 2, 100 3 to communicate with the mitigating workload processors 200 1, 200 2, 200 3. Similarly, interconnecting bus 102 may be any connection that enables the mitigating workload processors 200 1, 200 2, 200 3 to communicate with the web servers 300 1, 300 2,

300 3. The interconnecting busses 101, 102 may be, for example, internet, Ethernet, 3G, 4G, LTE, Wi-Fi, or any other wired or wireless connections or some combination of these. For example, if a client device 100 1 , 100 2, 100 3 is a mobile device, the interconnecting bus 101 may comprise a wireless connection, such as Wi-Fi, an internet connection, and an Ethernet connection.

[0039] FIG. 2 illustrates a schematic representation of a device 200 according to an embodiment. The device 200 may also be referred to as a mitigating workload processor, and it may comprise one or more mitigating workloads 201. Furthermore, a mitigating workload may comprise one or more mitigating web browsers 202. A client device 100 1, 100 2, 100 3 may access the mitigating workload using client communication 203. Furthermore, the mitigating workload 201 and the mitigating web browser 202 may access the web servers 300_l, 300_2, 300_3 using external communication 204. The client communication 203 and the external communication 204 can be implemented, for example, as Hypertext Transfer Protocol, HTTP, communication. Client communication interfaces

206 may be used for adapting the communication between the mitigating workload 201 and the client devices 100 1, 100 2, 100 3.

[0040] Processing instructions 205 may be configured to pre- and/or post-process any communication between the client devices 100 1, 100 2, 100 3 and the mitigating workload 201, and between the mitigating workload 201 and the web servers 300 1, 300 2, 300 3. Transformations

207 for adapting content retrieved from the web servers 300_l, 300_2, 300 3 to a format compatible with the client devices 100 1, 100 2, 100 3 may also be configured in the device 200. The processing instructions 205, client communication interfaces 206, and transformations 207 may be configured using documents that may be located in the memory of the device 200.

[0041 ] Using the client communication 203 and the client communication interfaces 206, a client device 100 1, 100 2, 100 3 may send a request to the mitigating workload 201 for web content, such as a web page or a web application that is located on a web server 300 1, 300 2, 300 3. The mitigating workload 201 may use pre-processing to, for example, remove information from the request that could be used to identify the client device 100 1, 100 2, 100 3 that initiated the request. This may mitigate privacy threats. For example, a HTTP header or a uniform resource locator, URL, in the request may comprise such information. Furthermore, the pre-processing may comprise access control rules using access control lists, which may be used to block requests to, for example, unsafe content in order to mitigate security threats. The mitigating workload 201 may retrieve the requested content from a web server 300_l, 300_2, 300_3 using the mitigating web browser 202 and the external communication 204.

[0042] The mitigating workload may use post-processing on the retrieved content to, for example, perform deep protection in order to mitigate external security threats. Furthermore, the device 200 can use a pre-defmed data model to analyse and control data submission. The results of this analysis and control may be used to collect and prevent attempts of espionage, data leaking, or tracking. The mitigating web browser may construct an original-like representation of the retrieved web content, and the original-like representation may be sent to the client device 100 1, 100 2, 100 3. Therefore, any external threats, such as browser hijacks or malicious file downloads, target the mitigating web browser 202 instead of the client device 100. Thus, the mitigating workload 201 and the mitigating web browser 202 may serve as a protective layer between the client device 100 1, 100 2, 100 3 and any external threats. Furthermore, the mitigating workload 201 may be configured using the processing instructions 205 and/or transformations 207 to remove any unwanted components, such as advertisements or potentially harmful scripts, from the web content. Since all of these components may still be processed by the mitigating web browser 202, any external party may not be able to detect the removal of these components or the existence of the mitigating web browser 202. Furthermore, all of these functionalities can be implemented independent of the client device 100 1, 100 2, 100 3 configuration.

[0043] The functionality described herein can be performed, at least in part, by one or more computer program product components such as software components. According to an embodiment, the device 200 comprises a processor configured by the program code when executed to execute the embodiments of the operations and functionality described. Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include field-programmable gate arrays, FPGAs, application-specific integrated circuits, ASICs, application-specific standard products, ASSPs, system-on-a-chip systems, SOCs, complex programmable logic devices, CPLDs, graphics processing units, GPUs.

[0044] FIG. 3 illustrates a schematic representation of mitigating workload request handling according to an embodiment. The client device 100 may send a request 103 to the mitigating workload 201. The request 103 may indicate that the mitigating workload 201 should retrieve some web content. For example, the request 103 may comprise a request method and a request target. The request method may indicate an action that the mitigating workload 201 should perform on the content indicated by the request target. The method may for example indicate that the mitigating workload 201 should retrieve the request target. The request target may comprise, for example, a URL of the requested web content. Furthermore, the request 103 may indicate that the mitigating workload 201 should handle the request 103 as stateless, meaning that the state of the mitigating web browser 202 should not be conserved between consecutive requests. Thus, consecutive requests should effectively be isolated into own mitigating web browsers 202. For example, in stateless web browsing, if a user of the client device 100 clicks a link on a web page which sends a request for the new page that the link points to, the state of the mitigating web browser 202 should not be conserved between the two consecutive web pages. Thus, when the second page is requested, the browser should not comprise any indication that the previous page had been loaded previously or that the mitigating web browser 202 transitioned from the previous page to the second page. This may, for example, prevent any external party from tracking and analysing the browsing behaviour of the user. The mitigating workload 201 may mitigate this tracking and profiling by initialising the mitigating web browser 202 in operation 208 after receiving the request 103 and then retrieving the requested content using the initialised browser 202. Since the mitigating web browser 202 has been initialised, it should not comprise any history information about previous web content that the user may have visited, for example in the page history or in browser cookies.

[0045] FIG. 4 illustrates a schematic representation of mitigating workload request handling according to another embodiment. The handling of the embodiment of FIG. 4 may be similar to that of FIG. 3, but now the request 103’ may indicate that the mitigating workload should handle the request 103’ as stateful, meaning that the state of the mitigating web browser should be conserved between requests. This functionality may be beneficial, for example, when a browser session is required for a web page or a web application to function properly. However, as indicated by the empty field 209, a previous browser state may not exist in the device 200. Therefore, the mitigating workload 201 initialises the mitigating web browser 202 in operation 208, because no previous state can be loaded. This type of situation may arise, for example, when requests preceding request 103’ have been handled statelessly, and therefore a previous browser state has not been saved. After fulfilling the request 103’, the mitigating workload 201 may save the state of the mitigating web browser, so that it can be loaded if a following request should be handled as stateful.

[0046] FIG. 5 illustrates a schematic representation of mitigating workload request handling according to another embodiment. The handling of the embodiment of FIG. 5 may be similar to that of FIG. 4. Again, the request 103’ may indicate that the mitigating workload 201 should handle the request 103’ as stateful. Now, contrary to the previous embodiment, a previous browser state 209’ exists. Thus, the mitigating workload 201 can load the previous state 209’ into the mitigating web browser 202 in operation 210. Naturally, the device 200 implementing the mitigating workload 201 may comprise any number of previous browser states 209’ which may correspond to different browsing sessions or even to different users. These states may be stored in the memory of the device 200. This part of the memory may be referred to as state storage. In such a case, the mitigating workload 201 should load the previous state 209’ that corresponds to the request 103’ and the client device 100. Like with the previous embodiment, after fulfilling the request 103’, the mitigating workload 201 may save the state of the mitigating web browser 202, so that the state can be loaded if a following request should be handled as stateful.

[0047] It should be appreciated that the embodiments of FIGs. 3 - 5 may be implemented in the same device 200 and in the same mitigating workload 201, and that handling the requests 103, 103’ can be dynamically changed based on the type of the request 103, 103’ and whether the handling should be stateful or not. For example, the stateless handling of FIG. 3 may be used as a user browses various web pages. If some web page requires a browser session, for example, the first request requiring such browser session may be handled as presented in FIG. 4, and the consecutive requests may be handled using the embodiment of FIG. 5 so that the state of the mitigating web browser is conserved. When stateful browsing is no more required, the requests can again be handled using the embodiment of FIG. 3. Thus, the privacy of the user may be improved as tracking and profiling of the user should not be possible, while no additional inconvenience is introduced to the user.

[0048] FIG. 6 illustrates a schematic representation of a request process according to an embodiment. The client device 100 sends a request 103 to a mitigating workload 201 for some web content that is located on a web server 300. If the requested content comprises a large amount of dynamic content, which may be especially true in the case of so called web applications, fulfilling a single request 103 may require multiple consecutive requests and responses 301 as different parts of the content are retrieved. The number of requests and responses 301 in FIG. 6 is only exemplary and only illustrates that the single request 103 may cause multiple additional requests and responses 301. Furthermore, some content may need to be retrieved from other web servers. Since the mitigating workload 201 may construct an original-like representation of the requested content, the consecutive requests and responses 301 may be transferred between the mitigating workload 201 and the server 300. If the mitigating workload was not used, the consecutive requests and responses 301 could be transferred between the client device 100 and the web server 300. Therefore, the amount of data sent and received by the client device 100 may be reduced when the mitigating workload 201 is used, because the client device 100 only sends the original request 103 and receives in the response 104 an original-like representation of the requested content constructed by the mitigating workload 201.

[0049] The response 104 may comprise the original-like representation of the requested content in, for example, a markup language, such as hypertext markup language, HTML, or extensible markup language, XML, or similar. The mitigating workload 201 may transmit the response 104 as a response to the request 103. The mitigating workload 201 may transmit a single response 104 for each request 103.

[0050] Furthermore, latency between the client device 100 sending the request 103 and receiving the response 104 may be significantly reduced. Both of these effects may be especially significant if the connection of the client device 100 is substantially poorer with respect to latency and/or bandwidth than the connection between the mitigating workload 201 and the web server 300. This may be the case, for example, when the client device 100 is a wireless device and the mitigating workload 201 is located in a data centre. The power consumption of the client device 100 may also be reduced, since the client device 100 does not need to wirelessly transmit and receive all of the requests and responses 301. Additionally, since the mitigating workload 201 may use the processing instructions 205 to remove unnecessary, unsafe, or computationally heavy components from the requested web content, used bandwidth, latency, and power consumption of the client device 100 may be reduced even further.

[0051 ] FIG. 7 illustrates a schematic representation of a mitigation procedure that can be implemented in the mitigating workload 201 of the device 200 according to an embodiment. The procedure begins in an idle state 701. If a request is received, the procedure may move to a processing state 702. In the processing state 702, the request can be processed, and a set of processing documents can be loaded. If the request is rejected in the processing state due to, for example, access control rules, the procedure can move to a reject state 705, from there to a return state 706, and back to the idle state 701. On the other hand, if the request is not rejected, the procedure may move to a construct state 703. In the construct state 703, execution paths can be formed based on the processing, communication interface, and transformation data. Once the execution paths have been formed, the procedure may move to a mitigation state 704, where the formed paths are executed. After the mitigation state 704, the procedure can move to the return state 706 and then back to the idle state 701.

[0052] FIG. 8 illustrates a schematic representation of a flow chart of the processing state 702 that can be implemented in the mitigating workload 201 of the device 200 in further detail according to an embodiment. In operation 801, a request is received, and in operation 802, processing documents may be parsed so that processing instructions 205 can be configured. Based on the parsed processing documents, in operation 803, the request may be permitted or rejected. If the request is rejected, the procedure can move to a reject handler in operation 804, where a deny request object can be constructed. A rejection may be based on, for example, access control lists from the processing documents. The request may be decrypted using, for example, dynamic certificate singing. Alternatively, only plain communication may be supported, and encrypted requests may be rejected.

[0053] If the request is permitted, the procedure may move to operation 805, where the protection of the request by a mitigation service is decided. If the request is not to be protected, the procedure may move to operation 806, where a bypass request object may be constructed. If the request is to be protected by the mitigation service, the procedure can move to operation 807, where a protection request object can be constructed. From operation 806 or from operation 807, the procedure may move to operation 808, where the object constructed in operation 806 or in operation 807 can be returned.

[0054] FIG. 9 illustrates a schematic representation of a flow chart of the construct state 703 that can be implemented in the mitigating workload 201 of the device 200 in further detail according to an embodiment. In operation 901, the request object returned in operation 808 can be fetched, and the procedure may transition to operation 902, where client communication interface documents can be parsed in order to configure the client communication interfaces 206. The procedure may move next to operation 903, where it is examined if the interfaces are defined. If the interfaces are not defined, the procedure can transition to operation 909. If the interfaces are defined, the procedure can move to operation 904, where interface objects are constructed. After the construction, the procedure may move to operation 905, where any interface defined for the request object is identified. If no interface is identified for the request object, the procedure may move to operation 909. On the other hand, if an interface is identified for the request object, the procedure may move to operation 906, where request specific interface is constructed, after which the procedure may move to operation 907. In operation 907, interaction between the interface and the mitigation is assessed. If the interface cannot interact with the mitigation, the procedure may move to operation 908, where a response object may be constructed, and the procedure may move next to operation 912. If the interface can interact with the mitigation, the procedure may move to operation 909. As was stated above, the procedure may also move to operation 909 from operation 905 or from operation 903. In operation 909, transform documents may be parsed in order to configure transformations 207. After the parsing, the procedure may move to operation 910, from where the procedure may move to operation 912 if no transformation is defined. If a transformation is defined, the procedure may move to operation 911, where transformation objects can be constructed. After the construction, the procedure may move to operation 912, where object lists are returned. The object lists may comprise the request object, transform objects, the response object, the bypass request object, or some combination of these.

[0055] FIG. 10 illustrates a schematic representation of a flow chart of the mitigation state 704 that can be implemented in the mitigating workload 201 of the device 200 in further detail according to an embodiment. In operation 1001, object lists returned in operation 912 may be fetched, and request objects may be parsed in operation 1002. If a bypass request object is detected in operation 1003, the procedure may move to operation 1024. Such a bypass request object may have been constructed in operation 806. Otherwise, the procedure may move to operation 1004, where a response object can be parsed. The procedure may move next to operation 1005, from where the procedure may move to operation 1023, if a response object has been initialised. The initialisation of the response object may have already occurred in operation 908 if the interface does not interact with the mitigation. If a response object has not been initialised, the procedure may continue to operation 1006, where request transform objects can be parsed. If a request transform exists, the procedure may transition from operation 1007 to operation 1008, where the request transform is performed, and then transition to operation 1009. If a request transform does not exist, the procedure may directly transition from operation 1007 to operation 1009. In operation 1009, interface objects are parsed.

[0056] In operation 1010, the type of the interface object can be identified. If the interface is such that the state of the mitigating web browser should be conserved between consecutive requests from the client device 100, the interface may be stateful. On the other hand, if the state of the mitigating web browser should not be conserved between consecutive requests, the interface may be stateless. If the interface is not stateful, the procedure may move to operation 1013. If the interface is stateful, the procedure may move to operation 1011, where the existence of a previous browser state in the state storage is assessed. If a previous state does not exist, the procedure may move to operation 1014, where a state object is created and may be added to the state storage, and then the procedure transitions to operation 1013, where the mitigating web browser is initialised. On the other hand, if a previous state exists, the procedure may move to operation 1012, where the previous state is loaded, and then move to operation 1015, where the state is loaded into the mitigating web browser. After operation 1015 or operation 1013, the procedure may move to operation 1016, where the mitigating web browser is ready for the requested content to be retrieved.

[0057] In operation 1017, the request can be performed in order to retrieve the requested web content. Next, a response can be received in operation 1018. In operation 1019, response transform objects can be parsed, and the existence of response transforms can be assessed in operation 1020. If response transforms exist, the procedure may move to operation 1021, where the transforms can be performed to the retrieved content, and then the procedure can move to operation 1022. If response transforms do not exist, the procedure may move from operation 1020 to operation 1022. In operation 1022, the state of the document object model, DOM, is assessed. If the DOM is not complete, the procedure may return to operation 1017, where a new request is performed in order to obtain a missing component of the DOM, and operations 1018 - 1021 may be performed for this part of the DOM. If the DOM is still not complete, in operation 1022, the procedure may again return to operation 1017. Thus, the procedure may loop operations 1017 - 1022 until the DOM is complete. Once the DOM is complete, for example all components of a requested web page or web application have been retrieved, the procedure may move to operation 1023, where a response object may be constructed. After operation 1023, the procedure may move to operation 1024, where a return handler can be called. [0058] FIG. 11 illustrates a schematic representation of a flow chart of the return state 706 that can be implemented in the mitigating workload 201 of the device 200 in further detail according to an embodiment. In operation 1101, a return object can be fetched. If the request object is not of the response type, the procedure may move to operation 1103, and if the object is not of the request type either, the procedure may move to operation 1104, where an error handler can be called. If the return object is of the request type, the procedure may move from operation 1103 to operation 1106, where a request is sent. On the other hand, if the return object is of the response type, the procedure may move from operation 1102 to operation 1105, where a response is sent.

[0059] FIG. 12 illustrates a schematic representation of a procedure for displaying web page content on a client browser according to an embodiment. The procedure may be initiated by entering an URL 1201 into a client web browser 105. The client browser may be implemented by the client device 100. The client browser 105 may send a request for the web page corresponding to the URL 1201 to a web request proxy 1202. In the proxy 1202, procedure steps presented in the embodiments of FIGs. 7 - 11 may be used to process the request 103, and a mitigating browser 202 may be invoked. The mitigating browser 202 may send a request 1204 to the web server 300 and receive an initial page in a response 1205. After processing the initial page, the mitigating browser 202 may request for missing components, such as JavaScript parts, of the web page from the web server 300. The mitigating browser may continue sending requests 1204 for the components and receiving responses 1205 until the requested page is complete. When the web page is determined to be complete in operation 1206, a complete response 104 may be sent to the client browser 105 using a web response proxy 1207. The client browser 105 may then display the requested web page without further requests or structure processing. [0060] As can be seen from the embodiment of FIG. 12, less processing may be needed on the client device 100 compared to the situation where the mitigating browser 202 was not used. This may, for example, enhance the battery life of mobile devices. Furthermore, the client device 200 may need to send and receive less data, which may be especially beneficial if the client device is using a metered internet connection. Similarly, latency between sending the request 103 and receiving the response 104 may be reduced, which may enhance the user experience. Furthermore, the content may be optimised by the mitigating workload 201 for the client device 100, and privacy and security threats can be mitigated.

[0061 ] Any range or device value given herein may be extended or altered without losing the effect sought. Also any embodiment may be combined with another embodiment unless explicitly disallowed.

[0062] Although the subject matter has been described in language specific to structural features and/or acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as embodiments of implementing the claims and other equivalent features and acts are intended to be within the scope of the claims.

[0063] The functionality described herein can be performed, at least in part, by one or more computer program product components such as software components. Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs). [0064] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. It will further be understood that reference to 'an' item may refer to one or more of those items. The term‘and/or’ may be used to indicate that one or more of the cases it connects may occur. Both, or more, connected cases may occur, or only either one of the connected cases may occur.

[0065] The operations of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the objective and scope of the subject matter described herein. Aspects of any of the embodiments described above may be combined with aspects of any of the other embodiments described to form further embodiments without losing the effect sought.

[0066] The term 'comprising' is used herein to mean including the method, blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0067] It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, embodiments and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this specification.

Claims

1. A device (200), configured to:

receive a request (103) for web content from a client device (100), wherein a web server (300) comprises the requested web content;

initialise a mitigating web browser (202), wherein the initialisation removes history information from the mitigating web browser;

retrieve the requested web content from the web server using the mitigating web browser;

construct a representation of the requested web content from the retrieved web content using the mitigating web browser; and

send a response (104) to the client device, wherein the response comprises the representation of the requested web content.

2. The device of claim 1, further configured to:

determine from the request if the device should load a previous web browser state to the mitigating web browser;

load a previous web browser state from a state storage to the mitigating web browser, if the device should load a previous web browser state to the mitigating web browser and the previous web browser state exists in the state storage.

3. The device of any preceding claim, further configured to:

configure a communication interface according to a document; and receive the request from the client device and send the response to the client device using the communication interface.

4. The device of any preceding claim, further configured to:

remove from the request information that could be used to identify the client device.

5. The device of any preceding claim, further configured to:

remove from the request information that could be used to track the client device.

6. The device of any preceding claim, further configured to:

apply processing to the retrieved web content.

7. The device of claim 6, wherein the processing removes a harmful component from the retrieved web content.

8. The device of claims 6 - 7, wherein the processing removes an advertisement from the retrieved web content.

9. The device of any preceding claim, further configured to:

accept or reject the request based on access control rules.

10. The device of any preceding claim, further configured to:

adapt the retrieved web content to be compatible with the client device.

11. The device of any preceding claim, further configured to:

save a current state of the mitigating web browser to the state storage.

12. The device of any preceding claim, further configured to:

send only the single response to the client device as a response to receiving the single request.

13. The device of any preceding claim, further configured to:

send a plurality of requests to the web server while retrieving the requested web content.

14. A method, comprising:

receiving (801) a request for web content from a client device, wherein a web server comprises the requested web content;

initialising (1013) a mitigating web browser, wherein the initialisation removes history information from the mitigating web browser; retrieving (1017) the requested web content from the web server using the mitigating web browser;

constructing (1203) a representation of the requested web content from the retrieved web content using the mitigating web browser; and

sending (1105) a response to the client device, wherein the response comprises the representation of the requested web content.

15. A computer program comprising program code configured to perform a method according to claim 14 when the computer program is executed on a computer.