Do you remember the 2014 Sony hack, when North Korean hackers hacked into Sony?

Or how about the 2016 hack when a Russian hacking group leaked all of the Clinton campaign’s emails to WikiLeaks right before the U.S. presidential election?

Finally, what about the 2020 hack when the National Enquirer used Jeff Bezos's personal photos photos to blackmail him?

What do these stories all have in common?

They all began with phishing attacks.

In today's blog post, we're going to walk through these three examples, starting from the least sophisticated phishing attack (Podesta) to the most sophisticated (Bezos). And we’ll learn how you can protect yourself from similar hacks happening to you. (Spoiler alert: I built an anti-phishing plugin to protect people against attacks like this. But more on that later.)

Let's start with the least sophisticated attack.

The John Podesta Email Leak: A Bit.ly Blunder

In 2016, a Russian hacking group wanted to sow discord in the 2016 presidential election, so they decided to target John Podesta, Hilary Clinton’s campaign manager. Here is the actual email that Fancy Bear — the hacking group — sent to Podesta:

Right away, you may notice something weird about this email: if Google wanted you to reset your password, they probably would not send you to a Bitly link. (Bitly happens to be one of the top phishing sites in the world.)

John Podesta is a smart guy: he knew the email looked fishy, so he emailed IT and asked if it was real.

This was the response from Charles Delevan, head of IT:

You read that right: “This is a legitimate email.” (If even IT department heads fall for scams like this, nobody is safe.)

In Delevan’s defense, Delevan’s response email contains the correct google password reset link: myaccount.google.com/security. The problem is that John Podesta went back and clicked the link in his original email: the Bitly link, which redirected to a cloned Google login site. Within seconds of Podesta typing his password into the cloned site, Fancy Bear snagged his password — and soon after, all of his emails too.

So how could this have been prevented? Enter Too Phishy.

Last year, I built a tool called Too Phishy: a Gmail plugin that attaches to your Gmail inbox.

If I could go back in time and force John Podesta to use my plugin prior to getting hacked, here’s what he would have seen when he opened the email from Fancy Bear:

In short, Too Phishy analyzes all the links in an email and highlights the well known phishing sites. Had Podesta used my plugin, Clinton’s emails might have remained safe, she might have won the election, and 2016 wouldn’t have marked the end of democr… nevermind, that’s a blog post for another time…

Now for a medium sophistication attack: the 2014 Sony hack.

Like the Clinton hack, the Sony hack also began with a phishing link.

In 2014, North Korean wanted revenge for Sony’s release of the movie The Interview, a satirical movie that depicted the assassination of Kim Jung Un. So North Korea’s preeminent hacking group, Lazarus Group (also famous for the Bangladesh Bank heist and the WannaCry hack), began a spear phishing attack that targeted Sony executives. This was one of the many phishing emails that Lazarus Group sent to various Sony executives:

Like the Podesta email, Lazarus Group’s email purports to be from a legitimate tech company, Facebook. But you’ll quickly notice that the “Log In” button links to fancug.com, a domain name that is registered in South Korea. That's a red flag; since Facebook is a United States-based company, all of Facebook's “.com” URL domain names should be registered in the United States. Another red flag: fancug.com is not a top million link, i.e. one of the top million most commonly visited websites in the world.

When clicked, the fancug.com link directed the email recipient to a site hosted in South Korea, which, when visited, downloaded malware on the recipient’s computer and initiated a command-and-control relationship with two servers in North Korea.

Knowing this, I designed Too Phishy to show email recipients the country of registration for every link an email. And it also checks if the link is a top million link:

As you’re probably aware, hackers love causing two things: financial damage (usually accomplished by wiping victims’ hard drives), and embarrassment (by leaking personal information). Just like in the Clinton campaign hack, the Sony hackers leaked victims’ personal emails in order to cause maximum embarrassment. Amy Pascal, the executive who had arguably the most cringe-worthy emails, promptly resigned (it’s always the highest-ranking woman who gets fired, isn’t it?).

Ironically, The Interview got so much press from the Sony hack that despite the cancellation of its wide theater release, it still made $40 million, earning back its budget. And, perhaps even more surprisingly, Amy Pascal bounced back to produce the billion-dollar Spider-Man: Homecoming only two years later in 2017 and the Oscar-nominated Little Women in 2019. Take that, Lazarus Group.

And finally, the most advanced attack: the Jeff Bezos hack.

Often, when I speak about Jeff Bezos at conferences, no one has heard about his enormous phishing scandal.

Here are the bare facts: Jeff Bezos was (and still is, unfortunately) the owner of The Washington Post. Around the beginning of 2018, Mohammed bin Salman (MBS), the Crown Prince of Saudi Arabia, became frustrated with the Post’s unfavorable coverage of the Middle East. So, as world leaders are wont to do, MBS decided to hack into Bezos’ phone and blackmail Bezos into more favorable coverage.

As part of his plan, MBS sent Bezos the following WhatsApp message after the two met at a party:

MBS then sent a follow-up message to Bezos that contained a video. Embedded within the video was a zero-click exploit — that is, malware that silently installs itself on the recipient device without the recipient needing to click anything – which siphoned all the photos from Bezos’ phone to servers in the Middle East.

Then, suddenly, in January 2019, Bezos and his wife McKenzie Scott announced their divorce. Following the news, the National Enquirer published a cover story that mentioned “the cheating photos that ended his marriage”:

When Bezos saw the article, he knew that someone had hacked his phone.

Now, unlike the other two phishing hacks in this post, the Bezos hack was never investigated by the FBI, so we’ll have to trust the FTI Consulting report that Bezos commissioned.

One month after the Enquirer article was published, Bezos penned this blog post, revealing that he had been hacked and that the National Enquirer was using these hacked photos to blackmail him. He even published the blackmail letter itself, with the itemized list of photos they had stolen from his phone (including a “below the belt selfie”).

How could Bezos have protected himself?

The truth is that if someone is willing to pay a million dollars for a zero-click exploit to get into your phone, it’s pretty hard to stop them. But there’s one obvious thing Bezos could have done: turned off automatic downloads in WhatsApp (in fact, in all of his messaging apps). This would have prevented from the zero click exploit from getting onto his phone in the first place.

Are you thinking, “Eh, I’m not worried about this happening to me. I’m not a billionaire”? Think again: a recent study from iVerify found that seven out of 2,500 investigated phones had similar spyware installed on them, and that those phones belonged to a “cross section of society” — not just billionaires and politicians. Indeed, it’s never a bad idea to install a spyware scanner, no matter who you are.

I’m still not convinced. Who cares about phishing anymore? It’s 2025.

When I read cybersecurity news these days, there’s less coverage of phishing than there was ten years ago. Many people think phishing is a solved problem: in 2022, Gmail started requiring domain authentication for bulk email senders; subsequently, they saw a 75% drop in unauthenticated emails. (Microsoft adopted a similar authentication requirement at the same time, and saw a similar drop.) Indeed, according to the FBI Internet Crime Report, phishing dipped slightly in 2022, likely as a result of these bulk email sender authentication measures:

But if you look at the above graph, you probably notice that phishing is still — even in 2023 — five times more common than the next most common internet crime. Hackers can still get people to click links. (In fact, SPF and DKIM are actually kind of easy to get around.1) There are always going to be vulnerable users.

Furthermore, no phishing filter is perfect, because hackers are always innovating and coming up with new tricks for getting email users to click links. As recently as 2022, Gmail’s seemingly impervious phishing filter was found to miss 626 phishing emails per 100,000:

Sure, 626 is a small number, but as we've seen today, it only takes one phishing email for a catastrophe to happen. So stay vigilant! (And install Too Phishy.)

I’d long had my Too Phishy app in the Google Workspace Store, languishing at around 300 users. This August, I gave my first ever conference talk at the Carolina Codes Conference. The next day, Too Phishy had 200 new users, and I met ten IT practitioners who agreed to let me interview them for product research. 66% user growth in one day? And exponential growth in the number of customer interviews I’d been able to secure?? 

I felt like I’d hit a gold mine. 

So why aren’t more developers applying to speak at conferences?

My guess: They don’t know how. So I want to demystify the process and help more people get accepted to conferences.

Why Diversity in Tech Conferences Matters

This blog post is for my own benefit. I want to see spicier content at tech conferences. More hot takes. More outside perspectives. More – gasp, since DEI initiatives have been in freefall on my Linkedin feed recently (to say nothing of the past week) – diversity.

Tech conferences are still full of white men giving repetitive talks. I’ve been to 14 meetups that featured a guy who made a subway app using public transit APIs. As someone who’s built my fair share of unoriginal apps, I’m not one to judge, but I do notice that the apps getting presented at tech conferences become a LOT more interesting when the speakers come from more diverse backgrounds.

In short, I want more people to apply to conferences.

The Problem: People Are Too Intimidated to Apply

Applying to speak at conferences is intimidating. The term used to describe the conference application itself – a conference “paper” – is inherently intimidating, reminiscent of the academic-style papers from college that required careful citations and an appendix the length of one’s arm. 

The surprising truth is that applying to conferences is far easier than most things you have to do in your regular job, and far easier than any of the papers you had to write in college…

Step-by-Step Guide to Getting Accepted to Conferences

Write a 250-Word Conference Proposal

You only need to write 250 words to submit a “conference paper.” In fact, most tech conference applications have a 250-word limit so you couldn’t write more even if you wanted to. Here’s an example of a paper I recently submitted to a couple of conferences; as you can see, it’s nothing crazy. 

And, in the spirit of transparency, that 250-word “paper” was written by ChatGPT.

And if you’re wondering whether you need to train ChatGPT on examples of real conference papers, it’s not necessary to do so: conferences repurpose the accepted conference papers as the talk descriptions on conference schedules (which are publicly available on the web), so OpenAI has already scraped them all for you.

Include Links to Past Speaking Experience

My acceptance rate to conferences dramatically increased once I included links to past speaking experience, something I did upon the advice of my friend Akira, a conference veteran who told me, “Conference committees like to see videos of past speaking just to make sure you can speak in public and won’t get stage fright.” 

