When the browser disables Third-party cookies by default

A while ago, we found that a third party cookie is blocked by default in the high version of Safari, as shown in the following figure.

Problem

What is a third party cookie? When visiting a site A, site a counts as the first party, and if site a references another site X (the domain name of site x differs from the domain name of site a), then this site X is considered a third party. It should be noted that the criteria for distinguishing the different sites here are whether the domain name is the same, rather than whether the two sites are operated by the same company. For example, Taobao.com and tmall.com are considered to be two sites, although they all belong to Ali group.

It is very common to use third party resources in the construction of Web sites, which in most cases will not cause problems. Sometimes, though, we might want to be able to read and write cookies from this Third-party domain, and that's the problem.

For example, we have a Web site a.com, where a JavaScript script is buried, and every time a user opens a page in a.com, the script sends a GET request to x.com. In this way, you can understand the a.com access by simply analyzing the x.com log.

If only to statistics a.com PV, then only need to x.com all the records in the log add up on the line, but, if you want to statistics UV.

Then you need to write a cookie in the x.com domain to identify the current user, such as user_id. When a user accesses a a.com page, or initiates a request to x.com, the X.com server checks to see if there is a user_id cookie under the x.com domain, and if not, generates a new user_id and writes to the cookie. With this cookie, the analysis of the X.com log can also get a.com PV and UV. The whole process is shown in the following figure.

The problem is that X.com is a third-party domain, and in the high-version Safari browser, writing cookies to a third-party domain is blocked. The result is that every time a user accesses a.com, the cookie that is sent to x.com is empty, so X.com's server thinks it's a new visitor each time, creating a new user_id to write back, However, when the same user accesses the next a.com page, the cookie for the request sent to X.com is still empty. Finally, the analysis of x.com log will be found, access to PV did not change, but the UV is soaring, almost unchanged with PV.

Some people may ask why a x.com server uses a third-party domain. If you are using the same domain as the site a.com no problem. Indeed, if the server and the site are the same domain, there is no problem, but most of the time we can not do this, for example, we may need to have a lot of different domain name sites to provide the same set of services.

The problem is not serious at the moment, because only a high version of Safari has such a limit. However, Safari added this limit to keep users ' privacy (because a large number of ad sites abuse Third-party cookies), and it is likely that other browsers will follow up in the near future, so we have to find a solution as soon as possible.

The P3P scheme is also not going to make sense here, Kissy's developer Seung-sung once put forward a solution, simply, to use post instead of get, so that you can continue to write Third-party cookies in the high version of Safari. Unfortunately, this scheme is not available in the Safari 5.1.4+ version, and Safari has already fixed the bug. In addition, Google was accused of going to court for using a similar approach to read and write third party cookies in a high version of Safari, and was fined $22.5 million last August, meaning that if you continue to use various hack to bypass the browser to restrict reading and writing to Third-party cookies, It is possible to face legal risks. And as browsers continue to upgrade, a variety of previously available hack methods have been invalidated.

Therefore, you must look for additional solutions.

Second Party programme

After testing, we found that currently safari only blocks Third-party cookies when there is no cookie in the third party domain, and as long as any cookie is available under the Third-party domain, you can continue to read and write smoothly in the previous way. However, how can I write the first cookie under a third-party domain?

We tested a number of scenarios, including IFRAME nesting, and finally found that, at least in Safari 6, if there was no cookie at all in the third-party domain, there was no way to write cookies to it, the only way to turn it into a second party, which was to open the field in the top-level window. That is, if there is no cookie under the third party domain, write the first cookie to it, either skip the page to the field, write the cookie, jump back, or pop up a new window, write the cookie, and close the window.

Obviously, both of these scenarios are not good for the user experience.

Localstorage programme

We notice that the high version of Safari only blocks Third-party cookies and does not prevent third party localstorage, so we have a more radical solution: Discard Third-party cookies and use Localstorage instead.

The essence of this scheme is this: to embed an iframe in a w.com domain in a.com, this iframe reads localstorage (under w.com domain), takes a variety of values that were originally needed to be stored in a third-party cookie, and then sends a GET or POST request to x.com, which The information that is recorded in the cookie as the HTTP request hair is sent instead through the URL parameter (get method) or Form form (POST). If there is not much to send, you can send it using GET, just return a JSONP, and then the IFRAME writes the JSONP data to Localstorage. If you need to send a lot of content, it is possible to make the URL is very long, then you need to send by post, then you need to create an IFRAME in the IFRAME as the target of the post, Then the new IFRAME again data with PostMessage and other ways back to the original IFRAME, the original IFrame again write back to Localstorage.

The entire process (using post) is shown in the following illustration:

The problem of this scheme is more complex, the whole process is much longer, need to use some HTML5 characteristics, such as localstorage, PostMessage, etc., but fortunately browsers that do not support third-party cookies are basically a good version of the browser for HTML5 support.

For now, the safer approach is to use the new scheme in parallel, using Third-party cookies on the old browsers, and using the new scheme in browsers such as high version Safari that block Third-party cookies. Imperfect as it may be, it is indeed feasible. Look forward to a more perfect solution in the near future.