A Review of Browser Privacy Initiatives and Proposals

Russell Stringham
Oct 14 · 23 min read

Increased awareness about privacy and the extensive tracking of individuals that occurs regularly on the Internet is resulting in new laws such as the European Union’s General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) to protect an individual’s privacy. In addition to simply complying with these laws, companies are proactively offering increased privacy protections, as a competitive advantage. Browser vendors are at the forefront in this competition. The major browsers are taking different approaches to protect user privacy, sometimes ignoring existing standards and the collateral damage this can cause.

This blog post will review the privacy protections that have recently been implemented or announced for the most popular browsers. Since this is on the Adobe Tech Blog, I’ll also take time to highlight how Adobe specifically is affected by these measures. A subsequent blog post will review the actual impacts these changes have had on various Adobe Digital Experience products, and how they are responding or helping their customers respond to these changes. Throughout this post, I frequently need to distinguish between first-party and third-party cookies and calls, which I abbreviate as 1P and 3P cookies and calls.

Apple Safari

Safari represents about 10–15% of total browser usage, but approaches 50% on mobile devices in the U.S. It has the longest history with these types of privacy initiatives. Apple’s Tracking Prevention Policy describes the types of tracking they intend to disrupt. Apple’s goal for their WebKit web-browser engine is to “do its best to prevent all covert tracking, and all cross-site tracking” (emphasis mine).

Apple has been incorporating Intelligent Tracking Prevention (ITP) functionality incrementally into their browser for the last 2+ years. As bad actors change their tactics to get around ITP’s latest changes, Apple reduces their ability more and more to perform cross-site tracking.

  • ITP 1.0 (June 2017) blocked most third-party (3P) tracking cookies. It uses in-browser machine learning to identify tracking websites (same third-party domain accessed from multiple, unrelated sites). If the user has not interacted with a tracking website in the last 30 days, 3P cookies are automatically deleted and all new 3P cookies from the site are blocked. If they have visited the tracking website (domain listed in browser URL, not as part of a redirect) resulting in creation of a first-party (1P) cookie, this cookie can be used in a 3P context for 24 hours. After 24 hours, cookie can only be used in 1P context. After 30 days without a return visit to the tracking website, the cookie is deleted.
  • Storage Access API (Feb. 2018) added support for cross-site functionality such as like buttons that was broken by ITP 1.0. A 3P iframe can access a 3P cookie originally created in a 1P context if the user interacts with (clicks within) the iframe.
  • ITP 1.1 (Mar. 2018) changed 3P cookie behavior. When a tracking website has not been visited in 24 hours, treat 3P tracking cookies as session cookies (new 3P cookies cannot be created and existing 3P cookies cannot be updated)
  • Protecting Against HSTS Abuse (Mar. 2018) prevents a backdoor tactic used to create a persistent cross-site ID, used by illicit trackers. Evercookies, and similar techniques, produce extremely persistent cookies in a browser with the goal of identifying a client even after they’ve removed standard cookies, Flash cookies, and other standard tracking mechanisms. HTTP Strict Transport Security (HSTS) is used as one of several methods for encoding this ID, and this update breaks HSTS for this use.
  • ITP 2.0 (June 2018) eliminated the 24-hour window during which 1P cookies can be used in a 3P context. 1P cookies are not available in the 3P context (except via the Storage Access API). 3P cookies for tracking websites are always treated as session cookies. Detects sites only temporarily visited through redirects (such as when clicking on an ad and redirecting through the ad server to the advertiser site) and treats any cookies created on these sites session cookies, even in a 1P context. The referrer URL sent to tracking websites is truncated after the domain name portion of the URL (referrer policy is set to strict-origin-when-cross-origin)
  • ITP 2.1 (Feb. 2019) blocked all 3P tracking cookies (not even available as session cookies). Client-side first party (1P) cookies have a maximum expiration of seven days. Client-side cookies are those created locally on document.cookie such as by JavaScript running in the browser. This does not apply to cookies set by the web server.
  • ITP 2.2 (Apr. 2019) reduced the maximum expiration for client-side 1P cookies to 24 hours when navigation to the site is through a “tracking website” (including one that was part of a redirect chain) and the URL contains parameters. This applies for the duration of the session.
  • ITP 2.3 (Sept. 2019) configured sites where client-side 1P cookies expire after 24 hours (as a result of ITP 2.2), so that all “script writable” website data (primarily LocalStorage) will expire after 7 days. It expanded the referrer URL changes implemented in ITP 2.0 to also apply to the 1P site itself when coming from a site identified by ITP as a tracker, and the referrer value contains URL parameters. It is even more restrictive than it was in ITP 2.0 in that when the referrer is truncated, the value will simply be the eTDL+1. For example, a referrer value of “https://sub.social.com/some/path/?clickID=0123456789" was truncated to “https://sub.social.com" by ITP 2.0 and to “https://social.com" by ITP 2.3.

