Disabling third-party cookies causes privacy issues on Microsoft's Office.com
Almost all browsers allow all cookies by default. When third-party cookies are disabled, several major sites and services, including those from Microsoft and Google, fail badly and may even leak private data.
In the first part of our blog series “The third-party cookie mistake” we discussed the privacy and security issues caused by third-party cookies and how ‘allow all cookies’ nonetheless became the default in almost all major browsers. This post explains what may happen if you deviate from this default.
At present, if you browse the web with third-party cookies disabled, you may come across issues logging in and making payments. Here we outline several cases we have found involving major tech companies (which should be able to solve this issues), which have consequences from just preventing login or completing payment, to potentially leaking private company data from a Microsoft Office account.
We found that, when all third-party cookies are disabled, logging out on office.com seems to succeed, but actually fails. Additionally, this authentication remains available when subsequently navigating to office.com, which can be used to extract data from the SharePoint API. This issue was submitted to Microsoft but was rejected on the grounds that it is not remotely exploitable. It is however a risk on any shared computer that a subsequent user would be able to see document metadata for the organization, and perhaps modify data via the SharePoint API (For technical details see: https://whotracks.me/blog/block-third-party-cookies.html).
This can be simply reproduced by disabling third-party cookies in any browser, then logging in and then out again on office.com.
After the confirmation of a successful logout, simply navigate back to www.office.com, and one is returned to the view after login, including an up-to-date feed of recently changed documents.
The broken logout state can only be resolved by manually deleting office.com cookies. We also found the session may eventually be expired, but this only happened after multiple hours. Hence, users affected by this will 1) likely not be aware that they’re not logged out properly, as the logout appears to be successful, and 2) would not be able to logout anyway if they noticed the issue.
The issues with Microsoft Office continue when trying to purchase an Office 365 trial from products.office.com/try. This time, the source of the problem is detected, but the user is given no choice to continue unless they compromise their security and privacy by enabling cookies. Ironically, they also imply that allowing third-party cookies is somehow safer.
It is common practice for E-Commerce sites to embed payment systems from third-party vendors, such as Paypal, on their checkout pages. Such widgets should not require third-party cookies – usually the user can be redirected to pay at the payment provider’s site. This method is preferable, as it reduces the chances of phishing: loading the payment page as a first party will make the URL and certificate status visible, and only prompting users to enter payment information on the first party site is also good practice.
Despite this, we see examples of payment being blocked when third-party cookies are disabled. One such example is on the German E-Commerce site Thomann.de. When attempting to checkout with Amazon pay, we get an error mentioning that third-party cookies are being blocked:
Many sites use Google’s connect SDK, to allow users to login to sites with their Google account. When testing cases on www.tripadvisor.com and www.stumbleupon.com with third-party cookies disabled, the ‘Connect with Google’ button fails to do anything when clicked. Both these sites also offer Facebook login too which works with cookies disabled. It is not clear why the Google implementation requires third-party cookies to be allowed.
Following GDPR, websites using third-party services which collect data about users acquire consent for this, as well as provide a reasonable way of opting-out of data collection and processing. While many publishers have converged on a solution which gathers consent as a first-party cookie which can then be passed to third-parties, other still rely on an older system of setting opt-out cookies for each vendor. Obviously, if third-party cookies are blocked, this mechanism will not work, as can be seen on the Telegraph:
In this case, users with third-party cookies disabled will be denied their right to opt-out (though blocking these cookies will effectively prevent a large proportion of tracking).
Third-party vendors may say that this mechanism is required in order to remember a user’s consent settings. However, previous attempts to allow browsers to convey tracking consent explicitly to servers, via the ‘Do Not Track‘ standard were killed by the same vendors collectively saying they would ignore this signal.
All these cases show how the web ecosystem is preventing users from reverting the third-party cookie mistake. But don’t worry! It’s still possible to block third-party cookies without breaking the user experience on web pages. We will discuss this in detail in the third part of our blog series.
This article was first published in full on WhoTracks.me.
