Relying on bug bounties 'not appropriate risk management': Katie Moussouris

I love this article. Katie, as usual, is on point.

The vast majority of bugs found via bug bounty programs are cross-site scripting [XSS] bugs, a known class of bugs that are easy to detect, and easy to fix.
“Why would organised crime or nation-states pay for simple classes of bugs that they can find themselves? They’re not going to pay some random researcher to tell them about cross-site scripting bugs,” Moussouris said.

Amen! I want to hand out tee shirts with a snappier phrase to organizations.

“You should be finding those bugs easily yourselves too.”
Moussouris is a huge supporter of bug bounties, having run both the Hack the Pentagon and Hack the Army programs for the US military. But she says that relying on a public bug bounty program just creates the “appearance of diligence”.
“This is not appropriate risk management. This is not getting better when it comes to security vulnerability management,” she said.
Moussouris told the story of one security researcher who’d made $119,000 within four hours in a bug bounty program. That’s more than $29,000 per hour to find simple bugs in a known class.
“That’s a great ROI [return on investment] for that researcher. It’s a terrifying ROI for the organisation that paid him,” she said. …
Simple bugs can be found way, way more cheaply.

Bug bounties are a tool, but only one tool. And it’s a game, so people will look to take advantage.

Then there’s the eternal problem of basic cyber hygiene. Moussouris says we “struggle as an industry” to deal with the last-kilometre problem of actually applying the patches.
“A lot of the patterns [have] not actually shifted that much from where we were when I started out professionally 20 years ago as a penetration tester,” she said.
“We’ve created a $170 billion industry, which, we’re really good at a few things, security not exactly being one of them. Marketing, definitely.”

(Via Relying on bug bounties ‘not appropriate risk management’: Katie Moussouris; picture Via Caleb Bryan on Unsplash)

Please, No! Founders Brewing Sells Out!

Today’s news, though, is making waves: MiBiz reports Founders’ two cofounders have sold 90% of the company to Mahou-San Miguel Group, each retaining just a 5% stake. Founders has confirmed the deal to The Takeout.

(Via The Takeout)
I wasn’t jazzed when Founders sold a bit of the company a while back, but this news is just too disheartening as a Michigan beer fan.

In an official statement provided to The Takeout, the brewery says daily operations at the brewery and taproom will remain unchanged.
“Founders will remain autonomous in managing its business, products and teams,” the statement says. “Engbers and Stevens [Founders’ two cofounders] will continue to be shareholders in Founders and have no intention of leaving.”
Mahou-San Miguel also owns a majority of Avery Brewing of Boulder, Colorado, but Founders says there’s no plans to roll the companies together. The company also notes the sale is subject to regulatory approvals.

The missing phrase for the end of each of the above paragraphs is “for now.”
I’m on the prowl for pictures from my last visit to Grand Rapids and the Founders Taproom with my friend Kent from back in the early ‘10s. When I find these examples of a simpler time I shall share them here with you.

Moving Away Moving Toward

In 2016, elementary moved to a Medium publication to host our official blog. At the time, Medium was touted as a simple, clean, and reader-focused host for writers. They supported custom domains, a robust API, RSS, rich formatting, and great image embedding. We had been largely happy with the experience—as were our readers—but something changed in 2017.

(Via Welcome to the New Blog ⋅ elementary Blog)
I like elementaryOS. Yet this is not a post about it. Nor is this yet another post about the problems with Medium.
I’m still considering moving from my self-hosted WordPress on DreamHost to a static site on This elementaryOS post documents my own thoughts on this potential migration.


The post talks to several key points I like:

  • Fast. Since it’s a static site, there’s no waiting around for pages to load and render on a server. They’re served as-is directly off a fast, global CDN.
  • Total control. Since we are writing the entirety of the HTML, CSS, and JS, it means we can decide exactly what the blog is, looks like, etc.
  • Privacy-first. Because we have total control and are leaning on the static nature of Jekyll, it means we can be fanatical about privacy: no external JavaScript, no analytics, no social tracking scripts, etc. Just what matters: the content.

Where I diverge is not relying on GitHub. i have two reasons:

  1. It’s yet another corporate cloud provider owned by Microsoft; and
  2. I don’t use GitHub all that much for reasons that have nothing to do with 1. has Jekyll support. I like SDF’s model and they’ve been around for over 30 years.
More advantages:

Modern Features
Just because it’s a simple static blog doesn’t mean we don’t support all the modern features you’d expect:

  • RSS feed for all the subscribing and cross-posting you could desire.
  • Completely responsive design from the start.
  • Great typography for long-form reading with sane line-lengths, pull quotes, etc. […]
  • Rich image embedding with side-by-side layouts, zooming in, and full-bleed support.
  • Sharing to social media without the privacy-invasiveness that usually comes with it.

I’m also following their lead by avoiding a on-site comment system. Instead I will rely on ActivityPub. If I want to see how my posts do, because:

… [I] get enough sense of “engagement” via social media and press coverage to know what [my] users and readers find interesting. And since [my] goal for the blog is to spread genuinely useful information …
[I’m] not incentivized to tailor […] content to what gets the most clicks or attracts the “right kind” of readers. 

