Privacy by design -> not a user ? nothing sent to anyone
1000i100 opened this issue · comments
Perhaps it's already the behavor, if yes, add it to design goal could be great !
- not a user -> nothing sent to anyone
- not a supported site/webmaster -> nothing sent to anyone
Can you provide some context? What does this have to do with the Interledger protocol stack?
Sure :
I've read this document :
https://github.com/interledger/rfcs/blob/master/0028-web-monetization/0028-web-monetization.md#design-goals
And by reading the goal, it's not clear to me if privacy is thinked from protocol level or left to implementation choices.
For my level of understanding, the web-monetization protocol can work well with privacy, but if the site don't host itself the code to handle it, but use the one of the provider, it will send visitor at least statistic to the provider. If the protocol can forbid this, i see it as a good thing.
Hi @1000i100, it's still not exactly clear to me what you are inquiring, but since I have taken an interest in some of the privacy applications of Interledger, I will take a stab at answering... But it will almost certainly include privacy considerations beyond the scope of the web monetization API.
The Interledger protocol stack does not make any privacy guarantees, because it largely operates under free market principles in which you might opt-in to a KYC/AML sub-protocol, or perhaps in some cases, a privacy-enhancing sub-protocol -- both of which have not been formally discussed. For brevity, I will say that the web monetization protocol does not make any identity or privacy guarantees, and is likely out of scope.
Here is why you might run into some privacy issues, even if it was a design goal:
Ledger Layer Privacy
Since ILP performs transactions across different ledgers, it is somewhat unreasonable to assume any level of privacy unless you are using privacy-enhanced ledgers. Senders and receivers (or in this case; users, webmasters, and providers) can take additional measures to preserve privacy at various layers of the protocol stack. Since most fiat ledgers will require some KYC/AML compliance, receivers using those ledgers will likely track as much as they can with respect to senders.
Less stringent connectors might not require the same conditions, or perhaps charge a higher fee for privacy, perhaps due to regulatory concern and adequate demand. For example, privacy-enhanced ledgers such as Monero or Zcash still might require an identity sub-protocol with some connectors to maintain regulatory compliance. It might be technically feasible to implement a cross-currency mixer using ILP and then pipe it into the web monetization API, but I have yet to see a formal specification.
Connector Layer Privacy
At the connector layer, you could hypothetically break payments up across different routes and addresses, but this would likely result in higher on-ledger fees, so this might be sub-optimal. You could also incentivize others to "mix" across different assets by paying an additional fee, similarly to how CoinJoin works on the Bitcoin network, but there is a caveat: transaction obfuscation does not guarantee privacy either.
Application Layer Privacy
This is not legal advice, but if a webmaster or provider obtains sensitive information from a user, then they would certainly want to protect the data of their users, but transmitting sensitive information over ILP right now is generally inadvisable. If sensitive data is shared over ILP, then it should probably be done across private ledgers and a formally audited sub-protocol. For example, when sending sensitive medical information in the United States, you would probably use a private ledger and if any information was sent in an ILP sub-protocol, then it must be in compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Side note: users are guaranteed some security assurances, but they are still susceptible to the attempts of determined hackers equipped with nmap, wireshark, etc.
A user might register with a provider, but the provider sets the conditions for what information is to be collected, typically used as a way to provide the webmaster with enough information to issue an enhanced customer experience with its associated user. Proxy services could be created on top of the web monetization API for users who value privacy, but this might result in malformed user-tailored experiences. The user ultimately decides what information they consent to handing over to the provider. You can see an example of web monetization in action from @sharafian here.
In summary, all participants should only conduct a transaction over ILP according to the specific parameters in which they are comfortable with. If a webmaster requires additional information that a user and/or provider does not feel comfortable with sharing, then they should not (or cannot) perform transactions with one another. The webmaster should disclose what information needs to be collected in their terms and conditions. Otherwise, introducing specific privacy requirements within the web monetization API seems quite inflexible.
TL;DR: Don't do business with people who collect your data.
If you have any other privacy-related questions that are out of scope, might I suggest continuing the discussion on one of the gitter channels?
Thanks for explaining, @ekrenzke ! I just want to clarify/correct a few points in that explanation.
Ledger Layer Privacy
An important detail here is that ILP aggregates packets into on-ledger settlements. So just by looking at someone's ILP settlements even on a public ledger, you can't determine the amounts nor destinations of any ILP packet's they've sent. You could only see an aggregate amount and the ledger address of their direct peer.
Connector Layer Privacy
At the connector layer, you could hypothetically break payments up across different routes and addresses,
This would be tricky to do, because Interledger senders don't pick the route (Each connector just picks the next hop). You could, however, build something resembling a VPN on top of the Interledger network.
... but this would likely result in higher on-ledger fees,
Anything you do on ILP isn't going to be subject to ledger fees, because Interledger adjusts balances that live on a level above the ledger itself. Ledger fees are only going to occur when you actually talk to the ledger to settle your balance.
Application Layer Privacy
If sensitive data is shared over ILP, then it should probably be done across private ledgers
ILP packets don't go through actual ledgers, so the privacy of the data in the ILP packet is independent from the privacy of the ledgers used for settlement. Connectors could save data about the packets they process, but that's why the ILP packet data is always encrypted by a transport protocol like STREAM.
This is not legal advice, but if a webmaster or provider obtains sensitive information from a user, then they would certainly want to protect the data of their users, but transmitting sensitive information over ILP right now is generally inadvisable.
Transmitting private information between two parties on ILP is actually secure so long as you're using a protocol like STREAM. STREAM encrypts your data so that intermediate connectors can't read it. They can see the amount and destination address (ILP address, not on-ledger), but that's it.
A user might register with a provider, but the provider sets the conditions for what information is to be collected, typically used as a way to provide the webmaster with enough information to issue an enhanced customer experience with its associated user.
There's a limit to what the Web Monetization provider can collect. Right now it's just ILP packet contents (any encrypted data inside these packets cannot be read by the provider) and the URL origins on which the provider's Iframe is embedded to polyfill Web Monetization. The provider doesn't have to report or save these, though.
If you went to https://www.example.com/my_page/post_xyz?token=abcdefg and then sent 100 XRP drops as well as some data over ILP, your provider could at most see that you were on https://example.com and that you sent 100 drops.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.