ITP breaks targeted advertising, which relies on 3P cookies. Apple has a proposal, Privacy Preserving Ad Click Attribution, that attempts to allow some amount of attribution to occur on ads placed on a publisher’s website. Personally, I don’t think it will ever be adopted, because it doesn’t offer enough value to advertisers to be worth the work.

Mozilla Firefox

Firefox is making a strong play to be the best at providing strong privacy protections. Mozilla’s Anti-tracking Policy enumerates their goals related to the uses they intend to block, only some of which are they currently able to do. Like Apple, their goal is also to eliminate the ability to perform covert or cross-site tracking.

Mozilla’s solution is called Enhanced tracking prevention (ETP), and was first announced in August 2018. In June 2019, it was configured for standard mode by default for new installations (off by default for existing users). Starting in Sept. 2019, all users are configured to standard mode by default. ETP relies on blacklists of websites known to perform tracking. ETP standard mode automatically blocks 3P cookies from any of these sites. During in private browsing or when in strict mode during all browsing, ETP blocks not only cookies for tracking sites, but blocks the actual calls to these sites.

ETP is based on functionality provided by disconnect.me. The Brave browser also uses this functionality and it is available as a plugin for Chrome and Safari. Disconnect.me maintains two blacklists of tracking websites. Most Adobe domains are in the first list. The more restrictive second list includes all values from the first. For whichever list is being used, ETP always blocks cookies for domains on the list and, except during regular browsing in standard mode, blocks calls to those domains as well.

Users can easily switch to strict mode, which uses the second list, and enables call blocking for all browsing, rather than only for in private browsing. However, strict mode breaks many websites (for example, sites using Adobe Launch or Dynamic Tag Management products to load functionality visible to the user), so I expect most people will avoid this mode. In the custom mode, users can elect to use the less restrictive list, but have it always enabled or they can choose to block 3P tracking cookies, but allow the calls. They can choose to block 3P tracking cookies, 3P cookies from unvisited websites, all 3P cookies or all cookies. However, both standard and strict modes only block 3P tracking cookies. Most users will not understand these choices and so will avoid the custom options.

Blacklists

Firefox maintains preproduction versions of their blacklists on github.

They have a number of blacklists. Adobe shows up in two of them. The disconnect blacklist categorizes different domains based on the type of tracking they do. They have mis-categorized several of Adobe’s properties:

Advertising Category

  • 2o7.net
  • auditude.com
  • demdex.com
  • demdex.net
  • dmtracker.com
  • efrontier.com
  • everestads.net
  • everestjs.net
  • everesttech.net
  • hitbox.com
  • omniture.com
  • omtrdc.net
  • touchclarity.com

At least 2o7.net and omtrdc.net should instead be classified as analytics trackers rather than advertising trackers, but since Firefox blocks both types in standard mode, it probably doesn’t make any difference. However, Analytics doesn’t violate Firefox’s stated anti-tracking policy, because even when using 2o7.net or omtrdc.net, it doesn’t track visitors across sites; each company owns the data collected from their sites and cannot see data collected from other sites. Omniture.com shouldn’t be in either of the lists as it isn’t used for tracking, but instead is used for accessing Analytics reporting; it might be appropriate in the Content list.

Analytics Category

  • adobedtm.com

For DTM/Launch customers, it is even worse than for Analytics that they have been misclassified, because these products don’t perform tracking at all, and when they are blocked, the website itself often breaks. Just last week, disconnect.me accepted to pull request to correct this misclassification, but it may take months before the change appears in Firefox, because Firefox does not appear to sync their lists frequently.

Content Category

  • adobe.com
  • fyre.co
  • livefyre.com
  • typekit.com

Domains classified as content trackers are only blocked in strict mode and only when accessed as a third-party.

Adobe also shows up in the EasyPrivacy Blacklist, with entries for adobedtm.com, adobetag.com and adobe.com, but I don’t know how this list is used. None of the lists seem to be updated very often; at the time of this writing a couple had been updated two months ago and the rest were eight months or more old.

Firefox maintains a list of domains that are owned by the same company (entity) and does not block 3P cookies or calls between sites within this set of owned domains, even when ETP is enabled. It only maintains this list for companies that have at least one domain in their organization that is identified as performing tracking, fingerprinting or mining. So while most e-commerce and news organizations don’t appear on the list, Adobe is in Firefox’s list of related domains:

Adobe Entities

"Adobe": {     "properties": [        "adobe.com",        "livefyre.com",        "typekit.com"    ],    "resources": [        "2o7.net",        "adobe.com",        "adobedtm.com",        "auditude.com",        "demdex.com",        "demdex.net",        "dmtracker.com",        "efrontier.com",        "everestads.net",        "everestjs.net",        "everesttech.net",        "fyre.co",        "hitbox.com",        "livefyre.com",        "omniture.com",        "omtrdc.net",        "touchclarity.com",        "typekit.com"    ]}

Fingerprinting attempts to combine multiple aspects of a user’s environment to uniquely identify a visitor across sites. Sites like AmIUnique and the EFF’s Panopticlick will show your fingerprint using current, widely used techniques and demonstrate that just about everyone can be uniquely identified using only a subset of these techniques, even across browsers on the same device. Your fingerprint may change overtime as your OS and browser are updated and other system changes occur, but it can be remarkably consistent over short time periods of days or weeks. It is possible to predict some of these changes, evolving the fingerprint over time for continuous identification.

While fingerprinting has been around for many years, it is receiving increased interest now that 3P tracking cookies are going away. Firefox’s ETP strict mode also enables a feature that blocks sites identified as performing fingerprinting, and this can also be enabled in the custom mode. I suspect that they will change their fingerprinting default so that soon it will be enabled in standard mode.

Similar to what Apple did with ITP 2.0, Firefox sometimes changes the referrer policy to strict-origin-when-cross-origin, which truncates the referrer value included in the HTTP header after the domain value (removing the path and querystring). Starting in January 2019, Firefox implemented this policy only during in-private browsing. With the October 22, 2019 release of Firefox 70, Firefox also sets it during regular browsing when a 3P resource is loaded from a site on its tracker blacklist.

Microsoft Edge

Microsoft has stopped enhancing Internet Explorer (except for security updates) and restricted new development to their Edge Browser.

“Originally built with Microsoft’s own EdgeHTML and Chakra engines, in 2019 Edge was rebuilt as a Chromium-based browser, using the Blink and V8 engines. As part of this change (codenamed Anaheim), Microsoft has made the preview builds of Chromium-based Edge available on Windows 7, 8, 8.1 and macOS, in addition to Windows 10. As of September 2019, only preview builds of Chromium-based Edge are available.” (wikipedia)

On Nov. 4, 2019, Microsoft announced that Edge will be released on January 15, 2020 on all supported platforms. A Linux version may follow later. Unlike the current version of Edge, which gets twice-yearly updates, Chromium-based Edge will be updated every six weeks (similar to Chrome’s update schedule). The first release will be based on Chromium M79, the same version used in Chrome 79 that Google will release in December.

In a June 2019 blog post Microsoft announced Microsoft Tracking Prevention (MTP). It is available in the Chromium beta versions of Edge and will be included in the released version. It appears very similar in functionality to Firefox’s Enhanced Tracking Prevention, and may share open source code from disconnect.me. I downloaded the latest Mac OS beta to test it out. MTP offers three protection levels, basic, balanced (recommended) and strict. Balanced is the default. Unlike Firefox, MTP doesn’t have a custom mode, and doesn’t behave differently between InPrivate mode and not. Like ETP, it blocks 3P cookies from known tracking sites, and in strict mode blocks calls to those sites.

The same blog post says that Edge will maintain a list of organizations that own multiple domains and calls between these owned domains will not be blocked (this is similar to the entities feature described for Firefox).

The blog post also says that they classify trackers based on what they do. Trackers that are identified as performing fingerprinting will be blocked at all levels of MTP.

Google Chrome

Google’s Chrome is the dominant browser with 50–70% market share according to most rankings, with the Microsoft combination of IE and Edge coming in a distant second. Since targeted ads make up a majority of Google’s revenue, privacy features that break targeting are unlikely to appear any time soon. Still, Google is under extreme pressure from U.S. and European regulators and has implemented, announced or proposed functionality to improve some aspects of privacy and security.

Google has recently mandated that certain flags must be used on certain types of cookies and changed the default behavior for some of these flags. The SameSite flag is used when comparing the domain displayed in the browser URL to the URL of a requested resource, such as the image request used for visitor IDs. The original version of the SameSite specification (proposed in April 2016) supported two values, both of which applied only to 1P cookies (SameSite prevented the cookie from being used in a 3P context):

  • Strict — the referring domain for the page/resource must match the domain of the requested page/resource or the cookie is not sent with the request. When an ad on xyz.com refers someone to www.acme.com, no 1P cookies for acme.com are sent, because xyz.com is a different domain than the cookie’s domain. However, when the landing page, www.acme.com, requests an image from stats.acme.com, the 1P cookies are sent, because the “referrer” is www.acme.com.
  • Lax — the domain in the browser URL must match the domain in the requested URL for the cookie to be sent.

In the original specification for SameSite, when the flag is not set, its value defaulted to none, but it was not possible to specify none as a value for the flag. When SameSite’s value is none, the cookie can be used in 3P contexts and is sent with all requests to its domain. However, if SameSite is set to a value other than strict or lax, it defaults to strict. Chrome, Firefox and Opera added support for the SameSite flag in 2017. Safari and Edge added support in 2018. IE still does not support this flag (it is ignored).

Later the specification was updated to allow explicitly setting the value to none:

  • None — ignore browser URL and send the cookie with all requests to the cookie’s domain (i.e. allow the cookie to be used in 3P contexts). This is the same as the default behavior when the flag is not specified.

The original purpose of this flag was to help prevent cross-site request forgery (CSRF) attacks. In May 2019, Google announced that it would shortly change the behavior of Chrome so that any cookie that did not specify the SameSite flag would default to SameSite=lax rather than to SameSite=none. The primary purpose of this change is to protect against CSRF attacks, because so few websites (only around 1%) had been updated in the previous three years to specify the SameSite flag to protect against these attacks. A second result is that it is now very easy to identify cookies that are intended to be 3P cookies. Google has a beta feature that allows users to easily delete cookies where SameSite=none.

One side-effect of this change is that any cookie that is intended to be used as a 3P cookie will need to add the flag SameSite=none when creating these cookies, or the cookies will not be available for 3P requests.

Secure

In the same blog post, Google also said that it would require specifying the secure flag whenever SameSite=none. This means that only HTTPS can be used with 3P cookies. The July 2019 release of Chrome (version 76), included support for defaulting SameSite to lax and requiring the secure flag when SameSite=none, but it is off by default. It will be on by default starting in the Chrome 78 betas, but will not be on by default in released versions until Chrome 80, which is expected to be available in February 2020.

Web Standard

Google has submitted a proposal to make these changes a web standard for cookies. Shortly after this, Mozilla announced that Firefox would also support it. The functionality is available in the current version of Firefox, but like Chrome, still off by default. As far as I am aware, Firefox has not announced when they will have it on by default, but I would expect that it won’t happen until after Chrome makes this change. An Edge developer has indicated that Edge will be adopting these changes, and another developer says they should be available in Edge 80 (tentatively set for release February 26, 2020). They are hidden behind feature flags in the current Edge beta.

Incompatibilities

On October 23, the Chromium blog shared their recommendations on how developers should prepare for the SameSite and Secure cookie changes. They note that cookie functionality will break on many older browsers if a site tries to create a cookie with SameSite set to None. These include Chrome versions 51–66 inclusive, which are still in use on many older Android phones. Android apps built using WebView and running on older phones with these versions of Chromium will also be broken. The UC Browser (popular in China) is broken prior to version 12.13.2. All of these will reject any cookie specified with SameSite=None, behaving as if 3P cookies are blocked.

WebKit 12 was the first version of WebKit to implement support for the SameSite attribute, but did not support specifying None explicitly. Following the original specification, when WebKit didn’t recognize the value, it treated it as if SameSite=strict had been specified. The result was that if you tried to specify that it was OK to use the cookie in a 3P context, you would have restricted the cookie to only a 1P context on WebKit-based browsers. Since many of these 3P cookies would be blocked by Safari’s ITP anyway, this problem isn’t very visible. However, Apple mandates that WebKit be used for all browsers on iOS, so when using Chrome on iOS 12, if a 3P cookie was created with SameSite=none, it would behave as if SameSite=strict had been specified, resulting in the cookie being valid only in a 1P context. Webkit marked this bug as fixed in mid-September, and included the fix in Safari 13 and iOS 13 released later that month. However, many users will not have upgraded, so the problem will continue for Chrome users on iOS 12. It appears that Google is accommodating this by not requiring SameSite use in their iOS version of Chrome. In Chrome 78, if a user wants to enable the SameSite functionality, the flag has the following description:

Treat cookies that don’t specify a SameSite attribute as if they were SameSite=Lax. Sites must specify SameSite=None in order to enable third-party usage. — Mac, Windows, Linux, Chrome OS, Android

Notice that iOS does not appear in this list. It would seem to be safe for now to simply not set the SameSite flag for iOS browsers. Better yet, Google has provided pseudo-code that parses the UserAgent string to help websites decide when they should set SameSite=None for 3P cookies and when they should leave it unset.

Chrome 80 will change the default referrer policy from no-referrer-when-downgrade to strict-origin-when-cross-origin, which will truncate the referrer value by removing the path and querystring when the domain of the current page is different from that for a new page or for a requested resource (i.e. a 3P request). Google has a proposal to make this default the new standard. Chromium-based Edge has this functionality, but it is currently disabled by default. As noted above, Firefox already has this functionality during in-private browsing and to blacklisted trackers, while Safari has something similar. Note that for all but Safari, this is only a change to the default referrer policy and a web server can override this policy for referrals from its site.

In the same May 2019 blog post Google says:

Because fingerprinting is neither transparent nor under the user’s control, it results in tracking that doesn’t respect user choice. This is why Chrome plans to more aggressively restrict fingerprinting across the web. One way in which we’ll be doing this is reducing the ways in which browsers can be passively fingerprinted, so that we can detect and intervene against active fingerprinting efforts as they happen.

In the blog post, they don’t say how they will do this or when, but in August 2019 they shared a separate proposal for Combating Fingerprinting with a Privacy Budget, that matches the description. This proposal suggests this is something that could be adopted by all browsers (i.e., a new standard). The browser will keep track of all API calls made by a website that can be used for fingerprinting and calculate the number of bits of additional identifying information revealed by each call. When too many calls have been made, the privacy budget for that website will have been exceeded and additional calls will either fail, return results that are identical for all users or will return noisy results. If the website needs the correct values for legitimate purposes, such as “3D games or video conferencing,” it can use a special API to prompt the user to grant unrestricted access to the APIs that can be used for fingerprinting. They also want to investigate reducing the information currently in the User Agent (UA) string (and similar data, such as timezone, sent by default) to make it less unique and only provide the full UA string through an API call, if the website wants to spend part of its privacy budget on it.

