So, why would I spend more money in a service that has now decided to abandon the principles which are the entire reason why I subscribed in the past? And for what? for AI vibe-coding. A serious, leading product is literally being turned to shit. Well Andy, you can pay for slop out of your own pocket. You’ve lost my money, and that of thousands of other subscribers.

That’s the cost of arrogance and greed. Another reason to abandon the project is that employees have been summoned to “re-interview” on their AI skills to keep their existing jobs, which frankly sounds like a fancy way of expressing “constructive dismissal”, a process by which an employer hounds employees into quitting. That’s just a downright scummy thing to do, and as someone who’s spent the entire year looking for employment I am absolutely disgusted by this move. Yes, those “re-interviews” have been cancelled — as a result of public backlash. If Andy Yen thinks that this is enough to keep me as a customer, he’s got another thing coming. Only his resignation from the company could even get me to reconsider at this point. He is not someone that can be trusted.

And trust is what Proton used to have. It was the selling point. It’s not so much that I’m quitting Proton — it is Proton and its CEO that have quit my patronage.

Well, since no one else feels like being the sober man at the table, I will.

The security exploits

AI-assisted cybersecurity researchers, while going through code that probably dated back to the 1990s, managed to find two instances in existing PHP code where a very specific condition would lead to an ability by attackers to execute code on a server. That is known as a RCE vulnerability. Two of those were found in existing PHP code. For historical context, PHP was created in 1994 as “personal home page tools” by Rasmus Lerdorf.

To put it in very simple terms, an attacker could put a web site (or, more likely, web host) in a condition where the PHP server framework would just quit unexpectedly. And a failure at that point means that there is a very small opportunity of time where an attacker could execute code arbitrarily on the underlying operating system. Now that code could do anything, including decrypting passwords held in memory and then using those credentials to gain access to external systems. Obviously not a situation you want to be in.

Now, PHP has changed greatly since 1994, which is, let’s remember, 32 years ago, and software testing has as well. However with the use of AI tools, researchers were able to point out exactly what the conditions of the exploit could be found.

Initially the new vulnerabilities were meant to be kept secret until October 22nd. However, someone leaked the story, on October 21st, which set off the tone of panic.

The problem had already been found and, patched, with new, safe versions being ready for use, by the time the information was made available to the public.

So that’s 90% of the problem solved already. The remaining 10% is deployment.

This is things can become complicated. Not for most sites which are regularly maintained, but for legacy sites, which are often left to languish without maintenance but keep working as web sites, “as long as it works”. PHP, as a development language, has created a lot of those sites, largely because it’s an easy and accessible languages for creating dynamic web sites.

Those sites can still represent a problem because the patch that resolves the RCE issues was issued only for the current versions of PHP, which are all decimal versions of PHP 8. As such any site running previous versions of PHP (7 and below) would still be vulnerable. And with AI-assisted coding tools it could be easy to create a way to trigger the conditions for the RCE and insert malicious code into those sites. Those servers need to be updated to PHP8, if they’re even maintained at all, or their owners risk being liable for damage or system intrusions that originate from their servers.

That being said, those sites are not of particular concern.

Why the “crisis” is overblown

While the RCE vulnerability is serious, it’s a problem that’s resolved at the system administration level. For a lot of sites that are served through a shared web host, the site owner does not have to do anything. In fact the owner will probably already have received a notification that the system has been patched to a safe version of PHP.

For people (like myself) who use their own host to serve PHP pages — I do it through a cloud provider, but it’s the same process for people serving from their own bare-metal servers — it’s a simple matter of updating PHP at the host level. In that case it involves a little more work on the site owner’s part, but the fixed PHP versions have been available since the afternoon of October 21st. That’s when I patched my host.

No other change is required, the web app does not have to be modified in any way. The change implemented by the patch works purely at the level of PHP’s internal workings and has no other effect.

That’s why I can’t understand companies that have taken their entire site offline for extended periods as a result of the vulnerability. Once the patch is applied, you restart the system and things work as they previously did. That’s all.

Alarmist tech journalism is the real problem here. Unless you run your own web server, there is no cause to be alarmed. If you do run your own web site, maintain your system. That’s all there is to it.

Oddly enough yesterday I figured out how to get around that problem, more on that later. But earlier today, at 3:09am, I got a github message about it. It seems that someone did in fact look at my article, probably from seeing it posted on LinkedIn, and at least tried it out. Now this brings up the interesting question as to whether the Canadian federal government is outsourcing its IT work to India, because 3am is not considered “working hours” anywhere in Canada, but that’s a question for another day.

Here’s a screenshot of the message I got:

