February 2024 – Something Odd!

Resize Images with Tasker

Motivated by the change in Google Photos that stopped offering “free storage” I worked on a script that would resize images on my Android phone and released the first version in November 2022. The script requires Tasker to run.

The Arc de Triomphe in France photographed on my phone.

There were a couple of problems with it, however. I wasn’t entirely happy with the workflow.

Images were deleted from DCIM/Camera immediately (and moved elsewhere), making it impossible to review the image I just photographed in the camera gallery.
When I opened the gallery app separately, the resized images wouldn’t show until some time later, or not at all. I verified the files were there using a file manager. Android’s media system just didn’t know about them.

I put up with these downsides for quite a while, occasionally researching how to fix the disappearing image problem, but I couldn’t find any good answer until last month.

I found out that Tasker must run the “Media Scan” command when it creates a new image file. The documentation says you can give it a directory, but that didn’t work for me. When I gave it the filename of the newly created image, it all worked! The image appeared in my gallery apps immediately!

Next up was the problem with deleted images. Originally, I moved the files into a “work in progress” directory to easily work on them, but if I left them in DCIM/Camera, I could check if a file of the same name existed in DCIM/Resized/. If it didn’t, then it’s time for a new file!

That did leave the problem that files were left in DCIM/Camera. Some of which might have been resized, some not. (It happens if I burst mode photos, where the task starts and works while new files are being created. It doesn’t catch the very new files). I created a new task “Photo Backup” that simply runs the resize task, and then runs the shell command “mv” to move all the Jpg files to where Lightroom will see them on my computer. I added that task to my launcher with an icon. I tap that when I get home and within a few minutes, the files are synced to my computer, using Syncthing.

To better track changes, I’ve uploaded the task to GitHub in this Resize Images task for Tasker repository. All development happens on my phone, and I’ll publish it to Taskernet first, but then changes will be copied there.

To install the task, go to the Taskernet page for it on your phone and click on Import. You can also manually import the .xml file if you like. How you use the task is up to you, but I created a profile that uses the “File Modified” event, and gave it “DCIM/Camera” as the File. The action to fire is the “Resize Jpeg Files And Leave Originals” task listed here.

“Verify this email is yours” spam

Yesterday I got an unusual email spam. It hit my inbox on Fastmail, coming from my Google account. The spam link was embedded in the actual email address, using the plus notation that Gmail supports. On Fastmail, the link wasn’t clickable, but on Gmail it was. When I checked Gmail, the email had been moved into Spam, so I guess they were dealing with many copies of this. Surprisingly, the link is still clickable, even with the email in the Spam folder.

I thought I hadn’t received spam like this before but looking at it again, I think I did. Just once.

The email came from “Google <noreply@google.com>”, and the spammers used some online service that requires verification. They stuffed the spam link into the email address. Here’s what it looks like on Gmail:

A spam email I received. I have obscured the spam link in this ALT text:

Verify this email is yours
[my email]+~New~messages~Read-[spam link]#@
googlemail.com
This email address was recently entered to verify your email address.
You can use this code to verify that this email belongs to you.
793352
If this wasn't you, someone may have mistyped their email address. Keep this code to yourself, and no other action is needed at this moment.
The Google Accounts team

They added a “#” character at the end of the link, so the @googlemail.com part of the email would become an anchor tag. Pretty clever, pretty devious. The link goes to a 404 now, but had an image with a link yesterday.

So, be careful if you get any email verification emails. Especially if you weren’t expecting it. It’s probably spam.

When you move IP, move all the IPs

I recently moved the server hosting this site and my photoblog to a new Linode. About time too as the old one was full of cruft built up over a decade of upgrades. It had finally reached the point where I had trouble finding new dpkg files for software that wasn’t as ancient as my installation. Updates would stop in the next year or two as well, which was a huge problem.

When I did move, I pointed the DNS at my new server and all seemed fine. That is, until I saw an email from Google on Friday saying a new user had been added to the search console for www.inphotos.org!

I don’t use the www hostname on any of my sites, and didn’t actually have a search console property set up on that site. I don’t remember now if I had to create one, but when I eventually logged into it, I found an “Ian Trader” already in there. He was a validated user, too.

He had been allocated the IP address of my old server. He saw that www.inphotos.org still pointed at it and asked Google to validate his ownership by uploading a HTML file to his server.

A screenshot from the Google search console showing the ownership verification details of the attacker who created a validated account on www.inphotos.org

A screenshot of my browser showing the validation file the attacker used to gain access to the search console for www.inphotos.org

Yikes! Quick as I could, I checked the DNS and found that yes, www.inphotos.org was still pointing at my old IP address! Damn.

Fixing it was fairly easy, I thought. I removed that user, and removed the www hostname.

However, Ian had one more trick up his sleeve. He had put a sitemap on www.inphotos.org, and it led to 129,864 fake links that Google could not index.

Screenshot of the "page indexing problems" chart from Google Search Console showing 129,984 problematic pages since last Wednesday.

It looks like he was setting up a malware server with the names of books on each page:

/c/pdf/upload?PUB=new_apostolic_church_hymn_collection_songs&blackhole=017
/c/pub/go?EPUB=hawker_battery_charging_instruction_manual&daily=034
/c/pub/list?BOOK=a_shade_of_vampire_7_a_break_of_day&dua=047
/c/pub/list?EPUB=ib_vietnamese_past_paper_2013&monument=094
/c/pub/list?PDF=lowepro_user_manual&codevember=001
/c/pub/list?PDF=suzuki_swift_owners_manual_2009&bubbley=087
/c/pub/upload?PUB=caravaggio_ediz_illustrata&particles=015
/c/pub/upload?PUB=mi5_and_me_a_coronet_among_the_spooks&sassy=021
/c/pub/url?BOOK=radiation_detection_and_measurement_solutions_manual&delapan=081
/c/pub/visit?EBOOK=mercruiser_hp_engine_manual&daily=009
/d/book/data?PUB=gossie_and_gertie_gossie_friends&particle=016
/d/book/file?DOC=engine_repair_manual_for_f550&dribbble=005

I fixed those with some simple mod_rewrite rules, so visiting those URLs should take you back to the homepage. Google is validating my fix now. Besides, that fake sitemap is gone, so I expect Google to forget about them soon, I hope.

So, when you’re moving websites around, make sure you update all the DNS records for your sites. I may not have noticed for a good while if he had set up the redirect scripts on his server correctly and didn’t go into the search console.