Taking their advice, I added more links to my application, even though none of this speaking experience was “technical.” Specifically, I’d spoken at a large tech conference about building a Green Team at MongoDB in 2021. I’d also given a short talk to students at my former high school about learning to code in my mid-twenties. Yes, this talk was literally targeted at 15-year-olds, and I included it anyway. (And it seems to have helped my acceptance rate a lot, but we’ll get to that later.)

Use the STAR Framework in Your Session Outline 

Secondly, on the suggestion of my friend Josh, I wrote a supplemental description for my talk using the STAR (situation, task, action, and results) framework. 

Josh’s exact words when I first sent him my initial GPT-written conference paper draft were “This was clearly written by AI.” Hah! He was right. 

Heeding Josh’s advice, I begrudgingly rewrote the talk description myself (yes, without the use of generative AI) using STAR. You can see the new version here. I liked this new version a lot better, but it felt weird to reference myself so much (I used the word “I” eight times) in the talk description. Most conference papers use the term “we” instead of “I”, because the speaker usually works for an actual company (whereas at the time of writing these proposals, I was a solopreneur).

Faced with a time crunch, I eventually decided to stick with my GPT-written conference paper. Most conference paper application portals have an “optional” section, so I wrote “Here is my talk outline:” and pasted the STAR description. Again, not perfect, but it worked in a pinch.

Prepare for Rejection, but Keep Applying

Here’s the truth. Carolina Codes Conference was the first conference to accept me after nine months of applying to conferences. Prior to this summer, I’d gotten at least 75 conference talk rejections. 

Persistence pays off. Keep tweaking things and keep applying.

The Two Key Changes That Led to My Acceptance

When I finally started getting accepted to conferences, I reached out to my marketing mentor, Omari – “You know that app I built last December, Too Phishy? Well, I applied to a bunch of conferences earlier this year, and now all of a sudden, it’s getting accepted!”

“Well,” Omari asked, “What changed?”

Funnily enough, it was only the two simple changes above – adding links to past speaking experience and adding the STAR framework description in the optional section – that brought my acceptance rate from 0% to 30%. Since then, I’ve spoken at four conferences – Carolina Codes Conference (300+ attendees), BSides Nova (700+ attendees), BSides NYC (1,000+ attendees), and Triangle InfoSeCon (1,650+ attendees), and had a heck of a time doing it. I’ve met 100+ IT practitioners and learned more from them in-person than I ever could from online sources. That’s what made me want to write this blog post.

Start Applying Today

Don't let rejection stop you. The hardest part of applying to conferences is finding conferences. Here's the conference application site I use: https://sessionize.com/app/speaker/discover. Once you're logged in, it’s surprisingly useful, because it sorts conferences by their application deadline and/or conference date. 

Good luck!

I’ve said it once and I’ll say it again: I’m really proud of my most recent app, Too Phishy. It’s by far the best anti-phishing add-on I’ve seen in the Google Workspace store. That being said, it hasn’t caught on as much as I would have hoped or as fast as I would have hoped. 

In an effort to build one app per month, I have to be more ruthless than other app builders in terms of timing. Things have to take off fast, or it’s time to pivot. So I’ve decided to pivot into new ventures. Here’s my blog post explaining why.

Too Phishy’s launch

A few weeks ago, Too Phishy launched on Product Hunt. In its first few days, it got no page clicks. No subscribers. No comments. No reviews on Product Hunt (except, as usual, from my dad). And no downloads in Google Workspace. Admittedly, with my marketing budget of $0, I had told no one about this app, and Product Hunt doesn’t market your apps for you. But it was disheartening nonetheless.

I spent the next three weeks reaching out to bloggers, and trying to get signups. I even posted to 19 reddit communities, earning me more than a thousand website visits to toophishy.com. Along the way, I managed to get 12 free trial users, who would become paid users once the two week free trial period ended. Woohoo! 

But looking more critically, I had to wonder why my website had such a low ratio of website visits to app signups. My posts on reddit were getting real attention, but somehow my app did not address enough of a real problem to get people to sign up.

By the end of December, six of those trial users churned, and six became paid users. I had to accept two things: I had 50% turnover, and I gained one user for every three days of marketing. Ultimately, I wondered if the time investment per user acquisition was sustainable. It was time to take a pause and figure out what to do. 

First, in an effort to remove the most obvious friction point of user acquisition – cost – I decided to make Too Phishy free. I sent the following email to my users:

Making my app free got me another 24 users, bringing my user count to 30.

Next, I emailed 93 cybersecurity practitioners across the world, telling them about my five-star free anti-phishing app and asking if I could speak to them for advice. (I got six meetings out of this outreach, but most practitioners I spoke to already had an anti-phishing tool in place and preferred to spend their budget on post-breach response rather than pre-breach defense.) 

As Yvon Chouinard, the founder of Patagonia, once said:

If I get an idea, I immediately take a step forward and see how that feels. If it feels good, I take another. If it feels bad, I take a step back.

At this point, I felt bad. 

An object in motion stays in motion, which is to say, it’s sometimes easier to keep going than to stop. 

So instead of diving into my next app right away, I’ve decided to take a pause, write this blog post about what I learned, and start over.

The elephant in the room: the lack of publicly available phishing data

I mentioned this in my launch post for Too Phishy, but there is a dearth of example phishing emails in the public domain. This makes it really, really hard to come up with correct algorithms, and to identify “bad actors” in real time. Without the ability to see the millions of phishing emails making their way across the internet and into Gmail’s inboxes, it’s hard to immediately flag bad actors. So in the end, I wonder if my biggest issue was not having enough email data to work with. This is the biggest lesson I take away from this experience.

Things I got right

First, I’d like to reflect on what went well in the Too Phishy launch. I learned a ton.

Things I learned:

• Hey, I launched an app! That was exciting. And it got approved by the Google Workspace Review team (which took a month of back and forth).

• I found a paying audience – 12 free trial users! That’s way better than zero free trial users.

• And I found a non-paying audience - 30 users.

Things I got wrong:

• I launched a relatively expensive ($6/month) subscription app on a platform (Product Hunt) that doesn’t specialize in paid apps.

• Somehow I built an app that people wanted to learn about but didn’t want to install.

• I didn’t research the customer for my product before building.

• I built in a vacuum without talking to people along the way, compounding my above missteps.

So what am I planning on doing going forward? Let’s dive into it.

Know thy customer

As someone who was very social in college, I joined my first software engineering job at the age of 25 and soon realized that my social skills learned in college did not translate to the startup world. I vividly remember my first day on the job, when all the male software engineers (and one product manager) walked by my desk on the way to lunch without acknowledging me. I’ll show them, I thought, I’ll learn to code so well that they invite me to lunch. Well, I did learn a lot of code, and eventually I got invited to lunch. But I turned down the invite. By then, I had fully transitioned into an introvert.

These days, I feel very comfortable around a compiler and a debugger, but I’m terrified to go to Meetup events. (If you’re wondering how I managed to spam 19 reddit communities as an “introvert,” I have the sweat stains to prove how difficult that was for me.) Hell, I’m scared to even send a single LinkedIn message. 

So over the past few weeks, I’ve forced my rusty social skills into shape. I’ve gone to two (count ‘em) Meetups, and I’ve forced myself to talk about my product ideas to one new person at each event. And, as mentioned above, I’ve sent 93 Linkedin messages this month – mostly with my eyes closed, and hyperventilating while doing it. (Don’t block me, please.)

In an effort to be a woman of the people, and not just a cyborg working remotely in rural Brooklyn, I even went to Rockefeller Center and interviewed tourists on the sidewalk outside of an Equinox. “I’m starting a cybersecurity TikTok,” I told them, “Would you mind if I asked you a few questions about cybersecurity?” (Most people took pity on me because I do not look like a TikToker and they probably knew I was desperate; over two hours, only two people said no.)

“Do you ever worry about your data on Tiktok being used?” I asked. 

“No,” they said.

“Do you ever worry about being hacked?” 

“Yes.”

“Do you use a password manager and/or VPN?” 

“No,” they said. Some said that they had VPNs, not because of privacy concerns, but for watching Netflix abroad.

“Do you do anything to protect yourself from phishing emails?” 

“Yes, but only for my work email.”

Hm. Well that’s interesting, I thought. None of these people even uses a phishing app for their personal email. (To you, this may seem very obvious; to me, it was genuinely a surprise. Again, I do not talk to people very often.)

Who is my customer? I wondered. And what do they want? The truth was, I didn’t even know. 

I had 30 customers, so someone clearly wanted my app. There are people who are scared of being hacked, but I didn’t know yet how to translate that into an app.

Conduct market validation 

Not only had I been avoiding people for many years; I’d also been avoiding conducting market research. Most advice on the internet seems to be “build the app that ~you~ want!” Well, I’m a strange person. I’m not sure the world wants the apps that I want. 

To figure out what the world wants, I realized I should probably do this thing called “market research.” So I signed in to Google Keyword Planner to see how often people search for terms relating to my app ideas.

My search revealed that only 50 people in the world search for the term "phishing gmail" every month. In comparison, 500 people search for “free parking app,” which explains why there are so many successful parking apps.

Again, many people probably do want a phishing plugin, but it’s useful for me to quantify how many people want a phishing plugin versus a free parking app, so that I can spend my time most productively.

Launch on paid platforms

Right after my Product Hunt launch, I called up my friend Bosen, an indie game developer, and cried (metaphorically) about how few paid users I had. “Of course you’re not making any money,” he told me, “You launched on Product Hunt!” He pointed out that Product Hunt apps rarely charge money, whereas iPhone and Android apps can charge money and still go viral. The iPhone Store, the Google Play Store, and Steam platforms all market your apps for you by sending out marketing emails and making your app searchable. (They want their 30% cut after all.)

Make a free tier if you want to go viral

I charged $6/month for Too Phishy because I was following the advice of Marc Andreessen, who said that startup founders always charge too little for their products. (And, as mentioned above, you can make real money selling apps.) But free versions are what go viral. 

