It is not a problem to distribute the decryption algorithm. The question remains against what this will protect. Normal https encrypts the traffic safely during transit. With this, the data is also encrypted on the server. But if you can access the server, you can modify the javascript code to send the password back to a server.
It could be used on something like IPFS, where all data is basically public but you can be sure it hasn’t been modified.
Oh no the wires are a mess. Usb3 cables have extra wires and pins for super-speed. IIRC usb-c has said extra pins for usb configuration like pd or displayport alt mode. The wires can also be different. Some can carry more current, most cables are insufficient for really high data rates…
USB-PD is only specified for USB-C. I think they use an extra channel for this configuration, so it’s not possible to use PD over A plugs.
There were competing standards like Qualcom quick charge. AFAIK they never went above 20-ish watts on USB-A, while PD is specced at up to 240W.
They probably can. jut every hack done has the possibility of spoiling the exploit. A good exploit can cost a million $. So if hacking you is worth more then say 100k to them, you’re in trouble. Otherwise they will only target you with everyday surveilance.
Certificate pinning?
Also all let’s encrypt certs are public. So if someone malicious gets a cert for your domain, you can notice.
(Thats also why it may be a bad idea to use that for secretButPublicStuff.Yourdomain.com certificate transparency logs are a great way to find attack surface.)
edit oh certificate pinning has been deprecated in favor of checking transparency logs.