This story is unusual and somewhat disturbing. Some of you may have seen a quick glimpse of my Amazon Echo 5 article a few weeks ago. A day after it was published, there was an incident causing me to redirect the page web address (URL) to the blog page of WAVGroup.com.
It was a sunny, hot, and humid morning, the windows in my office fogged with condensation. I was beaming with pride because I published an article the night before that was fun to write. The premise of my article was to explore how technology was on a path to deliver content as a multimodal experience and its relevance to NAR MLS policy.
What is a multimodal experience?
In the past, the delivery of content was in the form of a single mode. If you wanted to read the news, you grabbed the paper and read, you turned on the TV and listened, or pulled up your trusty mobile device to either read or listen.
A multimodal experience dispenses content through different devices at the same time. Some of the content is duplicative via audio and visual displays, but some content is different depending on the delivery device.
We have seen an outbreak of device innovation in this space, and the methods to distribute content are rapidly evolving. Amazon is the leader in this space right now, with Alexa and all of its devices. Ask Alexa a question, and an explosion of content unveils itself onto any device connected to it. Just look at all the devices that can connect to Alexa:
- Echo
- Echo Plus
- Echo Dot
- Echo Spot
- Echo Show
- Newly released Echo Show 5
- Firebox
- Fire HD Tablet
Companies like Bose and Sonos are jumping on the bandwagon by integrating Alexa into their devices.
Back to the grim story
What happened that caused me to unpublish my article and redirect the web address to another section of the web site?
The first task of that early morning was to do a quick proofread of my article. I accessed the web site, navigated to the article, and before the morning blast to the subscribers, I went through one last proof.
Thirty minutes later, I received the dreaded red screen notification from Google Search Console in my inbox.
WTF – How did this happen? I checked all my external links to validate they were safe. I tried to open the page again. Bang! I received the Google red screen web page notification indicating malicious software. I went to Firefox and received their red screen notification.
What the heck?
My first step was to double-check all external links and review the other parts of the web site. Only my page delivered the red screen notification.
The next step was to download the files and perform a “Grep” to find a change date on any file or other common infiltration of code. The files for the web site were normal.
At this point, I needed to recover as best as I could. Unpublish the page and create a 301 redirect to the /blog/ page.
What I found out was this. The red screen notification displays on the URL, and it is the browser that delivers the warning. The person accessing the page is not even getting to our web server for the redirection occur. This means we will have to wait for Google to remove the warning.
Check the log!
My next step was to check the Apache log and see what requests were handled by the web site. I had the time stamp of the email from Google Search Console, so it was reasonably easy to find abnormality in the log.
Denial of Service (DoS) Like Attack on the Page!
What I found was surprising. Just before Google SEC’s notification to me, there was a request to the server for PHP files using the articles web address. Here is a fictitious example:
/2019/06/16/article web address/login.php
This type of request to the server occurred every second for about 20 minutes using different kinds of .php files. These files don’t exist at the end of the article. Someone was purposely requesting multiple files that did not exist on the web server.
After these requests completed, I believe the person then submitted a malicious page report to Google.
I would bet when Google received the request, they looked at the network logs across the Internet and saw these false file requests. Bingo, they shut down the page.
Help, Google – This is a false report!
Yeah, like Google cares about false reports. I still went through the process of submitting a request in order to have the page removed from the red screen warning. There are multiple places to send a request, my recommendation is to do them all.
It took Google three days to confirm that the web address was removed from the red-screen warning. Note: It took three seconds for Google to put the notice into action, but three days to remove the notification!
I AM Upset!
This tactic is someone’s attempt to censor my thoughts. A digital attack to impede my First Amendment rights to free speech. So, I made a few modifications to the article and the web address and published the article two weeks later.
Yup, you guessed right. The day after publishing the article, I received the same Google SEC notification of my page having malicious content on it. Rinse and repeat the above steps.
Now, what to do?
Wipe off the condensation from the windows and tell the story for others to hear. It is possible to censor people digitally. It is easy and unforgivable as Google has shown.
The optimist in me wants the person to come forward and have a genuine debate about broker attribution. At the time I am writing this, as reality sets in, it is extremely questionable if they will come forward or NOT. I am betting on the NOT. It is a shame that this individual(s) is able to hide behind their in-depth knowledge of technology in order to violate free speech.
The worst part for me is that I suspect whoever did this was from our industry. For me, it is a sad revelation in an industry where I have great respect and reverence for the people in it. I never thought this would happen. It is inexcusable to prevent another person’s right to free speech in any form or manner.
I hope someone proves me wrong that this act of censorship was done on purpose. Please do!
To stay on top of the most important issues facing real estate today, subscribe to the WAV Group newsletter HERE.
Fascinating and disturbing. My initial thought was that it was a competitor of Amazon trying to quash articles about Alexa/etc., assuming that a tech giant has systems in place to identify when such articles appear, and the resources to act quickly on it. I’d like to know if more comes of it.
I would hope it is an Amazon competitor that is so petty and stoop to this level! Thanks for the comment!
1,200 requests trying to “guess” a login page is pretty mild. Multiple IPs on my servers are incessantly pounded with attempts to login to wordpress, or example — despite that wordpress has never been installed on any of the IPs on those servers. (I’m assuming there’s more in the details to the story than you’re presenting?) Were the approx 1,200 requests in the apache log all from the same IP, different IPs but within the same IP block, different random/pseudo-random IPs?
Watch for more hair-pulling strange, annoying happenings now that Facebook has opened up its “AI” (sic) APIs to developers. Legions of techno nerds who know little about how the WWW works (let alone how the internet works — let alone how computers work) will be increasingly messing-around causing what are (probably) unintended consequences …
Each request was targeting the articles URL with a different PHP file that doesn’t exist. Yes, the requests were coming from the same IP address and from an oversee’s VPN. I still have the log file.
Wow David! This is crazy!
Hi Georgia: Yes, really crazy and scary.