Veilid: A secure peer-to-peer network for apps that flips off the surveillance economy Infosec super-band the Cult of the Dead Cow has released Veilid (pronounced vay-lid), an open source project applications can use to connect up clients and transfer information in a peer-to-peer decentralized manner. The idea being here that apps – mobile, desktop, web, and headless – can find and talk to each other across the …
So is posting someone a 3.5 inch floppy
I remember (in my first IT job) getting a bunch of 5.25 inch floppies with some hardware drivers on (network stuff I seem to remember). We only had one or two PCs with that size drive (most of ours were 3.5" PS/2's so we had to copy the drivers over to fresh floppies.
The supplied floppies also had the Form.A virus. Which was fun - as the concept of an anti-virus was largely not registered at that point. Fortunately, I seem to remember that it couldn't successfully infect the hard drives so just discarding the infected floppies (and any others that had been infected) cured the infection. And delayed the hardware rollout by several weeks until we could get the drivers on clean floppies.
The supplier got called into the IT directors office and got given a thorough reaming and left, promising a big discount on our next order.
It depends what you're referring to. If you meant the initial infection, the way that some attackers use IPFS, it doesn't sound like it. They use IPFS because there are still public relays that allow an HTTP client to access files on IPFS. The decentralization there is an asset because it makes deleting their payload harder, and the relay allows someone to download the file without having to do any setup. This protocol, on the other hand, doesn't appear to have any bridge system set up, nor does it implement a single application. Therefore, for a user to get a file, they'll have to set up a client of some sort to connect to the protocol and then open communication with something. That's friction, and attackers try to have the least friction possible when getting the initial connection.
If, instead, you meant for existing malware to contact command and control infrastructure, you may be more correct. However, there's not a lot that can be done about that. Malware writers have been using the internet for payload delivery in lots of ways that hide the traffic from inspection, and although I'm certain some will use this protocol, it won't be the first encrypted network that they've used for that purpose, often created from their own infected nodes.
I for one would love to see Veilid built into every app that would benefit from it. Unfortunately as a Signal user I have a hard time persuading anyone else to use Signal (basically only my geekier friends are interested) instead of Messenger, WhatsApp etc, so the Cult has its work cut out...
Good luck to them, genuinely!
It's not that people don't want the privacy of Signal, it's just that *everyone* has THEIR method of digital communication and genuinely expects everyone else to join in for their convenience.
Just connected with someone this past weekend who wanted to communicate via Google Meet. And I HATE Google. So Signal, Telegram, Skype, WhatsApp, Facebook, Instagram, Meet, Zoom, iMessage...I'm sick of everyone having *their* choice and then expecting me to go out of my way to join their preferred supplier just to be able to talk to them.
Pick up the damn phone and call me, OK?
>Pick up the damn phone and call me, OK?
See icon.
This is where governments have been somewhat disappointing. Governments used to set standards, pretty soon after a new tech thing came into existence (e.g. telephony, AC power grids, radio broad casting, TV, etc). The disinterestedness shown by governments wrt tech has allowed enormous walled gardens to develop, and a mis-mash of competing applications persisting long past the time when the functionality is pretty much settled. We all knew what IM looked like, back when BlackBerry Messenger was all the rage. Mandating a standard such functionality (not BBM itself) as a license condition for network operation should have happened years ago, just like a network operator is supposed to support phone calls...
I know this is what Google want with RCS, and maybe that should be the answer. But, "nothing" is not a useful answer.
"We all knew what IM looked like, back when BlackBerry Messenger was all the rage. Mandating a standard such functionality (not BBM itself) as a license condition for network operation should have happened years ago, just like a network operator is supposed to support phone calls..."
I disagree. It makes sense for a phone network operator because they will be given a lot of limited resources, whether that's a monopoly on providing service to the public (the wired model) or a large chunk of spectrum which only has room for a few companies (wireless). On the internet, there is no real limit and no central authority giving anything away. The great part of the internet is that I can put whatever bytes I want through it and expect them to arrive, so I don't need to apply for my protocol to be accepted before it can be used. I don't agree with a mandated standard for that reason, but there is another reason for it: feature support.
We've had IM for quite a long time, and it generally works the same, but it lacked many features we have today. For example, encryption. A lot of people want end-to-end encryption, and any attempt to create a single standard encrypted protocol would end up having to specify a key management system, which is likely to prove fragile. Meanwhile, multiple encrypted IM systems can figure out their own key management, and we can pick between the models as is useful. Even outside of encryption, there are other features that people might want, or want to avoid, in their IM. Is IM just for text, or can you send images as well? If you can send images, can you send files? Do the files go somewhere or are they streamed directly across? Does it come with video or audio communication? Should the identifiers be phone numbers, email addresses, some new address format, or a combination thereof? Is there a part of the structure which allows for per-message billing, and what data collection is needed to facilitate it? Is there a distinction between intra-country and international communication? What if Canada adopted one standard and Germany adopted another, but someone wants to communicate between countries? I prefer letting the users pick between options for one that supports the features they want and is convenient for their use.
I think you're missing the point. Whereas the telephony industry has been highly successful in ensuring that any telephone can call / SMS any other telephone, anywhere on the planet, the Internet industry has been infected by greed, self promotion, and the inevitable lack of interoperability. You do agree with mandated standards - you depend on them entirely, just to be able to make posts here (for example).
The purpose of standards bodies like the ITU is to control and own standards on behalf of all nations and companies. Thus if the ITU or 3GPP (or whatever) said, "6G has <insert list of IM features>", then by treaty agreement all countries will agree with that, and industry has a clear direction as to what to implement. It already does this, on a limited basis: SMS is the original IM technology. The fact that we've not been able to move on from SMS/MMS is because the companies that do this say there's (presently) no point having the costs of implementing a richer IM layer as part of the next mobile G, because the large tech companies have fragmented the market and locked people in.
End to End Encryption
BTW, end-to-end encryption is at the moment something of a sham. The argument in favour of it is that the service provider cannot get access to your messages, and nor can anyone else.
Thing is, the service provider controls the software you're running. You don't. You are implicitly and totally trusting them not to push out an update that does give them access to your messages. If Mark Zuckerberg wanted to read all of WhatsApp tomorrow, he could push out an update making it so, et voila. No one would be the wiser, because the application code is closed-source; it would take some time to see the extra network traffic generated by the modified WhatsApp client as being "data egress".
The other problem is that the only reason why a third party is unable to modify the client software for (say) WhatsApp is because Facebook guards its signing keys and dev login credentials. As we've seen several times - notably Microsoft in the recent past - guarded signing keys and login credentials is something of a weak control. Facebook are just as vulnerable as anyone else. If someone can use stolen keys to see inside MS's ecosystem, someone else can use stolen keys to alter WhatsApp's source code.
So at best E2EE as it exists today, with single companies both defining implementing it whilst also being completely opaque about how they do it gives only a very limited guarantee of privacy. The real value of it is to the service providers; it keeps the walled garden walls intact; no one else can implement an independent client and nick whatever ad revenue can be gleaned from running the service.
The benefit of a mandated standard is that 1) the standard is reviewable and transparent, and 2) there can be multiple different implementations, interoperating. If the standard gave E2EE, you might be wary of a phone built in China that implements it but be a lot more trusting of one built in, say, Europe. You could even build your own. And, because there could be numerous independent implementations, it'd be a whole lot more difficult for anyone minded to attack such a thing.
On the flipside, did we not end up here BECAUSE SMS was standardised and didn't move quickly enough, allowing these new service providers get in ahead of them. The telcos built the networks so knew what was coming. RCS initiative was started in 2007 and took until 2016 (!) to release Universal Profile. A decade is a lifetime in this industry and opened the doors for the great new services to be released. They could have easily been started before that, but instead GSMA/Telcos were milking their SMS cash cow. So classic Disruption Theory occurred and they couldn't pivot to the new services.
On the flipside, I also believe we're still in the early days of the messaging world: Snap didn't exist 11 years ago and it's disappearing messages, or any possible new messaging formats that come from VR/AR devices. Sure, lets standardise - but not until we've found out the range of possible messaging options that can be done. Personally, it's an annoyance that some people message me on one service where I'd prefer to live on Service XYZ. But I also know, they all bring unique tricks/benefits/ideas and am happy to experiment and see the various solutions on offer.
I still disagree with basically all of your points.
"Whereas the telephony industry has been highly successful in ensuring that any telephone can call / SMS any other telephone, anywhere on the planet, the Internet industry has been infected by greed, self promotion, and the inevitable lack of interoperability."
From my point of view, the internet industry allows me to contact any computer that agrees to take my connection and transmit to them, and if we agreed on what protocol we're using, we can communicate just fine. Yes, there isn't one single protocol that communicates with anybody, but I can, in fact, use any of the options equally well or I can build my own and it will work too. The internet industry needs interoperability between the links that allow my packets to flow, and they have it. This is why I can have a video call between me and people on two other continents, encrypted, through my own server, and I don't have to pay the prices I'm still charged if I were to make a single voice call to one of those people using the phone system which has its one standard and is much more greedy.
"You do agree with mandated standards - you depend on them entirely, just to be able to make posts here (for example)."
Not really. I use a lot of standards, but not mandated ones. I use the WiFi standards because it's convenient, but if I had implemented my own point-to-point wireless protocol, it would also work. I use the Ethernet standard because that's the ubiquitous cable, not because someone told me that other cables were forbidden. As for TCP, UDP, DNS, and HTTP, all of those are standards which are optional and maintained by people who make them available, not demanded. Should I decide to implement my own network protocol over the basic IP level (also not mandated, but it's what my ISP supports), I am free to do so, you are free to use it, and if we do, we can talk to one another over it.
"The fact that we've not been able to move on from SMS/MMS is because the companies that do this say there's (presently) no point having the costs of implementing a richer IM layer as part of the next mobile G, because the large tech companies have fragmented the market and locked people in."
I agree with them for a different reason. It's not worth adding another version because we now have network communication, so we don't need them. There are advantages to a communication system that's not tied to phones, so you could send a message from a computer that doesn't have to hand the communication part on to a phone. If I want to send you an SMS, I have to use one of the weird email-to-SMS bridges that some providers probably still have, and if you want to reply, there's a chance that the bridge doesn't go the other way. If I want to send you an email or use one of the many other chat systems that are generic, I can do it from anything with a data connection.
Oh, and on the encryption front, you're correct about the provider having the ability to damage the software you're running, which is one reason I don't use WhatsApp even though it is encrypted. Using open source software and/or decentralized clients helps with this. I have the knowledge to check that, as I'm sure you do as well. Dismissing it based on that risk isn't very convincing when the alternative is no encryption or really any security at all.
*iMessage...I'm sick of everyone having *their* choice and then expecting me to go out of my way to join their preferred supplier just to be able to talk to them."
I know what you mean, but it was always that way. CompuServe / AOL (before they merged) messengers, ICQ, Yahoo, MSN, NetMeeting and God knows how many more. Remember the squabbles between AOL and Microsoft when they tried to make MSN talk to AIM? I used to see PCs with several messengers running all the time.
Such is the nature of competition, I'm afraid. Of course, if we don't like the preferred supplier, we don't have to trouble ourselves with it - our contact can use our preferred means of communication, such as picking up the phone, or bugger off. Or they can send us a good old fashioned txt.
Unfortunately, I'm as guilty of this as anyone. I have WhatsApp on my phone, not because I like it, but because that's what the people I need to talk to use. Such is life.
I know what you mean, but it was always that way
it doesn't have to be that way. Look at USB cables and chargers: IF an unsuspected organisation said that an IM messaging protocol has to follow this and that rule, then an interoperable IM service spanning multiple vendors would exist.
Instead of this, we have multiple seemingly identical IM services from private vendors that are in effect non-interoperable, with said vendors finding excuses why they all need those non-interoperable IM services. So we have private giga-companies that make money from quasi-monopolistic organisation, claiming they can't make a public interoperable standard : they would say that, wouldn't-they ? Why do politicians let them get away with that? What is the benefit for the users of a messaging app that can't exchange messages with another messaging app ? We've had e-mail and SMS that can exchange texts and images and videos since more than 30 years, but can't figure out an open and standard way to exchange texts and image in 2023 ?
There is no technical reason behind this, it's only lobbying by the GAFA
The thing that made Signal a non-starter for me, is the requirement for a smartphone with the app installed. And I also don't like the inability to hide your number and work with a name.
So I use(d) Telegram, but they changed it so it now requires a smartphone for initial logon. Which basically means most of my Telegram only contacts are slowly being disenfranchised. Which means finding a new platform. I like Session, but the performance isn't wonderful, and it's not the simplest for users. I wonder if they will be looking at this project? (Worryingly, Teams is looking like the most viable replacement)
"All apps are equal, we're only as strong as the weakest node and every node is equal."
If that is true all those three letter agencies or other snoops would have to do is put up one intentionally weaked node and they have compromised the whole network. Why is he saying that like if it is a good thing?
I think the takeaway point there, as I understand it, is the protocol is constructed in such a way that individual nodes, although "equal," cannot compromise the entire network in this manner. If one tries, in the manner of a three-letter agency, to weaken the network, be that interception, origin tracking or decryption of passing traffic, it is no longer able to function as a Veilid node and is simply dropped from the network.
Confused person here:
(1) From behind NAT, the usual IP addresses are not routable (e.g. 192.168.MM.NN). Problem?
(2) So this only works well from routable (i.e. public) internet addresses?
(3) ....but given #1 and #2, it's not clear that it will work from the various coffee shops which I patronise.
No doubt someone can clear up my confusion......
The local addresses are not routable, but you can still open a connection out. That connection can contact something with a public IP, which can relay your traffic to more nodes, eventually connecting to another connection from someone else who has also opened out. You don't have to accept an incoming connection to communicate with someone if you can coordinate initiating your connections. This is inconvenient for most use cases which is why getting more usable address space will be useful, but it doesn't make the problem insoluble.
This is, by the way, only for CGNAT situations. For a NAT setup with a dynamic IP address, you can still forward ports to allow inbound connections, and there are tools like UPNP to allow programs to do so without asking for your assistance (or permission, which is why you might want that turned off).
This post has been deleted by its author
With exception to x25519.. it's strange the authors chose XChaCha20 for encryption and Poly1305 for authentication when there are much more elegant loghtweight algorithms designed to run on any architecture. Had they chosen Ascon or Xoodyak for encryption and authentication, there would be more interest from the embedded/hardware community that could help with creation of nodes.
It ticks most of the boxes. It could be better. A bolt-on version that could face-hug any app, hijack I/O and switch it to encrypted P2P would be better. Then all the messaging services that are going to vanish from the UK could be released with back doors for GCHQ, which this software could replace when users applied it.
So IF...
This was implemented as a "service" which provided socket and DNS services then EVERY app could use it.
More generally there needs to be "server" implementations on Android and Mobile iOS. ( Good luck getting this past Apple Inc)
And of course the real reason IPv6 isn't deployed in the west, is IPv4 NAT forces routing security compromise. And it is difficult to justify NAT on IPv6
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
