Scamwagon

I once spent an inordinate amount of time with a friend of mine, who I consider to be a master of recording & sound engineering.  He has been at it for decades, paid his dues, and worked with some greats.  He executes his craft with the utmost care and caring ... (something I have come to realize is what separates the true pros from the learned hacks). Anyway, I remember watching him in do his thing in the studio as I assumed the role of a quiet observer.  Despite his obvious adeptness and ingenuity, he would always play the part of the  Absent-Minded Professor, as opposed to the James Bond smooth-operator type.  I think it was partly a schtick to make people feel more at ease, but there was a genuineness and willingness to be vulnerable, as though allowing himself to be human probably made the job less fatiguing.   I distinctly remember my favorite phrase of his.  On a couple of occasions, while turning knobs and fixing some problem, in a wonderous voice he would declare, "so

Despite what one would think/hope, sending a message to a given address does not inherently give Google a high confidence that a reply from this address is expected (and, for example, that it should bypass spam checks). I have confirmed with Google's tech support that there is no way to automatically have this happen. The user can do the following: 1. Add the address to your contacts list in Gmail. 2. Check spam folder for replies, and mark it as "not spam" if something ends up there, which should influence the fate of future replies received. I can also approve an address at the domain level, i.e. if it is a big vendor or similar. I've had to do this with several of our Chinese vendors. I regularly ask engineering and purchasing to give me a list of the supplies we deal with, so I can approve them as a preventative measure. For what it's worth, all of the false positive instances of reply -> spam we have experienced have involved the sender's email server

Situation: You have installed Microsoft Office on your computer.  Whenever you logon to the computer, you see a Microsoft Teams splash that asks you to login, which you have to close every time if you choose not to login. Possible remedy: You can go into task manager, click the "Startup" tab, click Microsoft Teams, right-click and disable.  However, this doesn't work permanently as it will come back if you update or reinstall Office.  Also, other users who login to the computer will still get the Microsoft Teams thingy loading automatically at startup. "Real" fix: Add this to a user logon script, such as your domain logon script*: REM Delete Microsoft Teams Auto startup reg key   reg delete HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "com.squirrel.Teams.Teams" /f That second bit is all supposed to be on one line. *if you don't have a domain logon script, you can just put this in a .bat file and stick into  C:\ProgramData\Micr

A major source of headache for system administrators these days, and has been for some time, is the uptick in phishing messages that fake the sender address so it appears to be from someone within your organization. If you are like me, this is one of the things that keeps you awake at night. Organizations using Google Workspace can take advantage of a safety feature that purports to prevent this from reaching users. You can access its settings from within the admin console under Apps->Gmail->Settings->Safety. Unfortunately, there are still a ton of legit e-mail servers that don't authenticate, so that safety feature is not going to be very helpful.  However you can enable the checks that detect someone trying to send a message with an employee's e-mail address, your domain (or a variation on it) or even an employee's name.  These are very common attacks, and such checks regularly prevent nefarious messages from reaching our end users.   The problem is, due

Happy New Year. I have been developing a Cordova app on Android that uses Bluetooth Low Energy (BLE).  To accomplish this, I have been using Don Coleman's cordova-plugin-ble-central .  This is a neat plugin with a pretty simple API that lets you do serial communications over BLE. It is compatible with both Android AND iOS.  It's installable with NPM, but I recommend you get it directly from his Github.  The one on NPM seems to be broken on newer Android devices.  The issue  is that Google now requires ACCESS_FINE_LOCATION permission if you are using bluetooth, and the one on NPM is older and hasn't been updated to request this permission.  But that's not really what this post is about. My app is essentially a remote control for a light.   All I am trying to do is communicate over bluetooth when the app is in the foreground.  However, the Don Coleman plugin demands the BACKGROUND_LOCATION permission (presumably this would be required if I was trying to continue to send/