A few things I learned, relearned, or just learned more about this week, mostly by reading. Since I can't absorb knowledge by osmosis, unfortunately. Yet.
Malicious site blocklists and APIs
When I hear about devices like Gryphon or Bark having access to hundreds of thousands of sites, or a browser, browser addon, search engine, or whatever else checking for malicious/unsafe sites, I've wondered how exactly they're doing that. It'd be incredibly inefficient for everyone to amass and maintain their own lists (although some probably try), but I never bothered to look for the source.
This week I stumbled on a site with a list of block lists (how meta), which solves that mystery I suppose. Contact me for the movie rights. 🕵️♂️
Some of the links are broken, but there's some interesting stuff in there...
- Lists of phishing sites by OpenPhish and Artists Against 419 (sites trying to trick you into entering your creds for another site, usually by taking advantage of typos or by using a popular domain as the subdomain of their own dodgy website)
- Lists of malware sites by URLhaus (sites that trick you into downloading software that might look like a legit app, or by scaring you with big popups warning you that you have a virus and need to download their antivirus app)
- APIs you can use in your own app, like the one from URLhaus and Google's SafeBrowsing API
Encoding vs Encryption
The world of IT is filled to the brim with acronyms and terms, and it's easy to get some of them mixed up. Some of them are important to distinguish though, like the difference between encoding and encryption.
I came across some code online this week that was base64 encoding some values, but the names of the classes, methods, etc suggested the values were being encrypted. They're definitely not the same.
Encoding is for transforming data for one reason in another. For example, base64 encoding and decoding a string in C# is simple and not at all secure... it's not meant to be.
There are neat things you can do with it too, like encode an image and embed it in a webpage, like this:
<img title="Link" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABYBAMAAAC3wuwbAAAALVBMVEUAAAApKSnGGCGMWilSlBA5lGu9ayH/ewDvY7V7vSFC3nPnlFL3pWv33kL///9VMw/WAAAAAXRSTlMAQObYZgAAAPtJREFUaN691lERgzAQBNBYOAu1gAUsxEIsxAIWsBALWMACFqqh7CyXpJ3Sr2b3A0LufdyEMCSELnYl3GU4MJvPrOs836DhwMsMkBJgiLZy9iZzBq+tDgdm+262LCQMxgCoKAHiG8bHOpBSIy0op6QDvlB9MKMC4SIpPc+k5PdalgASFLA4WDTCt09HAPyVEfA1KYFZKTGSMCjHWEpdycHAbJrwCMIFw53PqKgACVttI85rwLZ5W6WGFBUVwCBGJxz5vAqgfJwxa1cSDfBjBRo7rvj2qbt6OAB5PBx5ETPd1y0A+KkSscifqxK0Y16fr+fAgeAT/TyP/hu8AMIVt4cNSUt4AAAAAElFTkSuQmCC" />
Encryption, on the other hand, is about keeping your data safe. You can certainly encode an encrypted value, but the intent of encryption is different and can't be easily undone like simple encoding/decoding.
Here's a nice explanation and comparison:
The wrong way to accept Outlook invites.. apparently
Outlook (un)pleasantly surprised me this week. When I setup meetings, I find the flurry of "accept" emails redundant and annoying. If I want to know who accepted, I'll just check the appointment.
Since I don't find them useful personally, I usually select the "Do Not Send a Response" accept option to other peoples' invites, figuring I'm saving someone else a headache too.
As it turns out, that doesn't have the intended behavior at all. So what does it do?
The first two options (Edit the response before sending & Send the response now) both send an email to the organizer, and the attendee's response is recorded in the organizer's tracking list.
The third option (Do not send a response) does not notify organizer, so the attendee's response remains as "None" in the organizer's tracking list.
That quote comes from a program manager at Microsoft, who reached out to users back in 2018, asking whether MS should make Outlook do what I think most people would assume it's already doing.
Many users report that they expect Do not send a response to be recorded in the organizer's tracking list, but just not to send an email. We are considering updating the behavior so that all 3 response options are recorded in the organizer's tracking list. Attendees can still use the Do not send a response option to avoid sending email to the organizer, but their response would now be recorded & shared with organizer.
Nearly 5 years later and nada, so for those of you who (like me) want to ignore all those response emails when you're setting up meetings, there's actually an option to automatically delete empty response emails.
That's it for now! This week was good, this week was fun (except for that outlook thing.. seriously, I've been choosing that option for at least a year)... next week will be another one. 😏