No Tracking, Remote JS, External CSS, or AMP

Here is one of my key tenants:

… avoid as many forms of tracking as possible. This sounds easy, but it turns out that modern web development practices heavily push you towards including external scripts, tags, etc. for simple functionality … 

Because this drives me crazy:

We’ve also found that a clean, tailored blog doesn’t actually need any JavaScript to function (a near-blasphemous concept on the modern web!), and any tiny amounts of progressively-enhancing JS we may want can be included on the page where needed. For CSS, we use Sass to make it easier to write (and more organized across multiple component files), then the preprocessor compiles it all into one minified file.

In addition to the above, I love their statement around Google’s largely unnecessary AMP technology:

We feel that AMP is perhaps an acceptable technology that may solve problems for large, slow sites, but Google is unacceptably pushing it on all websites—and unfairly deprioritizing sites that don’t adopt their technology. Instead, we believe in web standards and the open web, and will continue to publish stories on a crazy-fast performing static blog without resorting to non-standard technologies.

Final Thoughts on WordPress and DreamHost

I have no ill will for either company (Automattic in the case of WordPress). I’m finding I’m spending too much time fixing and tuning compared to writing. Both are solid choices for a self-hosted on a trusted platform solution.
Stay tuned!

Software Subscriptions Mostly Only Benefit the Developer

Many apps I used are moving to a subscription model (a.k.a. Software-as-a-Service in the corporate world). As they move to the SaaS model I take a deep look.
Immediate red flags for me are when devs explain their move in these ways:

  • Implemented a custom proprietary sync mechanism
  • Implemented encryption
  • Costs are rising
  • Push notifications (in most apps, unnecessary chrome)
  • Theming, styling, icons &| dark mode (again, unnecessary chrome)

There are select apps in the subscription model to which I subscribe and why:

  • Apollo (Reddit reader app): superior to the native app & other options; theming; and to support development
  • CARROT Weather (Weather app) Tier 2: additional data sources; Apple Watch; map layers; and other stuff
  • Fiery Feeds (RSS reader app): for “Smart Views” ; to support development; and I read a lot of feeds
  • Overcast (Podcast app): to remove adds; to support development; and I listen to a lot of podcasts

Apollo violates two of my red flags, yet the developer is crazy responsive; his app is heads & shoulders better than the native Reddit app; and he regularly pushes out updates for security/bug fixes/functionality/chrome.
CARROT Weather also often pushes out updates for security/bug fixes/functionality/chrome, and is also better than the other options.
Overcast does, too, but more judiciously based less on chrome. I like PocketCasts, too, but less so.
Some apps that I avoid in the subscription model but use in their legacy or alternate license mode:

CloudFlare Did the Right Thing the Wrong Way

But I don’t know what the right way is:

Networking and web security giant Cloudflare says the recent 8chan controversy may be an ongoing “risk factor” for its business on the back of its upcoming initial public offering. […]
8chan became the second customer to have its service cut off by Cloudflare in the aftermath of the attacks. The first and other time Cloudflare booted one of its customers was neo-Nazi website The Daily Stormer in 2017, after it claimed the networking giant was secretly supportive of the website.
Cloudflare, which provides web security and denial-of-service protection for websites, recognizes those customer cut-offs as a risk factor for investors buying shares in the company’s common stock. […]
Cloudflare had long taken a stance of not policing who it provides service to, citing freedom of speech. In a 2015 interview with ZDNet, chief executive Matthew Prince said he didn’t ever want to be in a position where he was making “moral judgments on what’s good and bad,” and would instead defer to the courts. […]
Cloudflare has also come under fire in recent months for allegedly supplying web protection services to sites that promote and support terrorism, including al-Shabaab and the Taliban, both of which are covered under U.S. Treasury sanctions.
In response, the company said it tries “to be neutral,” but wouldn’t comment specifically on the matter.

(Via Cloudflare says cutting off customers like 8chan is an IPO ‘risk factor’ by Zack Whittaker)
I am mixed on this takedown even after a solid week of reflection. There is no doubt in my mind that 8chan is toxic and a blight on humanity, and the same with The Daily Stormer. I’m happy they aren’t being protected by CloudFlare.
However, I don’t like that:
– there’s no oversight into these takedowns;
– CloudFlare acted from public pressure (well, social media pressure), and the mob is oft not rational (or real);
– and, from a technical perspective, these instances offer a problematic precedence.
CloudFlare and similar companies are almost as core to the Internet’s function these days as DNS and NTP. My site is protected by CloudFlare, in fact (and in full disclosure, etc.). They and their competitors are akin to an active Internet insurance policy. Denying core-adjacent functionality and insurance to sites because the sites are reprehensible in giving the dregs of society a place to congregationally amplify their hate seems a no-brainer on first blush. But it also helps lay out a blueprint for blocking sites for far less.
Sadly, I don’t know how I would feel better about or how I would solve this. I’m open to constructive discussion.
To be clear: I agree wth CloudFlare on their actions in regard to 8chan and The Daily Stormer. I would like the actions to get codified into a documented policy.