LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point. You can also listen directly on Soundcloud.
- [01’33”] Hydra darkweb market decapitated.
- [05’06”] Ruby module supply chain hole.
- [10’46”] Quantum computing sidestepped.
- [15’43”] A robot revolution that could result in ransomware.
- [22’46”] The Zuckerberg scam that just won’t die.
With Doug Aamoth and Paul Ducklin.
Intro and outro music by Edith Mudge.
You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.
Podcast Reader
Will you be providing podcast transcripts anytime soon?
Paul Ducklin
We provided them for a while (see episodes in the 60s), after a few people insisted they were vital… but we found (as we did when we last tried a few years ago) that *actual* enthusiasm for transcripts was illusory, because traffic to the articles remained the same.
A decent transcript is a *lot* of work, and our podcasts aren’t designed to be read anyway (spoken English doesn’t make good prose, and vice versa). So I started using the time it took me to do a decent podcast to produce an extra written-to-be-read article each week. I am just not convinced that people who dislike podcasts will bother reading them instead when they will already have read the written artifice about the various topics that have already come out.
I can change back, but every time we’ve done transcripts in the past, they seem to have served very little purpose for the time they take. (Yes, I know transcripts can be automated so that no human involvement is needed. But so can tech support calks… with equally frustrating results for all concerned :-
I suspect that transcripts are even less popular now that speed-up options such as 1.5x listening give such excellent results.
I’m open to being talked round… but ATM I am taking a break from transcripts and writing more actual, errr, written material instead.
HtH.
Podcast Reader
Hey Paul,
Thank you for taking the time to respond! That makes complete sense, and I don’t blame you one bit for taking the time to write more articles versus writing out the transcript.
Cheers!
Paul Ducklin
Thanks for your understanding. I must admit the transcripts can be fun to do (we use an automated system for a first draft) but they do take a lot longer than you think to make them clear and readable.
Paul Ducklin
That one gets seems to get the JS engine to treat an object (fixed size) as an array with plenty of space so it can use the type confusion to write into memory that’s well beyond the amount allocated for the original object, thus providing not only a buffer overflow but an overflow *into a memory region that is flagged as executable and that already contains precompiled code ready to re-use later. So next time that chunk of code runs… it executes the untrusted code that the exploit injected there, not the trusted code that the compiler originally created…