Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Browsers
Brave
Brave Browser release info
Message
<blockquote data-quote="oldschool" data-source="post: 864885" data-attributes="member: 71262"><p><span style="font-size: 26px"><strong>Script Blocking Exceptions Update</strong></span></p><p>by <a href="https://brave.com/author/brave/" target="_blank">Brave</a>Feb 12, 2019<a href="https://brave.com/category/press/" target="_blank">Press</a>, <a href="https://brave.com/category/security-privacy-category/" target="_blank">Security & Privacy</a></p><p></p><p></p><p><em>We have received many questions about script blocking exceptions being reported by several news outlets and blogs. </em>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.</p><p>Brave aims to maintain a <em>working </em>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 <em>first-party</em> and <em>third-party</em> content, granting different permissions to each.</p><p>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.</p><p>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.</p><p><strong>For many publisher implementations, blocking the script request would break Facebook-based OAUTH and Facebook likes and shares.</strong></p><p>As an example, the <a href="https://developers.facebook.com/docs/javascript/examples" target="_blank">Facebook JavaScript SDK</a> 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<a href="https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow" target="_blank"> relies on using redirects in place of the Facebook SDK</a>, which uses the<a href="http://www.facebook.com/" target="_blank"> www.facebook.com</a> hostname. For more information, see<a href="https://github.com/brave/browser-laptop/issues/780" target="_blank"> the initial bug</a> 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.</p><p><strong>Fingerprinting is not always a reliable tracking method.</strong></p><p>Given that most users on the web share IP addresses with other users because of <a href="https://en.wikipedia.org/wiki/Network_address_translation" target="_blank">NAT</a>, 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 <a href="https://github.com/brave/brave-browser/wiki/Fingerprinting-Protection-Mode" target="_blank">by default</a>.</p><p>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.</p><p></p><p>[URL unfurl="true"]https://brave.com/script-blocking-exceptions-update/[/URL]</p></blockquote><p></p>
[QUOTE="oldschool, post: 864885, member: 71262"] [SIZE=7][B]Script Blocking Exceptions Update[/B][/SIZE] by [URL='https://brave.com/author/brave/']Brave[/URL]Feb 12, 2019[URL='https://brave.com/category/press/']Press[/URL], [URL='https://brave.com/category/security-privacy-category/']Security & Privacy[/URL] [I]We have received many questions about script blocking exceptions being reported by several news outlets and blogs. [/I]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 [I]working [/I]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 [I]first-party[/I] and [I]third-party[/I] 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. [B]For many publisher implementations, blocking the script request would break Facebook-based OAUTH and Facebook likes and shares.[/B] As an example, the [URL='https://developers.facebook.com/docs/javascript/examples']Facebook JavaScript SDK[/URL] 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[URL='https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow'] relies on using redirects in place of the Facebook SDK[/URL], which uses the[URL='http://www.facebook.com/'] www.facebook.com[/URL] hostname. For more information, see[URL='https://github.com/brave/browser-laptop/issues/780'] the initial bug[/URL] 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. [B]Fingerprinting is not always a reliable tracking method.[/B] Given that most users on the web share IP addresses with other users because of [URL='https://en.wikipedia.org/wiki/Network_address_translation']NAT[/URL], 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 [URL='https://github.com/brave/brave-browser/wiki/Fingerprinting-Protection-Mode']by default[/URL]. 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. [URL unfurl="true"]https://brave.com/script-blocking-exceptions-update/[/URL] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