Instagram and Calendly were free when they launched. Free versions are how you get free marketing. Because, shocker: a small team can’t afford a full time sales team, let alone one sales person, so Product Hunt and Twitter clicks are their only way to market an app.

Then how will I make money?

I’m not trying to be a billionaire here, but I need to pay rent. I’ve spent the past few months trying to figure out how I can survive as an indie app developer.

Eventually, I came to a fairly obvious conclusion. No, not getting a real job – life is too short for that – but becoming a freelance cybersecurity consultant and web developer. 

Funny story: a week ago, I added “CEO” to my Linkedin title (mostly inspired by my sister, an incredible startup founder). The second I did, I started getting tons of inbound messages from other executives on Linkedin. In fact, from that Linkedin interest, I set up a few calls, and I already have my first sales leads! So my plan is to spend 20 hours per week consulting, and the other 20 hours building products. Plus, this way, I’ll be able to find people with actual problems that I can build products for.

Conclusion

To sell my apps going forward, I’m going to have to talk to people a lot more (and having freelance clients should definitely help). I’m going to have to find customers before I build. And I’m going to need to ask other developers for ideas and feedback. With a new system in place – that is, focusing more heavily on early market research and customer feedback – I’m actually excited to start building researching my next product. First stop, Reddit.

🌟 Acknowledgements

I’d like to give credit to Lior Neu-ner’s great blog post that inspired me to write about starting over.

1920

Herbert O. Yardley, the founder of the Black Chamber (a government agency that proceeds the NSA), convinces Newcomb Carlton, the president of Western Union, to grant him access to all telegraphs going through Western Union. The overreach of government oversight begins.

1945

The Soviet Union gifts The Thing, a secret electromagnetic listening device disguised within a commemorative plaque, to Averell Harriman, the U.S. Ambassador to the Soviet Union. British radio operators discover it in 1951. This is the first electromechanical bug ever discovered.

1967

The Supreme Court holds in Katz v. United States that the monitoring and recording of private conversations within the United States constitutes a "search" for Fourth Amendment purposes, and therefore requires a warrant. (Prior to this, the 1928 ruling from Olmstead v. The United States held that wiretapping a private phone conversation did not violate the Fourth Amendment.) This is the beginning of courts requiring police to obtain search warrants for telecommunications data.

1978

The NSA's eavesdropping on Vietnam War protesters and civil rights activists motivates Congress to pass the Foreign Intelligence Surveillance Act. This act requires the NSA to have search warrants approved by a secret F.I.S.A. court in order to spy on Americans. Domestic spying ends for a brief moment.

1979

The Supreme Court holds in Smith v. Maryland that a warrant is required for the government to acquire the content of electronic communications. However, only subpoenas are required for the business records (metadata) of these communications. "Metadata" includes the phone numbers that an individual has dialed, and the location of phone communications.

1985

During Project GUNMAN, the NSA finds a Soviet bug attached to a typewriter inside the U.S. embassy in Russia, capturing every keystroke. This is the second electromechanical bug ever discovered.

1986 

• Karl Koch, A German hacker, is caught selling hacked information from United States military computers to the KGB. This is the first known cyberattack by Russia on American soil.

  

• The Electronic Communications Privacy Act of 1986 is enacted by Congress to extend restrictions on government wiretaps to include the transmission of electronic data.

1988

The Morris Worm takes down 60,000 computers. This is the first worm to take down more than 10% of the internet. Robert Morris Jr., the creator of the worm, is a fascinating individual: the son of NSA chief scientist Robert Morris Sr., he co-founds Y Combinator in 2005.

1996

The CIA’s CITO unit, the predecessor to the CIA's Information Operations Center, starts training spies to put NSA hardware – like spyware spiked microchips – in corporate supply chains.

1998

The CIH virus infects sixty million computers internationally, especially impacting countries that don't have widespread antivirus software. This virus hugely accelerates the awareness of the need for antivirus software.

2001

• Congress passes the Patriot Act, allowing the U.S. government to store phone records, including call logs (but not recordings), along with internet activity and text messages, for purposes of antiterrorism.