First of all, thanks for confirming it’s a bug. But it’s disappointingly lazy to say “well, it’s not my job” in response. It’s a bug that affects the usability of the site, it shouldn’t just get closed (which it did), and if it’s “not your job” it really should be passed along to the people whose job it is to fix it.

Secondly, it’s not even a difficult bug to figure out, and I know that because I figured it out by myself yesterday. And I’m not even getting paid to do this. Which is even more annoying, speaking as someone who’s been looking for a job in the IT field for 8 months now and will probably have to go work on the shop floor at Costco because the tech job market is absolute shite at the moment in Montreal (mind you, if you do have to work in a retail establishment, Costco is the gold standard there).

But, let’s get back to the matter at hand.

It’s the “candidate registration” page that’s broken. It simply will not work if you didn’t sign in to the CRA careers site before you get to it. If you go to the CRA Careers site you will see this near the top of the page:

Click on the “Sign in or register” link, sign in through your authentication partner (or CRA ID), and THEN click on the “candidate registration” link, and you will be able to fill out your candidate profile. 

The easiest way to fix this would be to disable the fields in the “candidate registration” landing page if the user is not logged in, and inform the user that they must be logged in before continuing.

However, it appears that the web dev teams at the CRA operate in silos, where each team is responsible for small individual parts of the site while remaining blissfully unaware of what the other teams are doing. Those teams are probably offshore, working for different companies, and have no clear way of communicating with one another. I don’t know what happened to the “Canada First” and “Elbows up” attitude that the Prime Minister keeps talking about, but it doesn’t seem to apply to IT work done for the federal government. That’s a shame, because there are thousands of Canadian IT workers currently desperately looking for jobs, running through their EI, and eventually forced to apply for welfare at the provincial level. If I’d been in that same situation 20 years ago I would have just looked for employment in the USA, or somewhere else in the world, but that’s no longer an acceptable (in the case of the USA) or even possible option for a guy my age.

So, CRA, I’ve figured it out for you. Fix your damned web site!

Checking my email this morning I found three more emails in my inbox! Each one as dodgy as the four I already mentioned.

One of them came to me from someone claiming to be from the “Robert Walters” recruitment agency, but the domain of the email was “robertwaltters.com”. Which obviously is a typosquatting tactic that works if you don’t pay attention to these “little” details.

Another came from a Gmail account, but a very funny one. The account that originated the scam was [name].[company].sgourmetpizzaa@gmail.com. I mean, come on. This guy was barely even trying. The interesting thing is that this came as a message that used Gmail “Confidential Mode”, which I thought was a scam until I read up on it and found that it actually exists. Nevertheless the only people I’ve seen using that feature are recruitment scammers, so I must add it to the already long list of “tells” of recruitment scams.

The third also came to me via Gmail “Confidential Mode”, and claimed to be from Northrop Grumman. Now that is a big company involved in aviation, so why would they be relying on free gmail addresses? FWIW the address they used was [lastname].[firstname].northrop.grumman@gmail.com.

So, stay vigilant my employment-seeking friends. The vultures out there know there are lots of bodies ripe for pickin’. In more positive news I did score an interview tomorrow. For Costco. I haven’t worked there for 35 years, but hey, it’s a job.

Unsurprisingly, all four “new connection” recuiters turned out to be scammers. I noticed that 3 of them no longer have LinkedIn accounts, and I just reported the fourth one.

The game is this: these “people” (probably AI bots) pretend to be “independent recruiters” who have a job you’d be interested in. This can be sniffed easily enough from your profile. They give you a little spiel about they’re impressed by your qualifications and experience and you’re almost sure to get the job… BUT they want to make sure you get picked and your resume could use improvement! And of course they know someone who can do this, for a fee.

What are the tells? Just look at the profile. Low number of connections (for a recruiter in this economy?), their email is a free account (gmail, outlook, yahoo), often they don’t appear in the “recruitment firm” they claim to work at but they follow that company, sometimes they’ll redirect you away from Linkedin messaging and onto a proper custom-domained email account… that’s also a free email account. 1/4 of the candidates in my experiment did this, and probably just didn’t know that Yahoo mail adds branding to the emails they send. Also the custom domain had no web site. For a recruiter. In 2026.

They’ll also be as impatient as a Nigerian scammer — if you don’t answer quickly they’ll keep pinging you on Linkedin, and send reminder emails that say stuff like “looking forward to your feedback”. 2/4 of the scammers “suggested” resume optimization within 2 hours. One of them even showed that my resume had an ATS score of 39%… when all the ATS checkers I used showed high 60s to low 70s.

