Friday, April 15, 2022

The Hidden History of Big Brother in America by Thom Hartmann: A Review

 

Companies like Facebook-Meta and Google are under increasing scrutiny as we have come to realize that our personal information and browsing habits are the highly profitable product that they are selling. In his book “The Hidden History of Big Brother in America”, radio host and best-selling author Thom Hartmann shows us how the consequences of Big Data are far more extensive than we imagined. His thought-provoking expose details the history of “privacy” and the endgame for Government and Big Business, highlighting the urgency of guarding our information.


After a compelling introduction, this short 4-part book moves through the evolution of the meaning of privacy, the use of personal information for social control, the emergence of so-called surveillance capitalism and the unsettling rise and implications of global cyberwar. Somehow the final section – a call to arms to fight the nefarious uses of private information by Big Tech and Governments – seemed a bit impotent compared to the threats that face us.


Our assumed right to privacy is not explicitly guaranteed in the U.S. Constitution; while the Fourth Amendment assures personal freedom and protects against unreasonable searches, it never uses the word “privacy.” At the time of the Founding Fathers, privacy had a completely different meaning, referring to things done in secret. Asking for privacy in those days meant that you needed to use the toilet, hence the name “privies.” We’ve come a long way, both in plumbing and in personal rights.


Social control is generally the goal of privacy violations, which have been used in various forms from Puritan New England, through the US period of slavery, and into modern times to alter behavior. Supreme Court Justice Louis Brandeis wrote a 1928 opinion mentioning “the right to be let alone” which rocked the legal establishment and ignited generations of debate over an individual’s right to privacy. Nearly four decades later, Justice William O. Douglas affirmed this right, citing the Ninth Amendment which says that just because some rights are specifically detailed in the Constitution doesn’t mean others are automatically excluded. The ensuing series of laws created some protections on wiretapping, financial records and other forms of personal information held by the Federal Government. When Edward Snowden revealed the use of secret, illegal court orders to pry information from ISP’s and phone companies, Congress responded with the 2015 USA Freedom Act which banned this type of bulk information gathering.


Now that the Internet of Things is a thing, many of us are embracing the idea of a smart house where conveniences abound. In exchange, we give up information about the size and layout of our homes, our sleeping habits, our daily schedule, and even our conversations. The services which gather and process this information often use it to create scores, which can then be used to screen people for jobs, loans, and apartment rentals. The accuracy of this data, and the algorithms used to derive the scores, are completely secret.


Spying has been around forever, and governments are always using it to get the upper hand on one another. The risk/reward calculus of cybrwar is far better than nuclear war and may very well define the battlefield for the next great international conflict. So many of the systems we depend on – water, electricity, sewer service, communication – are connected to the Internet and are ripe for disruption. Your smartphone can use facial recognition to log you in or sort your pictures, but China – the world leader in this technology – uses it as the foundation for their surveillance state.


So how do we take back control of our privacy? We exchange information with the government to make us feel more secure, and we make a similar deal with Big Tech to make our lives easier. The European Union has the set of laws known as GDPR (General Data Protection Regulations) that seek to limit the amount of data that can be collected and how it is used. In the US, government agencies may have some restrictions on what they can gather from residents without the use of a warrant, but spying on people remains the fundamental business model of Big Tech.


The title “Hidden History....” raises expectations of new information or connections that we haven’t read before, and Hartmann’s book doesn’t disappoint. His biases as a popular progressive radio host are apparent, but the book is well researched, and an extensive list of references support his narrative. Hartmann’s personal experiences with the “Stingray” cell towers that surround the White House, or while visiting East Berlin with his daughter in the late 1980’s, are both revealing and impactful. Using people’s past behavior to sell them stuff, for social control, or as a form of warfare is not a new thing, but the speed and precision with which this can be done has grown frighteningly over the past few decades.


This is something to think about the next time you ask Alexa to order more tissue for the “privy.”


Author Profile - Paul W. Smith - leader, educator, technologist, writer - has a lifelong interest in the countless ways that technology changes the course of our journey through life. In addition to being a regular contributor to NetworkDataPedia, he maintains the website Technology for the Journey and occasionally writes for Blogcritics. Paul has over 40 years of experience in research and advanced development for companies ranging from small startups to industry leaders. His other passion is teaching - he is a former Adjunct Professor of Mechanical Engineering at the Colorado School of Mines. Paul holds a doctorate in Applied Mechanics from the California Institute of Technology, as well as Bachelor’s and Master’s Degrees in Mechanical Engineering from the University of California, Santa Barbara.



Monday, April 11, 2022

"Get Off Your Butt and Go for A Walk!"

 One of the key points I occasionally make when teaching, presenting or writing, is that sometimes you need to stop looking at your red light/green light monitoring system, stop pinging, and please stop rebooting equipment! Nothing replaces getting out there and physically looking at the problem.


In my 30+ years of troubleshooting, I can not tell you how many times the problem looked obvious when I physically got out there to investigate the problem. I've seen a ladder leaned up against a breaker, cables pressed up against power buttons, equipment hanging in a bag that was powered on causing the bag to melt around it, excess cabling wrapped around an arc welder, cables pinched in doors, cables spliced and wrapped in electrical tape, trust me, the list goes on.