• The ILoveYou worm spreads globally. This is the first email worm to combine social engineering (who doesn't want to open an email that says "I love you"?) and a Windows vulnerability in order to spread quickly.

2002 

• Symantic buys Bugtraq, a public bug tracker, and makes it private. This is the beginning of private companies and governments paying hackers for exploits instead of publicizing known vulnerabilities. In 2007, Charles Miller, a security researcher, publishes a paper that reveals that government agencies like the NSA will pay hackers very high prices (usually $5,000 to $250,000) for discovering security vulnerabilities.

• The Pentagon announces the Total Information Awareness project. Funding is cut off one year later,  but the NSA continues to use its software to mine telephone conversations and web searches as part of Stellar Wind. This enables the NSA – with George W. Bush’s knowledge and consent – total, unsupervised access to all fiber-optic communications in the U.S. until 2004, when domestic communication data collection is deauthorized.

• The NSA installs a listener in Room 641A of the San Francisco AT&T building – along with more than ten other telecom buildings across the country – to collect all metadata relating to NSA-provided search terms. This later becomes public knowledge in 2013 when Snowden reveals the existence of Project UPSTREAM.

2005

China begins its Titan Rain espionage attacks on the networks of NASA and Lockheed Martin. This is the beginning of Chinese hacking on American soil.

2007

Russia conducts DDOS cyberattacks on Estonia, marking the beginning of what cybersecurity researchers often refer to as Web War 1.

2008

• The NSA deploys the Stuxnet worm to infiltrate an Iranian nuclear plant. This is the first cyberattack to use multiple zero days. (It uses four.)

• The Foreign Intelligence Surveillance Act of 1978 Amendments Act of 2008 expands the government’s ability to conduct electronic surveillance domestically without court orders, basically codifying what the NSA has been doing illegally. Congress grants telecom officials immunity not only from prosecution but also from civil suits.

2009 

Charlie Miller jailbreaks an iPhone, MacBook Air, and Android by directing users to a malicious website that allows him to see every keystroke. Google ignores his bug report so he starts a “no more free bugs” campaign. (In 2014, Google reverses its decision by starting Project Zero, an internal team that publicizes all bugs that Google knows about, and encourages other tech companies to do the same.)

2010

NSO, an Israeli cybersecurity firm that sells spyware – built using vulnerabilities found in popular mobile phone technologies like iPhone and Android – is founded. This is the beginning of the commercialization of the zero day industry.

2012 

Iran deploys the Shamoon cyberattack on Saudi Aramco to retaliate for Stuxnet.

2013

• Edward Snowden reveals that the NSA is storing U.S. citizens' phone records. His revelations unearth NSA programs like PRISM and MUSCULAR (which proved the NSA had hacked into Google without even Google knowing). A Pew report soon after the scandal shows that 46% of Americans are still not concerned about American surveillance.

• Der Spiegel releases a report that NSA TAO unit hackers have developed a program called DROPOUTJEEP that allows the NSA to track every keystroke on an iPhone. Next, Der Spoegel publishes a 50 page list of NSA exploits that journalists call "way more revealing" than the Snowden leaks. 

• Under pressure after Snowden, the Foreign Intelligence Surveillance Court reveals that, in 2012 alone, it approved 1,748 of the 1,789 applications it received to survey Americans.

2014 

• Google finds a bug in SSL called Heartbleed that allows 17% of the internet’s web server’s private keys to be stolen. This is the first vulnerability to affect as much as 17% of the internet.

2016 

• A group of hackers calling themselves the “Shadow Brokers” leak several NSA zero days, thought to be stolen from the home of an NSA employee. This is the first time the NSA is publicly hacked. The next year, the Shadow Brokers leak one of the most virulent of these vulnerabilities, nicknamed Eternal Blue, which is then used in two subsequent worldwide cyberattacks: WannaCry (see below) and NotPetya (also below).

• Russia hacks the Democratic National Committee through the famous John Podesta phishing email.

• The F.B.I. buys a zero day to jailbreak the phone of the San Bernadino shooting suspects. This is the first time the F.B.I. publicly acknowledges paying for a zero day.

• A North Korean hacking group steals $81 million from Bangladesh’s central bank. This increases public awareness of North Korea's hacking expertise; many say that North Korea trails only the U.S., Russia, and China in hacking capabilities.

2017 

• Chinese hackers commit the Equifax data breach.

• Wannacry, built using Eternal Blue, shuts down the U.K. hospital system.

• Russia conducts the NotPetya cyberattack on Ukraine (“Web War 2”) that cuts power across Ukraine in 5 hours. One year later, the U.S. Treasury announces sanctions against nineteen Russians organizations thought to be involved.

2018

NSO spyware called Pegasus is used to hack the phone of Jeff Bezos. His personal photos end up in the hands of the National Enquirer, which then threatens to blackmail him. In response, he releases the photos himself. This is the first scandal that puts NSO's phone hacking capabilities on the front page of the news.

2020

The SolarWinds cyberattack – likely the work of Russia's FSB security service – penetrates thousands of organizations globally, including multiple parts of the United States federal government. It spreads through these organizations via the Orion network management software, a product of SolarWinds. SolarWinds' development server's password was "solarwinds123," which allowed the hackers to get into the server and place malicious code in Orion's software toolchain. Brad Smith, President of Microsoft, calls it the "most sophisticated attack the world has ever seen.” He estimates that the attack required thousands of engineers to build and deploy.

2021

Russian hackers use an employee's leaked password to hack into Colonial Pipeline's servers, shutting down their servers until a ransom was paid. Since Colonial Pipeline supplies nearly half of the East Coast's liquid fuels, this becomes one of the most famous ransomware attacks on the United States. Luckily, Colonial Pipeline restores service within a day.

Sources

The Cuckoo's Egg (Clifford Stoll)

Sandworm (Andy Greenberg)

They Know Much More Than You Think, The New York Review (James Bamford)

This Is How They Tell Me the World Ends (Nicole Perlroth)

Unwarranted: Policing Without Permission (Barry Friedman)

To reduce procrastination and become faster at launching my projects, I’ve set the goal to launch 12 cybersecurity startups in 12 months. A few weeks after every launch, I do a debriefing on what I learned. Yesterday, I launched my third project, Too Phishy, an anti-phishing Gmail add-on.

I created Too Phishy to improve my ability to detect cleverly made phishing scams. I needed a tool — one that was easy and intuitive — to help when my better judgement wasn't enough.

I expected to build this project in two months. In the end, it took four months. Here’s what happened.

🌪️ Wait, didn’t I already launch a product called Is This Phishy? What happened to that?

Despite boasting 400 monthly active users in its first two months, my first project, Is This Phishy, saw its active user base drop down to one by its third month. (Hi dad!) 

It turns out that recognizing phishing emails is really hard. 

Too Phishy endeavors to be an improvement on Is This Phishy, using the lessons learned from Is This Phishy to provide better email analysis.

For example, Is This Phishy told you that an attachment might be suspicious, but it didn’t show you that someone named John Delacroix last edited the attachment. Similarly, Is This Phishy told you that an email contained a rarely seen link, but it didn’t show you that the link was hosted in Korea.

In short: Is This Phishy showed you beige flags; Too Phishy shows you red flags.

Also, I want to be funny with Too Phishy. Humor is a big part of my life and Is This Phishy was a little boring. Who says we can’t have a little fun while making sure someone hasn't stolen those 9 golden SSN digits?

🔮 So if Too Phishy is super fast, and super awesome, it must use AI, right?

Well, no. Too Phishy uses human-defined rules (defined by me) to analyze the two vectors of attack contained in an email: links and attachments. Building an AI — specifically an LLM model like OpenAI — requires millions (or billions) of data points from which a machine can learn, so building an AI model for recognizing phishing would take millions of phishing emails. Currently, there isn’t a big enough corpus of example phishing emails in the public domain to build such a model.1 

I'm planning to build a corpus of phishing emails with the aim of developing my own LLM. Right now I'm brainstorming the best way to achieve this — potentially incorporating this into the rollout and growth of Too Phishy itself. (Maybe I should offer a free month of Too Phishy for every phishing example sent to support@toophishy.com? Ideas are welcome.) 

Either way, I’m really proud of the human-defined model I created for Two Phishy: it is the only email plugin I’ve seen that shows you so much information in so little time, and lets YOU see all the hidden metadata in your emails that email providers hide from you.

I’d like to thank the Academy and ChatGPT for not helping.

ChatGPT is really useful, it turns out (who knew??)…for really specific coding questions. Like: How do i run the "node-exiftool" library on a Gmail email attachment in NodeJS? Or, What are the allowable values for memory in an ECS task definition? Those questions yielded me perfect cut-and-paste answers.

But if you need help with high level questions like which technology to use for a given problem, look elsewhere. 

I asked ChatGPT, How do I get my Stripe app to use HTTPS? It told me to sign up for Stripe Enterprise and use their partner solutions team (a.k.a. paid consultants). I’m an indiepreneur eating reheated quinoa for the fourth day in a row – I don’t have that kind of money.

Next: Is there an easy way to set up a Stripe payments site? Answer: “Why yes! Use Wix or WooCommerce for WordPress!” Again, I’m flying economy here, why does ChatGPT keep asking me if I want more champagne. 

(I ended up building a Stripe payments React app from scratch and hosting it in Amazon ECS. And it still costs me $76.44/month to run, which was more than I anticipated spending.2 So maybe ChatGPT had the last laugh here.)

Worst of all was asking ChatGPT for help writing a Gmail add-on because – surprise! – there’s hardly any information online about building Gmail add-ons. Asking ChatGPT questions like What does a google workspace addon mainfest file look like for Gmail? yielded completely nonsense answers. Without the help of cutting-edge AI, I used the second-best scientific approach known to man – that is, typing hundreds of random lines of code until one of them worked – which eventually yielded results (and a lot of swear words on my end).

Also, I hate Stripe's documentation

Whenever I interview with a startup (for when I imminently run out of savings, or until my secret trust fund finally materializes…), they say “we’re the Stripe of home delivery” or “we’re the Stripe of dog food.”  In other words, Stripe is the gold standard of startups. 

However, once you start building a website that uses Stripe payments, you quickly realize that Stripe’s docs are famously chaotic, a result of building lots of features over the years and not updating their docs accordingly. For example, it took me an entire week to turn my payments form (yes, one form) from the one shown below to a more modern design because Stripe hasn’t yet written documentation for their new checkout page React component:

How was the app approval process for Google Marketplace?

I knew that the app approval process for Apple can take months (although they claim it’s now down to a day). But I’d never developed a Google add-on before, so I was curious how long it would take to get my app reviewed and approved by Google.

In the end, Google rejected my add-on eight times before finally approving it 31 days later.

🏷️ Why I’m Charging $6/month for it

As I ate microwaveable quinoa for the seventh time this week, I made the decision to price my app at $6/month.

At first, I had decided to price Too Phishy at a low price point in order to attract as many users as possible, so that I could build the AI model of my dreams. $1/month seemed reasonable to me, and would make Too Phishy a steal when compared to Gmail’s other add-on offerings, which go for $3 to $10 a pop per month. But then I read this advice from Marc Andreessen:

“The number one thing – just the theme and we see it everywhere – the number one theme with our companies have when they get really struggling is they are not charging enough for their product.” 

🌟 Acknowledgements

I’d like to thank Aixsha, my college suitemate, who was generous enough to share her enormous corpus of phishing emails with me (while she was under constant attack from some crazy people who hate WGA members), which I used as a basis as my phishing corpus for Too Phishy. Up until very recently, Aixsha was in the middle of experiencing constant phishing attacks while she was on strike. But don’t feel too bad for her – she’s getting vengeance on her attackers as we speak by writing a television pilot about it.

I’d also like to thank my friends Mona and David who also contributed their phishing emails.

Appendix/Optional Reading 

🕰️ How I spent my time

In this section, I’ll show you how I spent each week and describe the problems I addressed.

Why? Because it’s messy, and seeing someone else’s mess can be encouraging. Also, it’s useful for me to keep track of the time I spent building an app. I learn a lot by seeing how wrong my estimates are: how quickly I complete “difficult” things and how slowly I complete “easy” things (ahem, Stripe payments).

Week 1

• Figure out: Are Gmail add-ons even profitable? 

• Found existing add-ons on the Google Marketplace, then searched for their Linkedin company pages, then determined how many employees they maintain over time to assess profitability potential

• Turns out that a few add-ons are full fledged companies! A good sign.

Weeks 2 & 3: Decide which payments provider to use to build Too Phishy.com in order to handle user payments 

• These weeks featured many, many tutorials

• For a payments solution, I went with Stripe because it’s the industry standard

• For a user authentication solution. I looked at Velvet, Stytch, AWS Amplify, Google Firebase, and others

• Realized halfway through that I don’t actually need an authentication solution in order to track customers, I can just use Stripe’s API to collect and track my customer info

Weeks 5 and 6: Productionize Too Phishy.com

• Figured out which cloud solution to use for running a web app (chose AWS ECS).

• I forgot how hard this is. Serving static pages on Cloudflare is one thing, getting an app running and making outside requests is another. This required piecing together 4 Stripe tutorials, along with 5 AWS tutorials, picking and choosing which parts to follow.

• Set up a CI system so that all code changes get automatically deployed to Too Phishy.com (went with AWS Codecatalyst because their tutorial was good)

Week 7:

• Tried to find online phishing corpuses to run tests on

• Realize a good corpus doesn’t exist

• Identified real life phishing emails for future examples

• (Thanks Aixsha!)

Week 8

• Took vacation

Weeks 9, 10 & 11

• Wrote Gmail add-on logic to parse and analyze email body and attachments

Week 12

• Submitted add-on it to Google for app review (OMFG so many requirements).

• Wrote Privacy Policy

  • Created graphic assets including screenshots

The short answer is a) no, and b) because of an accident of history.

The longer answer involves an obscure government agency, the passage of time, and the universal struggle to keep up with change.

Does adding complexity to passwords stop hackers?

In theory, a hacker can write an automated program that will guess thousands of passwords per second, so adding special characters to passwords makes them harder for a hacker to guess.

But ever since the early 2010s, when reCAPTCHA (and other innovations like rate limiting and multi-factor authentication) spread onto almost every web login imaginable, password-guessing attacks became impossible, because hackers would quickly run into a login attempt wall. For a long time I’ve wondered why password complexity rules still exist nowadays. So I decided to investigate.

Who came up with these password rules anyway?

If you’ve ever spent time in Boulder, CO, with a dad who admires government agencies that set the time for the rest of the United States (just me?) then you should be familiar with the National Institute of Standards and Technology (NIST). The basis for NIST’s existence goes way back to 1781, when the Articles of Confederation determined that Congress had the power to determine standard weights and measurements. Since then, NIST has been responsible for setting measurements like the exact standard of temperature (0 °C = 32 °F).

In addition to measurements, NIST also determines password guidelines for all U.S. government agencies. (Yes, I also found it astonishing that a government agency established in the 1700s now decides IT practices for the entire country.) All organizations that work with the federal government are required to adhere to NIST's guidelines in order to be considered for government contracts. NIST's influence has spread into the private sector too, where its guidelines are considered the gold standard by most IT practitioners.

NIST manager Bill Burr wrote SP 800-63: Electronic Authentication Guideline, the agency’s first authentication guidelines, in 2004, introducing password complexity rules to the world. Burr’s guiding theory behind complexity rules? If a password is easy for a user to remember, then it’s also easy for a hacker to guess:

Passwords chosen by users probably roughly reflect the patterns and character frequency distributions of ordinary English text, and are chosen by users so that they can remember them. Experience teaches us that many users, left to choose their own passwords, will choose passwords that are easily guessed.

Composition rules… can eliminate many obvious choices and therefore we believe that they generally improve the “practical entropy” of passwords.

The idea follows a certain kind of logic…albeit one backed by zero evidence. “Much of what I did I now regret,” Burr told the WSJ in 2017. Burr hadn’t had time to test any of his theories on actual passwords, and administrators at NIST had refused his request to look at the actual passwords on their network for empirical purposes. In fact, “they were appalled [he] even asked.”

