Google, I challenge you to a duel. Of wits. Nobody needs to change out of their comfortable shoes.
Someone I love fell for a fake helpdesk scam. When I was younger, this was the person who protected me from scams.
They got older. The technology kept moving. They outlived the tech they understood.
That is a real problem. Medical devices help keep someone alive while the software they need for ordinary life keeps demanding a new education. Technology helps you stay. Then it moves the door.
I love this person. I want them here. I also want them to be able to read their email without a security researcher standing behind the chair.
Graham Avenue
About 30 years ago, I came out of the Graham Avenue L station in New York. Nothing was open. Nobody was on the street except a guy with a machete. That stretch of Brooklyn felt like a ghost town.
I looked at him. He looked at me.
I'm still here.
I could see the machete. In an inbox, the threat can arrive wearing the same layout as the service you need. A helpdesk. An account notice. Someone offering to fix the problem they just invented.
I learned to pay attention on the street. I still have to learn new ways to pay attention online. Getting older should not mean every familiar doorway becomes another test of whether you recognize the danger.
Your move, Google
You are building for the age of artificial intelligence. I am asking for a folder.
Call it Phishing. Put suspected credential theft and impersonation somewhere that names the danger. Keep links and attachments inert in that view. Give people a safe way to inspect and report a message, with a clear recovery path when the classification is wrong.
Your own instructions say suspected phishing can receive a warning or go to Spam. Gmail has a “Report phishing” action. You already distinguish it.
Then make a folder.
A sale on patio furniture and an attempt to steal someone's account deserve different treatment. You can explain uncertainty without calling both junk. People sometimes open Spam because legitimate mail lands there. The suspicious message is still a message they can encounter.
I made the lab folder:
messagefromcriminalsthatgooglecanstopiftheywant
The name is the joke. The challenge behind it is serious. Suspected fraud needs a safer handling path. A folder alone cannot stop every criminal, and Google cannot guarantee that every classification is right. Build the handling rules, test the mistakes, and show whether fewer people reach dangerous destinations.
A custom Gmail label does not do that. It adds no detector and disables no links. I am asking Google to build the protection, not asking someone in their later years to configure another filter.
I tried following the trail
Back to hunting the punk that hurt an older person in my family. I placed canaries after the scam and got a trail. I spoke with police in New York and Florida. I couldn't get them to pursue it as I wanted.
My family wanted me to stop before chasing the person put me in the can. Let's just say I knew exactly the casino he laundered the money at. I also knew he was a regular at that casino and what he played. Those are my conclusions from the trail, not findings established by a court or independently verified for this article. A canary event alone does not establish identity.
I wanted to protect someone. I still do. An ordinary family should not have to turn an account scam into its own investigation, then work out where the evidence goes and whether anyone will take it.
Google, put a visible cybercrime reporting route beside that folder. A receipt. A case number. A status people can find again. Preserve the message and headers through a secure in-product flow. Connect the report to your cloud abuse process when your own infrastructure is involved. Explain the route to law enforcement without pretending that an abuse report is a police report.
You already have Cloud abuse reporting and documented enforcement. Connect the experience for the person asking for help. They should not need to draw Google's architecture diagram.
The economics of being careful
“Use something else” sounds simple until the address is tied to years of correspondence, account recovery, appointments, and people who know how to reach you. Moving has a cost. Learning the replacement has a cost. Fraud and recovery have costs too. A service can have no subscription price and still be expensive for the person using it.
Google's market power also deserves specificity. In the search case, the court found unlawful monopoly maintenance through exclusionary distribution agreements. The Justice Department's account of the remedies describes default placement and restrictions on competing search distribution. The 2024 opinion identifies capital costs, distribution, brand recognition, and scale as barriers to entry. Those findings concern search, not a judicial finding that Gmail is a monopoly.
Scale can spread engineering costs across a vast user base. Distribution can help a company acquire more users and data. Exclusionary agreements can make it harder for rivals to reach the scale needed to compete. Those mechanisms deserve separate names. Being large and shutting rivals out are different economic facts.
For someone dependent on an established account, the immediate question is whether leaving is a practical answer to feeling unsafe. Essential correspondence increasingly arrives through email. Gmail itself is a choice, but rebuilding an established digital life is work. Google should not treat that work as an adequate substitute for improving protection.
The cost of an additional safeguard appears in the company's budget. Much of the cost of a successful scam appears somewhere else: the victim's account, the family's time, the bank's recovery process. That separation matters. Reimbursement would move some of the loss back toward the company able to change the product. It would not eliminate fraud. It would make more of the harm visible in the same place as the protection budget.
Google, why hasn't this been fixed better? What prevents a distinct quarantine, safer review, and a report someone can follow? Is it detection quality, false positives, support capacity, or a different product priority? Publish the trade-offs and the measured results. Let us inspect the answer.
My criticism is that older users' protection does not receive the priority it deserves. I cannot read Google's internal motives. I can challenge the experience and ask the company to demonstrate something better.
The people who were here first
Some of today's older adults built the chips, taught the engineers, funded public research through their taxes, and supported the institutions in which this industry grew. The Computer History Museum describes the Valley's government, military, and space-program foundations. Stanford's computing and counterculture history examines the other strand: personal computing as a challenge to centralized authority.
Microchips, public money, growth policy, and a counterculture that included LSD. Silicon Valley did not arrive fully formed in a founder's garage. Nor did one generation or one drug invent it. The people now struggling with a changed interface lived through the world that made these companies possible.
There is a broken promise worth examining here. Technology that was supposed to expand personal agency can leave an older person frightened to open a message. Calling that person careless is a very convenient way to stop examining the product.
The bunker contrast sticks with me. WIRED documented plans for an underground shelter at Mark Zuckerberg's Hawaii compound. That is Zuckerberg, not Google's board. Private protection for powerful people is a project someone can plan, fund, and build. Google, bring that seriousness to the person opening their inbox. They need protection where they already live.
I want Google to reimburse verified fraud losses from scams delivered through its service, with defined eligibility, independent review, and appeals. That is a policy I am challenging you to create. Put the proposal beside its costs and tell us what you would build instead if you think another approach protects people better.
The part after the hash
A URL fragment, the part after #, stays out of the HTTP request. The browser retains it. Page JavaScript can read it. MDN documents that boundary.
That gives an investigator two different artifacts: the complete link in the message and the request arriving at the server. A scanner with the original email can inspect the fragment. A server access log ordinarily cannot recover it from the request target. Calling the fragment invisible skips the question of who is looking.
The fragment also does not execute itself. A page needs code that reads and uses it. A string after a hash is insufficient evidence of a redirect, a credential stealer, or a security-product bypass. Nested email tables prove even less. Legitimate newsletters have been committing those crimes against layout for years.
I built phishing-311-lab to make the boundary inspectable. It needs Node.js 22 or later and no packages. From that directory:
node --test test.mjs
node lab.mjs
The server prints a local address ending in /fixture#LOCAL-MARKER. Open it and change the marker after the hash. The page displays the value as literal text. No login, form, external resource, or redirect. The implementation uses textContent, so a marker containing HTML remains text.
The recorded run passes 12 checks. Its HTTP test makes two requests with different fragments to a temporary loopback server. Both arrive as /fixture, and both receive the same page body. Separate JavaScript checks run the page's script against a stub DOM. That is a local script check, not a browser-rendering result. No Gmail message or Google-hosted page was tested.
This demonstrates why a request-only view can miss information available in the original link. It does not establish what a particular mail gateway inspected. Rendering can reveal client-side behavior, but one automated visit can also miss conditional behavior. A useful investigation preserves the original message, the full URL, the fetched content, and any separately observed navigation rather than treating one of those as the whole event.
The receipt behind the button
The same lab includes summarizeReport, an offline function for an operator's evidence record. It takes a sample hash, report timestamp, channel, and an optional timestamped HTTP-status observation. It sends nothing and fetches nothing.
A report without follow-up returns NO_FOLLOWUP_RECORDED. An operator-supplied 404 returns HTTP_404_RECORDED. Provider action stays UNKNOWN in both cases. So do warning coverage and victim outcome. A missing page could reflect removal, an expired link, an access rule, or a change made by its owner. The status code does not identify who acted.
Google has a Cloud abuse reporting route and documents abuse notifications and enforcement, including phishing. I have not established a response time or failure rate for those systems. This lab submits no report. The reporting receipt I want would connect a user's submission to a meaningful status while protecting investigation details and other users' information.
For a security team, the practical work is preserving the sample, separating mail delivery from hosted content and destination behavior, choosing the appropriate reporting channel, and recording what changed afterward. Keep victim identifiers and recipient-specific tokens out of public evidence. Another analyst should be able to see where observation stops.
The folder now has handling rules
I built the local quarantine prototype. It runs on loopback, uses synthetic messages, and keeps the ridiculous folder name. There is now something behind the sign.
The browser has a Phishing view and an Inbox. Both keep message content inert. Original HTML expands as text. A mistaken classification can be reversed without losing the original content or decision history. Reporting creates a persistent local receipt, with a case ID and timestamp. The status moves through received, reviewing, and resolved locally. Google's action stays unknown. Closing my queue cannot close Google's investigation.
From the lab directory, these are the actual entry points:
node --test test.mjs quarantine.test.mjs
node evaluate.mjs
node server.mjs
The server prints the local address. State persists in a private-mode local JSON file. Nothing imports mail, follows a message link, or sends a report to Google. There is no attachment parser in this version. Moving a message back to Inbox does not turn its HTML into a live page.
The evaluation compares two rule sets against the same 12 authored messages. Six have phishing intent in the scenario; six are benign. The subject-only baseline catches two of the six phishing cases. The broader text rules catch five. Both falsely quarantine the training message that quotes credential-theft language. Both miss the coded message, whose meaning requires context absent from the text. The per-case record keeps those errors visible. I wrote the rules with these fixtures in view. This is a demonstration, not a held-out accuracy estimate.
Twenty-seven automated checks pass across the original fragment lab and the prototype. In a browser, I also followed a report through local closure, inspected inert source, and released the wrongly quarantined training message. That establishes a working local path. It does not establish usability for older people, Gmail integration, or a reduction in fraud. Those need their own evidence.
The operating notes name the next measurements: incoming review volume, minutes per review, oldest open report, correction rate, and harmful interactions from quarantine. Those determine staffing and cost. A status label can be built in an afternoon. A promise that someone will review it requires capacity and an accountable owner.
Google, the proposal now has code, a recovery path, and failures you can inspect. Bring a better implementation. Measure it with the people who need it.
Enough room to be human
I love technology. I build with it. We wear it, put it inside our bodies, use it to grow and deliver food, and depend on it to keep people alive. I want more years with the people I love. Medical engineering gives us some of those years.
That dependence deserves constant discussion. Salt and sugar belong in a kitchen. We still argue about quantities, ingredients, labels, and what gets added without our noticing. Technology deserves at least that much attention as it enters another part of our lives. Useful does not mean unlimited. Accepting one service should not mean accepting its expansion into every room.
Nobody should have to keep surrendering more of their attention, privacy, and independence just to manage ordinary life. History gives us plenty of reasons to question arrangements presented as unavoidable. A compulsory digital workflow deserves scrutiny even when the service behind it is convenient.
Personal responsibility belongs here too. Education matters. Learn what you can, verify a request, ask for help, and teach someone else without making them feel stupid. I have responsibilities as a user and as someone helping another person. Google has responsibilities as the company designing the environment. Both can be true at once. Education cannot compensate indefinitely for a product that keeps changing the examination.
The same applies when we read about a settlement. Read the case, the conduct, and the remedy before deciding what the number means. A large payment attracts attention. Whether the agreement changes the conditions that produced the harm takes more reading. That is part of our homework as citizens, including mine.
Google, the challenge is to make progress leave enough room for someone to age. Give people usable choices about what enters their life, a way to get help, and protection that does not depend on their remaining technically current forever.
A duel worth having
The local tests in this article inspect a small technical boundary. They do not explain Google's internal priorities or measure its fraud prevention. The folder is satire. The request for a safer product is not.
Google, bring your engineers, your resources, and a better answer. Show how you would protect someone whose ability to learn a changing interface no longer keeps pace with the interface. Show where a report goes. Show what happens when protection fails.
I am rooting for you to build it. Someone I love needs the result.
GhostInThePrompt.com // Their medical devices help them live. Their email should be safe to open.