5 ms·

I understand that Anonize is used for anonymous ballots. I understand that Brave used to submit its ballots via a single-hop proxy. My understanding is now that

I understand that Anonize is used for anonymous ballots. I understand that Brave used to submit its ballots via a single-hop proxy. My understanding is now that Brave no longer uses this proxy, which wasn't a good solution anyway because the proxy sees the user's entire set of ballots (aka browsing history). Thus Brave is now given all the ballots directly from the user, and thereby learns the user's browsing history. I do agree that other browsers and services also track users around the Web. Eliminating that is a goal that I support and that I think Brave does as well. I think that it is failing to achieve that goal. Either you don't realize the technical reality of your solution, or you are being misleading.

BrendanEich 8y ago
No, we do not see any user id. IP address we do see for any “tokens sent to user wallet” cases, for antifraud and per terms & privacy policy, but that is not a useful id and (more important) we do not use it for other purposes per GDPR. See GDPR’s “purpose limitation”. We would face 4% of global revenue fine if we violated this, and we are holding FB, G, and others to same standard. For IP masking in the case where you buy your own tokens, we have two options: 1/ relaying at IP level where we would not see your IP address and the partner would not see any encrypted payloads; 2/ Tor, which is already integrated. More to do but you led with “we see user history” and that is just false in all these cases. We do not see history of sites visited or supported on a linkable to user basis.
- ohmygodel 8y ago
  An IP address is an identifier. If it weren't, there would be much less reason to use a VPN or Tor. Suppose I understand you correctly and you do see the network IPs and timestamps of submitted tokens and ballots. Is your argument then that you can be trusted to follow your privacy policy? If we rely on trusting you to follow policy, then why not get rid of your zero knowledge proofs entirely? By saying that you "have two options", it sounds like you are saying that there are two mitigations for the privacy problem that you could use but do not yet. (1) is the one-hop proxy, which used to be used in the form of Private Internet Access service, but it seems like it is not currently being used by Brave. If you did use such a service and encrypted the publisher identities under Brave's public key, then that would be a improvement, although still not really private because Brave would receive the results in a batch from Private Internet Access. Browsing histories are essentially fingerprints for each user. The ten sites I visit each week are almost certainly not shared by any other Brave user on the planet, and moreover they are frequently identifiable (consider sites for individuals, companies, sports leagues, scohols, etc.). From [0]: "Our results show that for a majority of users (69 %), the browsing history is unique and that users for whom we could detect at least four visited websites were uniquely identified by their histories in 97 % of cases." (2) has the same batching problem as (1). It would be superior, though, because it would be harder for Brave and the proxy system to collude or (more likely) be forced to cooperate with some authority. To handle the batching problem, you should at least choose to upload each Anonize ballot at a uniformly random time in each month and on a separate connection (i.e. TCP connection or Tor circuit). You should also explain how this works in a technical document to give people the ability to understand what exactly they are signing up for when they enable payments in Brave. Ideally you would use a cryptographic protocol more suited to strong anonymity than a proxy network, such as a verifiable mix network or a secure-multiparty-computation protocol. [0] Olejnik et al., "On the uniqueness of Web browsing history patterns", 2014, <https://link.springer.com/article/10.1007/s12243-013-0392-5> https://link.springer.com/article/10.1007/s12243-013-0392-5>
  - BrendanEich 8y ago
    Please read up on GDPR "purpose limitation". We cannot use IP address except for antifraud, so it is not legally viable for us to try to link zero-knowledge proofs into a profile based on IP address. Also, my home AT&T IP address wanders often, so do many others; mobile is even more variable. But my main point here is purpose-limitation where we take IP address for antifraud. Which we must do, or our user growth pool would be quickly taken by fraudsters. As we are all open source and will get annual audits when scaled beyond trials, I think you are mistrusting prematurely. On linkability for users who buy their own BAT and so do not require the antifraud terms: as noted in my item 1, we are talking to PIA about using an IP relay (not full VPN). This got delayed by their work on handshake.org but we're restarting it. Tor (item 2) is better and batching is not an issue. We do not make cross-site/channel linkable batches in any event. Each ANONIZE session paying a given domain or YouTube/Twitch account is separate from every other. Putting these through separate Tor circuits is possible, as we also randomly space them out in time. I don't know why you are telling us to do things we already do. Did you find a bug in the open source? We pay bounties.
    - BrendanEich 8y ago
      Separate thing, not promising it on a schedule yet so really FWIW: our BAT roadmap's "Apollo" phase aspires to decentralize as much as possible. This could certainly include p2p flows with ZKPs in state channels or better. We are looking at OMG's Plasma implementation. So the ultimate goal is to get away from ANONIZEd traffic to a blind accounting server. But as I say, lots of problems to solve before promising this. Yet with Ethereum scaling and anonymity support, for users who buy their own BAT (where I claim your objection to IP address has most merit), we could go p2p on-chain for decentralization w/o fraud risk for bring-your-own-BAT users.
      - ohmygodel 8y ago
        Interesting, but decentralization does not equal privacy. Indeed, it might make privacy worse by sharing the data more widely and making it even easier to get copies of the data. Consider, for example, BitTorrent, which has a pretty decentralized distribution protocol that also makes it easier for third parties like the MPAA to observe who is sending and receiving the files. Even using a privacy-enhanced blockchain isn't necessarily sufficient. Blockchains do not provide anonymous messaging. Therefore, a recipient R of a transaction can identify the sender S if R can observe S sending the transaction. Yes, this problem affects Bolt, Zcash, Monero, etc.