In the absence of any other guidelines to follow, government agencies and private companies alike followed Burr's advice. Even today, 45% of the 120 most popular websites still require complex passwords.

Empirical evidence, finally available in 2017, showed that complex character rules make passwords no less easy to guess. Per NIST document SP 800-63-3 (first published in 2017):

Research has shown... that users respond in very predictable ways to the requirements imposed by composition rules. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

So adding a 1 or a ! to the end of your password isn’t going to make your password that much harder to guess.

What will? It turns out that it’s far more effective to make passwords long than to make them complex:

An 11-character password containing complex characters would take a computer 3 days to guess; a 25-character password containing no complex characters would take 550 years to guess.

In a nutshell: long and simple passwords are better than short and complex passwords.

Just how often does NIST change their password guidelines?

As I started reading these password guidelines documents, I became as fascinated by NIST as my dad, although my interest had less to do with time measurements than with the history of password guidelines.

Luckily for me, all of the password guidelines ever written by NIST are available online. (Kids, don’t let ChatGPT write your history papers. It told me that “NIST first recommended two factor auth” in 2006, but I already knew from the WSJ article that the first 2FA guidelines had been published in 2004.)

To make it easier for my future self to track these guideline changes over time (reading them wasn't thrilling enough) I made this table:

Reassuringly, NIST’s most useless password rules – like the 90-day reset rule and the password complexity rule, both written in 2004 – were out of fashion by 2017.

On the other hand, guidelines that make intuitive sense, like MFA, which was first recommended by NIST in 2004, have stuck around for ages. Some types of MFA, like text-message codes, have turned out to be susceptible to various attacks like SIM swapping. But others, like MFA that relies on biometric data or physical security keys (both mentioned in NIST’s 2004 guidelines), have proven quite safe over time.

Do companies keep up with these rule changes?

NIST’s tendency to change rules over time introduces an obvious problem: the rest of the world has trouble keeping up. ADP, the global HR company that managed payroll for my former employer, made me reset my password TEN times in four years.

So I asked my friend Reba, who works in IT for the government, why so many websites remain out of compliance with NIST guidelines. She explained that many government agencies – and non-government agencies – don't have the time or money to follow NIST guidelines. “It’s a matter of not having enough budget to rebuild an agency's entire authentication system,” she says.

Since password rules change faster than organizations can afford to implement them, outdated rules are here to stay. So, for the foreseeable future, we'll just have to keep adding “N!ST” to the end of our passwords (...just me?).

So this month’s startup – startup #2 of my 12 startups in 12 months – is not a software product: it’s a startup incubator.

When I launched my first startup, isthisphishy.io, last month, reddit commenters almost immediately asked me to turn it into an Outlook plugin, because they wanted a single click solution:

The problem was, I didn’t want to build an Outlook plugin. I tried to build one for a few weeks (which I detail below), but I’ve used Gmail for the past 17 years and didn’t want to switch to Outlook now. So I decided to ask the internet for guidance. I ran a marketing experiment of sorts: I made landing pages for all of my startup ideas, added A/B experiments to each landing page (i.e. “Download for Gmail” versus “Download for Outlook”), created Google Ad campaigns, and then waited to see which product idea got the most traction.

Thus, My Startup Incubator was born. It’s a place to test and stack rank nascent startup ideas:

⏪ Rewind to trying to build an Outlook plugin

Seven weeks ago, inspired by my Reddit commenters, I started building an Outlook plugin.

Then, three weeks ago, deep in the trenches of Outlook plugin development, I awoke in a cold sweat because I was four weeks into this project and had very little to show for it. Using Microsoft’s developer ecosystem was slowing me down. Just to get a Microsoft 365 Developer Account had taken me seven days of back and forth with various Microsoft support teams. And getting a free VS Code developer license had taken another three days of back and forth.

Along with my new stack slowing me down, one question kept echoing in the back of my mind: Is building a Microsoft Outlook plugin even the right thing to be doing?

That afternoon, I called my friend William – a fellow entrepreneur – to get his advice. I told him that building an Outlook plugin had taken me four weeks and I was only halfway done. I missed the Google and AWS developer ecosystem I was used to.

“If you want to build something people will use, don’t build anything,” he said. “Build an ad and see if people click it. Then only build something once it gets a lot of clicks.”

Hm, I thought, Ads? Will that really work?

I’d never built ads before, although I had heard of Google Ads.

Pivoting to Google Ads

Even though Google Ads is usually something you pay someone online $5k to do for you, I decided to build Google Ads campaigns myself. I knew I wasn't experienced enough to build an effective Google Ads campaign, but I was inexperienced enough to build three terrible Google Ads campaigns. And the point of an experiment wasn't to run good ad campaigns, but rather to compare product ideas using similar (-ly bad) ad campaigns.

Also, I figured that using Google Ads might end up saving me a lot of work in the long run. Last month, when I launched isthisphishy.io, I skipped ads entirely (for $$$ reasons). I launched the startup by posting about it on Reddit, Hacker News, Product Hunt, and twenty other sites. Posting on all those websites had been a lot of work. I had to track where all my users were coming from on my own, and retarget my future launch strategy accordingly. Google Ads will save me time, I figured. (Hah! Hah! Says future me.)

In the end, Google Ads did not save me time (see ad bans mentioned below). But I learned a lot, at least.

So here we are. And the experiment has worked: Too Phishy for Gmail is the idea that has gotten the most clicks so far, so expect to see a blog post on that startup next!

What I learned about Google Ads

In a nutshell: AI has not yet taken over the world. Setting up a Google Ads campaign is the most manual process in the world. When I launched my bare minimum campaigns using the default settings, I got absolutely no ad clicks. And yes, I even used the Performance Max campaign type which claims to use AI.

It was only after I manually defined the search terms I wanted my campaign to be shown with (e.g. “spam call”) that I finally started seeing some ad clicks and conversions. Considering that spamcallkiller.com contains the word “spam call” in the name, it doesn’t seem too crazy to think that some search terms should have been attached to my campaign by default. (I later learned that Performance Max campaigns have a lot of issues, and that many ad agencies have stopped using the tool.)

That being said, Performance Max, though expensive and buggy, did have some nice features. Its AI algorithm created polished Youtube ads for no additional cost:

Let’s talk money

I spent a godforsaken amount of money ($819) on my campaigns. Google Ads likes to proudly claim “you only pay for the clicks you get,” but as someone who got very few clicks, I quickly learned that Google Ads has a minimum spend they’ll charge you just for impressions. So they put my ads on a bunch of websites that no one clicked and charged me $40/day for it. Ugh.

ALSO, it’s really hard to get people in the United States and Canada to click your ads. When I set up my campaigns, this was the default audience Google Ads chose for me. Over time, since I was getting so few ad clicks, I expanded the audience to all first world countries, and got way more clicks, especially in India, Kazakhstan, Costa Rica and Argentina. I guess not a lot of companies pay for ads in those countries, so there's less competition for clicks? Who knows.

And oh yeah, Google banned all of my ads multiple times. Reddit tells me that ad bans happen to a lot of people. And when I set up appointments with Google Ads' support team, thinking that they’d actually show up given that I spent more than $500/month on their product, both support agents ghosted me. (Which has become common since the pandemic, I hear.)

After speaking with my friend Ron, a marketing executive, I realized that these bans likely happened because my landing pages had no organic online reputation (e.g. links from other websites), and basically just collected email addresses, so it's not shocking that Google thought they were scams. I've also learned recently that Facebook Ads, since it doesn't track websites' reputations, is much less likely to ban ads. (Good to know for next time!)

Going Forward

I hope that by being transparent about my first experiment running Google Ads campaigns, it’ll encourage readers to share your tips and help me fill in any gaps in my knowledge.

Do I think it was truly worth it to spend $819 to learn that there’s more market demand for a Gmail plugin rather than an Outlook plugin? Honestly, maybe: that’s how much two hours talking to a marketing consultant would probably cost anyway.

Plus, I learned a lot. Going forward, I feel more confident about how to estimate product market fit before building products. And next time I'll use Facebook Ads, instead of Google Ads, for marketing not-yet-existing products.

Thanks for reading Lydia’s Substack! Subscribe for free to receive new posts and support my work.

And here we are! One startup done, six weeks passed. (Yes, the plan was originally one startup per month, but have you tried to create a minimum viable product in only a month?!?)

For each startup I launch, I’ll be writing a post like this, and explaining how it achieves my broader goal this year to make cybersecurity products more accessible to a wider audience. Since this was my first startup, I wanted to make something that would be useful for everyone from your kid brother to your grandma: an elegant email server that can identify phishing emails.

🤔 The Problem

The problem is that every time I get a sketchy email, I never know whether it's a phishing scam. When I google “how to identify a phishing email," hundreds of websites offer one hundred different answers. My cousin works at a big bank, and she told me that bank customers can send suspicious-looking emails to the security team, and they’ll tell you whether it’s a phishing attempt. That’s what made me realize there needs to be a similar service for any person, for any email, anywhere.

🛠️ Solution

Say hello to help@isthisphishy.io, a friendly email address that you can forward any and all emails to (for free), and you’ll get a response telling you why or why not the email is a phishing scam. 🎣📩 Check it out at isthisphishy.io.

🚨 The Launch

One month after its launch, Is This Phishy was featured on prominent blogs like Insanely Useful Websites, the OneLaunch blog, the Mike Taylor blog, and Beta List. It also reached 403 monthly active users in its first month.

Since this was my first launch ever, I followed the advice of Read Make and took a "spray and pray" approach, posting about my launch everywhere from Twitter and Reddit to Indie Hackers.

The single biggest social media response came from my post to Reddit's r/msp (managed service provider) community, which garnered 23,200 impressions and a big uptick in users. Before posting, I didn't realize that the group had 148k members worldwide; I simply wanted good feedback on my landing page. I started laughing incredulously when I noticed that the post had 4,000 impressions only a few minutes after I'd posted it. In the end, I got 39 comments from people who cumulatively had decades of IT experience. (I know this because I DM'd some of them to get feedback on future product ideas.) Many commenters, unsurprisingly, wanted more security transparency before they used my service. This feedback inspired me to add a security notification to the top every email:

