I’ve mentioned several times that I’ve been working on a freelance project — and it’s about ready to be release! I estimate that all the MVP requirements are finished. Now, my client just needs to wrap up a few things on his end, and people can use my software. What’s left for my work are a couple cosmetic things that won’t necessarily prevent an MVP release.

One critical feature of this project is connecting a website to a printer that is located on the local Wifi. For further context, I am hosting this website on Vercel who requires HTTPS deployment. While developing, I found out that one can’t send a request to a local Wifi endpoint from an HTTPS website, for security reasons. So I thought about ways to skirt around this block. The options were to turn off that security feature in the browser, develop a desktop app with Tauri, or go to an HTTP website instead. Two of those options wouldn’t turn out in the end.

Turning off that security feature was great for immediate testing of the production website, but that could not reasonably be done on the end-user side. I just couldn’t see things ending well if a user disabled a security feature, and I just couldn’t see a user wanting to use a website where a security feature was disabled.

I could make a Tauri app, where local calls are permitted and the security of Tauri is more locked down. I first developed the Mac application, and that worked great. I paid the $100 developer fee, and I was able to make a distributable desktop application. The catch came with Windows applications. The cost to make a distributable wSndows application was surprisingly a lot more than making a Mac app. Everything I saw indicated having to pay 2x-4x the $100 fee of Mac applications! So I stopped that progress, because I simply didn’t want to pay that much.

Note! I did find Azure Trusted Signing, and that wasn’t GA yet. Azure Trusted Signing would put the cost of signing desktop applications with potential range of a Mac application. Now it is GA, and perhaps I can now make more affordable desktop applications now! I’ll explore it with other avenues.

So I went with the third option to host a website on Digital Ocean for HTTP. That worked great for a while, until my client showed the requests to his local printer were getting blocked for the same reason HTTPS had originally blocked the requests. HTTPS and HTTP swapped places. So, out of curiosity, I pulled up the HTTPS version of the website and I found that it was functioning now.

I guessed that this was some kind of Chrome update, and it turned out it was! And the Chrome update coincided with when my client encountered the error on the HTTP website. I think this is such a neat feature, and it make sense. The browser will now advise on sending or using data found on the local Wifi. It hopefully will lock down on security while being permissible.

A futuristic web browser connects to local Wifi
Web applications hosted on HTTPS can now access local Wifi servers!

With this update to Chrome, that means my freelance website can now be completely hosted on HTTPS. That sounds great because it could mean more visual security for the user. I can also use any other HTTPS related technology, like service workers which I am currently using in the website. This Chrome update couldn’t have happened at a more opportune moment. Granted, there is a remaining question on if end-users will have the right Chrome version, so the HTTP website will remain as a fallback.