3 ms·

Thanks. I understand autoupdate and web infrastructure, as well as the Ken Thompson hack that resolves all these cases into the same threat. The question was rh

by sowbug 4y ago

Thanks. I understand autoupdate and web infrastructure, as well as the Ken Thompson hack that resolves all these cases into the same threat. The question was rhetorical. I doubt that someone who has invested the time in developing code-auditing skills also values their own time so little that they'd audit and build their chat client. And if they're willing to farm auditing out to someone else, or to vouch to other users of the app, then they've lost the plot. Not saying such a person couldn't exist. But the intersection in the Venn diagram seems small.

rdl 4y ago
Much larger cross section when you expand "person" to companies. I probably wouldn't bother with chat, but absolutely would/have with smart contracts and wallet software. (Was a multi-human effort within an organization.)
yazzku 4y ago
This gross oversimplification precludes one from understanding anything but a yes/no answer. The answer is not binary. Like the parent said, delivering the client on every single call makes the rogue update trivial and possibly targeted. Having your software come from, e.g., a bi-annual release Linux distribution, and/or one that focuses on security, makes the rogue update less likely. Not impossible, but still more difficult.
- sowbug 4y ago
  As long as the yes/no doesn't have an inversion error, I'm fine with the coarse granularity. Unless you're targeted by an APT, the threat model would consider all of this to be noise. It's just odd to single out Gmail E2E of all things for this reason in a top-level HN comment on this article. Within a reasonable confidence interval, it's irrelevant to anyone already concerned about using Gmail for their high-security data (because they aren't using Gmail!), and irrelevant to everyone else because they don't care (because it's just their email). I'm way more worried about all the dirty little fingers on the hundreds of Rust crates, Python packages, Java libraries, and NPM packages that get slurped, unreviewed, into so much software these days. (But I'm still not actually going to do anything about it.)

by sowbug 4y ago

rdl 4y ago

Much larger cross section when you expand "person" to companies. I probably wouldn't bother with chat, but absolutely would/have with smart contracts and wallet software. (Was a multi-human effort within an organization.)

yazzku 4y ago

This gross oversimplification precludes one from understanding anything but a yes/no answer. The answer is not binary. Like the parent said, delivering the client on every single call makes the rogue update trivial and possibly targeted. Having your software come from, e.g., a bi-annual release Linux distribution, and/or one that focuses on security, makes the rogue update less likely. Not impossible, but still more difficult.

sowbug 4y ago
As long as the yes/no doesn't have an inversion error, I'm fine with the coarse granularity. Unless you're targeted by an APT, the threat model would consider all of this to be noise. It's just odd to single out Gmail E2E of all things for this reason in a top-level HN comment on this article. Within a reasonable confidence interval, it's irrelevant to anyone already concerned about using Gmail for their high-security data (because they aren't using Gmail!), and irrelevant to everyone else because they don't care (because it's just their email). I'm way more worried about all the dirty little fingers on the hundreds of Rust crates, Python packages, Java libraries, and NPM packages that get slurped, unreviewed, into so much software these days. (But I'm still not actually going to do anything about it.)