Additionally, my post to LinkedIn fetched 3,422 impressions and 96 likes, by far the most "likes" I got anywhere. (By comparison, my post to Hacker News got only 4 likes.) I was surprised and pleased by the number of friends and former coworkers who saw the post on LinkedIn and reached out to say they'd shared Is This Phishy with their IT team. Some even sent me the feedback from their IT teams which was especially helpful.

In the first week of launch, Is This Phishy made it to #45 on Product Hunt (out of 144 total product launches that day), and over 400 people viewed it:

💰 Biggest win: IsThisPhishy.io costs only $26.66/month to build and maintain

I’m most comfortable with AWS, so I decided to use AWS for this project. Whenever I researched email server solutions, AWS was always much cheaper than competitors like Mailgun: AWS SES only costs $0.10 cents per 1,000 emails sent, while Mailgun costs eight times more. This means that my costs for running isthisphishy.io are REALLY low, so I can offer it for free.

Expenses to maintain the isthisphishy.io site:

• $89/year: cruip.com for static website design template (this was a one time purchase but for simplicity I’ll record it as an annual purchase)

• $36/year: Registering domain name isthisphishy.io on Cloudflare

• $0: Cloudflare pages for hosting

Expenses to maintain the email server:

• $16/month – Amazon Workmail (for an email client interface to read the emails sent to my four @isthisphishy.io email addresses)

• $1.39/month – Amazon Simple Email Service (for receiving and sending automated emails)

• $0.09/month – Amazon Simple Storage Service (for storing emails in the cloud)

• $0.01/month – AWS Lambda (for running arbitrary code in a container when an email is sent to isthisphishy.io)

• $0.07/month - Amazon Elastic Container Registry (for hosting container images containing the email server code)

• $0.01/month - Amazon Cloudwatch and Simple Notification Service (for getting alerts when things go wrong)

Total: $27.99/month

⌛ How I managed my time

I started this app on Monday, April 3. I posted it to Product Hunt on Wednesday, May 17. Total time to launch: six weeks.

The approximate time breakdown of the 6 weeks was spent as follows:

Week 1: Researched which stack I’ll use

• Spent time figuring out the cheapest way to send emails (Answer: AWS SES)

• Spent time figuring out the cheapest way to make a landing page (Answer: cheap online templates + Cloudflare pages)

Week 2: Took vacation!

Week 3: Made a bare-bones MVP (minimum viable product) to see if the stack would work

• Basically, at first I made an AWS Lambda function that responds “Hi” when you send it an email.

• Then I added some simple rules.

Week 4: Created a landing page for the website

• Competitive research: what products existed and how they marketed themselves.

• Came up with a vision for the landing page and found an online template to match it.

• Wrote copy for the landing page (which was surprisingly difficult and time intensive).

Week 5: Solicited feedback from beta users (a.k.a. found bugs and fixed them)

• At this point, I sent out my beta version to a few close friends and mentors. They found inevitable issues and bugs, so this time was spent addressing those.

Week 6: Added a feature where the email server checks the top one million most popular domains

• This feature wasn’t a must-have for launch, so I was torn. Adding it flew in the face of my bare-bones ethos, but I felt strongly that it should be included. In the end, I think I made the right choice here.

💪 Reflection on Productivity

Ever since reading The 4-Hour Workweek, my life goal has been to accomplish as much as possible in as few hours as possible. (Ideally, 4 hours of work per week.)

For the past six weeks, I worked around 5 hours per day, 6 days a week, so I worked a 30-hour week. Certainly, I came nowhere close to Ferris’s 4-hour per week target, but he was selling muscle supplements, and I’m building a web app, so I’ll forgive myself the 26 extra hours.

These are the things I did well productivity-wise that I will continue:

• Only do what feels fun on a given day: This philosophy was inspired by advice from my friend Pooja. I always try to have 3 pots cooking simultaneously: blog drafts I’m working on, app code I’m writing, and business activities like tracking costs or signing papers. Some days I wake up and want to work on code, while others, I wake up, and write. To keep myself motivated, I do whatever feels like fun that day. That way, I keep my energy and motivation levels up. (In the spirit of honesty, signing business forms is something I never wake up wanting to do. So I force myself to do that one, but only when I have lots of energy/coffee.)

• Use a coworking space: As someone who used to work from home most of the time, splurging on a coworking space has been a game changer. Having a separation of home and work keeps me more motivated because I get time to relax every day when I’m in my “home” space. (And by “relax,” I mean watch Love is Blind.)

Things I could do better next time:

• Get to my coworking space earlier: I now realize it takes me about 1.5 hours to actually start coding after I sit down at my computer – after all, there’s Architectural Digest to read, and Harry Styles’ love life to track. It takes a really long time to warm up my brain. I need to just accept this, plan for it, and sit at my desk sooner in the day.

• Go straight to the docs: Instead of wasting time watching tutorials on youtube, I wish I’d gone straight to the AWS docs sooner. This was the main AWS tutorial I used for building the MVP of my email server, and I wish I’d started with it. There’s a lot of bad training content on the internet, and I need to ensure I’m using the most trusted online sources. (Yes, this is a jab at ChatGPT.)

Biggest technical learning: Parsing forwarded emails is surprisingly hard 📨

I built my MVP in Python first, only to realize three weeks in that Python does not have any libraries to parse forwarded emails. Different email clients – Gmail, Yahoo Mail, Outlook, etc. – all format forwarded emails in different ways, so it’s actually really complicated to parse something as simple as the “from” sender on a forwarded email. And I didn't want to build a parsing library from scratch in Python – I only had one month! The only code I could find online that could parse forwarded emails for all email clients was written in Javascript: email-forward-parser, which is an amazing library from Crisp. This meant that halfway into this project after I’d built my MVP in Python, I had to rewrite everything in Javascript, which I hadn't coded in since 2019.

The silver lining: being an independent developer allows me to choose my own technical stack, which I’ve never been able to do before. I was able to switch to JavaScript on a dime to best serve my development needs, which was very liberating!

The most valuable way you can help me is by providing feedback and ideas👂

Please comment below.

I’d been interested in cybersecurity ever since the Cambridge Analytica scandal in 2018 when I discovered that Facebook advertisers had free access to my private messages without my knowledge. Ever since then, I’ve believed that people should have the right to know where their data is and who’s using it.

In fact, I originally became a software engineer to make technology more accessible to people. But after almost a decade of solving difficult technical problems, I suddenly realized that I’d lost track of the thing I had originally set out to do.

As I considered my options this past Spring, my friend Amir texted me, “You should read this!” He sent me the blog post I'm Launching 12 Startups in 12 Months by indie developer Pieter Levels.

In the post, Levels argues that indie developers should push themselves to release “startups,” which he describes as simple apps to which you can add more features later.

Levels makes the case for building 12 startups in 12 months. His theory is that building something new every month ensures you don’t spend too much time focusing on perfection: “AirBnB started as a company selling Obama-themed cereal, while Dropbox was just Drew Houston building a graphical user interface for rsync as a side-project.” Many amazing businesses have humble beginnings as one-off apps.

Upon reading the post, I realized, This is what I want to do. Specifically, I want to build cybersecurity startups.

The cybersecurity field genuinely requires deep technical knowledge, but still, I’ve been astounded by how much the literature uses obscure industry-speak to explain simple concepts. Someone needs to demystify cybersecurity for consumers and developers, so why not me?

Thus, I’ll create and post one new cybersecurity startup each month for the next year.

Cybersecurity apps should be built for individuals, not just companies.

“Cybercrimes” are the new Regina George. Hackers have hurt so many of my friends: stolen their social security numbers, ruined credit scores, or posted personal photos online. Yet most cybersecurity protection apps are built for companies and are inaccessible to the average person.

Women are cybersecurity customers too.

You know what the average cybersecurity app looks like: dark gray background, lime green color scheme, sans serif font, and an overall aesthetic that screams, I’m a character in a David Fincher film.

Instead of a design scheme that speaks to a precocious, terminally online 12 year old, I want cybersecurity products with pink logos. Or funny, approachable emojis. Or really anything that doesn’t revolve around making the user feel secure in their masculinity.

When a hack is worldwide news, it targets women more than 50% of the time (see: Gamergate, Celebgate, and even the Sony Pictures Hack, which was most famous for leaking all of Amy Pascal’s emails). Yes, famous men get hacked too, but it isn’t the rule. It’s women who tend to be victimized by rote, everyday hacking like revenge porn.

I myself live in terror of what’s published online about me. When I first heard about the website haveibeenpwned.com, which tells you if your email address has been in any security breaches, I waited two months before having the courage to check it. Sure enough, my data had been leaked in TWELVE different breaches.

I truly believe that if haveibeenpwned.com had a less intimidating interface, and looked more like the websites I already use, then I wouldn’t have been so afraid to use it.

Interestingly, women are actually more willing to spend money on cybersecurity than men. Recent survey results show that women are more concerned about their online data being misused than men are, meaning that by subtly gendering cybersecurity design, there’s a huge market left completely untapped.

Customers are smart. They deserve to know how things work.

So many cybersecurity tools use artificial intelligence and machine learning to detect issues. These tools are amazingly powerful, but they obscure the mechanics at play. I want to build apps that explain not just the what but the how.

Apps need to prioritize looking nice on mobile devices.

I'm amazed at the number of security apps I use that look ten times better on desktops than on mobile devices. You know what I mean: huge fonts, pictures that get cut off sideways, and spacing that looks like it’s from the original Space Jam website. Given that 60% of the world now accesses the internet on a phone, it’s time to build for mobile devices from the get-go. Especially as mobile devices increasingly prioritize transparency around user apps and privacy, which desktop computers don’t.

Finally, your operating system shouldn’t matter at all— apps should be built for the browser.

Your data deserves to be protected no matter which operating system you’re using. With cybersecurity software, there’s usually one tool for Windows, and one for Linux. Coming from a background in building database software, which has slowly but surely moved to a browser-based model, it surprises me that cybersecurity apps are rarely developed for the browser. You know, that thing we invented in the 1990s?