BrendanEich 8y ago

No, we do not see any user id. IP address we do see for any “tokens sent to user wallet” cases, for antifraud and per terms & privacy policy, but that is not a useful id and (more important) we do not use it for other purposes per GDPR. See GDPR’s “purpose limitation”. We would face 4% of global revenue fine if we violated this, and we are holding FB, G, and others to same standard. For IP masking in the case where you buy your own tokens, we have two options: 1/ relaying at IP level where we would not see your IP address and the partner would not see any encrypted payloads; 2/ Tor, which is already integrated. More to do but you led with “we see user history” and that is just false in all these cases. We do not see history of sites visited or supported on a linkable to user basis.

ohmygodel 8y ago
An IP address is an identifier. If it weren't, there would be much less reason to use a VPN or Tor. Suppose I understand you correctly and you do see the network IPs and timestamps of submitted tokens and ballots. Is your argument then that you can be trusted to follow your privacy policy? If we rely on trusting you to follow policy, then why not get rid of your zero knowledge proofs entirely? By saying that you "have two options", it sounds like you are saying that there are two mitigations for the privacy problem that you could use but do not yet. (1) is the one-hop proxy, which used to be used in the form of Private Internet Access service, but it seems like it is not currently being used by Brave. If you did use such a service and encrypted the publisher identities under Brave's public key, then that would be a improvement, although still not really private because Brave would receive the results in a batch from Private Internet Access. Browsing histories are essentially fingerprints for each user. The ten sites I visit each week are almost certainly not shared by any other Brave user on the planet, and moreover they are frequently identifiable (consider sites for individuals, companies, sports leagues, scohols, etc.). From [0]: "Our results show that for a majority of users (69 %), the browsing history is unique and that users for whom we could detect at least four visited websites were uniquely identified by their histories in 97 % of cases." (2) has the same batching problem as (1). It would be superior, though, because it would be harder for Brave and the proxy system to collude or (more likely) be forced to cooperate with some authority. To handle the batching problem, you should at least choose to upload each Anonize ballot at a uniformly random time in each month and on a separate connection (i.e. TCP connection or Tor circuit). You should also explain how this works in a technical document to give people the ability to understand what exactly they are signing up for when they enable payments in Brave. Ideally you would use a cryptographic protocol more suited to strong anonymity than a proxy network, such as a verifiable mix network or a secure-multiparty-computation protocol. [0] Olejnik et al., "On the uniqueness of Web browsing history patterns", 2014, <https://link.springer.com/article/10.1007/s12243-013-0392-5> https://link.springer.com/article/10.1007/s12243-013-0392-5>
- BrendanEich 8y ago
  Please read up on GDPR "purpose limitation". We cannot use IP address except for antifraud, so it is not legally viable for us to try to link zero-knowledge proofs into a profile based on IP address. Also, my home AT&T IP address wanders often, so do many others; mobile is even more variable. But my main point here is purpose-limitation where we take IP address for antifraud. Which we must do, or our user growth pool would be quickly taken by fraudsters. As we are all open source and will get annual audits when scaled beyond trials, I think you are mistrusting prematurely. On linkability for users who buy their own BAT and so do not require the antifraud terms: as noted in my item 1, we are talking to PIA about using an IP relay (not full VPN). This got delayed by their work on handshake.org but we're restarting it. Tor (item 2) is better and batching is not an issue. We do not make cross-site/channel linkable batches in any event. Each ANONIZE session paying a given domain or YouTube/Twitch account is separate from every other. Putting these through separate Tor circuits is possible, as we also randomly space them out in time. I don't know why you are telling us to do things we already do. Did you find a bug in the open source? We pay bounties.
  - BrendanEich 8y ago
    Separate thing, not promising it on a schedule yet so really FWIW: our BAT roadmap's "Apollo" phase aspires to decentralize as much as possible. This could certainly include p2p flows with ZKPs in state channels or better. We are looking at OMG's Plasma implementation. So the ultimate goal is to get away from ANONIZEd traffic to a blind accounting server. But as I say, lots of problems to solve before promising this. Yet with Ethereum scaling and anonymity support, for users who buy their own BAT (where I claim your objection to IP address has most merit), we could go p2p on-chain for decentralization w/o fraud risk for bring-your-own-BAT users.
    - ohmygodel 8y ago
      Interesting, but decentralization does not equal privacy. Indeed, it might make privacy worse by sharing the data more widely and making it even easier to get copies of the data. Consider, for example, BitTorrent, which has a pretty decentralized distribution protocol that also makes it easier for third parties like the MPAA to observe who is sending and receiving the files. Even using a privacy-enhanced blockchain isn't necessarily sufficient. Blockchains do not provide anonymous messaging. Therefore, a recipient R of a transaction can identify the sender S if R can observe S sending the transaction. Yes, this problem affects Bolt, Zcash, Monero, etc.