Open svewa opened 2 years ago
alexbosworth
commented
2 years ago Some ideas to improve things here:
--ignore-forwards-below can be used to disable forward reporting
GordianLN
commented
2 years ago This issue stems from a brief conversation in plebnet, and I substantially agree with it.
Telegram is extremely convenient, easily scriptable, ubiquitous, with an extensive API; it does allow for e2ee, but only when communication is phone <-> phone ("start secret chat"), there is no desktop nor bot API support, and in any case, even if that was possible, e2ee means you could only see the chat either on your phone, or on your desktop, not ubiquitously.
Obfuscating the data kind of defeats the purpose of having reports from your node, yet that would be the easiest, fastest way to implement.
Having an alternative platform to send the data through would be the best solution, and yet require either the adoption of another existing system, that I currently fail to guess which might be, or the development of a whole new messaging system, that will preferably allow for mobile and desktop interfaces, but is also decentralized. LN itself?
Maybe a web endpoint that gets checked periodically, and hosted on the node?
svewa
commented
2 years ago I rose the issue before on that telegram channel, but ultimately this here is the right place to discuss it, I figure.
Due to the long running nature of such a bot, I believe no amount of fuzzing or obfuscation will be sufficient, as long as meaningful information is provided.
So this might be a feature for those mobile apps that connect to your node (like zeus?) and regularly poll as @asvdf suggested, or use chat systems that are more privacy friendly in their nature.
alexbosworth
commented
2 years ago You could say that all the telegram channels themselves represent a way to connect people to their node relationships. If I have access to the telegram data I can look at who is in the telegram chat channel and say they probably have nodes with some connections to each other, especially if they are chatting etc
The premise of the issue though is in the long term. There is no fundamental reason why telegram needs to not offer e2e encryption and they may add it, or there may be other software that is written that people adopt, those kind of things are out of scope though of this project. The same goes for lots of data, if people upload their accounting data into Google spreadsheets or Turbo Tax etc, you have the same issue, so this is a broad problem
alexbosworth
commented
2 years ago Another way to approach this issue would be to create a documentation of potential OPSEC issues, like running nodes in the cloud where the cloud operator could potentially see all the traffic or get activity signals from network usage, looking up node or blockchain info on public explorers, not running over Tor, using clearnet or common VPN providers, etc
svewa
commented
2 years ago In your last 2 comments you talk about general OPSEC issues for node operators. I'm talking about bos offering the storage of precise forwarding data on a central location in clear text.
This is not about the OPSEC of the individual node operator. This is about the privacy of the lightning network as a whole.
If you look at tor: it is not logging anything of value. And if one wanted to log what packets he is forwarding for what circuit it would require real work, as tor project know if they would log it, it would be confiscated, end up on clouds, pastebins etc. You won't be able to stop people from putting their data into Google spreadsheets, and of course lightning operators have a valid desire for more information on their channels compared to tor relay operators and their forwards. But if this is a requirement, it should incentivized to be done in a way that is way more privacy friendly.
Of course it would be best if telegram decided to allow e2ee for bots, but this is out of control of this project.
alexbosworth
commented
2 years ago Privacy of the network as a whole is the sum of OPSEC of operators
The design of the reporting system in bos is designed to be abstract, that way people can create an alternative surface for the messages to be delivered. Once that is compelling enough to use I think people would switch, just like you say it is about making attractive options for people
svewa
commented
2 years ago There certainly is some overlap of individual OPSEC and privacy of the whole network. But publishing detailed forwarding information does not necessarily harm my personal security.
I believe it's wrong to just risk the privacy of the whole network right now, because it's comfortable and works. I think it's wrong of the node operator who actively uses it, most likely without even understanding the implications. And I think it's wrong to offer tools to just do that without even as much as warning. It's like offering a tor config variable to backup full logs with details on dropbox.
But I guess we are not agreeing on that as much as I thought after your first comment, and fear I can't add more on this issue for now.
alexbosworth
commented
2 years ago Yeah I agree more can be done, I don't think the solution is don't create software, rather I think the solution is improve the existing software and documentation so that people can make their own best choices
bos currently supports sending information about individual forwards to the node operator (or anyone as per config of the node/bos).
"💰 Forwarded [amount of sats] [incoming node] → [outgoing node]. Earned 0.00000000 0.00% (0)"
This is helpful and entertaining information for the individual node operator. But on a big scale, this hurts privacy as telegram chats by bots are never end-to-end encrypted. If enough users/nodes use this feature, information that can be used to follow each and every payment through the network is permanently stored on the systems of telegram, in clear text. If in the future telegram or any other party that has (illegitimate?) access to the data, past payments can be de-anonymized, possibly revealing the true sender and recipient node of payments.