Doomscroll News πŸ‡ΊπŸ‡Έ

Category: Security

  • Don’t Ground ‘Quiet Skies’: A Proposal for Smarter, Safer Aviation Security

    Don’t Ground ‘Quiet Skies’: A Proposal for Smarter, Safer Aviation Security

    The recent announcement that the TSA is ending its “Quiet Skies” program has been framed as a victory against wasteful spending and political misuse. While any program that costs taxpayers millions and is used to target political opponents deserves scrutiny, scrapping Quiet Skies entirely is a dangerously simplistic solution. I have a nuanced critique: the core concept of the program is not only sound but essential. The problem wasn’t the mission; it was the flawed execution and political weaponization. Instead of ending the program, we should be reforming it into a smarter, more effective tool that truly secures our nation.

    First, the idea of using dedicated analysts and undercover air marshals is a good one. However, their mission should be dovetailed with other tangible needs in our struggling aviation sector. Imagine if their observational data could be used for quality control or to assist our overburdened Air Traffic Control system. This would add immense value beyond pure counter-terrorism and justify the program’s existence on multiple fronts.

    (more…)
  • Signal Chat’s Group Verification Blind Spot

    Signal Chat’s Group Verification Blind Spot

    Think of verification (V) as a required security check (like that special handshake) between any two members in a secure chat.

    1. One-on-One Chat: Let the chat be just between Alice and Bob. The set is S = {Alice, Bob}. Signal provides the mechanism (Safety Numbers) for Alice to verify Bob (V(Alice, Bob)) and for Bob to verify Alice (V(Bob, Alice)). For full trust, this verification should happen. Signal makes it possible and encourages it for this single pair (Alice, Bob).
    2. Group Chat (Signal’s Current Design): Let the group be the set G = {Alice, Bob, Charlie, … N}. Signal allows Alice to individually verify Bob (V(Alice, Bob)), or Alice to verify Charlie (V(Alice, Charlie)), and so on for any pair, optionally. Crucially: The group chat works even if these verifications haven’t happened. Alice can be in the group and talk to Bob and Charlie without the system forcing her to verify them, and without them having to verify her using the Safety Number check.
    3. Ideal Group Chat (Logical Requirement): Let the group be the set G = {Alice, Bob, Charlie, … N}. For this group G to have the same fundamental identity assurance as a verified chat between just Alice and Bob, the system design should require or enforce that verification V exists between all relevant pairs within the group. This means: For Alice to securely participate, the system should ensure that V(Alice, Bob), V(Alice, Charlie), and V(Alice, Y) for all other members Y in the group G are established (or at least flagged clearly if not). The same should apply to Bob verifying everyone else, Charlie verifying everyone else, and so on. Think of it like needing a “complete graph” of verification: Alice is securely linked to Bob, Alice to Charlie, Bob to Charlie, and so on for every pair.

    The baffling point is: Signal built the tool for Alice to verify Bob (V(Alice, Bob)), but didn’t make establishing these verification links across the entire group (G) a mandatory prerequisite for group operation. It treated security within the group G as a collection of optional one-on-one checks rather than a fundamental, required property of the group itself.

    Originally Posted on 𝕏 on April 19, 2025

    David Gross

    Follow me at https://x.com/dgapps and https://davidgrossapps.com

  • Ethereum Classic on Coinbase: Seriously? Let’s Talk About That Hash Rate and the 2020 Ownage.

    Forget the deep history lesson. Let’s talk about the here and now, and the flashing red warning light whenever Ethereum Classic (ETC) pops up on major exchanges like Coinbase: its security is fundamentally shaky.

    Why? It boils down to one critical factor in Proof-of-Work cryptocurrencies: Hash Rate.

    Hash Rate = Security (or Lack Thereof)

    Think of hash rate as the total computing power protecting the network. Miners use this power to validate transactions and add blocks to the chain.

    • High Hash Rate (like Bitcoin): Makes it incredibly expensive and difficult for anyone to gain 51% control and attack the network (e.g., reverse transactions, double-spend coins).
    • Low Hash Rate (like ETC): Makes it comparatively cheap and easy for attackers to rent enough computing power to overwhelm the network and launch a 51% attack.

    And with ETC, this isn’t just some abstract threat. It’s a documented reality. Remember August 2020? Ethereum Classic didn’t just get 51% attacked once – it happened three times within that single month. Yes, you read that right. Attackers repeatedly gained majority control, reorganized thousands of blocks, and successfully double-spent millions of dollars worth of ETC. The very ledger that’s supposed to be immutable got forcibly rewritten, not just once, but again and again in rapid succession. It got owned. Publicly and embarrassingly.

    (more…)