Why Google Reduces the "Lifetime" of Cookies Received Using HTTP

    Back at the beginning of the year, Google reported that from July (when Chrome 68 comes out) all sites using HTTP will be marked as unsafe. The company believes that this will increase the privacy of users on the network.

    However, the IT giant’s work with HTTP did not end there. Last month, it became known that Google would further reduce the "lifetime" of cookies received using an insecure protocol to one year. We will tell you more about the situation below. / Flickr / Jeff Herbst / PD Sending HTTP cookies to Google is called a security risk. Company representatives celebrate




    that “cookie-centenarians” allow an attack called “ Pervasive Monitoring ”. This is a large-scale (and often hidden) tracking of transmitted information by collecting protocol artifacts, metadata (for example, headers) and application data. An example of a situation in which this type of monitoring has been implicated is the story when the NSA used a PREF cookie to track network users.

    Google claims that HTTPS protects against this type of attack. But since not everyone has switched to a more secure protocol (only 81 out of 100 sites use HTTPS by default), the researchers decided to go further and reduce the lifetime of cookies.

    According to Google telemetry, cookies received over HTTP have been “live” for more than a year. Chrome developers plan to limit cookie lifetime. And do it gradually: first, reduce it to one year, then - up to several days. They are convinced that it will be more difficult to track the actions of users on the Internet at different sites.

    This change is being implemented in the Chrome 70 update, which will be released at the end of October 2018.

    The essence of the proposal


    Google engineers suggest changing the cookie transfer format as follows.

    When forming a header for an outgoing request to an insecure URL, the date of creation of each cookie will be checked first. If the "age" is greater than a certain threshold value (12 months, and later several days), then the cookie is not added to the header, but deleted. It is also proposed to change the cookie creation time setting algorithm . If the content remains the same, then the creation time of the new cookie is consistent with the creation time of the old one.

    How will this affect web services?


    According to the assurances of developers, with backward compatibility problems should arise. However, this may affect the operation of services using insecure, long-term cookies. Therefore, Google suggests considering the following options:

    1. Still switch to HTTPS.
    2. Implement a system similar to ID rotation in DoubleClick, the value of which is re-encrypted and updated every day. This solution is suitable for those who for some reason cannot switch to HTTPS.
    3. Refuse cookies as identifiers and use localStorage instead.


    / Flickr / joi ito / cc

    What about other browsers?


    Developers of other browsers also tried to implement something similar. For example, 2 years ago, Mozilla representatives suggested turning some Firefox browser cookies into session cookies ( 1 and 2 ), but they refused this offer.

    The idea was to set cookies for the session if they did not have the secure flag. However, testing the initiative showed that too few sites set this flag. Even sites that use HTTPS (including google.com) have neglected this.

    Regarding the Google proposal, the company hopes that their decision to shorten the cookie lifetime will push the community to make HTTPS the “standard” in the web.

    What else are we writing on 1cloud's corporate blog:


    Also popular now: