Script Blocking Exceptions Update
by
BraveFeb 12, 2019
Press,
Security & Privacy
We have received many questions about script blocking exceptions being reported by several news outlets and blogs. This conversation is about script loading, not tracking. Loading a script from an edge-cache does not track a user without third-party cookies or equivalent browser-local storage, which Brave always blocks and always will block. In other words, sending requests and receiving responses without cookies or other means of identifying users does not necessarily create a tracking threat.
Brave aims to maintain a
working Web, while reducing or eliminating the invasive tracking that has become so ubiquitous online. In order to do this, we make the conventional distinction between
first-party and
third-party content, granting different permissions to each.
First parties are the websites you’re directly accessing, whereas third parties are embedded widgets and other resources in the page, which are indirectly accessed. If a user navigates to a website, they may find that several other requests will be made to fetch resources on other websites. Depending on the website, Brave may cancel the request entirely, or permit it while severely limiting access to user data.
We found that blocking certain third-party scripts broke many sites, so predicated on our cookie blocking and fingerprinting protection, we hardcoded some exceptions to ensure the best possible user experience. For example, Facebook and Twitter both contain widgets which web authors can integrate into their online properties. These widgets aim to make it easier for users and publishers to connect by allowing users to authenticate through Facebook or Twitter, rather than creating and maintaining an account with the publisher themselves. The exception list covered by several news outlets allows both of these widget sets to operate on a leash. They can load, but they cannot access local data on the client so as to track the user.
For many publisher implementations, blocking the script request would break Facebook-based OAUTH and Facebook likes and shares.
As an example, the
Facebook JavaScript SDK that uses the connect.facebook.net hostname is used for Facebook likes and shares, for Facebook login and for the Facebook Graph API. There is an alternative method for developers that
relies on using redirects in place of the Facebook SDK, which uses the
www.facebook.com hostname. For more information, see
the initial bug report that we received saying that users could not log in to sites with Facebook. In 2016, we found many examples of sites such as Fitbit, Quora and Digg that used Facebook login in this manner; it is possible that some of them do not anymore.
Fingerprinting is not always a reliable tracking method.
Given that most users on the web share IP addresses with other users because of
NAT, it is unlikely this can be used to reliably track users unless they have a very distinctive user agent string. Brave mitigates this challenge by not having our own user-agent string; for instance on desktop, our UA is the same as that of Chrome. Brave also blocks some types of JavaScript fingerprinting in third-party iframes
by default.
At Brave, we continually work to protect users without breaking the Web and users can always be assured that we are doing everything in our power to prevent third-parties from eavesdropping on their browsing experience. We are working to eliminate these script-blocking exceptions without blocking the embedded widgets with which some users do choose to interact.
We have received many questions about script blocking exceptions being reported by several news outlets and blogs. This conversation is about script loading, not tracking.
brave.com
