Methods and systems for spillover from cookie to database
Patent Information
- Application Number
- CA3326449
- Authority / Receiving Office
- CA · CA
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-19
- Filing Date
- 2025-03-26
- Publication Date
- 2025-10-16
AI Technical Summary
Large browser cookies can cause performance issues due to size constraints and increase the risk of Denial of Service (DOS) attacks by storing excessive data, leading to inefficient server storage and retrieval.
Implement a data storage and retrieval system that allows browser cookies to overflow to a server-side database once a size threshold is reached, using encrypted and unencrypted headers to manage data distribution between the cookie and database, ensuring efficient data handling and security.
This approach mitigates size constraints and DOS attacks by optimizing cookie performance, reducing server load, and minimizing database storage requirements while enhancing security.
Abstract
Description
METHODS AND SYSTEMS FOR SPILLOVER FROM COOKIE TO DATABASECROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present disclosure claims priority to U.S. Application No. 18 / 893,296, filed September 23, 2024 and entitled “METHODS AND SYSTEMS FOR SPILLOVER FROM COOKIE TO DATABASE” and to the continuation-in-part U.S. Application No. 19 / 056,968, filed February 19, 2025 and entitled “METHODS AND SYSTEMS FOR COOKIE PROCESSING OPTIMIZATION”, the entire contents of which are incorporated herein by reference.FIELD OF THE DISCLOSURE
[0002] The present disclosure relates to web domains, and in particular relates to cookies for web domains.BACKGROUND
[0003] A browser cookie, often simply referred to as a "cookie," is a small piece of data that a website or domain stores on a user's computing device, typically through the web browser. Cookies are used to remember information about the user, their preferences, and their activities on the website. This data is stored in a file and is sent back and forth between the user's browser and the web server each time the browser requests a page from the server.SUMMARY
[0004] The embodiments of the present disclosure provide for a browser cookie that allows the adding of data to a server-side database once a size threshold has been reached for the cookie.
[0005] In one aspect, a data storage and retrieval system for a computer memory associated with a web browser may be provided. The data storage and retrieval system may comprise means for configuring said computer memory for storing a browser cookie. The browser cookie may include session cookie information, the session cookie information being up to a threshold size; and overflow cookie information, the overflow cookie information including an overflow indication and a database identifier pointing to a database on a server where additional cookie information is stored.
[0006] In some embodiments, the session cookie information and overflow cookie information may be encrypted, and the browser cookie may further comprise an unencrypted header providing a key identifier for a key used for decrypting the session cookie information and the overflow cookie information.
[0007] In some embodiments, the unencrypted header may further include a database location for the key.
[0008] In some embodiments, the browser cookie may be compressed.
[0009] In some embodiments, the unencrypted header may further comprise an indicator of a compression algorithm used for compression.
[0010] In some embodiments, the overflow cookie information may include a decryption key for the additional cookie information stored at the database on the server.
[0011] In some embodiments, the overflow cookie information may identify a region for the database on the server.
[0012] In some embodiments, information within the browser cookie may be prioritized, and wherein information stored in the session cookie information may have a higher priority than information stored at the database on the server.
[0013] In some embodiments, the threshold size may be set for all cookies within the computer memory for a domain.
[0014] In a further aspect, a method at a computing device for creating a browser cookie may be provided. The method may include determining that information within a browser cookie exceeds a threshold size and storing a subset of the information within the browser cookie. The method may further include storing a subset of the information in a database on a server and adding overflow information to the browser cookie, the overflow information including an indication and an identifier for the database.
[0015] In some embodiments, the subset of information within the browser cookie and overflow information in the browser cookie may be encrypted, and the browser cookie may further comprise an unencrypted header providing a key identifier for a key used for decrypting the subset of information within the browser cookie and the overflow information within the browser cookie.
[0016] In some embodiments, the unencrypted header may further include a database location for the key.
[0017] In some embodiments, the browser cookie may be compressed.
[0018] In some embodiments, the unencrypted header may further comprise an indicator of a compression algorithm used for compression.
[0019] In some embodiments, the overflow information may include a decryption key for the subset of the information in the database on the server.
[0020] In some embodiments, the overflow information may identify a region for the database on the server.
[0021] In some embodiments, information within the browser cookie may be prioritized, and the subset of information stored in the browser cookie may have a higher priority than the subset of information stored in the database on the server.
[0022] In some embodiments, the threshold size may be set for all cookies within a computer memory for a domain.
[0023] In a further aspect, a computer readable medium for storing instruction code may be provided. The instruction code, when executed by a processor of a computing device, may cause the computing device to configure a computer memory associated with a web browser for storing a browser cookie. The browser cookie may include session cookie information, the session cookie information being up to a threshold size; and overflow cookie information,the overflow cookie information including an overflow indication and a database identifier pointing to a database on a server where additional cookie information is stored.
[0024] In some embodiments, the session cookie information and overflow cookie information may be encrypted, the browser cookie may further comprise an unencrypted header providing a key identifier for a key used for decrypting the session cookie information and the overflow cookie information.
[0025] In some embodiments, the unencrypted header may further include a database location for the key.
[0026] In some embodiments, the browser cookie may be compressed.
[0027] In some embodiments, the unencrypted header may further comprise an indicator of a compression algorithm used for the compression.
[0028] In some embodiments, the overflow cookie information may include a decryption key for the additional cookie information stored at the database on the server.
[0029] In a further aspect, a computer system having at least one processor, a first computer memory associated with a browser, and a second computer memory may be provided. The second computer memory may be configured for storing instructions for configuration of the first computer memory, the instructions providing for storing a browser cookie. The browser cookie may include session cookie information, the session cookie information being up to a threshold size; and overflow cookie information, the overflow cookie information including an overflow indication and a database identifier pointing to a database on a server where additional cookie information is stored.
[0030] In a further aspect, a method at a computing device may be provided. The method may include receiving a request from a web browser, the request including a received cookie having an unencrypted portion and an encrypted portion. The method may further include determining, from the unencrypted portion of the received cooked, that a freshness timer has not expire, and based on the determining, creating a revised cookie, the revised cookie usingthe unencrypted portion and freshness timer from the received cookie. The method may further include sending the revised cookie to the web browser.
[0031] In some embodiments, the method may further include receiving a second request from the web browser, the second request including a second received cookie having a second received cookie unencrypted portion and a second received cookie encrypted portion and determining, from the unencrypted portion of the second received cookie, that the freshness timer has expired. The method may further include sending a request to a network server for an updated encrypted portion, receiving the updated encrypted portion, and resetting the freshness timer. The method may further include creating a second revised cookie with the updated encrypted portion and reset freshness timer and sending the second revised cookie to the browser.
[0032] In some embodiments, the revised cookie may include an updated expiration timer that differs from the expiration timer of the received cookie.
[0033] In some embodiments, the freshness timer may be shorter than an expiration timer for any of the received cookie and the revised cookie.
[0034] In some embodiments, the method may further include storing at the computing device the encrypted portion of the received cookie in unencrypted form.
[0035] In some embodiments, the received cookie may include an identification number in the unencrypted portion, and wherein the revised cookie may use the same identification number in its unencrypted portion.
[0036] In some embodiments, the received cookie may include a decryption key identifier in the unencrypted portion, and wherein the request to the network server may include the decryption key identifier.
[0037] In some embodiments, the encrypted portion of the received cookie may include user profile information.
[0038] In a further aspect, a computing device comprising a process and a communication subsystem may be provided, the computing device configured to receive a request from a web browser, the request including a received cookie having an unencrypted portion and an encrypted portion. The computing device may be further configured to determine, from the unencrypted portion of the received cooked, that a freshness timer has not expire, and based on the determination, create a revised cookie, the revised cookie using the unencrypted portion and freshness timer from the received cookie. The computing device may further be configured to send the revised cookie to the web browser.
[0039] In a further aspect, a computer readable medium for storing instruction code may be provided, which, when executed by a process of a computing device cause the computing device to receive a request from a web browser, the request including a received cookie having an unencrypted portion and an encrypted portion. The computing device may be further caused to determine, from the unencrypted portion of the received cooked, that a freshness timer has not expire, and based on the determination, create a revised cookie, the revised cookie using the unencrypted portion and freshness timer from the received cookie. The computing device may further be caused to send the revised cookie to the web browser.
[0040] In a further aspect, a data storage and retrieval system for a computer memory associated with a web browser may be provided, comprising means to receive a request from a web browser, the request including a received cookie having an unencrypted portion and an encrypted portion. The data storage and retrieval system may further include means to determine, from the unencrypted portion of the received cooked, that a freshness timer has not expire, and based on the determination, create a revised cookie, the revised cookie using the unencrypted portion and freshness timer from the received cookie. The data storage and retrieval system may further include means to send the revised cookie to the web browser.BRIEF DESCRIPTION OF THE DRAWINGS
[0041] The present disclosure will be better understood with reference to the drawings, in which:
[0042] Figure 1A is a block diagram showing an example plaintext browser cookie with an overflow indication.
[0043] Figure IB is a block diagram showing an example browser cookie with an overflow indication, where a portion of the browser cookie is encrypted.
[0044] Figure 2 is a block diagram showing an example system in which browser cookies may be used.
[0045] Figure 3 is a dataflow diagram showing the provision of a browser cookie having an overflow indication and the providing of overflow data to a database.
[0046] Figure 4 is a block diagram showing the storage and retrieval of overflow data based on cookies in various regions.
[0047] Figure 5 is a dataflow diagram showing the creation of revised cookies depending on whether a freshness timer in a received cookie has expired.
[0048] Figure 6 is a block diagram showing a simplified computing device capable of being used with the embodiments of the present disclosure.DETAILED DESCRIPTION
[0049] The present disclosure will now be described in detail by describing various illustrative, non-limiting embodiments thereof with reference to the accompanying drawings. The disclosure may, however, be embodied in many different forms and should not be construed as being limited to the illustrative embodiments set forth herein. Rather, the embodiments are provided so that this disclosure will be thorough and will fully convey the concept of the disclosure to those skilled in the art.
[0050] HTTP (Hypertext Transfer Protocol) is considered stateless, meaning that each request from a client to a server is independent and unrelated to any previous requests. This statelessness implies that the server does not retain any information about past interactions with a particular client. Once a request is made and a response is sent back, the connection is effectively terminated, and the server does not maintain any knowledge of the client's previous requests or session data. This design simplifies the implementation and scalability ofweb servers since they do not need to store extensive amounts of information about each client session.
[0051] Browser cookies were introduced as a solution to the statelessness of HTTP, allowing websites to maintain some level of state or continuity between requests. Cookies are pieces of data sent from a website and stored in a user's web browser while the user is browsing. They contain information such as user preferences, session identifiers, or other data relevant to the website's functionality. When the user makes subsequent requests to the same website, the browser sends the stored cookies along with the request, enabling the server to recognize the user and maintain continuity across their interactions. Cookies thus provide a way for websites to associate individual requests with user sessions, personalize content, and maintain stateful interactions within the stateless environment of HTTP.
[0052] Cookies are relatively small data structures stored on a computer that are transmitted to webservers along with HTTP requests. As provided in U.S. Application No. 63 / 632,306 and / or U.S. Application 18 / 893,296, the contents of which are incorporated by reference, a computing device may encode data in a cookie such that there is an unencrypted header and encrypted payload. The header contains a pointer or identifier indicative of a decryption key (or key pair), and the pay load is encrypted / decrypted by that key (or key pair). When a webserver receives such a cookie from a user, it will decrypt the contents and use the information when generating a response to the HTTP request.
[0053] However, in some cases the size of a browser cookie can grow very large. This may be due to the accumulation of data over time. Specifically, as a user interacts with a website, the website may store more and more information within the cookie, potentially causing the browser cookie to grow in size. Also, cookies may grow due to the inclusion of large or complex data structures within the cookie. Specifically, a website in some cases may store user-generated content such as text, images or multimedia files within the cookie.
[0054] While the size of a browser cookie for a webpage or web domain does not have a strict maximum, for example defined by a standard, there are practical maximum sizes due to browser implementations and design constraints of underlying network protocol layers. Other network layers and server properties also affect performance of an HTTP Request containinglarger and larger cookie payloads. Therefore, while small cookies have little impact on HTTP request performance, large cookies may have a more significant impact.
[0055] An alternative to storing data in cookies is to provide a serial number or other session identifier that corresponds to data stored in a server-side database. This however has several downsides, including the database lookup performance and the providing of a Denial of Service (DOS) attack vector, where an attacker can trivially generate new sessions that cause data to be stored server-side. This can lead to a significant server storage resource cost just to store session information.
[0056] The embodiments of the present disclosure overcome the issues of large cookies and server-side database retrieval and attack vectors by providing a data storage and retrieval system which provides a cookie that allows the adding of data to a server-side database once a size threshold has been reached for the cookie. Specifically, if there is only a small amount of information to be stored, it can be stored self-contained in the cookie. Conversely, if the amount of information is greater than the threshold, some data can be stored in the cookie along with an identifier indicating there is overflow data in a database, and which database it is in.
[0057] This cookie structure overcomes both size constraints, as well as retrieval and DOS attack issues. Specifically, the cookie can be set to a size that is below a threshold, meaning that it will be capable of being attached to each request without causing performance issues, or causing the request to fail (for example based on browser constraints, web server constraints, or intermediate router or computing device constraints).
[0058] Reference is now made to Figure 1A, which shows an example plaintext browser cookie 100 in accordance with the embodiments of the present disclosure.
[0059] In particular, browser cookie 100 contains session cookie information 110. Session cookie information 110 could include any information or subset of information typically found in a cookie, including but not limited to a name for the cookie; a value, which includes the information stored in the cookie; expiration date or time, or a maximum age, indicating when the cookie should be deleted by the browser; a creation timestamp; a domain orsubdomain that the cookie is valid for; a path for which the cookie is valid; a secure flag to indicate that the cookie can only be transmitted on HTTP Secure (HTTPS) connections; an Http-Only Flag to prevent access to the cookie at the client, thereby mitigating cross site scripting attacks; and a Same-Site Attribute, which controls when cookies are sent with crossorigin requests.
[0060] In some cases, the browser cookie 100 may have User Agent (UA) and a client fingerprint, which may be used for cross-site-request-forgery (CSRF) detection.
[0061] The value within the session cookie information can store various data, and can include text, images, or multimedia, and can thus grow to become large. In this regard, according to the embodiments of the present disclosure, an overflow indication 120 may be added to a browser cookie 100 to indicate that additional data for the cookie is stored in a network database. Overflow indication 120 may in some cases be referred to as a spillover indication, an extension indication, among others.
[0062] In some embodiments, overflow indication 120 may include a flag or other signal to a web server that the browser cookie 100 has further information stored elsewhere.
[0063] Further, overflow indication 120 may provide an identifier for a database that the additional information is stored in. For example, the database identifier may be a Uniform Resource Locator (URL) or other address for the database. The identifier may include a region that the database is located in (e.g. America-East, Europe-Central, Y0W1, LHR2). The identifier may include the physical or logical location of the database. Other identifying information for the database may be stored in overflow indication 120.
[0064] Further, overflow indication 120 may include a session-key identifier or other identifier used for storage access.
[0065] In some cases, data stored in the database may be stored in a different format or schema than data in the session cookie information 110. In this regard, the overflow indication 120 may in some cases store an indicator for the schema or format for the database stored information.
[0066] In some cases, data stored in the database may be encrypted. In this regard, the overflow indication 120 may in some cases store a decryption key. This could further ensure privacy of the information in the database, as the web server or other computing device in the network would not be able to decrypt information from the database without the browser cookie 100.
[0067] In some cases, data stored in the database may have a pre-amble and an encrypted portion, similar to the cookie described below with regard to Figure IB.
[0068] In some cases, when the data stored in the database is encrypted, the overflow indication 120 could include a key identifier to indicate where to get the decryption key and what key to get. This could be used in situations where, for security, encryption keys are rotated, and thus the correct key to decrypt the data may need to be identified.
[0069] In some cases, data stored in the database may be compressed, and the overflow indication 120 may include an indication of the compression algorithm used to compress the data.
[0070] Other information may further be stored in the overflow indication 120.
[0071] While the embodiment of Figure 1A shows a plaintext cookie, in some cases parts of the cookie may be encrypted. Reference is now made to Figure IB, which shows a browser cookie 100B.
[0072] In the embodiment of Figure IB, an unencrypted preamble 130 within browser cookie 100B allows retrieval of a decryption key at the server. Such information may include a key identifier in some cases. In some cases, the key identifier may include a location or “region” identifier for the key store. Such key identifier may provide enough information that the server receiving the cookie can find the correct decryption key. Specifically, keys may rotate frequently, and thus the key identifier may identify which key was used at a specific time in the past to allow the browser cookie 100B to be decrypted. This may be useful in situations where a site visitor may have long periods of inactivity, but in which re-authentication may not be possible, such as an electronic commerce application. Because information in the cookie may be sensitive, the keys used for encryption may be changed frequently, but the information may still need to be decrypted after the long period of inactivity. Thus, the key identifier could be used to find the correct decryption key.
[0073] In some cases, the key identifier may be a public key significant bit or bits.
[0074] Further, in some cases, the server doing the decrypting may be different from the web server, where the web server may forward the encrypted browser cookie 100B to the decryption server for decryption. This is for example shown in Figure 4, as described below.
[0075] In some cases, the unencrypted preamble 130 may store a compression algorithm identifier to identify how portions of the message are compressed.
[0076] In some cases, the unencrypted preamble 130 may have a timestamp the cookie was created at for easy tracking and sorting. In the case of rotating encryption / decryption keys, the timestamp may be used to determine which key was valid at the time of the cookie’s creation.
[0077] In some cases, as described below, the unencrypted preamble 130 may contain a “freshness” timestamp 134, indicating when the payload for the cookie was last updated.
[0078] Specifically, in some cases the encrypted payload 132 of the cookie may be relatively static, and may change very little. In one case, an example payload in the encrypted portion of the cookie may be user profile information. It may therefore be computationally inefficient to send requests to a datastore, such as a Key Value server, constantly. In this regard, in accordance with the embodiments of the present disclosure, the unencrypted portion of the cookie may contain the freshness timestamp 134. Such timestamp is in addition to the typical cookie expiration timestamp provided by the cookie metadata. The freshness timestamp 134 may be used by a middleware server to determine whether the cookie payload needs to be updated, or whether the current cookie payload is sufficient.
[0079] In some cases, metadata on the cookie could form part of the unencrypted preamble 130. For example, such information may include any information or subset of information typically found in a cookie, including but not limited to a name for the cookie; expiration date or time, or a maximum age, indicating when the cookie should be deleted by the browser; a domain or subdomain that the cookie is valid for; a path for which the cookie is valid; a secure flag to indicate that the cookie can only be transmitted on HTTP Secure (HTTPS) connections; an Http-Only Flag to prevent access to the cookie at the client and therefore mitigating cross site scripting attacks; a freshness timestamp; and a Same-Site Attribute, which controls when cookies are sent with cross-origin requests. Such information may be used by the web browser to determine when the cookie can be sent, and thus may form part of the unencrypted preamble in some cases.
[0080] Other information could also form part of the unencrypted preamble 130.
[0081] The encrypted cookie portion 132 may contain information similar to browser cookie 100A from Figure 1A.
[0082] In particular, encrypted cookie portion 132 may contain session cookie information 140. Session cookie information 1400 could include any information or subset of information typically found in a cookie, and in particular the value field, which includes the information stored in the cookie.
[0083] In some cases, the encrypted cookie portion 132 of browser cookie 100B may have User Agent (UA) and a client fingerprint, which may be used for cross-site-request-forgery (CSRF) detection.
[0084] The value within the session cookie information can store various data, and can include text, images, or multimedia, and can thus grow to become large. In this regard, according to the embodiments of the present disclosure, an overflow indication 150 may be added to the encrypted cookie portion 132 of browser cookie 100B to indicate that additional data for the cookie is stored in a network database. As with overflow indication 120, overflow indication 150 may in some cases be referred to as a spillover indication, an extension indication, among others.
[0085] In some embodiments, overflow indication 150 may include a flag or other signal to a web server that the browser cookie 100B has further information stored elsewhere.
[0086] Further, overflow indication 150 may provide an identifier for a database that the additional information is stored in. For example, the identifier may be a URL or other address for the database. The identifier may include a region that the database is located in. However, in some embodiments the region for the database may be the same as the region for a keystore found in the unencrypted preamble 130.
[0087] In some cases, the identifier for the database may include a session-key identifier used for storage access.
[0088] Other identifying information for the database may be stored in overflow indication 150
[0089] In some cases, data stored in the database may be stored in a different format or schema than data in the session cookie information 140. In this regard, the overflow indication 150 may in some cases store an indicator for the schema or format for the database stored information.
[0090] In some cases, data stored in the database may be encrypted using a different key than the key used for encrypted cookie portion 132. In this regard, the overflow indication 230 may in some cases store a decryption key for the particular overflow data in the database associated with browser cookie 100B. This could further ensure privacy of the information in the database, as the web server, operator, or other computing device in the network would not be able to decrypt the information from the database without the browser cookie 100B.
[0091] In some cases, when the data stored in the database is encrypted with a different key than that used for browser cookie 100B, the overflow indication 150 could include a key identifier to indicate where to get the decryption key and what key to get.
[0092] In some cases, data stored in the database may be compressed. In some cases, this compression may use a different algorithm than one used for browser cookie 100B. Thus, the overflow indication 150 may include an indication of the compression algorithm used to compress the data in the database.
[0093] In some cases, data stored in the database may have an unencrypted preamble and an encrypted portion, similar to the browser cookie 100B.
[0094] Other information may further be stored in the overflow indication 150.
[0095] Key-value pairs and schema for browser cookie 100B may be enforced using various data formats. One non-limiting example is Protobuf, which is an open source data format used to serialize structured data.
[0096] The cookie 100B from the embodiment of Figure IB may be used in a web browsing system. For example, reference is now made to Figure 2, which shows a simplified system that may be used with the embodiments of the present disclosure.
[0097] Specifically, in the example of Figure 2, a browser 210 may be an application located within a computing system. For example, the browser may be on a personal computer, desktop computer, laptop, tablet, mobile device, among other options.
[0098] The browser may communicate with a web server, shown in the example of Figure 2 as a middleware or edge server 220. Depending on the location of the browser 210, on web traffic, on routing patterns or algorithms, or on other factors, different middleware or edge servers 220 may service browser 210 from time to time.
[0099] In the example of Figure 2, the middleware or edge server 220 may include a cache 222, which may store keys used to decrypt an encrypted cookie 100. However, if cache 222 does not have the requested information, in some embodiments the cache 222 may perform a lookup from a datastore 230, where in some cases datastore 230 may be a global key / value store. Cache 222 may, in some embodiments, be optional.
[0100] In some cases, cache 222 could further store unencrypted versions of encrypted payloads.
[0101] Thus, in some embodiments, the middleware or edge server 220 may receive an encrypted cookie and may extract, from the unencrypted header, the location of the key value store, which may for example be datastore 230. For example, the unencrypted header may in some embodiments contain two values. A "public key significant bit" may reference a symmetric key, which in some cases may be looked up as a secret environment variable rather than from a key / value server. A "Region identifier" may reference a storage server where the expanded session resides.
[0102] The middleware or edge server 220 may then provide a request to the datastore 230 to obtain the key to decrypt the cookie in some cases. In some cases, the middleware or edge server 220 may provide the encrypted cookie or payload from the cookie to the datastore 230 and the datastore 230 may then provide a copy of the unencrypted payload back to the middleware or edge server 220. In some cases, the middleware or edge server 220 may provide the encrypted cookie or encrypted cookie payload to datastore 230, which may then decrypt the payload, modify it as necessary, re-encrypt it, and provide the new payload back to the middleware or edge server 220. Other options for communication between the middleware or edge server 220 and datastore 230 are possible.
[0103] Thus, in some embodiments, a web server such as a middleware or edge server 220, may receive a message from a browser 210, such as an HTTP GET, with a cookie attached. The cookie, as described above, may have an unencrypted portion and an encrypted portion. The middleware or edge server 220 may send metadata from the unencrypted portion, optionally along with the encrypted portion, to a datastore 230, for example using cache 222, which may return a new encrypted cookie payload. The middleware server may then provide, in a response to the browser, a SET Cookie message with the new cookie.
[0104] As will be appreciated by those in the art, communication between servers, decrypting and encrypting, among other operations, can be computationally demanding when scaled to a large system with many cookies, and may lead to delays in communication.
[0105] Further, in some cases the encrypted pay load of the cookie may be relatively static, and may change very little. One example payload in the encrypted portion 132 of the cookie 100B may be user profde information. It may therefore be computationally inefficient to send such requests to the cache 222 and / or to datastore 230 constantly.
[0106] In this regard, in accordance with embodiments of the present disclosure, the unencrypted portion 110 of the cookie may contain the freshness timestamp 134. Such timestamp is in addition to the typical cookie expiration timestamp provided by the cookie metadata. The freshness timestamp may be used by the middleware or edge server 220 to determine whether the cookie payload needs to be updated, or whether the current cookie payload is sufficiently fresh.
[0107] Specifically, in accordance with embodiments of the present disclosure, a middleware server receives an HTTP GET message with a cookie. The middleware server may look for the freshness timestamp in the unencrypted portion of the cookie.
[0108] When the freshness timestamp is within a predetermined time from the current time (for example 1 hour), then the middleware server may compose and set a cookie without a request to a datastore such as a key value server. In this case, the encrypted portion from the cookie that was received at the middleware server, or a cookie for the session stored in the cache at the middleware server, may become the encrypted portion for the new cookie. Further, the freshness timestamp in the unencrypted portion of the cookie will remain the same. However, the cookie expiration time may be updated, for example to allow the cookie to expire in a predetermined interval. Such new or revised cookie may be sent to the web browser in an HTTP SET Cookie message.
[0109] Conversely, when the freshness timestamp is older than the current time minus a predetermined threshold (i.e. the freshness timer has expired), then the contents of the encrypted portion may need to be refreshed. In this case, the middleware server may make a request to the datastore. In some cases, such a request can include the encrypted payload or the entire cookie. However, in some cases the request may simply include an identifier which may be associated with a copy of the cookie stored at the key value server. In some cases, the decrypt on / encry ption may be done by the middleware server, rather than at a keyvalue server. Other options are possible. The datastore may, in some cases, decrypt the encrypted portion. The datastore may update the encrypted portion of the cookie and reencrypt it. The datastore, if it comprises the key value server, may then send the updated cookie (or the updated cookie payload) to the middleware server.
[0110] The middleware server may then create a cookie by using the encrypted payload, adding a new freshness timestamp to the cookie, and adding a new expiration time for the cookie itself. This new (revised) cookie may be sent to the web browser in an HTTP SET Cookie message.
[0111] The browser cookies from Figure 1A and / or Figure IB could be used to allow data to overflow to a database once the browser cookie reaches a threshold size. Reference is now made to Figure 3.
[0112] In the example of Figure 3, a client 310, which may comprise a web browser, may communicate with a server 312. Further, a database 314 may be used to store information or data when a browser cookie reaches a threshold size.
[0113] An initial communication from the client 310 to the server 312 is shown with message 320. Such initial communication may be a web request, for example.
[0114] Server 312, on receiving the message 320, may provide a response 322. The response 322 may further include a Set-cookie HTTP response header in which an initial cookie is set at the client 310.
[0115] Subsequent interactions between client 310 and server 312 could be in the form of requests and responses. The request could include a cookie, as shown with request 324. Specifically, an HTTP Request would typically include the cookie for a domain of server 312, where such cookie is stored by client 310 for the domain.
[0116] In response 326, if the server 312 wants to add to the cookie, this may be performed with a Set-cookie HTTP response header, which would cause client 310 to replace the stored cookie with the new cookie received.
[0117] In addition, in some cases the server 312 may provide a different cookie that would not be overwritten, but would also be stored at client 310. This would result in subsequent requests to server 312 having multiple cookies.
[0118] As will be appreciated by those in the art, during a browser session the size of the cookies needed for Requests could grow. Thus, the server 312 may check whether the cookie(s) for the client 310 exceed a threshold size, as shown by block 330, prior to sending a Set-cookie HTTP response header.
[0119] In some cases, such check to determine whether the threshold size has been exceeded may be for a single cookie.
[0120] In some cases, when multiple cookies exist, the check may be for the cumulative size of the cookies. Specifically, in some cases, the threshold check can be based on the cumulative size of cookies for a particular domain. If a domain has more than one cookie stored at the client, then the cumulative size of all the cookies for the domain could be used for the threshold check.
[0121] When the cookie(s) do not exceed the threshold size, a response such as response to the 326 with a Set-cookie response header having a standard cookie may be sent back to client 310.
[0122] When the cookie(s) do exceed the threshold size, the server 312 may create a browser cookie 100A or 100B from Figures 1A or IB, where the browser cookie 100A or 100B includes an overflow indication and the size of the cookie is limited.
[0123] Thereafter, the server could, in response 340, provide the browser cookie 100A or 100B in a Set-cookie HTTP response header to client 310. Further, the server 312 could provide the overflow data to the database 314 with message 342.
[0124] In some cases, server 312 may determine which data forms part of the browser cookie and which data forms the overflow data. This may be temporal, where the oldest data may bestored at the database 314 and the newest data may be part of the browser cookie. In some cases, the temporal division may be where the newest data is stored in the database 314 and the oldest data is provided in the browser cookie.
[0125] In some cases, server 312 may prioritize data that is needed by the server more frequently to be in the cookie, while data that is less frequently used may be stored in the server-side database 314, reducing data retrieval times. In this case, various prioritization schemes or algorithms can be implemented to classify such data.
[0126] Other options for splitting the data between the browser cookie and the overflow data for the database are possible.
[0127] Client 310 may subsequently send a request 350 to server 312, where request 350 includes a browser cookie 100 and / or 200 having an overflow indication.
[0128] Based on receipt of request 350, server may decide it needs the overflow information, and thus may send a message 352 to database 314 to retrieve the data, and database 314 may return the overflow data in message 354. As will be appreciated by those in the art, the message 352 may be signed by server 312 in some cases to provide system security by only releasing the overflow information to authorized servers.
[0129] Based on the received overflow data and the session cookie information from request 350, the server 312 may return a response 360.
[0130] When a user stays in a specific region, the processive Figure 3 may be used to retrieve overflow data. However, in cases where a user moves to a different region, or when Internet routing causes a user to connect to an HTTP server in a different region, among other options, overflow data may need to be obtained from databases in the first region. Reference is now made to Figure 4 which shows a simplified example of the interaction with HTTP servers in multiple regions.
[0131] In the example of Figure 4, a first region 410 includes an HTTP server 420 and an overflow data database 422. In some cases, overflow data database 422 and HTTP server 420may be on the same computing device. In some cases, overflow data database 422 and HTTP server 420 may be on the different computing devices.
[0132] A user may interact with a browser or other HTTP client 424 within the first region 410
[0133] In this regard, and in accordance with the embodiment of Figure 3, the client 424 may communicate with server 420, and the server 420 may set cookies in the HTTP request / response messages 430.
[0134] When the cookie size reaches a threshold, as described with regard to Figure 3, the HTTP server 420 may set the overflow data to the overflow data database 422, as shown with message 432. In this regard, the messages 430 may then include cookie(s) with overflow data, as described above.
[0135] Thereafter, a user may move to a second region 440, or Internet routing may be routed through a second region 440, among other options. In this case, the browser / HTTP client 452 may interact with HTTP server 450. As will be appreciated by those in the art, the browser / HTTP client 452 would generally be the same as the browser HTTP client 424.
[0136] In the example of Figure 4, an overflow data database 454 exists within the second region 440. In some cases, overflow data database 454 and HTTP server 450 may be on the same computing device. In some cases, overflow data database 454 and HTTP server 450 may be on the different computing devices.
[0137] Client 452, when interacting with server 450, may send existing cookies within HTTP request / response messages 460. In this case, the cookies may include an overflow data indication. However, since the overflow data indication also may indicate the region of the database, rather than interacting with database 454, HTTP server 450 may interact with database 422 in order to receive the overflow data, as shown of message 462. In this way, the overflow data that was previously stored in the overflow data database 422 can be retrieved.
[0138] Thus, from the embodiments of Figures 1A, IB, 3 and 4, systems and methods are provided where browser cookies with an overflow indication can be used when the browser cookies reach a threshold size. In this case, overflow data can be stored in a network side database. Benefits of this system include that more basic users with shorter sessions will not have accumulated much session information, and all data will be stored in a cookie. Such users will have little or no database storage burden.
[0139] Conversely, users with lengthy or more complex sessions may utilize resources in the database.
[0140] Such system prevents a DOS attack vector from simple traffic generating bots by requiring cookie support. Sessions would need to be a certain length before a threshold cookie size is reached, thwarting simple DOS bots without cookie functionality. For example, common DOS or distributed DOS bots do not implement or support cookie functionality. Such “cookie-less” DOS bots do not (and cannot) store cookies to build sessions. Adding such a feature would increase compute / storage / cost for DOS attackers and implementation complexity. Because of this, mounting a DOS attack can be more difficult with the present system, meaning the risk of such attacks may be lessened. For example, as a session cannot be created by a bot without cookie support, the difficulty of mounting a DOS attack targeting session state resources may be lessened.
[0141] Conveniently, also, by preferencing storage in cookies over storage in the database, the amount of storage used in the database may be reduced. Indeed, with the present system, not only do a smaller population have data in the database, but those that do have a smaller amount of data. This results in smaller session databases. Conveniently, this may also have benefits in terms of a reduced risk of a DOS attack targeting the database storage: because only clients with associated session data stored in the database even consume backend storage and because the database is only used for storage when cookie storage overflows, absent significant state data, an attacker may experience great difficulty in even triggering consumption of database storage let alone filling the database to the extent of materializing an actual denial of service. Furthermore, to even be able to get to a DOS bot being able to trigger consumption of database space for a session, the DOS bot would need to implement browser cookies (to be able to participate in a session) and thus the difficulty of mounting a DOSattack targeting backend storage is also lessened because of the above-discussed lack of cookie support in conventional DOS bots and the potential difficulties of adding that support to them.
[0142] Reference is now made to Figure 5. In the example of Figure 5, a client 510 such as a web browser, communicates with a server 512 to obtain identification for the client 510. Further, a middleware server 514 and a datastore 516 may form part of the system.
[0143] In particular, a client 510 may login or otherwise seek to obtain an identification cookie by sending a GET message 520 to server 512, and receive a SET cookie message 522 in response, the cookie including an identifier for the client 510. In some cases, server 512 may be independent of middleware server 514 and datastore 516. In some cases, server 512 may be part of one or both of middleware server 514 and / or datastore 516.
[0144] Subsequently, for example on a page load, client 510 may communicate with middleware server 514. The first time the client does this, only the identifier cookie from message 522 and a potential, unnamed cookie that has not yet been set exist, and thus a GET message 524, without a session or profile cookie, may be sent to middleware server 514.
[0145] Middleware server 514, upon receiving GET message 524, may perform a lookup from the datastore 516, shown with message 526, for example by providing an identifier from the identifier cookie of message 522 to datastore 356.
[0146] Datastore 516, upon receiving message 526, may search for any data used to construct a cookie stored therein, and identified with the identifier provided in the lookup message 526. In this case, no previous data (or profile cookies) are stored or have been set, and the datastore 516 returns a null message 528 to middleware server 514.
[0147] The middleware server 514 may then create a profile cookie having an unencrypted preamble with payload freshness timestamp, no payload, and cookie expiration time. For example, the payload freshness timestamp may be 1 hour and the expiration time may be one day, one week, one month, among other options. This profile cookie is then returned to the client 510 in message 530.
[0148] Subsequently (not shown) a user may perform more actions, and the system may build their profile, and post profile data to the datastore 516 for the user ID.
[0149] However, in the example of Figure 5, the time period for expiration for the profile cookie may pass (for example one week). In this case, a client 510, on page load, may send another GET message 540 to middleware server 514. In this case, since the previous profile cookie has expired, the GET message 540 contains no profile cookie.
[0150] In this case, middleware server 514 sends a lookup message with the client identifier to datastore 516, shown with lookup message 542. Since the datastore stored profile data previously, it may return message 544 with profile data. In some cases, such profile data may be a cookie payload. The cookie payload may be encrypted in some embodiments. Message 544 may therefore in some cases contain a decryption key identifier in an unencrypted format.
[0151] Further, in some cases, message 544 may contain an unencrypted payload that can be stored in a cache at middleware server 514.
[0152] While the embodiment of Figure 5 shows messages 542 and 544 resulting from a GET message without a cookie, in practice messages 542 and 544 could be used anytime there is profile data used to construct the cookie present in the datastore 516. This may happen either on the first request for a newly identified user, or the first request after the browser cookie has expired. Thus, in some cases message 544 may be sent in response to message 526, for example, when datastore 516 contains profile data. Other options are possible.
[0153] Middleware server 514 may then create a profile cookie in some embodiments. The profile cookie could include an unencrypted preamble and an encrypted payload. The encrypted payload would be the payload received from the datastore 516 in message 544. The unencrypted payload could include various metadata and information, including the decryption key identifier in some cases. The unencrypted preamble could further include the client identifier within it.
[0154] The unencrypted preamble could further include an expiration time for the profile cookie. Specifically, the expiration time for the profile cookie can be set to a predefined time period after the cookie creation, such as now plus one week for example.
[0155] The unencrypted preamble could further include the freshness timer value. For example, the unencrypted preamble could include an indication of when the freshness timer was set. This can be a key value pair where the key indicates that the value is for the freshness time and the value could be the current time or the expiration time, depending how the system is configured.
[0156] Thus, for example, the timer could be set in the preamble with a variable such as fresh_time=now. In this case, when a profile cookie is received by the middleware server 514, such server could add a predefined value (e.g. 1 hour) the time after fresh_time and see whether that time has passed. For example, if fresh_time was March 12 at 1 : 04: 45 pm, and the system preconfigured the freshness as being within an hour, then the system could check whether the current time is less than March 12 at 2:04:45pm.
[0157] In other cases, the fresh time value could be set to the expiration time. Thus when creating the profile cookie, if the time the cookie was created was March 12 at 1:04:45pm then the fresh_time value could be set to March 12 at 2:04:45 if one hour is being used as the defined freshness expiry time.
[0158] In other cases, the value could be placed in a specific location within the preamble, and thus a key indicating what the value is for may not be needed.
[0159] Other options are possible.
[0160] The profile cookie could then be sent to client 510 in message 546.
[0161] Subsequently, but before the profile cookie expires, the client 510 loads a webpage. This causes a GET message 550 with the profile cookie received at message 546 to be sent to middleware server 514.
[0162] Upon receiving message 550, middleware server 514 may, at block 552, check whether the freshness timer in the received cookie has expired.
[0163] When it is determined at block 552 that the freshness timer has not expired, then the middleware server 514 may create a new (revised) profde cookie in which the existing encrypted payload is used in the revised cookie. The unencrypted preamble is also largely the same. However, a new expiration time may be used with the cookie, and this may be indicated in the unencrypted preamble in some cases.
[0164] The revised cookie may further include the original freshness timer to ensure that the encrypted payload will still expire at the same time.
[0165] Further, the decryption key identifier, the client identifier, and other information in the received cookie may be the same in the revised cookie.
[0166] The profile cookie may be sent back in a set cookie message 554 to the client 510.
[0167] As will be appreciated by those in the art, if the freshness timer has not expired, then no messaging between middleware server 514 and datastore 516 is needed, thereby saving communication time and system resources.
[0168] Conversely, if the check at block 552 finds that the freshness timer has expired, then a look up request with the client identifier may be sent to the datastore 516, shown with message 560 in the example of Figure 3.
[0169] Datastore 516 may, on receiving message 560, look up the profile cookie and / or data for the profile cookie for the client identifier and provide a revised encrypted payload back to the middleware server, shown with message 562. Message 562 may in some cases contain a decryption key identifier in an unencrypted format, where such decryption key identifier may be used in locating the decryption key for the encrypted payload.
[0170] Further, in some cases, message 562 may contain an unencrypted payload that can be stored in a cache at middleware server 514.
[0171] Middleware server 514 may then create a (revised) cookie in some embodiments at block 564. The revised profile cookie could include an unencrypted preamble and an encrypted payload. The encrypted payload would be the payload received from the datastore 516 in message 562. The unencrypted payload could include various metadata and information, including the decryption key identifier in some cases. The unencrypted preamble could further include the client identifier within it.
[0172] The unencrypted preamble could further include a new expiration time for the cookie.
[0173] The unencrypted preamble could further include a new freshness timer value as the encrypted payload has just changed.
[0174] The revised cookie could then be provided back to client 510 in message 566.
[0175] In some embodiments, a payload may need to be updated each time the page is loaded. In this case, the freshness timer may be left out. The check at block 552 could determine that no freshness timer exists within the received cookie, and may therefore send message 560 to the datastore 516.
[0176] Thus, from the embodiment of Figure 5, a profile cookie may have a time-to-live threshold for its payload that may differ from the time-to-live for the cookie itself. This may be important in cases where the system does not want to update the payload with every request, because this may be too resource intensive, but wants to update the payload more often than the cookie expiration time. For example, the cookie expiration may cause continuity interruptions in the browsing session of the user, which may not be desirable, and thus the threshold for the life of the cookie itself may be a first value. However, this first value may be too long to wait to update the payload, and thus the embodiments of the present disclosure provide for a separate freshness threshold for such payload.
[0177] Thus, from the embodiments of Figures IB, 2 and 5, systems and methods are provided where an encrypted payload may not need to be decrypted if a freshness time for the encrypted payload has not yet expired.
[0178] Such periodic updating of the payload allows resources to be saved, for example by removing the communications with a server, and the decryption, updating and re-encryption steps, when the payload freshness timer has not expired.
[0179] A further benefit to having a static payload for a threshold time is that it may improve a user experience by providing a consistent navigation experience, rather than a disjointed navigation experience that may occur if a profile cookie is constantly updated in website configurations in which the user interface is responsive to data within the cookie payload.Computing Device
[0180] The above-discussed methods are computer-implemented methods and require a computer for their implementation / use. Such computer system could be implemented on any type of, or combination of, network elements or computing devices. This could include web servers; datastores, key value servers, decryption servers; computing devices running browsers; computing devices hosting databases; among others. For example, one simplified computing device that may perform all or parts the embodiments described herein is provided with regard to Figure 5.
[0181] In Figure 6, computing device 610 includes a processor 620 and a communications subsystem 630, where the processor 620 and communications subsystem 630 cooperate to perform the methods of the embodiments described herein.
[0182] The processor 620 is configured to execute programmable logic, which may be stored, along with data, on the computing device 610, and is shown in the example of Figure 6 as memory 640. The memory 640 can be any tangible, non-transitory computer readable storage medium, such as DRAM, Flash, optical (e.g., Compact Disc (CD), Digital Video Disc (DVD), etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.In one embodiment, processor 620 may also be implemented entirely in hardware and not require any stored program to execute logic functions. Memory 640 can store instructions (instruction code), which, when executed by processor 620 cause the computing device 610 to perform the embodiments of the present disclosure. In some cases, memory 640 could be a first computer memory associated with a browser, while when computing device 610 is a server, memory 640 could be a second computer memory at the server used for storing instructions for the configuration of the first computer memory. However, the first memory and second computer memory could in some cases be the same memory. Further, the memory 640, when used for storing browser cookies, may be persisted memory, or may be temporary memory such as Random Access Memory.
[0183] Alternatively, or in addition to the memory 640, the computing device 610 may access data or programmable logic from an external storage medium, for example through the communications subsystem 630.
[0184] The communications subsystem 630 allows the computing device 610 to communicate with other devices or network elements. In some embodiments, communications subsystem 630 includes receivers or transceivers, including, but not limited to, ethemet, fiber, Universal Serial Bus (USB), cellular radio transceiver, a Wi-Fi transceiver, a Bluetooth transceiver, a Bluetooth low energy transceiver, a Global Positioning System (GPS) receiver, a satellite transceiver, an Infrared Data Association (IrDA) transceiver, among others. As will be appreciated by those in the art, the design of the communications subsystem 630 will depend on the type of communications that the computing device is expected to participate in.
[0185] Communications between the various elements of the computing device 610 may be through an internal bus 660 in one embodiment. However, other forms of communication are possible.
[0186] The elements described and depicted herein, including in flow charts and block diagrams throughout the figures, imply logical boundaries between the elements. However, according to software or hardware engineering practices, the depicted elements and the functions thereof may be implemented on machines through computer executable mediahaving a processor capable of executing program instructions stored thereon as a monolithic software structure, as standalone software modules, or as modules that employ external routines, code, services, and so forth, or any combination of these, and all such implementations may be within the scope of the present disclosure. Examples of such machines may include, but may not be limited to, personal digital assistants, laptops, personal computers, mobile phones, other handheld computing devices, medical equipment, wired or wireless communication devices, transducers, chips, calculators, satellites, tablet PCs, electronic books, gadgets, electronic devices, devices having artificial intelligence, computing devices, networking equipment, servers, routers and the like. Furthermore, the elements depicted in the flow chart and block diagrams or any other logical component may be implemented on a machine capable of executing program instructions. Thus, while the foregoing drawings and descriptions set forth functional aspects of the disclosed systems, no particular arrangement of software for implementing these functional aspects should be inferred from these descriptions unless explicitly stated or otherwise clear from the context. Similarly, it will be appreciated that the various steps identified and described above may be varied, and that the order of steps may be adapted to particular applications of the techniques disclosed herein. All such variations and modifications are intended to fall within the scope of this disclosure. As such, the depiction and / or description of an order for various steps should not be understood to require a particular order of execution for those steps, unless required by a particular application, or explicitly stated or otherwise clear from the context.
[0187] The methods and / or processes described above, and steps thereof, may be realized in hardware, software or any combination of hardware and software suitable for a particular application. The hardware may include a general-purpose computer and / or dedicated computing device or specific computing device or particular aspect or component of a specific computing device. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal and / or external memory. The processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine readable medium.
[0188] The computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.
[0189] Thus, in one aspect, each method described above, and combinations thereof may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof. In another aspect, the methods may be embodied in systems that perform the steps thereof and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware. In another aspect, the means for performing the steps associated with the processes described above may include any of the hardware and / or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.
Claims
CLAIMS1. A method at a computing device for creating a browser cookie, the method comprising: determining that information within a browser cookie exceeds a threshold size; storing a subset of the information within the browser cookie; storing a subset of the information in a database on a server; and adding overflow information to the browser cookie, the overflow information including an indication and an identifier for the database.
2. The method of claim 1, wherein the subset of information within the browser cookie and overflow information in the browser cookie are encrypted, the browser cookie further comprising an unencrypted header providing a key identifier for a key used for decrypting the subset of information within the browser cookie and the overflow information within the browser cookie.
3. The method of claim 2, wherein the unencrypted header further includes a database location for the key.
4. The method of claim 2, wherein the browser cookie is compressed.
5. The method of claim 4, wherein the unencrypted header further comprises an indicator of a compression algorithm used for compression.
6. The method of claim 1, wherein the overflow information includes a decryption key for the subset of the information in the database on the server.
7. The method of claim 1, wherein the overflow information identifies a region for the database on the server.
8. The method of claim 1, wherein information within the browser cookie is prioritized, and wherein the subset of information stored in the browser cookie has a higher priority than the subset of information stored in the database on the server.
9. The method of claim 1, wherein the threshold size is set for all cookies within a computer memory for a domain.
10. A data storage and retrieval system for a computer memory associated with a web browser, comprising means to perform the method of any one of claims 1 to 9.
11. A computer readable medium for storing instruction code, which, when executed by a processor of a computing device cause the computing device to perform the method of any one of claims 1 to 9.
12. A method at a computing device, the method comprising: receiving a request from a web browser, the request including a received cookie having an unencrypted portion and an encrypted portion; determining, from the unencrypted portion of the received cookie, that a freshness timer has not expired; based on the determining, creating a revised cookie, the revised cookie using the unencrypted portion and freshness timer from the received cookie; and sending the revised cookie to the web browser.
13. The method of claim 12, further comprising: receiving a second request from the web browser, the second request including a second received cookie having a second received cookie unencrypted portion and a second received cookie encrypted portion; determining, from the unencrypted portion of the second received cookie, that the freshness timer has expired; sending a request to a network server for an updated encrypted portion; receiving the updated encrypted portion; resetting the freshness timer; creating a second revised cookie with the updated encrypted portion and reset freshness timer; and sending the second revised cookie to the web browser.
14. The method of claim 12, wherein the revised cookie includes an updated expiration timer that differs from an expiration timer of the received cookie.
15. The method of claim 12, wherein the freshness timer is shorter than an expiration timer for the received cookie and the revised cookie.
16. The method of claim 12, further comprising storing at the computing device the encrypted portion of the received cookie in unencrypted form.
17. The method of claim 12, wherein the received cookie includes an identification number in the unencrypted portion, and wherein the revised cookie uses the same identification number in its unencrypted portion.
18. The method of claim 13, wherein the received cookie includes a decryption key identifier in the unencrypted portion, and wherein the request to the network server includes the decryption key identifier.
19. The method of claim 12, wherein the encrypted portion of the received cookie includes user profile information.
20. A computing device comprising a processor and a communication subsystem configured to perform the method of any one of claims 12 to 19.
21. A computer readable medium for storing instruction code, which, when executed by a processor of a computing device cause the computing device to perform the method of any one of claims 12 to 19.