Why does Google reduce the “lifetime” of cookies received via HTTP?
Back at the beginning of the year, Google announced that from July (when Chrome 68 is coming out) all sites that use HTTP will be marked as insecure. The company believes that this will increase the privacy of users in the network.
However, the work of the IT giant with HTTP has not ended. Last month it became known that Google will further reduce the “lifetime” of cookies received using an unprotected protocol to one year. More on the situation will be discussed below.
/ Flickr / Jeff Herbst / PD
')
Sending cookies via HTTP to Google is called a security risk. Representatives of the company point out that long-livers cookies 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 was implicated may be the story when the NSA used a PREF cookie to track network users.
Google says HTTPS protects against this type of attack. But since not all have 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’s telemetry data, cookies received via HTTP “live” for more than a year. Chrome developers plan to limit the cookie's lifetime. And do it gradually: first, shorten to one year, then to a few 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 implemented in the update Chrome 70, which will be released in late October 2018.
Google engineers suggest changing the cookie transfer format as follows.
When generating a header for an outgoing request for an unprotected URL, the date at which each cookie is created is first checked. If the “age” is greater than a certain threshold value (12 months, and later several days), the cookie is not added to the header, but is deleted. It is also proposed to change the algorithm for setting the cookie creation time. If the content remains the same, then the creation time of the new cookie is consistent with the creation time of the old one.
According to the developers, the problems with backward compatibility should not arise. However, this may affect the operation of services that use unprotected long-term cookies. Therefore, Google proposes to consider the following options:
/ Flickr / Joi Ito / CC
The developers of other browsers also tried to implement something similar. For example, 2 years ago, Mozilla representatives offered to turn some Firefox cookies into session cookies ( 1 and 2 ), but this offer was refused.
The idea was to set cookies for the session if they did not have the secure flag. However, testing initiatives showed that too few sites put this flag. Even sites that use HTTPS (including google.com) have neglected this.
As for Google’s proposal, the company hopes that their decision to shorten the cookie’s lifetime will push the community to make HTTPS a “standard” in the web environment.
However, the work of the IT giant with HTTP has not ended. Last month it became known that Google will further reduce the “lifetime” of cookies received using an unprotected protocol to one year. More on the situation will be discussed below.
/ Flickr / Jeff Herbst / PD
')
Sending cookies via HTTP to Google is called a security risk. Representatives of the company point out that long-livers cookies 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 was implicated may be the story when the NSA used a PREF cookie to track network users.
Google says HTTPS protects against this type of attack. But since not all have 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’s telemetry data, cookies received via HTTP “live” for more than a year. Chrome developers plan to limit the cookie's lifetime. And do it gradually: first, shorten to one year, then to a few 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 implemented in the update Chrome 70, which will be released in late October 2018.
The essence of the proposal
Google engineers suggest changing the cookie transfer format as follows.
When generating a header for an outgoing request for an unprotected URL, the date at which each cookie is created is first checked. If the “age” is greater than a certain threshold value (12 months, and later several days), the cookie is not added to the header, but is deleted. It is also proposed to change the algorithm for setting the cookie creation time. 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 the work of web services?
According to the developers, the problems with backward compatibility should not arise. However, this may affect the operation of services that use unprotected long-term cookies. Therefore, Google proposes to consider the following options:
- Still go on https.
- Implement a system similar to the rotation of the ID 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.
- Opt out of cookies as ids and use localStorage instead.
/ Flickr / Joi Ito / CC
And what about other browsers?
The developers of other browsers also tried to implement something similar. For example, 2 years ago, Mozilla representatives offered to turn some Firefox cookies into session cookies ( 1 and 2 ), but this offer was refused.
The idea was to set cookies for the session if they did not have the secure flag. However, testing initiatives showed that too few sites put this flag. Even sites that use HTTPS (including google.com) have neglected this.
As for Google’s proposal, the company hopes that their decision to shorten the cookie’s lifetime will push the community to make HTTPS a “standard” in the web environment.
What else do we write in the 1cloud corporate blog:
Source: https://habr.com/ru/post/358382/
All Articles