browser recommendation: Brave #78

2016-10-06T06:11:52Z

ocramleznem commented

2016-10-06 06:11:52 +00:00

(Migrated from github.com)

Referring to @diracdeltas on Twitter I added the browser Brave as new recommendation.

I used the place, coloring, styles of IceCat which was placed there some time ago.

Referring to @diracdeltas on [Twitter](https://twitter.com/bcrypt/status/783736770835783680) I added the browser [Brave](https://www.brave.com/) as new recommendation. I used the place, coloring, styles of IceCat which was placed there some time ago.

ghost commented

2016-10-06 21:06:27 +00:00

(Migrated from github.com)

It's basically a browser that has some features which can be added as addons to other browsers.
Firefox with addons is better imho (due to security issues, audits, community, support, etc).

It's basically a browser that has some features which can be added as addons to other browsers. Firefox with addons is better imho (due to security issues, audits, community, support, etc).

diracdeltas commented

2016-10-06 21:23:58 +00:00

(Migrated from github.com)

@Shifterovich as someone who was the author/maintainer of some of those firefox addons (HTTPS Everywhere, Privacy Badger), i can mention a couple ways that brave is different from FF + addons:

chromium-based, which means it has process separation that prevents some of the attacks that firefox is vulnerable to
better protection from Flash content: while it is possible to enable Flash in Brave, we disable it by default and pretend it isn't installed in order to trigger HTML5 fallback, which makes Flash less necessary in the first place. AFAICT no other browser currently does this. https://github.com/brave/browser-laptop/wiki/Flash-Support-Deprecation-Proposal
fingerprinting defense: AFAIK, no browser except Tor Browser Bundle includes all of these: https://github.com/brave/browser-laptop/wiki/Fingerprinting-Protection-Mode. we also have 0 plugins, so the navigator.plugins fingerprinting attack doesn't really work.
adblocking and tracking protection are built into the browser core, so it's faster than addons.

Firefox is great and has a fantastic user community, but I think it is good to have diversity in browser engines.

BTW Brave is MPL licensed so it's also free software.

@Shifterovich as someone who was the author/maintainer of some of those firefox addons (HTTPS Everywhere, Privacy Badger), i can mention a couple ways that brave is different from FF + addons: - chromium-based, which means it has process separation that prevents some of the attacks that firefox is vulnerable to - better protection from Flash content: while it is possible to enable Flash in Brave, we disable it by default and pretend it isn't installed in order to trigger HTML5 fallback, which makes Flash less necessary in the first place. AFAICT no other browser currently does this. https://github.com/brave/browser-laptop/wiki/Flash-Support-Deprecation-Proposal - fingerprinting defense: AFAIK, no browser except Tor Browser Bundle includes all of these: https://github.com/brave/browser-laptop/wiki/Fingerprinting-Protection-Mode. we also have 0 plugins, so the `navigator.plugins` fingerprinting attack doesn't really work. - adblocking and tracking protection are built into the browser core, so it's faster than addons. Firefox is great and has a fantastic user community, but I think it is good to have diversity in browser engines. BTW Brave is MPL licensed so it's also free software.

👍 2

ghost commented

2016-10-07 20:33:23 +00:00

(Migrated from github.com)

@diracdeltas Oh, I didn't know it's chromium-based (didn't look too much into it).
The backend might be nice, but the frontend is the reason why I personally wouldn't use this browser. And frontend matters a lot (it's a browser) too.

@diracdeltas Oh, I didn't know it's chromium-based (didn't look too much into it). The backend might be nice, but the frontend is the reason why I personally wouldn't use this browser. And frontend matters a lot (it's a browser) too.

johnnagro commented

2016-11-11 16:54:20 +00:00

(Migrated from github.com)

👎 This is a bad idea:

How does Brave walk that fine line? The browser infers from your browsing history what you're interested in, such as gourmet coffee or European cars, and shares industry-standard categories with publishers who can then place appropriate ads without knowing anything else about you. Brave, the company, says it doesn't know or want to know any of this information.

https://www.cnet.com/news/ex-mozilla-ceo-try-braves-new-browser-for-a-faster-private-web/

:-1: This is a bad idea: > How does Brave walk that fine line? The browser infers from your browsing history what you're interested in, such as gourmet coffee or European cars, and shares industry-standard categories with publishers who can then place appropriate ads without knowing anything else about you. Brave, the company, says it doesn't know or want to know any of this information. https://www.cnet.com/news/ex-mozilla-ceo-try-braves-new-browser-for-a-faster-private-web/

bridiver commented

2016-11-11 18:52:02 +00:00

(Migrated from github.com)

@johnnagro could you elaborate on why you think it's a bad idea? The article has a very high-level description of the process and a lot goes into it to minimize data leakage. The browser never sends a persistent identifier and all requests are proxied through a CDN that has logging disabled so no IP address or header data that could be used for fingerprinting is available. The browser also takes several steps to prevent fingerprinting by unique sets of categories. The total number of categories sent in any request is limited and it will both suppress real signals and insert fake ones to further obfuscate the data. A very small amount of information does leak. When the ad is delivered the advertiser will see your ip address, but they will not have access to cookies or local storage and javascript access will be severely curtailed. The browser history used to generate the segments never leaves the browser in a form that can be read by anyone else. If syncing is enabled it will be stored remotely, but the data will be encrypted by a browser generated key (think 1password). There is a lot more that goes into it and we are trying to make it as private as possible. If you have any ideas to improve it we would love to hear them and if you still have a problem with it then just don't turn it on. Ads are disabled by default.

bridiver commented

2016-11-11 18:57:03 +00:00

(Migrated from github.com)

I forgot to mention that the requests for the current beta version return a placeholder ad, but when it goes live the request will return a collection of "bids" that the browser can choose from. It could pick one from the current response, one from a previous response that hasn't exceeded a time limit or choose not to display anything at all. This allows the browser to request ads asynchronously and independently of the current page

diracdeltas commented

2016-11-11 19:03:51 +00:00

(Migrated from github.com)

Also note that the privacy-preserving ad feature does not exist yet and will be off-by-default whenever it comes out. Browsers are supposed to act on behalf of users' interests, and we think users should have a choice in if/how they fund content on the web. Our preferred way is to block ads and let people send automated micropayments, but alternatives are (1) block original ads, insert ads that are less intrusive and (2) just show the original ads like other browsers do.

bridiver commented

2016-11-11 19:08:13 +00:00

(Migrated from github.com)

There is also the option to block ads and not send micropayments. We would prefer that people support content providers and our goal is to help support them in a way that is far less invasive than the current system, but we understand that some people just want to block ads so Brave works for them too

johnnagro commented

2016-11-12 14:48:37 +00:00

(Migrated from github.com)

Looks like one of the Brave devs is on the thread, bcrypt herself @diracdeltas - I'm open to hear your thoughts/corrections/comments... At the end of the day, Brave seems to make it's money by either targeting advertising OR micro payments (which must produce an audit log?). Perhaps the fashion in which it's done is better than the way the world works today but, help me reconcile how this isn't by definition producing a form of fingerprinting? Should we be concerned that they exist at the behest of people who want to pay them money to serve you ads? Genuinely want to know.

bridiver commented

2016-11-13 01:36:08 +00:00

(Migrated from github.com)

@johnnagro we have gone to great lengths to protect the privacy of our users with both ads and micropayments. Rather than collecting data server-side, the browser keeps track of everything client-side and submits the data through a process based around Anonize (https://eprint.iacr.org/2015/681.pdf). We worked closely with two of the authors (Abi and Rafael) to help ensure that we were not unintentionally leaking data. We also intentionally designed it in a way that doesn't require you to trust us. We don't collect data and promise we won't use it in evil ways, we just don't collect anything that we could use in evil ways in the first place and that can be easily verified because all the code running on the browser is open source. All the server-side code is open source as well, but you don't have to trust us on that because you know exactly what is being sent. If you're looking for some sinister hidden motive you're not going to find it here. Yes, Brave needs to make money and that money comes from a small cut of micropayments and ads. We are all big privacy advocates and we want to be as transparent as possible about everything we do. There is plenty of code and documentation at github.com/brave so you can see for yourself how it works.

johnnagro commented

2016-11-13 15:04:46 +00:00

(Migrated from github.com)

@bridiver I am not suggesting you folks have evil intentions. A couple follow up questions?

You seem to be saying that this is 100% a client-side application? With the exception of perhaps micropayments which are obfuscated with Anonize. So, there is no MITM to process content for profiling or deliver ads & no server-side profile kept?
How is profiling/targeting accomplished? How does the browser go from browsing history/usage to a locally stored advertising profile?
How is that profile used to select/target the appropriate ad? When the browser has a choice to display an alternative ad targeted with your profiling, is that done client-side too?

@bridiver I am not suggesting you folks have evil intentions. A couple follow up questions? - You seem to be saying that this is 100% a client-side application? With the exception of perhaps micropayments which are obfuscated with Anonize. So, there is no MITM to process content for profiling or deliver ads & no server-side profile kept? - How is profiling/targeting accomplished? How does the browser go from browsing history/usage to a locally stored advertising profile? - How is that profile used to select/target the appropriate ad? When the browser has a choice to display an alternative ad targeted with your profiling, is that done client-side too?

bridiver commented

2016-11-14 18:38:34 +00:00

(Migrated from github.com)

@johnnagro

It is not 100% client-side, but there is no server-side profile and all reporting data (micropayments and ads) uses Anonize. More details in 2
All behavioral online advertising uses "segments" for targeting. Segments are generally interest/intent/demographic groups and advertisers may target one segment or a combination of segments. We have been developing an in-browser modeling engine that infers segments without collecting any server-side data. Also as mentioned above a user could potentially be fingerprinted by the set of generated segments so they are limited/obfuscated.
The browser sends an ad request which is forwarded to various demand providers through our anonymizing proxy (and other services described below) which hides the IP and any other fingerprintable information from the provider. The response will return relevant ads based on the obfuscated set of segments the browser sent. The browser can then discard any ads that don't fit the real profile (fake segments are sent along with the real segments) and decide which ad(s) to display (subject to client-side user preferences). The response is similar to RTB and the browser may decide to show some, all or none of the ads on either the current page or some future page that is displayed before the "bids" expire.

We do need to provide reporting data that takes the place of existing tracking pixels. Advertisers may have specific conversion goals or other metrics they want to analyze and that data is reported by the browser asynchronously using anonize. The current reporting system for micropayments is a good place to start because it's live in beta testing right now.

The browser locally stores information necessary to give each site you visit a "score". That score is used to determine the relative distribution of your payment. The score translates into a probability that any given site will receive a "vote". For each vote the browser randomly selects a site based using the calculated probabilities. For each reporting period (one month) the browser gets 30 votes. 30 independent anonize "surveys" are created to collect those votes. The surveys cannot be connected and anonize allows us to ensure that there is only one vote per browser/survey without knowing which browser/user submitted the vote. What we end up with is essentially an anonymous sample of the data. This allows us to pay both big and small sites without a detailed browsing history. Here is the explanation from Rafeal:

Let X be the number of ``daily-rewards'' (of $5/30) that some site
gets in a month. If we go for the $100 cut-off as discussed above (i.e., only sites that make
more than $100 per month need to get a reliable payment), think of  \mu = E[X] >  600.

Let's assume that users are independent. The multiplicative chernoff bound then says that Pr [X < (1-eps) \mu ] < e^{-\eps^2 \mu/2}. So, if we set eps = 0.1, we get that except with probability e^{-1/200 * 600} = e^{-3} < 0.05, the webpage
will get 90% of what it is supposed to get. (And webpages that are supposed to get $1000 will get at least 97% of that)

The reporting is done over randomized intervals and a very similar system will be used for ad reporting. You should be able to see a few issues here, one of which is that the submissions can potentially be linked by IP address. We don't log IP address, but you can't verify that so we are taking advantage of other services to hide the IP from ourselves. In the beta we're using a 3rd-party proxy service, but we'd like to split the messages across a variety of different channels which could include Tor, IM, etc..

The other issue is related to ads. When the ad is actually displayed by the browser the creative will come from the advertiser, not us (it would be cost prohibitive to proxy all the creatives). We block cookies, limit javascript, etc... as described above, but the advertiser will still see your IP address. At best this would allow an advertiser to infer a small amount of data based on the targeting criteria of the ad and link that to your IP address. That data could be added to any existing data the agency/advertiser has connected to your IP through other means (online purchases, logins, etc...). IPs are often shared and both IPs and targeting segments have varying lifetimes so the data leakage is minimal. A perfect system in this respect just isn't practical right now, but the current system is much, much worse.

I think everyone understands that "free" content isn't free and we need some way to compensate publishers for their work, but that method shouldn't be the privacy nightmare that it is today. To a large extent we have to make this work within the limitations of the existing ad infrastructure and I think we've done a very good job of doing that while still providing very good privacy. Other ad blocking companies which shall remain nameless take large payments to whitelist ads. The whitelisting criteria focus almost entirely on presentation and are completely silent on the subject of tracking. We think we can do a lot better than that.

@johnnagro 1. It is not 100% client-side, but there is no server-side profile and all reporting data (micropayments and ads) uses Anonize. More details in 2 2. All behavioral online advertising uses "segments" for targeting. Segments are generally interest/intent/demographic groups and advertisers may target one segment or a combination of segments. We have been developing an in-browser modeling engine that infers segments without collecting any server-side data. Also as mentioned above a user could potentially be fingerprinted by the set of generated segments so they are limited/obfuscated. 3. The browser sends an ad request which is forwarded to various demand providers through our anonymizing proxy (and other services described below) which hides the IP and any other fingerprintable information from the provider. The response will return relevant ads based on the obfuscated set of segments the browser sent. The browser can then discard any ads that don't fit the real profile (fake segments are sent along with the real segments) and decide which ad(s) to display (subject to client-side user preferences). The response is similar to RTB and the browser may decide to show some, all or none of the ads on either the current page or some future page that is displayed before the "bids" expire. We do need to provide reporting data that takes the place of existing tracking pixels. Advertisers may have specific conversion goals or other metrics they want to analyze and that data is reported by the browser asynchronously using anonize. The current reporting system for micropayments is a good place to start because it's live in beta testing right now. The browser locally stores information necessary to give each site you visit a "score". That score is used to determine the relative distribution of your payment. The score translates into a probability that any given site will receive a "vote". For each vote the browser randomly selects a site based using the calculated probabilities. For each reporting period (one month) the browser gets 30 votes. 30 independent anonize "surveys" are created to collect those votes. The surveys cannot be connected and anonize allows us to ensure that there is only one vote per browser/survey without knowing which browser/user submitted the vote. What we end up with is essentially an anonymous sample of the data. This allows us to pay both big and small sites without a detailed browsing history. Here is the explanation from Rafeal: ``` Let X be the number of ``daily-rewards'' (of $5/30) that some site gets in a month. If we go for the $100 cut-off as discussed above (i.e., only sites that make more than $100 per month need to get a reliable payment), think of \mu = E[X] > 600. Let's assume that users are independent. The multiplicative chernoff bound then says that Pr [X < (1-eps) \mu ] < e^{-\eps^2 \mu/2}. So, if we set eps = 0.1, we get that except with probability e^{-1/200 * 600} = e^{-3} < 0.05, the webpage will get 90% of what it is supposed to get. (And webpages that are supposed to get $1000 will get at least 97% of that) ``` The reporting is done over randomized intervals and a very similar system will be used for ad reporting. You should be able to see a few issues here, one of which is that the submissions can potentially be linked by IP address. We don't log IP address, but you can't verify that so we are taking advantage of other services to hide the IP from ourselves. In the beta we're using a 3rd-party proxy service, but we'd like to split the messages across a variety of different channels which could include Tor, IM, etc.. The other issue is related to ads. When the ad is actually displayed by the browser the creative will come from the advertiser, not us (it would be cost prohibitive to proxy all the creatives). We block cookies, limit javascript, etc... as described above, but the advertiser will still see your IP address. At best this would allow an advertiser to infer a small amount of data based on the targeting criteria of the ad and link that to your IP address. That data could be added to any existing data the agency/advertiser has connected to your IP through other means (online purchases, logins, etc...). IPs are often shared and both IPs and targeting segments have varying lifetimes so the data leakage is minimal. A perfect system in this respect just isn't practical right now, but the current system is much, much worse. I think everyone understands that "free" content isn't free and we need some way to compensate publishers for their work, but that method shouldn't be the privacy nightmare that it is today. To a large extent we have to make this work within the limitations of the existing ad infrastructure and I think we've done a very good job of doing that while still providing very good privacy. Other ad blocking companies which shall remain nameless take large payments to whitelist ads. The whitelisting criteria focus almost entirely on presentation and are completely silent on the subject of tracking. We think we can do a lot better than that.

johnnagro commented

2016-11-15 14:54:04 +00:00

(Migrated from github.com)

@bridiver

TLDR:
I'm not opposed to Brave being listed provided it was done with a more accurate and transparent description of what it is. I don't think perfection should stand in the way of progress - assuming users understand the compromises and choices made for your cause. Keep in mind, some of the readers of these recommendations have much higher stakes involved than just removing annoying ads.

RTFM:
I appreciate that you guys are trying to take a swing at one of the fundamental tensions on the web today (advertising funding it all). You've clearly had to make compromises in order to try out this experiment (fair to say experiment?). I'm not one who believes perfection should stand in the way of progress however, I am big on transparency and personal choice. If you are to be listed, I would think that the description "browser with ad-blocking built in" would be disingenuous (through omission) - it is not in the spirit of what your team is trying to accomplish. Remember, this page is about more than just removing annoying ads. Some of the readers have much higher stakes than that.

At the end of the day, you are white-listing advertisers who serve their creative to your users directly while you take a cut. It is a little greyhat to call out your competitors for doing something similar. You are trying to sandbox that, i get it, but arguably so is chrome, firefox, etc and yet malware ads still seem to compromise them from time to time. Furthermore, to me it sounds like as long as there is a direct connection between the advertiser and the user they can (over time) profile people - despite your efforts to obfuscate that.

Maybe you'll work out all these issues. It sounds like there are a few opportunities for your organization to put your weight behind some important projects like tor or i2p. Just be careful with comments like "we're working on [the next tor]". They are dangerous to the ill-informed and the insincerity of it will piss-off the well-informed very quickly.

@bridiver `TLDR:` I'm not opposed to Brave being listed _provided_ it was done with a more accurate and transparent description of what it is. I don't think perfection should stand in the way of progress - assuming users understand the compromises and choices made for your cause. Keep in mind, some of the readers of these recommendations have much higher stakes involved than just removing annoying ads. `RTFM:` I appreciate that you guys are trying to take a swing at one of the fundamental tensions on the web today (advertising funding it all). You've clearly had to make compromises in order to try out this experiment (fair to say experiment?). I'm not one who believes perfection should stand in the way of progress however, I am big on transparency and personal choice. If you are to be listed, I would think that the description "browser with ad-blocking built in" would be disingenuous (through omission) - it is not in the spirit of what your team is trying to accomplish. Remember, this page is about more than just removing annoying ads. Some of the readers have much higher stakes than that. At the end of the day, you are white-listing advertisers who serve their creative to your users directly while you take a cut. It is a little greyhat to call out your competitors for doing something similar. You are trying to sandbox that, i get it, but arguably so is chrome, firefox, etc and yet malware ads still seem to compromise them from time to time. Furthermore, to me it sounds like as long as there is a direct connection between the advertiser and the user they can (over time) profile people - despite your efforts to obfuscate that. Maybe you'll work out all these issues. It sounds like there are a few opportunities for your organization to put your weight behind some important projects like tor or i2p. Just be careful with comments like ["we're working on [the next tor]"](https://twitter.com/bcrypt/status/798383317959602176). They are dangerous to the ill-informed and the insincerity of it will piss-off the well-informed very quickly.

bridiver commented

2016-11-15 17:10:21 +00:00

(Migrated from github.com)

A few final points:

Ads and micropayments are off by default and there is no requirement to turn them on. That does make Brave an ad blocking browser without any caveats and it is a user's choice to enable ads or payments
What we are doing is very different from our competitors in terms of "whitelisting". We are basically an ad network with high privacy standards and unlike our competitors those standards include tracking and they are enforced by the browser. No one can pay us to bypass them because the browser won't allow it. Brave ads do not disable or change ad blocking or tracking protection lists. In any case ads are not currently enabled in Brave at all. If you turn on Brave ads you will get placeholders that are not driven by any browser history. We have several ideas in the works to address malware, etc... through client-side signature verification, but the discussion is theoretical at this point and we can address it again when we have a PR to go along with it.
I agree with your point about compromises and as Brave usage grows we will be in a better position to dictate new standards that can further minimize or eliminate them. I think we have been very transparent and most if not all of this information has been publicly posted on our website and github for a long time. I think I was also quite clear about what we have today and the known issues vs what we plan to do in the near future (tor, etc...) and I'm only using it to point out the fact that we are aware of the issues and working on better ways to address them.

As you said it's progress and not perfection. I think micropayments are extremely good from a privacy perspective and will be essentially "perfect" imo when other IP anonymizing services are added to supplement the existing method. Ads are more difficult right now because of the delivery issue, but we are working on an integrated webtorrent client and a few other ideas that could potentially help address it.

On Nov 15, 2016, at 7:54 AM, John Nagro notifications@github.com wrote:

@bridiver

TLDR:
I'm not opposed to Brave being listed provided it was done with a more accurate and transparent description of what it is. I don't think perfection should stand in the way of progress - assuming users understand the compromises and choices made for your cause. Keep in mind, some of the readers of these recommendations have much higher stakes involved than just removing annoying ads.

RTFM:
I appreciate that you guys are trying to take a swing at one of the fundamental tensions on the web today (advertising funding it all). You've clearly had to make compromises in order to try out this experiment (fair to say experiment?). I'm not one who believes perfection should stand in the way of progress however, I am big on transparency and personal choice. If you are to be listed, I would think that the description "browser with ad-blocking built in" would be disingenuous (through omission). Remember, this page is about more than just removing annoying ads. Some of the readers have much higher stakes than that.

At the end of the day, you are white-listing advertisers who serve their creative to your users directly while you take a cut. It is a little greyhat to call out your competitors for doing something similar. You are trying to sandbox that, i get it, but arguably so is chrome, firefox, etc and yet malware ads still seem to compromise them from time to time. Furthermore, to me it sounds like as long as there is a direct connection between the advertiser and the user they can (over time) profile people - despite your efforts to obfuscate that.

Maybe you'll work out all these issues. It sounds like there are a few opportunities for your organization to put your weight behind some important projects like tor or i2p. Just be careful with comments like "we're working on [the next tor]". They are dangerous to the ill-informed and will piss-off the well-informed very quickly.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

A few final points: 1. Ads and micropayments are off by default and there is no requirement to turn them on. That does make Brave an ad blocking browser without any caveats and it is a user's choice to enable ads or payments 2. What we are doing is very different from our competitors in terms of "whitelisting". We are basically an ad network with high privacy standards and unlike our competitors those standards include tracking and they are enforced by the browser. No one can pay us to bypass them because the browser won't allow it. Brave ads do not disable or change ad blocking or tracking protection lists. In any case ads are not currently enabled in Brave at all. If you turn on Brave ads you will get placeholders that are not driven by any browser history. We have several ideas in the works to address malware, etc... through client-side signature verification, but the discussion is theoretical at this point and we can address it again when we have a PR to go along with it. 3. I agree with your point about compromises and as Brave usage grows we will be in a better position to dictate new standards that can further minimize or eliminate them. I think we have been very transparent and most if not all of this information has been publicly posted on our website and github for a long time. I think I was also quite clear about what we have today and the known issues vs what we plan to do in the near future (tor, etc...) and I'm only using it to point out the fact that we are aware of the issues and working on better ways to address them. As you said it's progress and not perfection. I think micropayments are extremely good from a privacy perspective and will be essentially "perfect" imo when other IP anonymizing services are added to supplement the existing method. Ads are more difficult right now because of the delivery issue, but we are working on an integrated webtorrent client and a few other ideas that could potentially help address it. > On Nov 15, 2016, at 7:54 AM, John Nagro notifications@github.com wrote: > > @bridiver > > TLDR: > I'm not opposed to Brave being listed provided it was done with a more accurate and transparent description of what it is. I don't think perfection should stand in the way of progress - assuming users understand the compromises and choices made for your cause. Keep in mind, some of the readers of these recommendations have much higher stakes involved than just removing annoying ads. > > RTFM: > I appreciate that you guys are trying to take a swing at one of the fundamental tensions on the web today (advertising funding it all). You've clearly had to make compromises in order to try out this experiment (fair to say experiment?). I'm not one who believes perfection should stand in the way of progress however, I am big on transparency and personal choice. If you are to be listed, I would think that the description "browser with ad-blocking built in" would be disingenuous (through omission). Remember, this page is about more than just removing annoying ads. Some of the readers have much higher stakes than that. > > At the end of the day, you are white-listing advertisers who serve their creative to your users directly while you take a cut. It is a little greyhat to call out your competitors for doing something similar. You are trying to sandbox that, i get it, but arguably so is chrome, firefox, etc and yet malware ads still seem to compromise them from time to time. Furthermore, to me it sounds like as long as there is a direct connection between the advertiser and the user they can (over time) profile people - despite your efforts to obfuscate that. > > Maybe you'll work out all these issues. It sounds like there are a few opportunities for your organization to put your weight behind some important projects like tor or i2p. Just be careful with comments like "we're working on [the next tor]". They are dangerous to the ill-informed and will piss-off the well-informed very quickly. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

privacytoolsIO commented

2016-12-02 03:40:14 +00:00

(Migrated from github.com)

Great discussion and good suggestion. Thanks

ghost commented

2016-12-02 16:48:09 +00:00

(Migrated from github.com)

I am not so sure about

we also have 0 plugins, so the navigator.plugins fingerprinting attack doesn't really work.

Having 0 plugins means no Flash? That is sacrificing usability.

I am not so sure about > we also have 0 plugins, so the navigator.plugins fingerprinting attack doesn't really work. Having 0 plugins means no Flash? That is sacrificing usability.

bridiver commented

2016-12-02 16:54:32 +00:00

(Migrated from github.com)

@Shifterovich we have flash support, but it is click-to-play and @diracdeltas can comment on whether or not that is exposed through navigator.plugins after clicking

PrivacyCDN commented

2016-12-02 18:22:02 +00:00

(Migrated from github.com)

Having no Flash may mean losing usability on some sites, but given the vulnerabilities of Flash (1213 CVE's and the increasing number of sites using HTML 5 instead of Flash - if for no other reason than to be usable on IOS - I'm not sure that I'd call it a sacrifice.

Having no Flash may mean losing usability on some sites, but given the vulnerabilities of Flash ([1213 CVE's](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Flash) and the increasing number of sites using HTML 5 instead of Flash - if for no other reason than to be usable on IOS - I'm not sure that I'd call it a sacrifice.

👍 1

ghost commented

2016-12-02 18:24:29 +00:00

(Migrated from github.com)

@PrivacyCDN Increasing number, but a lot still stick to Flash.

bridiver commented

2016-12-02 18:34:40 +00:00

(Migrated from github.com)

Safari has shipped without Flash installed for quite a while and Chrome is also trying to kill it. Brave doesn't ship with Flash, but you can install it and enable for click-to-play. Click-to-play mitigates some of the issues with Flash, but once you click all bets are off

ghost commented

2016-12-04 22:43:10 +00:00

(Migrated from github.com)

"Brave doesn't ship with Flash, but you can install it and enable for click-to-play."

Well Chrome does the same apart from the fact that it does ship with Flash - but it's not enabled by default.

"Brave doesn't ship with Flash, but you can install it and enable for click-to-play." [Well Chrome does the same apart from the fact that it **does** ship with Flash - but it's not enabled by default](https://docs.google.com/presentation/d/106_KLNJfwb9L-1hVVa4i29aw1YXUy9qFX-Ye4kvJj-4/present?ueb=true&slide=id.p).

bridiver commented

2016-12-04 22:46:01 +00:00

(Migrated from github.com)

@Shifterovich I'm not making any claims about Brave vs Chrome, I'm just clarifying that you can use Flash with Brave

ghost commented

2016-12-04 22:48:35 +00:00

(Migrated from github.com)

I used it as an example. Not shipping with Flash is sacrificed usability but isn't any more secure than Chrome's approach.

This repo is archived. You cannot comment on pull requests.

No reviewers