MajesticHobo2

There doesn't need to be any kind of "polyglot payload". Local network services and devices that accept only simple HTTP requests are extremely common. The request will go through and alter state, etc.; you just won't be able to read the response from the browser.

Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.

Can you point me to some documentation or proof of concept for this? Would definitely like to change my workflow if this is the case.

Related/funny: three years ago, someone found exactly such a bug because it was exploited against a Minecraft server they were running in screen (probably without the perpetrator understanding the root cause): https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0...

> Is the syntactically correct dummy value the same each time? If so, how does that lead to new coverage?

Per my understanding, the dummy value is constant but is only used once (to create the first valid TLV). Everything after that is a mutation of the original value that, due to the custom mutator logic, is a valid TLV. The mutations are where new coverage comes from.

> In any case, why bother with this "if invalid replace with dummy" step? Why not generate/mutate a valid TLV value from the start?

I'm guessing to handle both when there are seed files that are already valid (which you'll want to use instead of a dummy value), and when there aren't any valid seed files.

Since a WireGuard peer only responds to cryptographically authenticated packets and UDP is connectionless — you don't get confirmation at the transport layer by way of a handshake or anything — WireGuard ports are invisible to you unless you own a private key whose corresponding public key is already approved by the peer.

They also hire firms for regular security assessments (I did one of them) and publish the reports: https://support.1password.com/security-assessments/

> Signal is very proud that once a long time ago the state came to them asking for user data and signal could only tell them they had no data to provide.

Have you looked at https://signal.org/bigbrother/ recently? There are five instances of this, one as recent as November 2021.

Do you not stay logged in to HN?

Phishing is still an issue that could be prevented with security keys. That said, I don't see most HN accounts being very interesting to phishers.

You can listen to tapes from his teenage years in the late 50s, where he's singing in almost that exact early 70s croon. But his voice throughout most of the 60s was very different and, for the most part, intentionally so.

You're trusting the client whether or not it can talk on the network. A malicious update that starts generating predictable passwords for websites doesn't need a network connection.

This is true of any password manager.

In addition to that, "Cultural Marxism" doesn't just refer to Marxism. It's an antisemitic canard used pretty much exclusively by the far right.

Services hosted outside the US offer less protection against US intelligence agencies, not more.

> Also would a CORS "Access-Control-Allow-Origin: localhost" prevent the connections being established?

WebSocket isn't bound by CORS, AFAIK.

While I found the talk more compelling, it's also worth mentioning Moxie's 2016 article, "Reflections: The ecosystem is moving", for several of the key points: https://signal.org/blog/the-ecosystem-is-moving/

Are you just going to ignore the fact that the official Twitter account for Gab actively promotes white supremacist talking points? It only takes about 30 seconds of scrolling through their feed to see this.