The problem with these tools is that they're extremely complicated to set up and use. Grandma wants a phone number, not a v3 Tor Onion Service address.
I'm interested in usable E2EE messaging apps -- that's what I compared Converso to. Whatever this is (I will read the docs some day) is in another realm.
Definitely - adding contacts in TFC is an unreasonable burden, cannot copy paste addresses into the source machine, 56-character tor addresses have to be typed in manually, followed by the recipients' public key.
> This is basically an indirect validation that most non listed messaging apps supposedly offering e2e encryption such as Whatsapp or Signal have backdoors with access from any government asking for access.
More likely: the government doesn't want to cause 'too much' discomfort among ordinary citizens. The decision to not block popular apps such as WhatsApp is probably purely political.
> the government doesn't want to cause 'too much' discomfort among ordinary citizens
This! I've yet to meet an Indian who doesn't have WhatsApp and we all know that pretty much every Indian with a phone uses it. We're not talking about a little discomfort, we're talking a lot. There's almost half a billion users. Government can't bad WhatsApp without a major freakout, so they're going after small players. It wasn't long ago that even Signal AND WhatsApp were pushing back against these laws and what resulted is more Signal downloads (tens of millions of users in India)
National security trumps "discomfort to citizens" every time ... otherwise all of us would have revolted by now for wasting hours in airport because of the security checks.
> When did you last see offline protests against airport security theater?
Isn't that what I am saying too? We accept the huge discomfort because we feel it is important and in our national interest! However important WhatsApp is, it is just a platform. If it is killed by a ban, people will just migrate to another platform and that's a lot more easier to do than give up on the benefits of flying by air. The only reason WhatsApp is allowed to function is because they are willing to provide a backdoor to the indian government - and that's easy to do when all the communication goes through their server and they handle the keys.
Yes. It is said the Colonial British used to say The sun never sets in the British Empire.
In today's context with WhatsApp, The sun never rises without a billion GOOD MORNING messages and another billion GOOD MORNING TO YOU TOO replies on WhatsApp in India /s
I am an indian who doesn't use WhatsApp or Facebook. It has never inconvenienced me - only WhatsApp users are inconvenienced when I ask them to SMS or email me. If the government bans WhatsApp today, most indians will simply switch to RCS or other platforms.
This appears to be a description of a theoretical attack to cause a specific target networked Bitcoin node to consume quite a bit of bandwidth by returning blockchain data to the attacker. It doesn't seem like this would have any effect on the Bitcoin network at large, however. While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".
>While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".
it meets all of the criteria to be called, bluntly, a remote financial attack/exploit that much of the network is vulnerable to
You can connect to basically any normal web server/service and waste their bandwidth/resources in the same way by downloading data they provide publicly.
If you think this is a real vulnerability I'd suggest you report it to any project like that, a proof of concept exploit would basically involve curl in a while loop with the output going to /dev/null.
that's actually not correct. apples and oranges. we're talking about mining rigs - not websites and apps maintained by sysadmins who can apply a simple fix or waf during an upstream overage attack. if this was a non-issue they wouldn't be patching it https://github.com/dogecoin/dogecoin/issues/3243
> that's actually not correct. apples and oranges. we're talking about mining rigs - not websites and apps maintained by sysadmins who can apply a simple fix or waf during an upstream overage attack.
Bitcoin mining rigs don't even use bitcoin p2p protocol themselves, they typically use stratum protocol(https://braiins.com/stratum-v1/docs) and don't accept incoming connections from the public internet generally. They usually connect to mining pool servers which have long had various forms of ddos attack mitigation systems in place.
They added an integrated basic bandwidth limiter from the looks of it, one can do something like that using external tools already. Hardly a real vulnerability.
it's an issue. it shouldn't be possible to pull a range of 2000 block headers in an unthrottled way from a remote bitcoin node. while you make some valid points - i find it humorous that you have tasked yourself with defining what constitutes a security vulnerability. furthermore - you may want to examine https://bitnodes.io/nodes/ and come to a realistic figure of how many machines running bitcoind aren't accepting tcp/8333 from 0.0.0.0
> while you make some valid points - i find it humorous that you have tasked yourself with defining what constitutes a security vulnerability.
Pretty much every internet connected service can be attacked with various forms of volumetric denial of service attacks, there are many mitigation measures available, you've implemented the bitcoin p2p protocol attack equivalent of curl in a while loop, that's not really something one would typically consider to be a real vulnerability.
> furthermore - you may want to examine https://bitnodes.io/nodes/ and come to a realistic figure of how many machines running bitcoind aren't accepting tcp/8333 from 0.0.0.0
First of all it's trivial to create fake nodes that show up on sites like that so I wouldn't really trust the numbers there, also it's easy for bitcoin users to add more real nodes if/when needed due to an attack, similar to how one can add more cloud application servers when there is a load increase or ddos attack on a web service the bitcoin network can add nodes if/when there is a need to mitigate these types of attacks.
> if this was a non-issue they wouldn't be patching it
As far as I can tell, nobody is claiming it's a 'non-issue'. Rather, it's a minor issue with an impact that is greatly exaggerated or sensationalised by the person reporting it.
you seem to be mixing up that mining pools expose tcp/8333 and if one pool's full node is attacked - many miners are caught in the crossfire unless in some type of special firewalled whitelist.
> you seem to be mixing up that mining pools expose tcp/8333 and if one pool's full node is attacked - many miners are caught in the crossfire unless in some type of special firewalled whitelist.
Mining pools don't typically expose tcp/8333 in a way that makes it easy for them to be targeted and when they do they typically have redundant nodes and other mitigation measures in place to ensure reliability.
There have additionally been high speed optimized block relay networks used in the past by mining pools, although I don't think they are used anymore due to the public p2p network being much faster and more reliable than in the past due to various protocol improvements.
https://crnkovic.dev/testing-converso/