So, yeah. Looking for a job makes you a huge target for scammers on Linkedin. But at least Linkedin seems to be doing something about it, or at least acting on the reports they get, even on a long weekend. So, there’s something positive to get out of this.

Ultimately, if something seems just a little too good to be true, it’s because it is. The tech job market is absolute shit right now and it’s not about to get better.

I’ve now been looking for employment for 8 months, after 4 month of unemployment last year and an unsuccessful stint at a job I had not applied for but been offered by the manager in charge, which turned out to be a complete shit show. So, I’ve come to know a lot about how companies hire — or, more exactly, DON’T hire — candidates at this time in history.

Along the way I’ve come across a number of sus “recruiters” who take it on themselves to string candidates along, promising jobs that pay a little too well, and try to sell you on “resume reviews” costing hundreds of dollars, while not really having any access or say in hiring decisions and probably not even being recruiters. Now, the thing about scams is that they tend to follow patterns. This is not a field of creative geniuses, and they have a number of tells.

So today I went to LinkedIn, posted a video entitled “Yes, You ARE Getting Auto-Rejected” which is apparently causing a whole lot of controversy in the HR community. A mere minutes later I was contacted by FOUR people claiming to be recruiters who have a job for me. One of them was for a job I had already applied for at the target company, so it’ll be interesting to see what comes from that. Two more advertised a job I had seen in my local job searches but was not a good fit for me for certain specific reasons.

Well, I decided to take the bait and send all four of them my resume, which has already been optimized by Claude AI for ATS performance. As things progress I’ll make follow-ups to track  the progress of these “applications”. So, stay tuned.

So I’m setting up a Django project, and naturally I wanted to use PostgreSQL with the project.  I just don’t like SQLite, it’s something I’m forced to use with Calibre and it causes problems with database portability — I have to have the application on the same host as the database and that’s a pain in the ass.

So I modify the venv in which Django is running and install psycopg2-binary, which has the PostgreSQL bindings for Django, and modify the settings.py file to point to the correct database.

Then I went online and the instructions everywhere are always this:

Log into PostgreSQL as the root user (e.g. psql -U postgres)
In psql:
CREATE DATABASE new_database;
CREATE USER new_user WITH PASSWORD 'newpassword';
GRANT ALL PRIVILEGES ON DATABASE new_database TO new_user;

This does not work! Well, it doesn’t work with PostgreSQL 16 and Django 6. When you go back to your django project, make the migrations, and migrate the project, you end up with this error:

psycopg2.errors.InsufficientPrivilege: permission denied for schema public

The worst part of this is, it’s not a new problem. After searching online, this is something that’s been pointed out for several years, and yet none of the “AI-powered search results” seem to be aware of this. It’s really not changing my opinion that search engine-generated “AI summaries” are crap that no one has ever verified — like most AI generated slop out there.

The missing instruction is that you have to, as the postgres user, log into the new database and ALSO grant the privileges to the public schema of the new database to the new user.

To do this, you must do this in a separate operation from the one that created the database:

Log into the new PostgreSQL database as the root user (e.g. psql -U postgres -d new_database)
In psql,
GRANT ALL PRIVILEGES on SCHEMA public TO new_user;

Once you do this, you can perform the database migrations as expected.

It’s really annoying that I even have to write this.  Most search engines now will provide you with instructions that don’t work, and this is directly  due to their decision to pollute their search results with unverified AI slop that just doesn’t work. It’s very frustrating and will probably continue being an issue as long as tech companies continue to insist on burdening the rest of us with this “artificial intelligence” monster they’ve sunk billions/trillions of dollars into, while laying off hundreds of thousands of employees and essentially killing the software job market.

Got a call last week about a job for which I had applied. Got a screening interview scheduled on Monday (August 24th) and was amped up for it. It was a Teams call, so I sign on 5 minutes before the interview, and waited.

And waited, and waited. No one else came on the call. I asked in the meeting chat whether the call was mis-scheduled — the person who created the meeting was in Kansas but the other person invited to the meeting was in my time zone. I also emailed the person who booked the meeting. So, not having anything else to do, I waited and browsed the internet during that time. An hour passed, then another 15 minutes, and I signed out.

I then emailed both persons in the meeting to inform them of this and said I was open to rescheduling the meeting anytime this week. I then received an automated response saying the other person on the call was on vacation until Tuesday.

However it’s now been two days and no response. Yes, I checked my “spam” folders just in case. This is not a small company, this is a major company in Canada with a sizeable presence in the USA as well.

It strikes me as rather bizarre that a company would call me to schedule a meeting and then ghost me. It seems really unprofessional. And, for me, quite depressing.