whisk3rs

minor clarification: That is not what this article says. Ford's network does not include Tesla's superchargers.

Try a Tor hidden service, configured with the low-latency/lower-privacy settings. It is slower than many of the other solutions, but very reliable and very simple.

Free

Try Wireguard on port 4500; this is usually allowed by any firewall/filter that allows ipsec.

I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.

Edit: spelling

What is the most effective way to encourage our elected representatives to correct this potential for violation of our rights?

This depends on what you mean by "properly" and "impossible" and "professional" and "forward".

Many professional name-brand corporations use Tor daily.

The only ports opened are those you configure to have onion services. Port limiting is one of the major features of firewalls.

You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.

Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.

Also, barring the recent attacks on discovery of onion services, connecting to a tor onion service allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes.

tor hidden services. slow, but secure!

Does anybody know if there have been attempts to use this browser based P2P tech to create a decentralized Kat.cr replacement?

why shouldn't people have to rotate the underlying secrets?

a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored.

seems like we should be making it easier to rotate secret values often and automatically.

For AWS users, KMS's GenerateDataKey is a simple way to store secrets locally in a way that reuses your IAM policies. You can also use grants and EncryptionContext to restrict the ability to decrypt secrets in a very fine-grained manner. As a bonus, all decrypts are logged in CloudTrail. The KMS docs are awful but if you're on AWS then it is worth checking out!