Google has their own proposal for how to handle organizations that own multiple domains in a standard way. They state that Google and Apple already support similar methods for sharing login credentials between mobile apps and a website. They propose extending the basic idea to allow organizations to define their own relationships between their various properties, rather than relying on the predefined lists used by Firefox and Edge. It defines methods to prevent abuse, such as preventing ad networks from defining large organizations that include all the sites they advertise on. This proposal would allow 3P cookies between related sites, even for browsers or plugins that otherwise block 3P cookies. While it would support credential sharing between these sites, it would still distinguish between 1P and 3P cookies/calls.

Google hasn’t announced any immediate plans to implement this.

In a separate May 2019 blog post entitled Raising the bar on transparency, choice and control in digital advertising, Google stated (emphasis mine):

To better protect user privacy and choice on the web, Chrome intends to make it easier for users to block or clear cookies used in a third-party context

Recall that the new SameSite behavior allows Google to easily distinguish between 1P and 3P cookies. They go on to state:

When a user opts out of third-party tracking, that choice is not an invitation for companies to work around this preference using methods like fingerprinting, which is an opaque tracking technique. Google doesn’t use fingerprinting for ads personalization because it doesn’t allow reasonable user control and transparency. Nor do we let others bring fingerprinting data into our advertising products.

In addition to the tools Google already provides, including My Activity, Ad Settings, Why this Ad and Mute this Ad, Google will create a browser extension (not limited to Chrome) that will show more details about the ad bidding process used for ads displayed on a page with details such as all companies involved, the data used for personalization, etc.

In August, Google blogged about their privacy sandbox, a set of early proposals to improve user privacy. The proposals include:

  • Combating Fingerprinting with a Privacy Budget — the fingerprinting proposal described above
  • Conversion Measurement — A proposal similar to Apple’s Privacy Preserving Ad Click Attribution, but with the ability to uniquely identify ads. Only supports conversions on clicked ad impressions with an emphasis on last-clicked.
  • Trust Token API — Allows anonymous authentication. For example, Comcast can issue some tokens to a logged in user that the user is a Comcast customer. When the user later visits ESPN, a token can be redeemed by ESPN, verifying that the person is a Comcast customer, but not in a way that uniquely identifies them. As another example, when a person answers a CAPTCHA, they can be granted multiple (say 10) tokens, which will allow them to skip the next 10 sites that require CAPTCHAs.
  • Federated Learning of Cohorts (FLoC) — Privacy preserving, semi-targeted advertising. The browser applies machine learning to a user’s web history (or supplemental info provided by the pages visited), to place the user into one very large cohort, based on the shared interests of this cohort. Globally, there would only be a few thousand unique cohorts, and each cohort would have a minimum of a few thousand people in it. When a website wants to serve an ad, it can discover the user’s cohort from the browser and serve an ad specific to that group. The user’s history is never shared with or analyzed by a third party.
  • Privacy Model for the Web — General ideas around restricting sharing between 1P sites, but allowing limited sharing in some cases.
  • Privacy Interest Groups, Including Noise (PIGIN) — As a user visits an advertiser’s website, the advertiser can pass interest group suggestions to the browser, along with a list of ad networks that support that group. When on another site that wants to display an ad using one of these ad networks, the browser can choose to share one or more of these interest groups with the ad network to help it select a targeted ad. Suggests ways to ensure the group is large enough to not uniquely identify/target someone. Does not work for (semi-)targeted ads for sites you have never visited.

Other Browsers and Plugins

Beyond the big four browser vendors are a number of small players (combined representing less than ten percent of users in most surveys). These browsers include Opera, Brave, Cake, Vivaldi, UC (developed by Alibaba), Samsung Internet, Android browser (replaced by Chrome on most newer Android phones), Konqueror, etc. A few are getting new attention, because of their takes on ads and privacy. I haven’t spent a lot of time researching these.

