But members of your social circle (family members, friends, coworkers/bosses etc.) do pay attention, and when they do, they can make it your problem. You can ignore an Internet mob, but you can't ignore getting fired by your employer because they want to preserve optics.
I don't know--I think these stories of real-world consequences stemming from online rage are few and far between. It happens but it's rare. IMO the Online World is kind of not-real, and it's really hard to get so much visibility there to actually affect the real world.
Liquidity is a value of its own. 10% equity in a $1M non-fungible residentially-zoned lot is much less valuable than $100K in cash, ready to wire at a moment's notice.
> But, wireguard also needs to update to support post-quantum
It's quantum-resistant if you define a PSK. You still have to distribute the key out of band, but you already have to do that anyways for the public keys of the peers.
Because the public key is the identity in the Wireguard protocol. If Alice and Bob want to communicate with each other over Wireguard, then Alice has to know Bob's public key, and Bob has to know Alice's public key. If they don't already know each other's public keys, then that information has to be exchanged in a secure manner at least once, in order to prevent nosy Mallory from impersonating one of them. How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.
In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".
> How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.
I don't think this is quite equivalent: with public keys you 'just' have to establish authenticity, but with PSK you also have to worry about secrecy.
In someone ways it's similar to the PGP/GPG situation: initial secrecy is not the issue, trust is. If you trust someone's Twitter/Bluesky/Mastodon account, they could just the pubkey there; if you think e-mail is 'secure enough' to not be tampered with, they could e-mail you their pubkey. The threshold for 'PSK safety' is probably much higher.
Establishing secrecy is easy if you've already established authenticity - do a key exchange and use the shared secret for your AEAD. Establishing the authenticity is the tricky part, and most encrypted communications protocols offload that to the user in some way:
SSH - the client pubkey has to somehow reach the server's authorized_keys file, and the server fingerprint has to somehow reach the client's known_hosts file.
HTTPS - The root certs have to be present in the client cert store in order for the client to authenticate the servers they connect to.
PGP - People exchange their public keys in key signing parties after verifying each other's identities in person.
> Establishing the authenticity is the tricky part, and most encrypted communications protocols offload that to the user in some way
This statement is mostly true for computers, but a human can look at a (e.g.) Twitter post and know that the account belongs to someone and copy-paste the key in the post, or via an e-mail that has crossed the Internet in a matter that they're confident has not been fiddled with. A computer (process) just has a string of bits that have come in via a socket: it has no other context and so a bunch of infrastructure has to be tapped into (as you listed).
Right, a lot of that trust is implicit and we don't think about it every day. But for threat modeling, it helps to spell out the chain of trust explicitly:
* You trust the browser/OS
* Browser trusts the root cert store (either embedded in the browser installation or managed by the OS)
* Root cert authenticates the twitter.com connection
* Twitter validates the legitimacy of the account (anti-spam/anti-impersonation/verified user etc.)
* You trust that the person who made the post on the Twitter account is the person you want to communicate with
If any of these can be violated, it's an opportunity for attack, be it via a technical exploit, social engineering, political favors, whatever. Ultimately it's up to the user to determine what to trust and what level of risk to accept.
So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in. Sending a binary over SSH/SFTP might sound weird at first glance, but VSCode can't assume that your remote machine can access the wider internet, and it needs a reliable way to bootstrap the agent on the remote. Shipping it over the SSH tunnel is the natural solution.
TRAMP (mentioned in the article) does it without installing anything on remote machine, just SSH, and shell commands. Which sounds more natural to me. Node.js security history, with all due respect, is not shiny. And the problem the author has with VSCode's way, I guess, is not that it can edit files, but that it extends attack surface without real need.
TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.
I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface
This should be covered by not giving developers SSH shell or equivalent access to production machines in the first place, or at the very least to have measures in place (ACLs, quotas, etc.) to strictly limit what they are able to do from the shell.
Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.
It didn't occur to me when I first read the article, but I do see now the author called it "remote editing" as you did too.
It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it's setting up a development environment (compilers, LSPs, editor extensions, etc.) on a remote thing (VM, container) that you access with a thin VSCode shell.
If you want to quickly edit a config file on a remote machine, TRAMP seems great. VSCode Remote SSH is not meant for that.
The very first page[1] of the VSCode remote documentation makes it perfectly clear that VSCode remoting is more akin to running an Emacs server on the remote than TRAMP.
Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.
Yeah, I learned how it worked when I made the mistake of trying to use it to develop on a Raspberry Pi, where it filled the disk and crashed/hung the Pi by using all the RAM until it started using swap. Fell back to local with an sshfs mount instead.
Oh wow I just checked my servers and on one the folder is 3.2GB and another has 1.7GB.
It kind of looks like it just keeps copies of every version its ever installed? Theres several copies of node and `node_modules` folders.
I'm not super low on space but it also pretty clearly doesn't need to be that large, it looks like most of it is copies of itself.
The need to drop privileges at all is a natural consequence of a process spawning API with inherit-by-default capability semantics. You'd never build a new VM or OS this way if you didn't require compatibility with existing software. The secure solution has always been default-nothing semantics, with whitelisted capabilities granted via explicit arguments in the process spawning API.
The closest you can get to that model on Linux is the strict mode in seccomp, which disallows every syscall except read(), write(), exit() and sigreturn(). It's more or less a way to restrict a process to being "pure compute/memory". If the process then wants to poke and prod at the outside world, it can only do so by reading/writing the file descriptors it inherited prior to the seccomp call. You can build a RPC on top of that to emulate the "whitelist", with access control and restrictions/policies enforced by whatever is listening on the other end.
Fundamentally, Unix security is per user (in uid sense), identity-based with ambient authority, not capability-based with directly passed authority. There are many attempts to nerf, limit, lock down authority at the process level, but they all go against the initial architectural grain. Unix was not designed to protect users from themselves, only from each other.
By default when creating a new thread or process under Fuchsia you don't have access to the kernel. You have to create the thread or process with explicit kernel access. Pity Fuchsia kinda got killed off (Ok its not completely dead yet but its slowed a lot. There still doesn't seem to be a 2026 roadmap either)
People have tried to build the opposite. It doesn't work well. Except in very limited cases you always end up passing every privilege or a god privilege to make it practical.
Sure, you can't avoid poorly designed apps. But a poorly designed app is much easier to fix/replace than a poorly designed OS, particularly when it comes to open-source software.
Why stop there? The bottleneck is not some immutable force of nature. The number of judges is determined by legislative action. It is within Congress's power to allocate new federal judicial seats, and likewise at the state level with the equivalent lawmaking body (for most states, at least). Why don't they do so?
Because federal district court judges have a tremendous amount of power. You both don't want 10,000 of them running around and you don't want to water down the qualification for the position--if you did do that, then that would devalue their judgments, everyone would appeal, and you'd just shift the bottleneck up to the appellate courts.
At the end of the day, litigation is conflict resolution. You don't just need a decision, you need a decision from someone authoritative enough to bully Fortune 500 CEOs into submission to accept the judgment.
Because everything in the real universe occupies a volume, and therefore no two distinct "things" can be 0 distance apart. The distance between two marbles' center of masses is the sum of their radii. So if you want to measure the potential gravitational energy between the two marbles, you'd take the integral of (GM^2/x^2) dx between x = [sum of radii of marbles] and x = infinity, as an approximation.
It would have to find an open Wi-Fi network that isn't gated behind a captive portal, which is very rare. Rare enough that most telemetry would be too stale to be useful.
Xfinity (Comcast) does the same, and the LG TV data leak demonstrated it joining these open “xfinitywifi” SSIDs to transmit telemetry home (edit: retracted, see below subthread).
While LG TVs send a lot of private data when connected to the internet, I'm not aware of any credible reports that they automatically connect to open or partner-provided wifi networks without a user choosing to do so.
It's certainly a threat to keep an eye open for, but it seems manufacturers haven't quite stooped to that low yet.
It has not been demonstrated actively in use, only that it is possible and trivial to implement. Statement with regards to it being demonstrated retracted.
I stand by the concept that any consumer IoT device could join these networks, and the end user would never know. The only legal solution to this problem statement is to physically disable the radio on the device if assurance is desired.
Another ! makes sense to me here. Are there any cases where it doesn't work to auto-assign ! to all associated types of a ! trait impl? Associated constants might require some mechanism similar to `compile_error!()`.
reply