This morning I was greeted by a spate of phishing emails in my inbox. How did I know? Because the Gmail Team spotted them for me. Google has gotten very good at spotting phishing. I began using Gmail as my main email client yesterday. This morning, the Gmail Team lit up my eyes. I had mixed feelings about Gmail’s unfamiliar interface and online requirement, but their phish spotting performance this morning moved the approval needle a whopping notch in the positive direction. Between 8 and 9 pm yesterday, Google recognized 22 phishing attempts on one of my email accounts. That is close to a denial of service attack, but Google took it in stride.
I’ll ignore the slightly disturbing fact that the phishing started an hour or so after I put the email address into Gmail.
If you are wondering, a Denial Of Service (DOS) attack uses a flood of messages of some kind to try to overwhelm a system. In this case, the flood was phishing email. More often, a DOS attack is on a web service, like Amazon or Google itself, in which a flood of requests for service are sent to the service. The effect is either to slow the service down to the point that legitimate requesters are unable to interact with the service, either because response is so dismal, they turn away, or the service itself fails under the bombardment of requests.
The most difficult type of DOS attack occurs when the attack comes from many different sources at the same time. This is called a Distributed Denial Of Service (DDOS). Often, a DDOS comes from a “botnet,” a collection of surreptitiously invaded computers, often home computers, that are subverted to send out requests at the bidding of the “botmaster.” Often, the point of a phishing attack is to secretly turn your computer into a bot.
Even though Google and other services are effective, don’t become complacent. Automated phishing detection is good, not perfect.
I skimmed over the crop of phishes; they were not well-crafted, mostly warnings of overdue payments from vendors with whom we never deal and notices from online fax services we don’t use. They were riddled with poor grammar and unprofessional formatting. They used slight misspellings in the URLs, like jpmoryan for jpmorgan, to appear that links were to legitimate sources. I’d give you more examples, but I followed best practice and permanently deleted the bogosities. Before I thought of writing about them. Ah well.
If you discipline yourself to look at all incoming email carefully, most phishing attempts are easily weeded out. Look at any invitation to click on a link with suspicion. Check the URL by hovering over the link and looking at the text (usually at the lower left of your display) for anything that looks suspicious like a “.ru” or a misspelled name.
Email attachments, especially zip files, are often treacherous. Don’t open them unless you are very sure of the source. If you know how, start up an isolated virtual machine and open dicey attachments there. If you don’t know what the previous sentence meant, don’t open the attachment. Get competent help if you feel you must open it.
Ask yourself if the message is reasonable. A request from a vendor or service you don’t deal with, for example, is not reasonable. If you think the message might be legit, but you have doubts, pick up the telephone and call their customer service. Don’t use a phone number in the message. Get a number from an independent source, like a secure (https) website that you find using a standard search like Google or Bing. Straight forward caution and common sense takes the day.
Caution, with the help of services like Google’s, will protect you from most phishing, but may not protect you from “spear phishing.” Spear phishing is insidious and seldom automated. Spear phishers study their prey. They can get to information on your preferences and habits collected by advertising services and they can purchase stolen information from criminal sites on the dark web. Or they can look at your public Facebook page, reviews on Amazon, even the book lists that you post at your public library site, to gather details about you, then craft emails that are plausible and hard to detect. For example, a spear phish might take the guise of a letter from a friend suggesting a link about a book you put on your library shelf.
Who wouldn’t be taken in by a friendly gesture like that? Google might spot some discrepancy or a connection to their long list of dangerous sites, but the best spear phishermen strive to stay way ahead of the white hats.
Fortunately, the kind of spear phishing I just described takes far more time, effort, and skill than hackers are willing to expend on random targets. Generally, the criminals rely on sloppy automated scatter gun attacks that only work because they hope for a one in ten thousand catch. However, if you happen to be a high-profile target, like a public figure or a person of interest to a foreign government, and worth the hacker’s effort, you must be cautious indeed. I suggest looking into something like Google’s advanced security program. Benjamin Wittes has a podcast on Google security that you may find worth your time.
A number of modern computer programming languages (such as Python and Java) do not require the programmer to explicitly declare a variable’s data type at compile time, rather the data type is inferred at runtime (a style known as type inference).
I wondered why this a good thing? It seems it’s just asking for runtime errors in cases where the input doesn’t coincide with the expected data type required for the operation to be executed successfully. For example, what if the operation was designed to multiply the user input to a constant representing the value of Pi in order find the circumference of a circle where the user might inadvertently enter a string of characters rather than an integer.
In declared type languages, such as VB 6.0, a programmer can easily trap for an error where the data type received at runtime is incompatible with the operation and take appropriate action using a generalized error trapping routine. In such cases, it seems type inferred languages might produce errors that can’t be easily dealt with at runtime.
For more information, see the Python programming reference at:
https://www.programiz.com/python-programming/variables-constants-literals#declaring-variables
or The Wikipedia entry for Type inference at:
https://en.wikipedia.org/wiki/Type_inference
I program mostly in C++, Java, and Perl. Perl is great for quick programs, especially for text processing. Perl has wildly permissive and fluid variable declaration and data typing. Dashing off a quick script to perform a simple task is quick and easy. However, when a program gets more complicated and leaves the author’s hands, the story changes. I find even short scripts that I wrote myself with maintenance in mind, hard to follow when I return to them a few months later. One of the reasons is that the datatypes are not obvious.Also, they work fine for me because I know the input I expect, but writing Perl scripts that work no matter how they are abused is hard. There are some large and robust projects written in Perl; it can be done. However, languages like C++ and Java with clearly declared data types have worked far better for me for large long term projects. (You have Java confused with JavaScript– JS has loose types similar to Perl– Java supports strong typing.)
I really can’t imagine a big project written in Perl. It seems to me that folks who try to use a language like Perl for large projects do it because they like Perl, not because it is the best engineering choice. I love to write Perl, but I get a sick feeling when I realize that a quick one-off script has turned into a project. Perl is perfect for dashing off a quick solution to a limited problem, but it turns to mush on large projects, IMHO.
I haven’t written much Python. My impression is that it is more oriented toward projects than Perl, but it is still in the quick solution category. Some of the engineers in my group were involved in developing Python. Their goal was a scripting language that was object-oriented. Perl supports object-orientation, but I find it works better as a structured procedural language. I haven’t written enough Python to say much about it, but I suspect that I would prefer it to Perl for object-oriented projects if I took time to learn it well.
The strongly typed languages are harder to learn and slower te write, but I believe they tend to produce more maintainable projects.
Best, Marv