Since browsers are built to run on any operating system, any app built for the browser gets operating system compatibility for free.

Ready, Set, Go.

I want to build products that speak to a broader audience: that appeal to all genders, work in the browser, and look good on mobile devices. Can't be that hard, right?

And with that, we're off! See you at app #1!

My progress report

#1: Is This Phishy

Read my recap here.

#2: My Startup Incubator

Read my recap here.

#3: Too Phishy

Read my recap here.

#4: Starting Over/Becoming a Software Engineer Contractor

Read the whole story here.

The short answer: it's free and super accessible to everyone, everywhere. (We’ll get more into WhatsApp’s merits soon.)

But this blog post isn’t about WhatsApp’s explosive growth. It’s about a privacy notification in the year 2021 that told users that their data was being shared with Facebook, and how that caused WhatsApp’s growth to slow to its slowest rate since 2012, and pushed Telegram to the #1 position as most downloaded app of January 2021.

Why didn’t WhatsApp’s growth slow in 2014, when Facebook acquired WhatsApp? Or in 2016 when WhatsApp started sharing user data with Facebook? Why was one privacy notification enough to send away hundreds of millions of users?

To answer those questions, let’s go back to 2014…

The $19 billion Acquisition

Ah, 2014, those were the days – before I’d ever heard the term “millennial dread”, lived without a roommate, learned what encryption was, tasted rolled ice cream, or fully registered that all of my internet data was being stored by the NSA. I miss 2014.

I still remember the day that Facebook bought WhatsApp for $19 billion, 19 times the price it paid for Instagram. At the time, I was working as a junior web developer at a small startup and learned about the acquisition over lunch. “Can you believe it, $19 billion?” my teammate Arjun asked me. “They have only 55 employees. Those must be the richest employees in history.”

“Wait, what’s WhatsApp?” I replied, while chewing my sushi.

What’s WhatsApp?

WhatsApp, it turns out, is a cell phone app that allows you to send messages through a smartphone app, avoiding SMS fees. Usually, when someone with an Android phone texts someone using an iPhone, they pay an SMS fee. Those fees can be quite high in places like Europe and the developing world where telecommunications companies have monopolies.

Starting in 2009 with iMessage, messaging apps started to surge in popularity because they avoided SMS fees. By 2014, WhatsApp was the only free mobile messaging app that was available on all phones including feature phones.

At the time of the Facebook acquisition, though, WhatsApp was much more than just a tool to avoid SMS fees. It was the only messaging app in the market that offered a truly global product, running on all major mobile operating systems from its inception: iPhones, Androids, Blackberrys, as well as the feature phones that are popular in developing countries. (This part will become important later.)

Plus, WhatsApp offered tons of languages since its founding, helping it to spread globally: “In the startup’s first year, they offered the service in German, Spanish, French, and Italian, among other languages,” Wired explained at the time.

It's true that WhatsApp's competitors, like iMessage and Telegram, offered features that WhatsApp didn't, like encryption (more on that later). But iMessage only worked – and still only works – on iPhones, a limiting factor that means that only 30% of smartphone users can ever use it. And Telegram was brand new to the market.

19 billion dollars

The acquisition was a true Cinderella story. WhatsApp’s founders, Jan Koum and Brian Acton, had applied to be engineers at Facebook in 2007 ("We're part of the Facebook reject club," they later said), only to be acquired by Facebook seven years later for the largest acquisition of a venture-capital-backed company in history.

The 19 billion dollar price tag seemed crazy at the time. It came out that Google had also sought to buy WhatsApp, which certainly drove up the price. Most significant, though, was how badly Facebook wanted to continue its breakneck speed of growth in developing countries, and how much it was willing to pay to gain entry to countries where WhatsApp was already quite popular. WhatsApp had 450 million monthly active users in countries that Facebook didn't, and Facebook wanted to understand these users: specifically their behavior, cell phone characteristics, and feature requests.

From an ethos standpoint, you may be wondering what exactly the WhatsApp founders gained from being owned by Facebook – besides the obvious 19 billion things – since Facebook’s business strategy was always surveillance-at-all-costs, and WhatsApp doesn’t even store your name. Koum, who grew up in the USSR during the 1980s, famously wrote during the acquisition, “Respect for your privacy is coded into our DNA, and we built WhatsApp around the goal of knowing as little about you as possible: You don't have to give us your name and we don't ask for your email address. We don’t know your birthday.” (To this day, you don’t need a name to sign up for WhatsApp.)

But Koum and Acton seemingly chose to ignore the obvious: that Facebook was going to get these users' data eventually.

Enter: WhatsApp’s Encrypted conversations

When Facebook bought WhatsApp, WhatsApp was in the middle of a multi-year effort to build end-to-end encryption, something its users frequently requested, and something the founders cared deeply about. (Plus, as we’ve discussed, competitor apps like iMessage and Telegram already offered encryption.) Finally, in 2016, WhatsApp launched end-to-end encryption, which meant that all WhatsApp conversations were disguised into machine-readable text that people like the NSA wouldn’t be able to read (without a warrant). Acton told Wired at the time, “I don’t really want to be in the business of observing conversations.”

Wait, doesn’t total freedom of speech online often breed extremist, criminal, or outright gross thought spaces? you might be thinking.

Well, yes… good point… but we’re talking about 2016, back when popular opinion was SUPER on the side of encryption. This was right after the Edward Snowden leaks, and people associated encryption with journalists and whistleblowers (like Snowden), not yet drug lords and arms dealers.

Zuckerburg, unsurprisingly, was supportive of end-to-end encryption throughout the acquisition. He even added a feature called "secret conversations" to Facebook Messenger that used the same encryption protocol as WhatsApp. And of course he was supportive: encryption kept Facebook free of responsibility for illegal activity conducted on their apps. If Facebook couldn't read the messages that were sent by users, they couldn't be held liable. (Even back then, Facebook struggled with ferreting out revenge porn and other illegal content.)

End-to-end encryption for messages is still used in WhatsApp to this day, and has certainly helped WhatsApp continue to grow. But that doesn’t mean that all of your WhatsApp data is safe, as we'll soon see…

The new privacy policy

In late 2016, the inevitable happened. WhatsApp changed its terms and privacy policy so that Facebook could make ads more personalized. As the founders explained in their blog (was a gun pointed at them when they wrote this?), “by coordinating more with Facebook, we'll be able to do things like track basic metrics about how often people use our services and better fight spam on WhatsApp. And by connecting your phone number with Facebook's systems, Facebook can offer better friend suggestions and show you more relevant ads if you have an account with them.” From this point onwards, WhatsApp data would be an input to Facebook’s ad targeting.

Koum and Acton fought this change tooth and nail, but eventually conceded defeat. After the privacy policy was announced, they left Facebook, famously leaving behind $400 and $180 million, respectively, in unvested stock. To his credit, Acton admitted that he'd chosen money over his privacy ethos, saying “I am a sellout. I acknowledge that.”

Enter: Telegram

Telegram has been around since 2013, and in many ways it’s a clone of WhatsApp if WhatsApp had never been acquired by Facebook. Telegram’s founders, like WhatsApp’s, were born in the Soviet Union and built the app to protect people’s data from authoritarian governments. Telegram even uses a green color scheme that looks like WhatsApp, including green double-check-mark read receipts.

But Telegram is a not-for-profit company. It is based in the British Virgin Islands. It doesn’t want to get acquired by anybody, and it even stores all its data in offshore servers to avoid government data requests.

Because Telegram was founded four years after WhatsApp, it was always second fiddle. Then 2021 happened.

The Privacy Policy Notification

In January 2021, Facebook’s parent company, Meta, launched WhatsApp Business, a new service that would allow users to message directly with businesses through WhatsApp. Meta sent out an official announcement that laid out WhatsApp's existing privacy policy – which had been in effect since 2016 – along with a caveat that businesses would now be able to see "what you're saying" and use it for their own "marketing purposes":

Some large businesses need to use hosting services to manage their communication. Which is why we’re giving businesses the option to use secure hosting services from Meta to manage WhatsApp chats with their customers, answer questions, and send helpful information like purchase receipts. But whether you communicate with a business by phone, email, or WhatsApp, it can see what you’re saying and may use that information for its own marketing purposes, which may include advertising on Meta.

In addition to the confusing wording about businesses having access to your message contents, the announcement didn't explicitly explain what was changing. It only explained what Meta wouldn’t collect, and didn’t explain what Meta would collect, so users probably assumed that anything not mentioned in the policy would be collected. (Events like Cambridge Analytica hadn't exactly built trust).

After the announcement, users flocked to competitor apps like Telegram. A week after WhatsApp sent out the privacy change notification, Telegram added more than 25 million users over the previous three days, pushing it to over 500 million users.

Telegram officially became the most downloaded app in the world for January 2021, officially dethroning WhatsApp.

Can Telegram maintain its hold over WhatsApp?

But not everyone cares about security. People are turning 13 and getting new phones, and they’re installing the apps that their parents use. While Telegram was the most popular Android messaging app of 2021, WhatsApp regained first place in 2022, according to Meltwater's 2023 Digital Report:

WhatsApp might very well keep its #1 spot for the foreseeable future (until TikTok adds better messaging, hah). But we saw something interesting happen in 2021: that WhatsApp sacrificed a significant corner of its market by revealing its lenient stance on privacy. To this day, Telegram is the most popular messaging app in ten countries, including Cambodia and Iraq, the majority of which have authoritarian governments. So Telegram hasn't completely lost its market hold.

It will be interesting to see if WhatsApp and Telegram diverge further in their privacy feature set over time, and how users respond to these changes.

As a fancy technologist who enjoys looking at celebrity real estate, my three favorite websites are wired, architectural digest, and curbed, and all of them allow me to read a few articles per month before a paywall goes up. Occasionally, I send article links from these sites to my nearest and dearest, and often get the same response: “I can’t see the article, it’s behind a paywall.”

You must be joking me!! I scream internally. College graduation rates are the highest they’ve ever been and no one knows how to get around a paywall. (I’m looking at you, mom.)