In this case, some wireless equipment had a poor signal and the technicians were rebooting it, checking for noise, etc. I then found out that the signal went out of wack after a wind storm, so I climbed up (why I'm huffing and puffing a bit) and sure enough the bolts on the bracket that stabilizes the tower had come loose.


Before you comment that "sometimes its not possible to go out everywhere", i simply counter that argument with "use your tech" use Zoom, facetime, or ask someone there to take photos/videos. Trust me, its better than nothing.



Monday, April 4, 2022

SNMP DISCOVERY & INVENTORY

 The most common question I get asked is “When troubleshooting, where do you start?”.

Other than the "client interview", the answer is simple, “start with an inventory”. When I say “Inventory” it is an all-encompassing term. It covers the physical equipment, connectivity, layer 2, 3, and any other layer it takes to get from point a to point b. Many times we can get a 'visual' from the client interview but other times we need more info, or have to confirm what they believe is out there.


I always say, “We can't fix what we can't see”. If the client already has documentation, great, let's review it with respect to the issue at hand. I am not surprised how many times I am presented with out-of-date documentation. In some cases, entire sites are omitted, not added or equipment upgrades are not reflected. I never consider this scenario a negative one and explain “all we have to do is update what we have”.


It's important that this does not turn into a “who didn’t update the documentation and why witch hunt”, let's just get the documentation updated and move on. This is always the interesting part of the documentation exercise; watching the client argue with colleagues about “who moved that”, “I thought we replaced that box”, and the ever-popular “that’s an old config”. Many times, we actually find and fix the problem as we go through the documentation exercise.


When I talk about the documentation process, the most common response I get is “I don’t have time to do that”, and I respond with “how much time do you have to update the documentation during an outage or troubleshooting?”


The best place to start with is at the physical layer, at the clients' desk and the destination could be a server/application you use. The client the best place to start because you can verify the cabling, switch configuration, etc easier. Then work your way up the physical layer, to layer2, then 3, etc. If you get stuck or aren’t sure, feel free to reach out to various people/departments for clarification.


You can literally start with a piece of blank paper, Powerpoint, Draw, Impress, heck, even Paint will do. As you build the maps, and more people see the value, you can consider a different application and how to share the information.


In this video, I was doing a physical inventory at a remote office and there was no documentation, so I grabbed a couple of my Cisco switches, enabled SNMP, swapped out the client’s switch, and ran a discover with my Optiview XG. Then I moved on to the next closet.

In this case, I took photos before I started, and documented all the current switch connections. Then I had to come in when no one was in the office, run my discovery and then put everything back. The whole process took an hour and about another 30 minutes putting the documentation together using Powerpoint.




Wednesday, March 30, 2022

“Its Dead Jim” Looking into a SSID Issue With My NetAlly Aircheck G2

 When troubleshooting WiFi issues, the last thing I want to do is worry about having issues with my laptop and trying to figure out how to do specific things.


For example, if you have 5 access points with the same SSID, can you connect to a specific BSSID using your Windows, Linux, Android or MAC for testing?


I’ve gone through various hacks, special drivers and all sorts of technical gymnastics to get my laptop to do specific WiFi troubleshooting tasks. That might be fine for learning and playing in the lab but not very practically when you have to troubleshoot on the fly.


In this scenario, I wanted to verify that a specific SSID was working on two access points. I ask this question all the time “are all your access points supporting your SSID’s?”. I ask because it is hard to verify if this is the case.


In some environments, you can go to your wireless controller, or to specific access points to confirm who is connected to it. But then you need the mac address of the device and in some cases, the support staff doesn’t have access to the controller or access point.


This is when I prefer to use my NetAlly AirCheck G2 since I can use it to connect to specific access points and run tests. In this video, I show you how I tested and proved if both access points were working properly.



Monday, March 28, 2022

Wireshark Windows Vs Linux

 I have always enjoyed testing tools in my lab. For those of you who have followed me over the years, know that I always say that you should ‘know your tools’. I know this sounds obvious but trust me, it is anything but obvious.


For example, you have a relatively new laptop with 8 GB or RAM, i7 processor and 1 Gb Ethernet adapter. So, you would think that you should be able to capture traffic up to 1 Gbps, right? Wrong!!


In my last article, “Wireshark, Microsoft pktmon, packet testing” (https://youtu.be/pZtWAwiH7lk), I compared various command line and GUI tools and how efficient they were in capturing packets. Thank you for all the feedback and I thought I would use one of the suggestions for this next article.


The point of the article is that you need to test your tools using various packet sizes and loads to determine when it will drop packets. The secondary goal is to show you how I tested my tools so you can use a similar methodology for your testing.


In this article, I compared the Wireshark GUI performance on a Linux and Windows. I used the same laptop for both tests and neither was within a VM. The only result that shocked me was that Windows barely outperformed Linux in the 10%, 64 Byte test. See, I learned something as well.



Popular post