5 ms·

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 pro

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
    Yeah, I noted blockchain issues in my latest (in time) reply. But at least you won't have IP addresses to worry about any longer :-P.
  - 18pfsmt 8y ago
    What if one were to run one of these "privacy-enhanced blockchain"s from a VPS (paid for with these same anonymized tokens)? In case it's not clear, I'm earnestly asking this question
    - ohmygodel 8y ago
      That's basically using a proxy, and so it has the same security. If the proxy is/geos bad (say, your VPS provider reveals your IP to some interested guys with guns), then you lose (anonymity). If your proxy remains good, then all that can be learned is the transactions originated at the proxy. However, the proxy does serve as a potential pseudonym, and so if the collection of transactions reveals something identifying, even if any one transaction doesn't, then you lose.
ohmygodel 8y ago
> Please read up on GDPR "purpose limitation". I am reasonably familiar with the contents of GDPR, having looked into it more after attending a lecture on the subject [0]. > 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. If your users must rely on you obeying a policy, then please just say that. Right now, it seems to me that you claim to use technical means to prevent Brave from learning browsing histories [1]. > my home AT&T IP address wanders often, so do many others; mobile even more variable. IP addresses can be so identifying that they have been ruled as personally-identifiable information by the European Court of Justice [2]. > I think you are mistrusting prematurely. But 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. Thank you for stating clearly that you aren't using PIA (aka "IP masking") at the moment for Brave Payments. You might consider your users who are worried about data breaches and compromised servers as much as they are worried about Brave's intentions. Please don't take my criticisms personally. > Putting these through separate Tor circuits is possible, as we also randomly space them out in time. Oh, you do randomly delay ballot submissions? I have not been able to find any such logic in the code but would be happy to be pointed to it. The specific way in which you choose delays is, of course, crucial to it providing security. [0] <https://petsymposium.org/2018/program.php> https://petsymposium.org/2018/program.php> [1] <https://brave.com/faq-payments/#anonymous-contributions> https://brave.com/faq-payments/#anonymous-contributions> [2] <https://www.irishtimes.com/business/technology/european-cour.. https://www.irishtimes.com/business/technology/european-cour....
- BrendanEich 8y ago
  > If your users must rely on you obeying a policy, then please just say that. I did just say that, several times -- but with conditions that do not make it a matter of "policy" only. We agree IP address should be masked for self-funded users. Working on it! We are very familiar with how any user log can be used as a history, but anonized proofs that can't link to a user id except illegally to IP address are not on the same level of threat as the Blendle, Flattrplus, etc. histories taken in the clear -- never mind Google et al. surveillance. To equate the tech and not make any distinctions does a disservice to us in my view. I'm not sure you did equate, but see next paragraph. Tech alone is never enough for anything like what we are doing. Addresses matter, if not IP then on blockchain. There are side channels. There will be bugs. IMHO you have to include the social and legal constraints, too. Even a p2p with ZKP solution has some risk due to the blockchain addresses, which need purpose-limited terms under GDPR too. On road, will get you links to code for randomizing time between ANONIZE sessions as soon as I can.

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
  Yeah, I noted blockchain issues in my latest (in time) reply. But at least you won't have IP addresses to worry about any longer :-P.
- 18pfsmt 8y ago
  What if one were to run one of these "privacy-enhanced blockchain"s from a VPS (paid for with these same anonymized tokens)? In case it's not clear, I'm earnestly asking this question
  - ohmygodel 8y ago
    That's basically using a proxy, and so it has the same security. If the proxy is/geos bad (say, your VPS provider reveals your IP to some interested guys with guns), then you lose (anonymity). If your proxy remains good, then all that can be learned is the transactions originated at the proxy. However, the proxy does serve as a potential pseudonym, and so if the collection of transactions reveals something identifying, even if any one transaction doesn't, then you lose.

ohmygodel 8y ago

> Please read up on GDPR "purpose limitation". I am reasonably familiar with the contents of GDPR, having looked into it more after attending a lecture on the subject [0]. > 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. If your users must rely on you obeying a policy, then please just say that. Right now, it seems to me that you claim to use technical means to prevent Brave from learning browsing histories [1]. > my home AT&T IP address wanders often, so do many others; mobile even more variable. IP addresses can be so identifying that they have been ruled as personally-identifiable information by the European Court of Justice [2]. > I think you are mistrusting prematurely. But 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. Thank you for stating clearly that you aren't using PIA (aka "IP masking") at the moment for Brave Payments. You might consider your users who are worried about data breaches and compromised servers as much as they are worried about Brave's intentions. Please don't take my criticisms personally. > Putting these through separate Tor circuits is possible, as we also randomly space them out in time. Oh, you do randomly delay ballot submissions? I have not been able to find any such logic in the code but would be happy to be pointed to it. The specific way in which you choose delays is, of course, crucial to it providing security. [0] <https://petsymposium.org/2018/program.php> https://petsymposium.org/2018/program.php> [1] <https://brave.com/faq-payments/#anonymous-contributions> https://brave.com/faq-payments/#anonymous-contributions> [2] <https://www.irishtimes.com/business/technology/european-cour.. https://www.irishtimes.com/business/technology/european-cour....

BrendanEich 8y ago
> If your users must rely on you obeying a policy, then please just say that. I did just say that, several times -- but with conditions that do not make it a matter of "policy" only. We agree IP address should be masked for self-funded users. Working on it! We are very familiar with how any user log can be used as a history, but anonized proofs that can't link to a user id except illegally to IP address are not on the same level of threat as the Blendle, Flattrplus, etc. histories taken in the clear -- never mind Google et al. surveillance. To equate the tech and not make any distinctions does a disservice to us in my view. I'm not sure you did equate, but see next paragraph. Tech alone is never enough for anything like what we are doing. Addresses matter, if not IP then on blockchain. There are side channels. There will be bugs. IMHO you have to include the social and legal constraints, too. Even a p2p with ZKP solution has some risk due to the blockchain addresses, which need purpose-limited terms under GDPR too. On road, will get you links to code for randomizing time between ANONIZE sessions as soon as I can.