Even if caller id had been used in this situation, he could have easily spoofed the number to appear to be coming from the neighbors house since they would have already had all the information necessary to do so. The Caller ID system you're thinking of simply does not exist. The current system is much to easy too spoof. Anyone with $15 and a VoIP number can do it.
The methods in use by Pegasus make it impossible to avoid. "Zero Click" malware allows them to take over a device without any interaction needed by the user so even if you factory reset the device, heck, even if you reinstall the OS entirely, Pegasus malware can get back into the device. Until the method they are using to break into devices is found and patched there will be no stopping it except for disconnecting the device from all networks or keeping it powered off.
Edit: They are using 0-Day exploits against mobile clients that take advantage of flaws in default applications like iMessage. Pegasus intrusions have been detected on devices as new as the iPhone 12 running iOS 14.6. This would be a severity rating 10/10 for a CVE, to put it into perspective.
This is sadly true. We need to return back to the Unix Philosophy of do one thing and do it well. None of these multi-purpose tools that have terrible feature creep and try to take over everything cough systemd cough. In all seriousness though, a lot of software that should be simple and easy to audit ends up having all these dependencies that are ether no longer maintained or doesn't get the necessary code reviews and it isn't until stuff like this happens that it actually comes to light.
I'm all for re-using code when rebuilding the wheel would be a hassle but it has to be balanced with proper code review before it should be included. Developers are much too quick to include outside code with the assumption that other people have already done the necessary reviews and this is where a lot of devs are getting bit.
I don't doubt that, it's also trivial for anyone to spin up their own local root mirror to resolve against, I'm just pointing out that maybe Verisign shouldn't be holding onto two. It's even pointed out on their Wikipedia page like some kind of trophy like "Oh hey look, we don't just run 1 we run *2*, that makes us a big deal". :eyeroll:
"Natural Competition" in this space can never be. What you're seeing is exactly how this space turns out. Verisign controls the registry for the .com TLD. They run the centralized authority that ultimately says if a .com domain is "legit" or not.
The Registrars like Namecheap and friends are just the messengers authorized to register .com domains into this larger database and they pay Verisign for the privilege to do so.
While it's possible for anyone to go out and stand up their own .COM zone in DNS, any domains created by that registrar don't actually exist in the eyes of the larger Internet and will not work.
Impossible due to how cryptocurrency works. In any cryptocurrency there is something called an "emissions target" which will only up to X amount of coins to be "released" on the discovery of a new block. This is also compounded by the fact that even if you did try to accelerate the mining by adding more powerful nodes into the network, the network would automatically adjust the difficulty in order to keep blocks spitting out at the predetermined time of 10 minutes per block.
Forks are generally required to maintain the original licensing of the originating source. That would be like taking part of the Windows source code and "forking" it with the only change being the licensing. Just because you forked it and changed the license doesn't make it true.
My idea for letting the trust being tied to the Root and TLD master keys was more in spirit of allowing people to have more say in SSL. The Internet is technically centralized to the IP and DNS namespace already so for me it seemed like the next step in the chain. While we centralize one part of the Internet we also open it up to allow for alternative root projects like OpenNIC to be able to establish community-based chains of trust.
Like I know one of the big problems with OpenNIC is nobody can really use SSL since if you trust a third party CA they can just sign for anybody without limits, and if you run both a DNS and CA service there then you have everything you would need to do large scale SSL interception in those cases :(