Brave claims to be 2–10X faster than other browsers, partially as a result of blocking most ads and trackers, eliminating their bandwidth consumption. They have suggested that they may support a model where they replace the ads on a website with ads they serve themselves, sharing the revenue between themselves, the browser user, and the site. Publishing sites are understandably upset about this as it reduces their revenue considerably versus targeted ads served directly from their sites. Brave has published an Ads Confirmation Protocol where they outline this proposal. It includes methods for validating that an ad was viewed without identifying who viewed it. As mentioned above, Brave also incorporates the functionality from disconnect.me to identify and block tracking and fingerprinting. For those extremely concerned about privacy, Brave also supports Tor natively.

Ad blockers are growing in popularity. According this infographic from GlobalWebIndex, ad blockers are now used by about 47% of users globally. While Brave is trying to make a name for itself by blocking all ads by default, other browsers are also moving to block some ads by default as well. While ETP/MTP are not meant to be ad blockers, when enabled, they eliminate calls to websites that perform tracking, resulting in many ads being blocked, because most ad networks use tracking to provide personalized ads. Sites that serve non-personalized ads are not blocked.

Surprisingly, Chrome is the only mainstream browser that intentionally blocks some ads. In June 2017 Google announced that they would start blocking all ads on websites that regularly violate the standards of the Coalition for Better Ads, even when those sites are serving Google ads. They began enforcing this in some countries in 2018 and have rolled it out globally in 2019. This is actually a move by Google to protect their ad revenue, because the most annoying ads that they are now blocking are the types that motivate people to install ad blockers in the first place. They hope that by getting rid of the worst offenders, they can slow the spread of ad blockers.

Some ad blockers, including two of the most popular, AdBlock and Adblock Plus, allow acceptable ads by default. They go further than Chrome in blocking the intrusive ads that annoy so many users, while allowing revenue for sites that commit to use only these non-intrusive ads (ads that don’t block the screen, contain video/motion/flashing, etc.).

The disconnect.me technology used by ETP is available as a free plugin for Chrome and Safari. Like ETP, this will block all calls to identified trackers. Other similar plugins are also available and block calls or cookies. Some plugins blindly block all 3P cookies, although this can be configured directly in many browsers without the use of a plugin. At this time, none of these plugins are widely used.

Many anti-spyware tools and some anti-virus scanners will delete 3P tracking cookies, when they run automated cleanups on a weekly or daily basis. For Adobe Analytics this means that each returning visitor on a site using 3P data collection is treated as a new visitor when they return after deletion occurs.

Conclusion

All major (and most minor) browsers are getting serious about protecting user privacy. The ability to track users across the Internet, even anonymously, is being eliminated. Companies can no longer rely on third-party cookies to track users. Third-party cookies are or shortly will be eliminated for most users of most browsers. Companies that hope to fallback to more stealthy methods, such as fingerprinting, that can track users without their knowledge or consent will be similarly frustrated, even if they are able to avoid legal consequences for these actions. Companies will only be able to track users when they give their explicit consent, often by signing into a site using a common identifier, such as a email address or social media login. On sites where they do not agree to do this, they will need to remain anonymous.

While this will be painful for many current business models that fund much of the Internet, the companies that will be most successful going forward will be those that embrace user privacy, commit to honor it and demonstrate that commitment by the actions they take.

A subsequent blog post will examine the impact that these changes are having on various Adobe Digital Experience products, the changes these products have made to adapt, and the changes that Adobe customers may need to make to their implementations to realize the most value for their investment within this new privacy-aware landscape.

Updated: This post was updated on October 21 to reflect changes made in WebKit for Safari 13 and iOS 13. It was updated on October 23 to reflect changes made in Firefox version 70. On October 31 it was updated to include information gleaned from a new Chromium post. On November 18, details added about Edge’s GA release and updates/clarifications related to referrer truncation.

Adobe Tech Blog

News, updates, and thoughts related to Adobe, developers, and technology.

Thanks to Josh Butikofer

Russell Stringham

Written by

Software engineer at Adobe

Adobe Tech Blog

News, updates, and thoughts related to Adobe, developers, and technology.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade