How to gain code execution on hundreds of millions of people and popular apps

Incident handling and communication

• Many commenters praise ToDesktop for fixing the issue quickly after report, cooperating with the researcher, and publishing a detailed incident write‑up plus audits.
• The phrase “cannot happen again” draws heavy criticism as hubristic; several people argue no one can guarantee that, only that this exact bug is fixed. Others think it’s reasonable if “this” is narrowly defined as this architectural flaw.
• Some suggest more honest, non‑absolute language: explain current standards, how they compare to peers, and how the team will know when to improve them.
• A subset thinks the response was solid overall and that people are overreacting to wording and “enterprise speak.”

Root cause and technical concerns

• Core issue: the build container both (a) ran untrusted customer code (e.g., postinstall script with a reverse shell) and (b) held high‑privilege Firebase credentials and signing/upload logic used across customers.
• Commenters note this violates basic least‑privilege and “sacred” treatment of code‑signing and auto‑update infrastructure.
• Some question relying on logs to assert “no malicious use,” since privileged attackers could potentially tamper with logs; others counter that you must assume some parts of the infra were correctly isolated.
• ToDesktop says they re‑architected: separate privileged sidecar for signing/upload, reduced permissions, audits, etc. Some worry containers alone aren’t a strong enough isolation boundary.

Third‑party risk and auto‑update

• Strong debate on using a third‑party build/update platform at all, especially for security‑sensitive apps like IDEs. Critics call it “insane” to delegate signing and update control; defenders note cross‑platform signing/build is painful and such services fill a real need.
• Broader supply‑chain anxiety: deep dependency trees, postinstall scripts, sourcemaps exposing code and sometimes credentials, CI runners with outbound internet, and shared CDNs without integrity hashes.
• Several suggest: air‑gapped or network‑isolated builds, vendored dependencies, internal artifact proxies, and HSMs or offline (“shoebox”) keys for signing.
• Auto‑updaters are viewed by some as effectively granting RCE to vendors; a minority advocate no auto‑update at all and relying on OS/package managers, but others argue that’s impractical at scale.

Responsibility, liability, and ecosystem

• Disagreement over blame: some place it squarely on ToDesktop; others insist customers are also responsible for granting broad update/signing access and choosing risky architecture.
• Long subthreads argue for greater developer accountability (even licensing/certification) versus concerns about over‑regulation and unrealistic expectations.
• Firebase is discussed: some see repeated misconfigurations as partly a product‑design failure; others say insecure rules are clearly a developer responsibility.

Meta: article style

• Many readers enjoy the write‑up’s narrative “gonzo hacking” style and playful cat cursor; others find the moving cat and lack of capitalization distracting or hard to read.