That was mean, sorry.

It’s unfair of me to complain that people don’t know how to get around paywalls, when paywalls are so annoying (and expensive) in the first place. I find it crazy that wired.com expects my mom to also buy a subscription to wired.com just to read the articles I send her. I get annoyed whenever I think about paywalls, because they're preventing us from sharing information.

On the other hand, I’m a realist and I know that content can’t be free. Someone has to pay for fun articles, whether it’s readers, advertisers, or benevolent billionaires (oh wait those don’t exist). I’ve watched the tug of war between content creators and paywall evaders for the past ~10 years, and I’ve noticed a few interesting things.

Cookies

First, I should explain what cookies are, and how websites use them for paywalls.

Let’s say you visit wired.com, and wired.com only allows you to view one article per month before you have to sign up for a subscription. So when you visit the site in a Chrome browser, wired.com will add a cookie in that browser saying you visited their site. Next time you visit, tada!, you’ll see a “You’ve hit your monthly limit on free articles, please subscribe now” popup. But – excitingly for those of us who spend way too much time avoiding paywalls – if you visit wired.com in a Chrome Incognito browser, the cookie from your non-Incognito browser won’t carry over, allowing you to view one article anew. (The same will happen if you switch to Firefox, or to Firefox Private Browser, or to Internet Explorer, and so on and so forth.) There’s also a somewhat harder solution, which is to delete the cookies manually in the “inspect” page of any browser:

There are also other, more complicated, workarounds for avoiding cookie-based paywalls, like using the Wayback Time Machine, or the Reader Mode browser extension, or others that you can find online.

Paywall History Exhibit A: The New York Times

Remember 2011, when you could delete everything after the “&gwh” in a nytimes.com url, and the paywall would just disappear? Those were the good days.

By now, the New York Times has caught on to my — and everyone else’s — paywall evasion schemes, so as of 2019, they’ve stopped allowing ANY free visits to their site. You visit, you subscribe, you read. So in late 2019, I grudgingly signed up for a digital subscription to the Times. And so did the rest of the world.

In the first half of 2020 alone, the Times added one million users:

I’d bet that The Boston Globe, the Los Angeles Times, and everyone else are likely to copy the no-free-articles system in the next few years (unfortunately for me).

If cookies weren’t Big Brother enough for you, don’t worry, there’s always IP addresses

Okay cool, so we’ve seen how companies can work around the cookies-don’t-really-work problem.

Streaming services have a slightly different problem. They’ve already done what the Times has done, requiring you to subscribe before you can view their content. But human beings are conniving things, and they quickly figured out a low-tech way to get around having to pay: password sharing.

I’m sure the Times has suffered from lots of password sharing over the years, but they don’t have the hundreds-of-millions-of-dollars in engineering resources to address it. Netflix, on the other hand, has an unlimited R&D budget, and they recently caught on to how much money they’re losing to password sharing, saying in their 2022 Q1 that “In addition to our 222m paying households, we estimate that Netflix is being shared with over 100m additional households.” 100 million households is a lot of lost money; if we assume that Netflix makes around $11 per customer, that means they’re losing out on $1.1 billion per month.

So Netflix decided to crack down on password sharing, and they decided to do it using the concept of "households". Households cannot share accounts, and by their definition, one IP address constitutes a “household.”

Just last month, Netflix added a footnote to their subscription plan page that explains “Only people who live with you may use your account.”

Too lazy to fake my IP address

Now, it should be stated that it’s possible to fake your IP – one popular option is to use a VPN, for example –but Netflix has started cracking down on VPNs, and I'm too lazy to play cat and mouse with Netflix, especially when their cheapest subscription is only $6.99/month. Cheaper than Hulu and HBOMax!

So once again, I’ve given up on playing cat and mouse with large corporations who want me to upgrade from their freemium plan.

In conclusion

Why do we live in a world where it's impossible to share content online? Why can’t my Times subscription allow me access to the Post, or my Netflix subscription allow me to watch a few episodes of HBO Max? Instead, internet content has only bifurcated over time, with TV companies creating their own online subscription services to compete with Netflix, and more and more news websites adding paywalls of their own. In the pre-internet age, we had to share articles by clipping them and sending them via snail mail; it feels like with all the technological innovation we’ve seen in the past decade, we’re right back where we were in the first place.

FAQ

What are the ethical implications of using methods like cookie deletion or IP address manipulation to bypass paywalls?

Ethical implications of circumventing paywalls involve considerations of fairness and sustainability in content creation. While it may seem innocuous to delete cookies or use VPNs to access free content, these actions undermine the financial model that supports journalism and creative industries. Content creators rely on subscriptions and ad revenue to fund their work, and bypassing paywalls reduces their ability to sustain quality journalism and entertainment. Moreover, such actions may violate terms of service agreements, potentially leading to legal consequences. Therefore, while frustrations with paywalls are understandable, ethical users often opt to support content creators through legitimate subscriptions or other authorized means.1

How do paywall strategies differ between different types of content providers, such as news websites versus streaming services like Netflix?

Paywall strategies vary significantly between news websites and streaming services like Netflix, reflecting the distinct nature of their content and revenue models. News outlets often employ metered paywalls, allowing limited free access before requiring a subscription. This approach aims to balance audience reach with revenue generation from dedicated readers. In contrast, streaming services typically offer no free content, relying solely on subscriptions for access. Strategies also differ in how they combat password sharing; while Netflix restricts account sharing based on IP addresses, news sites face different challenges with user authentication. These differences highlight how paywall strategies are tailored to the specific needs and dynamics of each industry.2

What are the broader implications of the trend towards exclusive content and paywalls on accessibility to information and cultural exchange?

The trend towards exclusive content and paywalls raises concerns about the accessibility and democratization of information and entertainment. As more publishers and platforms adopt paywalls and exclusive content models, access to diverse viewpoints and cultural content may become increasingly restricted based on economic means. This trend could exacerbate digital divides, limiting access to crucial information and cultural exchange among different socioeconomic groups. Moreover, the fragmentation of content across multiple subscription services may lead to consumer frustration and higher costs, potentially reshaping how individuals consume and share digital content. Addressing these broader implications requires balancing the financial sustainability of content creation with ensuring equitable access to information and cultural expression in the digital age.3

Until recently, I didn’t realize that police could use my Google search history to convict me of a crime. I also didn’t realize that Google itself can use my search history to sue me. This post is about my slow wake up call to the Big Brother world of Big Data.

As a United States citizen, I know how search warrants work: if the police request a search warrant, and if the court system approves it, the police can enter my home and search through my personal belongings. But in terms of my internet browsing history, I've always assumed that the data I create is so vast that it was untraceable. Really, who’s going to record the 500 celebrity gossip pages I visit per day? (And which government agency actually cares enough to store that information?) I know, call me naive, but logging onto a computer and visiting different pages of the internet felt sacred to me.

Alas, my idealism was misplaced. The government can access people’s search histories any time. Don’t believe me? Look no further than the 2012 LinkedIn hack, the hack that taught me how far the FBI's tendrils extend.

How the FBI finds hackers using search warrants

If you, like me, got a password reset notice from LinkedIn circa 2012, then you may already know about the LinkedIn hack of 2012. In it, a Russian hacker named Yevgeniy Nikulin stole 6.5 million LinkedIn users’ email addresses, usernames, and passwords, and then subsequently used those credentials to hack into other companies like Dropbox (from whom he stole 20 million users' data) and Formspring (from whom he stole 420,000 users' data).

But no matter how many databases Nikulin hacked, he was never going to have as much data about LinkedIn users as the FBI had about him. After the hack, the FBI spent four years collecting Nikulin's online data so that they could charge him for identity theft and computer intrusion. First, the FBI traced the original hack to the email address r00talka@gmail.com. Next, they asked Google for the search history associated with r00talka@gmail.com, and Google gave them everything, including google searches for a dentist near Moscow. And it wasn't just Google that complied with the warrant. Microsoft, Vimeo, and Automattic (the parent company of Wordpress) also complied.

Enter: The Fourth Amendment

In some ways, I’m okay with the government being able to retrieve information from Google in order to solve crimes. After all, the Fourth Amendment protects U.S. citizens unreasonable searches and seizures by the government. If the FBI wants someone's data, they probably have a good reason, right?

But I’m beginning to realize just how often government search warrants stretch the definition of "reasonable." Just a few months ago, police in Nebraska prosecuted a 17-year-old girl for getting an abortion, all using data acquired from Facebook through search warrants. And how did they get a search warrant for the girl’s Facebook message history? They told Facebook that they had evidence that she had burned and buried the baby (because they found the fetus discarded in a bag).

However, once the police read the Facebook messages, they realized that she had aborted the baby, not burned it, which changed the investigation from a murder investigation to an abortion investigation.

I am disturbed by Facebook's willingness to hand over the girl's records so readily. In fact, Facebook has stated publicly to the New York Times that, in the first half of 2020, they complied with 89% of search warrants received. By comparison, Google complied with 83%, and Apple only complied with 43%.

Tech companies also use their records to sue employees

Even more disturbing than tech companies handing over records to the government so readily is that they also use these records to sue their own employees.

In 2017, Google sued two top self-driving car engineers, who had quit Google and started working at Uber, for stealing Google’s self-driving car research. In the lawsuit, Google claimed that one of these engineers had – prior to leaving Google – googled things like "how to permanently delete google drive files from my computer."

If Google deems it necessary to publicize its employees' search history (like if 245 million dollars’ worth of AI car research is on the line), they will.

And for those of you who were reassured by Google’s new security policy that allows users to automatically delete all of their Google data – including search history – every three months, listen up. That policy only applies to Google search history, not Gmail emails themselves, which are still stored indefinitely, and which Google clearly hands over fairly freely. (See the aforementioned 83%.)

Sleep tight!

My point is, for those of you – like me – who long thought that your personal data is sitting pretty in a data center, not being used by anyone, or only being used for ad targeting purposes, just know that it can be used by law enforcement at the drop of a hat. And, if you're a tech worker like me, potentially by your future employer.

Subscribe now