Autonomic Nervous System and AI Real-Time Systems: As Applied to Autonomous Cars

By Lance Eliot, the AI Trends Insider

The autonomic nervous system of humans is sometimes also referred to as the vegetative nervous system, or the visceral nervous system, or even the sympathetic nervous system. We all know that whatever you call it, the purpose seems to be as a regulatory function of the human body and one that generally occurs automatically. In that sense, it happens seemingly unconsciously.

Your brain doesn’t apparently need to do much toward making sure that your heart is pumping blood. Cardiac regulation is mainly the role of the autonomic nervous system. Respiratory functioning is also usually being handled by the autonomic nervous system. Overall, the autonomic nervous system (ANS) is often considered the true core of our fight-or-flight response mechanism. It offers the handling of our key physiological responses. Most of the time it is happening in an involuntary fashion. It just happens and we live to tell the tale.

The other day, while studying some AI code that had been jointly written in Python and TensorFlow with a colleague of mine, he sneezed. This wouldn’t be particularly noteworthy except for the fact that he sneezed again, and again, and again. He somehow got himself into a sneezing fit. Was he allergic to Python? Maybe to TensorFlow? Maybe to AI? All kidding aside, it was quite a moment that caught both him and I unawares and he seemed to just keep sneezing. The first sneezes were almost humorous, but when he kept going it became more somber and we both wondered if somehow there was something amiss. Fortunately, it subsided, disappearing almost as mysteriously as it had originally appeared.

It might have been that his autonomic nervous system was reacting to an environmental condition, perhaps some allergen in the air or maybe the coffee he was drinking had some chemical that sparked the sneezing. Thus, one theory would be that it was entirely due to an involuntary act and a foundational human response that he had no conscious role in instituting and nor controlling.

Or, it could be that he was mentally reacting to our conversation and perhaps his mind was jogging his sneezing mechanism as a type of reaction or communication mechanism. In the old debate of mind over matter, we’ll likely never know whether it was a straightforward autonomic response or whether it was possibly a mentally generated response.

Dual Brains Of Sorts And How To Coordinate Them

Some liken the autonomic nervous system to being a “second brain” of the human body. It’s as though we have our normal brain that we believe does our thinking for us, and then a second kind-of-brain that is the “body controller” aka the autonomic nervous system and for which it tends to do whatever it wants to do. At times, the two brains (if you believe in this notion) are aligned and at other times they might be working seemingly separately. Your real mind might be saying don’t sneeze, and the second “mind” might be saying sneeze and sneeze some more. The real mind might not be able to do much to stop the second mind.

Now, one could suppose that the real mind could try to trick or control the second mind, in some cases and in some ways. While my colleague was sneezing, he grabbed for a glass of water and tried to drink the water. He later explained to me that he thought perhaps he could suppress or even stop the sneezing by guzzling down some water. Turns out this didn’t seem to make any difference to the matter and he kept sneezing. But, it is perhaps illustrative that his real brain had mentally come up with a quick plan of drinking water, doing so in hopes of overcoming the “second brain” of the sneezing fit being fueled by presumably his autonomic nervous system.

We might consider Robert Louis Stevenson’s famous Dr. Jekyll and Mr. Hyde as the same kind of duality of having two brains in our body. The real brain provides our presumably conscious kinds of thinking, while the “second brain” of the autonomic nervous system deals with our visceral, vegetative kinds of responses. Of course, Henry Jekyll was meant to represent good and Edward Hyde was representing evil, which in the case of the human body and its “two brains” as alluded to herein we aren’t saying one is good versus the other being evil. They both just are.

They each perform their respective function. At times they might be well aligned, and at other times they might be misaligned, including perhaps wanting the opposite of each other. For whatever reason, the autonomic nervous system might be saying sneeze, darn you, sneeze, while the real brain is saying let’s put an end to this disruptive and seemingly useless and unfitting sneezing fit.

AI Self-Driving Cars As Case Of Dual Brains Element

What does this have to do with AI self-driving driverless autonomous cars?

At the Cybernetic AI Self-Driving Car Institute we are developing AI systems for self-driving cars. One of the crucial open questions right now involves the role of so-called autonomic subsystems versus AI-led subsystems of an AI self-driving car.

Allow me to elaborate.

Many conventional cars today have an automatic braking system that is included by the car manufacturer. Often it is an added optional feature for your car. If you opt to pay for it, the feature is added to or included into your car. Don’t confuse this with the anti-lock braking system (ABS), which has been around for many years and comes pretty much as standard on most cars today. Instead, I’m referring to what is often called the Advanced Emergency Braking (AEB) system or at times referred to as the Automatic Emergency Braking or the Autonomous Emergency Braking. Either way you phrase it, let’s anoint it as the AEB herein.

The National Highway Traffic Safety Administration (NHTSA) pushed for the full adoption of AEB in the United States and by-and-large the auto makers agreed to do so by the year 2022. The notion is that it is an autonomic subsystem of your car, meaning that it acts independently of the human driver and tries to figure out when to apply the brakes, doing so only when it is considered an “emergency” situation and also doing so in the somewhat blind hope that applying the brakes is the right thing to do in the circumstance.

Notice that the way in which I’ve phrased the nature of the AEB is by carefully pointing out that it is intended to do more good than harm, though you need to keep in mind that it is a relatively simplistic subfunction and might be right or wrong when it opts to engage. If it detects an object in front of your car, and if your car seemingly is going to hit that object, the AEB deduces mathematically that it should go ahead and apply the brakes on your behalf as the human driver.

You generally don’t have much say about this. The AEB generally does its detection and calculations in split seconds and then activates the brakes. You might liken this to the human autonomic nervous system and consider it to be a reflexive or autonomic act of the car. In terms of the example earlier about sneezing, the autonomic nervous system of my colleague presumably invoked his sneezing fit, and his real brain didn’t have much to do with it. In the case of the AEB, you the human driver and with your real brain, generally don’t have much sway over the activation of the AEB and the AEB will do what it needs to do.

In some cars, you as the human driver can choose to disengage or deactivate the AEB. This raises all sorts of questions though. Why would you deactivate the AEB? In theory, if your car has AEB in it, you would want it to always be on, always be ready, always be available to automatically apply the brakes in an effort to save your life and possibly the lives of others. Some auto makers are prohibiting the car owner or consumer from being able to turn-off the AEB. It is considered essential and not to be toyed with. But, there are some car owners or consumers that believe they should be able to decide for themselves whether or not to have the AEB activated. Freedom of choice is their mantra.

Suppose a conventional car that is equipped with AEB comes upon another car that is stopped in the roadway and the AEB detects the stopped object and applies the brakes to your car and manages to stop prior to hitting the other car. The AEB is the hero! The human driver for whatever reason wasn’t noticing the stopped car or froze-up and failed to hit the brakes, and so the AEB stepped in like superman and applied the brakes.

Imagine if the AEB had not been engaged. As far as we can discern, the moving car would have plowed into the stopped car, possibly causing injury or death. If you were in the car that got rear-ended, you’d want to know why the AEB had been disengaged on the car that hit you. It would seem irresponsible that the driver had deactivated the AEB, a mechanism that could have possibly saved lives and prevented injuries. This kind of circumstances is exactly why some of the auto makers make the AEB unable to be deactivated by the consumer (often, it can instead be deactivated by a trained car mechanic or by the auto maker).

Besides the ability to possibly disengage beforehand the AEB, there is also often a feature of the AEB that allows for a type of “human action” default override of the AEB. For example, some AEB subsystems will detect whether the driver of the car is accelerating, and if so the AEB will not apply the brakes, even if the AEB has calculated that there seems to be an emergency and that applying the brakes seems like the better choice. This capability of the AEB is made under the assumption that if the human driver is accelerating, perhaps the human has determined that the best course of action involves speeding up to avoid a crash. In that case, the AEB quietly demurs to the choice of the human driver.

This brings up the duality of the two brains. You have a human driver that has all the intelligence of a human and therefore we might assume that for driving of the car they know best. We have a “dumb” advanced emergency braking system that relies upon very simplistic mathematical formulas and sensors of the car to try and figure out whether to apply the brakes in what appears to be emergency situations.

Million Dollar Question About AEB

Should the AEB always go ahead and apply the brakes when it ascertains what it believes to be an emergency situation, or should we allow that a human might be more aware of what’s really happening and therefore in some situations defer to the human?

That’s the million dollar question. Under what circumstance should the AEB apply? You might say that the AEB should just ask the human driver, hey, you, should I go ahead and apply the brakes right now? But, that’s not very practical. By definition, the AEB is generally going to undertake braking at the last moment, when just split seconds are left, and the time it would require to ask a human whether to go ahead and apply the brakes would defeat the purpose of the AEB. By the time it asked and the human responded, the odds are that the car would have already smashed into whatever the AEB was trying to prevent a crash from occurring.

We’re kind of back to the predicament about whether to allow a human to deactivate the AEB. Some say that the AEB should be sacrosanct. It should always be on. It should always proceed to apply the brakes when it ascertains that applying the brakes is warranted. Period. No further discussion or debate. There are those that point out that the AEB is a simplistic function and might or might not be right in what it chooses to do. For them, the AEB should either be allowed to be deactivated by a human, beforehand, prior to an emergency, or that during an emergency the acts of the human driver should determine whether or not the AEB acts, such as if the human driver is accelerating deeply then it implies the human is overtly trying to act and the AEB should not mess with the human driver.

Indeed, this brings up another salient point. Suppose the human driver was rapidly accelerating and genuinely believed that by accelerating they might get themselves out of a jam and avoid crashing. Meanwhile, suppose the AEB was blind to whatever the human driver was doing and figured that it made no difference whatsoever about the acts of the human driver. As such, all of a sudden, the AEB applies the brakes. The human driver is confused and confounded since they are trying to do the direct opposite. If both the AEB and the human driver are at odds, one can assume that the end result will be worse, namely that the car won’t necessarily brake in time and nor will the car accelerate in time to avoid the incident. Boom. Crash.

The same issue can confront AI self-driving cars.

I know it might seem surprising to consider that the same predicament can face AI self-driving cars. You would likely be under the impression that the AI of a self-driving car would determine all the actions of the self-driving car. But, this is not necessarily the case.

Many of the auto makers and tech firms are taking “conventional cars” and adding the AI self-driving car capabilities into those cars. Thus, it is not a grassroots from the bottom-up redesign of a car, but instead the morphing of a somewhat conventional car into an AI self-driving car. As such, there are a wide variety of elements of a conventional car that are still embodied in the arising AI self-driving car.

For my article about kits to convert cars into AI self-driving cars, see: https://aitrends.com/selfdrivingcars/kits-and-ai-self-driving-cars/

For my framework about AI self-driving cars, see: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/

For those that believe we ought to start-over about cars to make AI self-driving cars, see: https://aitrends.com/selfdrivingcars/starting-over-on-ai-and-self-driving-cars/

Those Two Brains Arise And Possible Conflict

In essence, once again we have two brains in a car. For a conventional car, it’s the human driver and the AEB. For a true AI self-driving car, it is the AI and the AEB. Well, actually, there are other semi-autonomous subfunctions of a conventional car that also relate to this whole notion of who’s in-charge of the driving, but the AEB is the most prominent and the focus herein. You can apply the same principles underlying the AEB matter to the other kinds of autonomous rudimentary functions on conventional cars.

Just as the human driver is the “real brain” and the AEB is the (shall we say) tiny brain, in the same manner we might ascribe that the AI of the self-driving car is the “real brain” and the AEB is the tiny brain. I want to be careful though in somehow implying or suggesting that the AI is the equivalent to a human brain of a human driver – it is not. Therefore, when I refer to the word “brain” as it relates to the AI, I am only using the word in a loose sense and not intending to suggest it is equivalent.

For an AI self-driving car, you’ve got the dilemma of having the AI that is supposed to be doing the driving, and yet also there’s an autonomic nervous system that consists of the AEB (and other subsystems). Which of them is in-charge?

You might contend that the AI should be in-charge. As such, you would presumably deactivate the AEB beforehand, prior to the AI driving the self-driving car. Thus, there’s no need for the AI to be concerned about the AEB and avert any efforts by the AEB that might seem counter to whatever the AI is trying to do while driving the car. Matter settled.

But, not so fast! We are still going to be faced with the same concerns as we did with the human driver that deactivates beforehand the AEB. Suppose there is a situation in which the AI was faced with a situation that could have been solved via the use of AEB, but because the AEB was deactivated the AI instead took some action that then led into the crash.

If this seems theoretical, allow me to point out that this very same question arose with the Uber crash in Arizona that killed a pedestrian crossing the street. The Uber self-driving car had the AEB deactivated. The AI that was driving the Uber self-driving car hit a pedestrian. If the AEB had been activated, the question remains whether or not the Uber self-driving car would have struck the pedestrian, or that if it had done so nonetheless that at least it might have been going at a slower speed due to the braking of the AEB by the time it hit the pedestrian.

See my analysis of the Uber incident: https://aitrends.com/selfdrivingcars/initial-forensic-analysis/

See my follow-on analysis of the Uber incident: https://aitrends.com/selfdrivingcars/ntsb-releases-initial-report-on-fatal-uber-pedestrian-crash-dr-lance-eliot-seen-as-prescient/

For my article about the cognitive timing of AI self-driving cars, see: https://aitrends.com/selfdrivingcars/cognitive-timing-for-ai-self-driving-cars/

Does Deactivation Make Sense

We’ve got the issue of whether to deactivate the AEB beforehand, and also the other question about what to do if the AEB is activated and it tries to override the AI of the self-driving car. Uber formally came out after the Arizona crash and pointed out that they had purposely deactivated the AEB since they believe that the self-driving car would otherwise possibly exhibit erratic driving behavior. This explanation fits with the points herein about the difficulties of driving a car when there are “two brains” involved and not necessarily working fully aligned.

At industry conferences, when I give presentations about AI self-driving cars, I often get asked the question of why t the AI of the self-driving car couldn’t do the same thing that the AEB was doing. We all get the idea that the AEB is different from a human in that it is a piece of automation and it can takeover for a human by applying the brakes in a sudden and deep manner. But, since it is a piece of automation, and since the AI is a piece of automation, it seems odd and maybe troubling to not have them fully aligned with each other. They should presumably be one and the same.

As mentioned earlier, the AEB is typically on a conventional car and when an AI self-driving car capability is grafted onto a conventional car you then end-up with these kinds of disparities. It’s almost like a Frankenstein containing multiple body parts from different sources. It’s not easy to make sure they are all integrated together.

For my article about the Frankenstein concerns of AI self-driving cars, see: https://aitrends.com/selfdrivingcars/frankenstein-and-ai-self-driving-cars/

For my article about the stealing of secrets about AI self-driving cars, see: https://aitrends.com/selfdrivingcars/stealing-secrets-about-ai-self-driving-cars/

For my article about the designs of AI self-driving cars, see: https://aitrends.com/selfdrivingcars/egocentric-design-and-ai-self-driving-cars/

You might rightfully wonder why the AI of the self-driving car doesn’t subsume the AEB function and perform the same tasks as the AEB would. In theory, we don’t need an AEB per se if the AI embodies the same capabilities of an AEB. That’s a good point.

The AI of most self-driving cars of today is not as well optimized to perform in the same manner as an AEB.

You can liken this to humans, in the duality of our minds and the autonomic nervous system. The autonomic nervous system works very fast and offers speed as an advantage for handling certain circumstances. When you put your hand near a hot stove, your hand recoils nearly instantly at the sensation of the heat. Some would say that this is happening in an autonomic fashion. Rather than your hand relaying to the brain that there is something hot, and your brain then figuring out what to do, including possibly sending a signal to the hand telling it to move away from the heat, the autonomic nervous system just makes it so.

One possibility in the Uber incident was that the AI might have taken too long to try and ascertain what action to take. If instead the AEB had been activated, it’s conceivable that the AEB would have acted like the retrieval of a hand that’s dangling over a hot stove, namely the AEB would have slammed on the brakes, right or wrong, in an autonomic manner.

In this particular case, we can likely surmise that the AEB would have been doing the right thing, based on what is known to-date about the circumstance. But, remember that the AEB would have presumably been activated all of the time, if it were activated at the time of the incident, and so you’d have had other tussles between the AEB and the AI, which might have led to other incidents. We don’t know.

And so this takes us to the gamble that most of the auto makers and tech firms are right now taking. Should they leave the AEB activated on their emerging AI self-driving cars, or should they deactivate it. If they deactivate it, there is the later question to be asked when an incident occurs as to whether or not they were right to have deactivated the AEB. If they don’t deactivate the AEB, it could turn out that there are situations where the AI and the AEB fight each other and the result is an incident that might otherwise have been avoided.

Darned if you do, darned if you don’t.

Integrating The Dual Brains Is Preferred

That being said, there are AI developers that also say that we need to better integrate the AI and the AEB. We need to design the AI to take into account the AEB. This might also mean that the AEB should be redesigned, doing so in light of the advent of AI self-driving cars. The notion is that the AI and the AEB are woven together, integrated as it were, rather than two different capabilities that happen to be on the same self-driving car. That makes sense and it’s the path we’re pursuing.

You might have seen in 2015 a viral video that showed a Volvo that was being demonstrated as to its AEB capability. The short clip of just thirty seconds or so became a worldwide sensation because it showed a Volvo being driven forward and a human stood in front of the car, anticipating that the AEB would hit the brakes prior to the Volvo hitting the human. Instead, the Volvo hits the human. Some wisecracks posted with the video included that the feature should be renamed the Auto Leg Breaker, or that it is the safest car in the world but only if you are sitting inside of the car.

It turns out that after the video rose to attention, it was discovered that the particular Volvo shown in the video did not have the AEB pedestrian feature in it. People that were criticizing Volvo, did so falsely, and assumed that the feature was in the car and that the feature was engaged. That’s part of the fake news in the AI self-driving car realm and something I’ve warned about many times.

For more about fake news about AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/ai-fake-news-about-self-driving-cars/

Conclusion

The point to that story is that when you get into a car, you often don’t really know what it consists of.

Likewise, when standing outside of a car, you don’t know for sure what’s under-the-hood. Right now, we have a brewing and bubbling issue of the AI versus the AEB in terms of AI self-driving cars. I can predict that we’ll have another incident involving an AI self-driving car that also had AEB, and for which the question of whether using the AEB would have been a life saver will arise. We’ve got to get the autonomic nervous system and the AI to be better integrated, soon.

And that’s nothing to sneeze at, I assure you.

Copyright 2019 Dr. Lance Eliot

This content is originally posted on AI Trends.

Government Bans on Facial Recognition Technology May be Premature

By Daniel Castro, Center for Data Innovation

Over the past year, a number of organizations have campaigned for policymakers to ban government use of facial recognition technology and for companies like Microsoft, Amazon and Google to not sell the technology to government. Their efforts have begun to bear fruit.

In February, a lawmaker in San Francisco proposed a rule that would ban all city departments from using facial recognition technology, and state legislators in Massachusetts and Washington have since followed suit with their own proposal to ban government use of facial recognition. However, these proposals are based on inaccurate or misguided concerns, and following through on them would weaken the effectiveness and efficiency of law enforcement, make schools less safe, and hold back technological progress at other government agencies.

Much of the opposition to facial recognition is based on the false belief that the systems are not accurate. But many of the most high-profile critiques of facial recognition are based on shoddy research. For example, the American Civil Liberties Union (ACLU) has repeatedly claimed that Amazon’s facial recognition service had an error rate of 5 percent when used to compare Congressional photos to mugshots, but the error rate would have dropped to zero had the ACLU used the recommended confidence threshold of 99 percent.

Moreover, there is clear evidence that facial recognition technology is becoming increasingly accurate. In 2018, the Department of Commerce’s National Institute of Standards and Technology (NIST) tested how accurately the facial recognition software from major developers could match two photos of the same individual from a database of nearly 27 million photos. NIST found that only 0.2 percent of searches failed. And while several facial recognition systems perform less accurately for certain demographics, the private sector has been actively working to address this problem, such as by developing more diverse image data sets to train their systems.

Unfortunately these proposed bans would limit many beneficial applications of facial recognition technology, such as allowing police to more quickly identify potential suspects, witnesses and victims; ensuring only authorized personnel can access secure government buildings; and helping schools prevent sex offenders, disgruntled employees, or other potentially dangerous people from entering their facilities.

Simply put, computers can search millions of photographs at a fraction of the time and expense of humans. Indeed, the technology has already proven its value on many occasions, including by finding missing children, catching people with false documents at airports, and combating human trafficking. Moreover, some of the proposed bans, such as the bill in Washington, would limit government from using other technologies, like tools to blur faces in surveillance footage before public release.

Read the source article at govtech.com.

Daniel Castro is the vice president of the Information Technology and Innovation Foundation (ITIF) and director of the Center for Data Innovation. 

Efficient Databricks Deployment Automation with Terraform

Managing cloud infrastructure and provisioning resources can be a headache that DevOps engineers are all too familiar with. Even the most capable cloud admins can get bogged down with managing a bewildering number of interconnected cloud resources – including data streams, storage, compute power, and analytics tools.

Take, for example, the following scenario: a customer has completed creating a Databricks workspace, and they want to connect a Databricks cluster to a Redshift cluster in AWS. The diagram below demonstrates the resulting state if all of these steps are completed correctly, as well as how data flows between each resource.

Achieving this state can be a lengthy process, and each configuration step involves significant substeps. For example, configuring the IAM roles to access S3 from Databricks alone requires a 7 step process.

Complex as this setup may be, it is by no means uncommon. Many customers have looked to cloud automation processes to simplify and speed the deployment of cloud resources, but these processes can pose challenges of their own. In general, we’ve found that many of the challenges in cloud automation include:

• Scalability– Adding new resources to an existing cloud deployment can become exponentially more difficult and cumbersome due to resolving dependencies between cloud resources.
• Modularity – Many deployment processes are repeatable and inter-dependent (for example, deploying to Redshift also requires a connection to S3 for staging the results).
• Consistency – Tracking a deployment state may simplify remediation and reduces risk, but it is difficult to maintain and resolve.
• Lifecycle management – Even if you can audit changes to some cloud resources, it may be unclear what actions are necessary to update an entire end-to-end state (such as the infrastructure state demonstrated in the above diagram).

To address these issues for our customers, Databricks is introducing a solution to automate your cloud infrastructure. Databricks Cloud Automation leverages the power of Terraform, an open source tool for building, changing, and versioning cloud infrastructure safely and efficiently. It offers an intuitive graphical user interface along with pre-built, “batteries included” Terraform modules that make it easier to connect common cloud resources to Databricks.

Keep in mind that many of these setup tasks such as VPC Peering and S3 authentication are specific to AWS. In Azure Databricks, for example, a connection to an Azure SQL Data Warehouse is simply a matter of authenticating with AAD, as the network connectivity is self-managed.

In developing Databricks Cloud Automation, we aim to:

• Accelerate the deployment process through automation.
• Democratize the cloud infrastructure deployment process to non-DevOps/cloud specialists.
• Reduce risk by maintaining a replicable state of your infrastructure.
• Provide a universal, “cloud-agnostic” solution.

With this new tool, connecting your cloud resources to Databricks is faster and simpler than ever. Let’s take a look at some of the reasons our customers are using Databricks Cloud Automation.

A graphical user interface to democratize Databricks cloud deployments

Databricks democratizes the deployment process by presenting a streamlined user interface that is easy and accessible, so you can be comfortable deploying cloud resources on Databricks without any DevOps experience. This high-level user interface allows us to manage cloud configurations behind the scenes, prompting you only for essential information.

An elegant solution for tracking infrastructure state

Aside from the simple setup, the tool’s most powerful feature is its ability to locally track and maintain the current and prior state of each cloud resource. As many DevOps engineers are aware, cloud resources often form a complex web of dependencies, each resource relying on others to function properly.

For example, a seemingly simple change to a single ACL entry can cause a cascade of errors downstream (and migraines for DevOps engineers). In the past, each of those dependent resources would need to be manually identified and to perform troubleshooting.

Terraform makes life easier by maintaining a “diff” between the desired state of resources and their current state. When it identifies a change, Terraform updates its internal “resource graph” and creates an ordered execution plan, automating the resolution of all cascading changes that would typically be necessary to keep these connections functioning.

A modular framework for your cloud infrastructure

For companies looking to dramatically scale their cloud infrastructure – now or in the future – Databricks Cloud Automation provides a simple interface to connect resources to Databricks using Terraform’s powerful infrastructure management capabilities. While casual users appreciate the graphical user interface and quick setup time, more experienced users appreciate the modular, extensible design principles that the tool embodies – allowing companies to rapidly grow their Databricks infrastructure without the hassle of complicated and easily-broken manual configurations and the risk of developing a monolithic architecture.

Terraform employs a high-level, declarative syntax known as HCL, allowing users to concisely define the end state of the resources that they intend to connect to Databricks. Many users prefer this style of quick, high-level resource declaration, which allows them to connect resources to Databricks right out of the box, while still giving them the flexibility to manually configure resources to their hearts’ content.

When a new resource is added, Terraform updates its internal resource graph, automatically resolves dependencies between resources and creates a new execution plan to seamlessly integrate the new resource into the existing infrastructure. Users can then view a summary of the changes Terraform will make before committing, by calling terraform plan.

Modules that can be shared, versioned and reused

One of the tool’s top features is the ability to create and save custom configurations as modules that can be reused or called by other modules. As a loose analogy, imagine using modules like a software engineer might use a class – to recreate an object, or to create a subclass that inherits properties from a superclass. For example, an S3 bucket configuration can be reused when creating a Redshift cluster, or a user can copy the configuration for a development environment directly to a production environment to ensure that they match.

This emphasis on repeatable, scriptable modules and “infrastructure as code” make it incredibly easy and efficient to scale up your cloud infrastructure. Modules can be shared amongst team members, edited, reviewed and even versioned as code – allowing DevOps engineers to make quick, iterative changes on the fly without fear of breaking their systems. This approach cuts the time-to-launch for new resource deployments by orders of magnitude and fits in nicely with many of the project management methodologies used today.

Connect to any IaaS provider

Terraform is “cloud agnostic” – it can be used to connect to any cloud provider or other systems – so DevOps engineers aren’t locked into a single ecosystem, and can connect resources between different providers easily.

They can also have confidence that they will not have to raze and rebuild their cloud infrastructure from the ground up if they decide to choose a new cloud vendor or connect a new system. In fact, there is a robust online community devoted to publishing robust modules and providers for nearly every cloud resource and use case.

Example: Connecting an S3 bucket to Databricks using the GUI

Let’s take a look at an example of how easy it is to set up and maintain your cloud infrastructure using Terraform with Databricks, by connecting an existing S3 bucket to Databricks using IAM roles (see here for the manual instructions). You will need:

• A previously created S3 bucket. Make note of the name and region. For a list of region identifiers, click here.
• AWS access key and secret key – to find or create your credentials, from the AWS console, navigate to IAM → Users → Security Credentials. If the S3 bucket was created by a different user, you’ll need the access key and secret key for their account, too.
• Name of the IAM role you used to connect Databricks to AWS. You can find that here.

First, using the command line, let’s download and install the Databricks Cloud Automation package, which includes Terraform:

pip install databricks-cloud-automation

To launch the web-based GUI, enter databricks-cloud-manager in the command line, then navigate to the following address in a web browser:

127.0.0.1:5000/

Here you’ll find examples of cloud infrastructure that you can add to Databricks using Terraform. Follow these instructions to get your S3 bucket connected:

1. Click Select under s3_to_databricks_via_iam.
2. Enter the credentials for the S3 bucket we’re connecting to. Under aws_region, enter the region that you use to connect to AWS. In our case, since we’re using US West (Oregon), we enter region code us-west-2.
3. Under databricks_deployment_role, enter the name of the IAM role you used to allow Databricks to access clusters on AWS. In our case, we enter the role name databricks.
4. Under custom_iam_name_role, enter a brand new name for an IAM role that we’ll create in order to access the S3 bucket.
5. Under aws_foreign_acct_access_key, aws_foreign_acct_secret_key, and aws_foreign_acct_region, leave these blank if your S3 bucket is under the same AWS account as the account you use to connect to Databricks. If you’ve got access to an S3 bucket owned by a different AWS user, enter those keys here.

6. Submit the form. You’ll see a summary of the plan, including resources that will be added, changed, or deleted. Review the list of proposed changes thoroughly, and select Apply changes to infrastructure. If you’ve entered valid credentials, you’ll get a page indicating that you successfully applied all changes, along with a list of everything that was changed. (Note that this added new resources, but it also updated some existing resources – for example, it might have added a line to an IAM policy that already existed). Scroll to the bottom of the success page and copy the s3_role_instance_profile written under the Output section, as seen below.

7. Sign in to your Databricks deployment. Click the Account icon in the upper right, and select Admin Console. Navigate to the IAM Roles tab, paste the role you copied in the previous step, and click Add, as shown below.

Congratulations! You’ve set up your first piece of cloud infrastructure, and managing it is now easier than ever. You can now launch clusters with your new IAM role, and connect S3 to the Databricks file system (DBFS) to access your data using the following command in a Databricks notebook cell:

dbutils.fs.ls("s3a://<s3-bucket-name>/")

Terraform is now tracking the state of our newly created infrastructure, and we can view the state by entering terraform show in the command line. If our resource has changed in any way, we can run terraform apply to repair it and any dependent cloud resources.

Connecting an S3 bucket to Databricks using the Command Line

If you prefer to use the command line to execute tasks, you can still get Databricks connected to an S3 bucket using Terraform using the Terraform CLI directly. This will allow you to leverage Terraform’s advanced features that are not easily accessible via the GUI, such as terraform import. To access the modules directly, run the following at a command prompt to install directly from the source:

git clone https://github.com/databrickslabs/databricks-cloud-automation.git
cd databricks-cloud-automation
python setup.py install

Once you have installed from source, simply navigate to the modules folder, and cd into the folder for a module (s3_to_databricks_via_iam, for the sake of our example). From there, run terraform init to initialize Terraform, then run terraform apply to enter your AWS credentials in the prompts that follow.

(Note: You can apply with the -var-file flag to specify input variables in a separate JSON or HCL file)

When you’re all done, copy the Instance Profile ARN provided, and paste it into Databricks via the Admin Console as we did in step 7 above. Voilà – you’ve connected Databricks to S3! Using the IAM role you’ve set up, you’ll be able to read and write data back and forth between Databricks and your S3 bucket seamlessly.

Connecting a Redshift Cluster to Databricks

Let’s revisit the example we proposed at the introduction of this blog – the most complex of our examples so far – to see how much easier the setup can be.

Imagine that you’ve just gotten started with Databricks, and you want to connect your company’s existing AWS Redshift cluster and S3 buckets so that you can get started. Normally, this would involve a time-consuming, procedural approach, requiring writing down various IDs and ARNs, and the following steps:

1. VPC Peering to the VPC containing the Redshift cluster, including adding new security group rules and route table entries
2. Create a new IAM role and attach it to the Databricks cluster
3. Create an S3 bucket with a policy that references the new IAM role
4. Grant AssumeRole permissions between the Databricks EC2 instance policy and the new role

The diagram below illustrates the complexity of setting up this architecture. Tedious as it may be, this is a real-life example that many of our customers face – and one that we can make significantly easier by using Databricks Cloud Automation.

Notice that in this example, in addition to connecting to a Redshift cluster, we are also connecting to an S3 bucket, just like we’ve done in the last two examples. Here is where the beauty of Terraform’s modular, “infrastructure as code” approach comes into play – since the S3 bucket module has already been built, there’s no need to “reinvent the wheel” and build a new S3 connection from scratch. Instead, we can call upon that already-built module, and add it like an interlocking puzzle piece that fits nicely into our existing resource graph. Likewise, we are also calling a separate “VPC peering” module which can even be refitted to set up VPC peering to resources other than just Redshift.

Just as before, we can use the Databricks Cloud Automation GUI to simplify and expedite this process. After calling databricks-cloud-manager from the command line, we then visit 127.0.0.1:5000/ in our browser and select redshift_to_databricks. In addition to the credentials needed to set up the S3 bucket, we will also need:

• Redshift cluster ID
• Databricks VPC ID
• Enterprise workspace ID (leave this blank if you are using a multi-tenant deployment; otherwise, contact Databricks to determine your Workspace ID.)

Once the proper credentials are entered, the Databricks Cloud Manager will configure all of the resource dependencies automatically, and let you know if there are any action steps you need to take. This process, though naturally still requiring you to find credentials for your resources, can be orders of magnitude faster than the alternative.

Summary

Whether you’re connecting to a single cloud resource or scaling your company’s infrastructure to meet your users’ growing demands, the Databricks Cloud Manager can dramatically reduce the time it takes to get you up and running. It’s popular among our customers due to its easy to use yet powerful features, including:

• A graphical user interface for quickly deploying your cloud resources without deep DevOps expertise.
• A high-level, declarative style that automates dependency and configuration management, allowing you to skip to an end result that simply works.
• “Infrastructure as code” paradigm, allowing you to reuse and modify modules to quickly scale your deployment without increasing the complexity.
• “Cloud agnostic” architecture, allowing you to connect to resources from different providers and systems, seamlessly.

Connecting your resources to Databricks is easier than ever, and with the power of the Databricks Unified Analytics Platform, harnessing the power of the cloud to find insights in your data is just a click away. If you’d like more information about this project, contact us, or talk to your Databricks representative.

--

Try Databricks for free. Get started today.

The post Efficient Databricks Deployment Automation with Terraform appeared first on Databricks.

Why Third-Party App Audit Should Be A Norm for Enterprises

Whenever the business world adopts a norm of the technical field, it must brace itself for the forthcoming of an inevitable wave of cyber-attacks. Hackers and fraudsters find new techniques and target such firms which embrace new and successful strategies to protect them from any vulnerability.

It takes years of extensive research and months of complex coding to design a system that successfully protects data and ensures that the network stays secure. This pattern is observed over the years as with the shift of preference towards small-screen devices and the cloud-based infrastructure.

The latest development in such trends is the acceptance of third-party apps by organizations for essential operations. Now, since cloud advancements have escalated, organizations prefer to find a business with cloud-based providers. This has resulted in making the network far more complex and dense.

William Evanina, the Director of National Counter Intelligence and security announced that;



Not only that enterprise is relying on third-parties suppliers, but these suppliers are also entrusted with the access to sensitive information, data and mission-critical systems. Before we move on any further let's understand what these apps are?

What Are Third-Party Apps?

A third-party application is created by a developer who is a specific product for open source or ...


Read More on Datafloq

6 U.S. Cities With Growing Tech Scenes

You may think of San Francisco and New York as a couple of the hottest places to move if you work in technology or want to land a job in the tech scene. Those cities are worth a look if you have your sights solely set on firmly established places.

If, however, you're open to living and working in areas with emerging landscapes, these locations may be for you.

1. Charlotte, North Carolina

Many people think of Charlotte as a hub for life sciences, but it's getting more well-known for technology as a whole. In 2018, CompTIA named Charlotte its Top Tech Town in the U.S. Moreover, the report about the CompTIA designation mentioned there were 44,464 IT job postings between August 2017 and July 2018.

Put Charlotte on your list as well if you're thinking about launching a startup. In January 2019, Charlotte hosted the Seed the South pitch competition, targeting all early-stage startups in the city. Although not reserved only for tech companies, this startup competition and others like it show that Charlotte is open to new ideas and companies — both of those things are good for the tech sector.

2. Austin, Texas

Austin aimed to become a tech hotbed several decades ago, ...


Read More on Datafloq

Coding & App-making just a child’s play for these school kids

Children are creating all kinds of things online, and a peep at White Hat Jr’s website reveals a range including simple drawings to games developed by children as young as 10.

US commerce secretary Ross to raise India's e-commerce rules in talks

Ross plans to discuss India’s new e-commerce rules that could have an impact on operations of firms such as Amazon and Walmart with his Indian counterpart

Japan's SoftBank set for small profit rise, Vision Fund IPO plans eyed

With investors struggling to quantify Vision Fund's growing investments amid a lack of clarity over its valuation methods, analysts think the listings could help underscore its strategy

Mastercard has a $1B plan for India in the next 5 years

About $350 million would go into setting up a local payments processing centre in keeping with the Reserve Bank of India’s mandate to store all payments data locally.

Is Big Data Changing How We Litigate Cases?

Individual court cases, while typically drawing on similar, prior cases, are by nature unique, but despite their discrete existence, data from other cases can provide litigators with a powerful advantage. From analyzing the composition of juries to building stronger law firms and analyzing case facts, big data is changing the way litigators practice law.

Assessing Case Facts

One of the most powerful tools that modern law firms have access to are libraries of past cases that can be used to inform current arguments. Pushing practice far beyond what’s possible by looking at legal precedents, big data allows firms to use these past cases more strategically. As described by the technology firm Gartner, big data begins with low-value information (hindsight), uses those past cases to gain insights, and predicts future outcomes through a process of foresight and optimization.

Practically speaking, these technologically driven insights help lawyers understand what makes new cases different from past ones and draws on all of that data to identify the best path forward. This is in large part because, as Texas attorneys M. Scott Brown & Associates note regarding their own practice, the role of any good lawyer is to “analyze factual and legal issues, look for fatal flaws.” For ...


Read More on Datafloq

PyMongo Tutorial: Testing MongoDB Failover in Your Python App

Python is a powerful and flexible programming language used by millions of developers around the world to build their applications. It comes as no surprise that Python developers commonly leverage MongoDB hosting, the most popular NoSQL database, for their deployments due to its flexible nature and lack of schema requirements.

So, what’s the best way to use MongoDB with Python? PyMongo is a Python distribution containing tools for working with MongoDB, and the recommended Python MongoDB driver. It is a fairly mature driver that supports most of the common operations with the database, and you can check out this tutorial for an introduction to the PyMongo driver.

When deploying in production, it’s highly recommended to setup in a MongoDB replica set configuration so your data is geographically distributed for high availability. It is also recommended that SSL connections be enabled to encrypt the client-database traffic. We often undertake testing of failover characteristics of various MongoDB drivers to qualify them for production use cases, or when our customers ask us for advice. In this post, we show you how to connect to an SSL-enabled MongoDB replica set configured with self-signed certificates using PyMongo, and how to test MongoDB failover behavior in your code.

Connecting to MongoDB SSL Using Self-Signed Certificates

The first step is to ensure that the right versions of PyMongo and its dependencies are installed. This guide helps you in ...


Read More on Datafloq

First successful use of Jenkins telemetry

Half a year ago we delivered a security fix for Jenkins that had the potential to break the entire Jenkins UI. We needed to change how Jenkins, through the Stapler web framework, handled HTTP requests, tightening the rules around what requests would be processed by Jenkins. In the six months since, we didn’t receive notable reports of problems resulting from this change, and it’s thanks to the telemetry we gathered beforehand.

The Problem

Jenkins uses the Stapler web framework for HTTP request handling. Stapler’s basic premise is that it uses reflective access to code elements matching its naming conventions. For example, any public method whose name starts with get, and that has a String, int, long, or no argument can be invoked this way on objects that are reachable through these means. As these naming conventions closely match common code patterns in Java, accessing crafted URLs could invoke methods never intended to be invoked this way.

A simple example of that is a URL every Jenkins user would be familiar with: /job/jobname. This ends up invoking a method called #getJob(String), with the argument being "jobname", on the root application object, and having it handle the rest of the URL, if any. Of course, this is a URL intended to be accessed this way. How about invoking Object#getClass(), followed by Class#getClassLoader(), by accessing the URL /class/classLoader? While this particular chain would not result in a useful response, this doesn’t change that the methods were invoked. We identified a number of URLs that could be abused to access otherwise inaccessible jobs, or even invoke internal methods in the web application server to invalidate all sessions. The security advisory provides an overview of the issues we’d identified by then.

The Idea

To solve this problem inherent in the Stapler framework’s design, we defined rules that restrict invocation beyond what would be allowed by Stapler. For example, the declared return type of getters now needed to be one defined in Jenkins core or a Jenkins plugin and have either clearly Stapler-related methods (with Stapler annotations, parameter types, etc.) or Stapler-related resource files associated with it. Otherwise, the type wouldn’t be aware of Stapler, and couldn’t produce a meaningful response anyway.

This meant that getters just declaring Object (or List, Map, etc.) would no longer be allowed by default. It was clear to the developers working on this problem that we needed the ability to be able to override the default rules for specific getters. But allowing plugin developers to adapt their plugins after we published the fix wasn’t going to cut it; Jenkins needed to ship with a comprehensive default whitelist for methods known to not conform to the new rules, so that updating would not result in problems for users.

The Solution

While there is tooling like Plugin Compatibility Tester and Acceptance Test Harness, many Jenkins plugins do not have comprehensive tests of their UI — the Jenkins UI is fairly stable after all. We did not expect to have sufficient test coverage to deliver a change like this with confidence. The only way we would be able to build such a comprehensive whitelist would be to add telemetry to Jenkins.

While Jenkins instances periodically report usage statistics to the Jenkins project, the information included is very bare bones and mostly useful to know the number of installations, the popularity of plugins, and the general size of Jenkins instances through number and types of jobs and agents. We also didn’t want to just collect data without a clear goal, so we set ourselves some limitations — collect as little data as possible, no personally identifiable information, have a specific purpose for each kind of information we would collect, and define an end date for the collection in advance. We defined all of this in JEP-214, created the Uplink service that would receive submissions, and added the basic client framework to Jenkins. The implementation is fairly basic — we just submit an arbitrary JSON object with some added metadata to a service. This system would inform tweaks to a security fix we were anxious to get out, after all.

Starting in mid October for weekly releases, and early November for LTS, tens of thousands of Jenkins instances would submit Stapler request dispatch telemetry daily, and we would keep identifying code incompatible with the new rules and amending the fix. Ultimately, the whitelist would include a few dozen entries, preventing serious regressions in popular plugins like Credentials Plugin, JUnit Plugin, or the Pipeline plugins suite, down to Google Health Check Plugin, a plugin with just 80 installations when we published the fix.

Learning what requests would result in problems also allowed us to write better developer documentation — we already knew what code patterns would break, and how popular each of them was in the plugin ecosystem.

The Overhaul

I wrote above:

For example, the declared return type of getters now needed to be one defined in Jenkins core or a Jenkins plugin and have either clearly Stapler-related methods (with Stapler annotations, parameter types, etc.) or Stapler-related resource files associated with it.

While this was true for the fix during most of development, it isn’t how the fix that we published actually works. About a month before the intended release date, internal design/code review feedback criticized the complicated and time-consuming implementation that at the time required scanning the class path of Jenkins and all plugins and looking for related resources, and suggested a different approach.

So we tried to require that the declared type or any of its ancestors be annotated with the new annotation @StaplerAccessibleType, annotated a bunch of types in Jenkins itself (ModelObject being the obvious first choice), and ran our scripts that check to see whether Stapler would be allowed to dispatch methods identified in telemetry. We’d long since automated the daily update of dispatch telemetry processing, so it was a simple matter of changing which Jenkins build we were working with.

After a few iterations of adding the annotation to more classes, the results were very positive: Very few additional types needed whitelisting, while many more were no longer (unnecessarily) allowed to be dispatched to. This experiment, late during development, ended up being essentially the fix we delivered. We didn’t need to perform costly scanning of the class path on startup — we didn’t need to scan the class path at all — , and the rules governing request dispatch in Stapler, while different from before, are still pretty easy to understand and independent of how components are packaged.

The Outcome

As usual when delivering a fix we expect could result in regressions in plugins, we created a wiki page that users could report problems on. Right now, there’s one entry on that wiki page. It is one we were aware of well before release, decided against whitelisting it, and the affected, undocumented feature in Git Plugin ended up being removed. The situation in our issue tracker is only slightly worse, with two apparently minor issues having been reported in Jira.

Without telemetry, delivering a fix like this one would have been difficult to begin with. Tinkering with the implementation just a few weeks before release and having any confidence in the result? Not causing any significant regressions? I think this would simply be impossible.

Like China, India also has a gruelling work culture

Indians are becoming exactly like the Chinese and Japanese when it comes to killer working hours

Robots Need to Get Emotional to be More Trusted, say Expert Panelists

Salvage Yard Privacy Tattletales by Scrapped AI Self-Driving Cars

By Lance Eliot, the AI Trends Insider

My latest rental car that I picked-up at the Chicago O’Hare airport was a treasure trove of information about prior renters. I could readily see data that had been imported into the car’s infotainment system that had come from at least six different smartphones. Lots of favored playlists of people that I didn’t know, but I now knew their taste in music.

Even scarier for those prior renters was that many of their contacts had also gotten transferred into the on-board systems of the car. Plus, via the built-in GPS tracking, I could see the specific locations and dates/times of where many of these prior travelers had gone while using the rental car. If I had been a nefarious person, it would have been possible to use all of this info in rather untoward ways. In my case, I was just curious to see what others had opted to leave behind.

When you get out of a rental car and drop it off at the airport or other destination, sometimes people leave behind quite a curious set of physical odds and ends.

The lost-and-found at a car rental office will typically have tons of sunglasses, which are a popular leave-behind, and likewise kids’ toys are another common leftover. In my own forgetfulness, I had one time left a charger cord and figured it was worth going back to the car rental agency to see if they had retrieved it from the car that I had rented.

The car rental clerk, upon listening to my pleading to find my charger cord, took me to their oversized bin of leftovers, which had a plethora of forgotten items, including surprisingly that there were numerous sets of keys. Keys upon keys, on key chains, on key rings, on carabiners, you name it. Obviously leaving behind your keys is a frequently forgotten item too (one wonders, don’t people miss those keys, and don’t they then surmise that they must have left their keys in that rental car they checked-in?).

Anyway, the quite helpful clerk let me rummage around in the bin (security lapse?). There were a lot of charger cords. I could not prove for sure which one was mine, since there were many that looked just like mine. In the end, I retrieved one that was the same as mine and went on my merry way. The lesson of seeing the full-to-the-brim bin was to always double-check and then triple-check my rental cars before I turn them in.

Digital Artifacts Leftover in Cars

In a modern world, we leave behind not just physical artifacts but also digital artifacts.

It is easy to pair your smartphone to the infotainment and GPS systems of a rental car. Apparently, a lot of people don’t add together two-plus-two and realize that what goes in won’t necessarily come out. When you pair your smartphone, depending upon the nature of the settings, you might be allowing the car’s on-board systems to slurp-up all kinds of info out of your handy cellphone.

I suppose that there are some people that are unaware of the transfer of data that occurs. They live in their own non-digital world or are just part of the unwashed of the digital realm. For some of them, the smartphone and Bluetooth are already somewhat magical, I suppose.

There are likely other people that know that it happens, yet perhaps assume that it will miraculously be erased for them. Perhaps it’s like the Mission Impossible movies and the inputted data will sizzle and disappear after it is done with your travel journey. This transferred data will self-destruct in ten seconds, good luck, Jim.

Certainly, the rental car agency could include as part of their rental car clean-up checklist the step of them resetting and blanking out the on-board systems that might have collected your private info. This added step would be nice for the renting public. You would never need to worry about it again, assuming that the rental agency actually did the erasure properly, and consistently, and without making any errors or omissions.

Admittedly, it would be an extra step for the rental firm, and if you are cost conscious as a rental agency, you might say that the cost of the labor to do this reset operation is going to be significant. I know it might seem trivial as an action and not seemingly labor intensive if the reset is setup as a one-click operation, but when you multiply doing this for the thousand and thousands of rental cars in a fleet, the labor becomes mind boggling. If it also added “wasted” time to turning around a rental car, this is another downside factor and means that your fleet of cars cannot be as efficiently put back onto the road to earn more rents.

FCC Provides a Warning About Digital Artifacts Leftovers

The Federal Communications Commission (FCC) has tried to forewarn people about the Bluetooth pairing dangers, including saying this: “If you connect your mobile phone to a rental car, the phone’s data may get shared with the car.  Be sure to unpair your phone from the car and clear any personal data from the car before you return it. Take the same steps when selling a car that has Bluetooth” (this is stated at the FCC’s web site, https://www.fcc.gov/consumers/guides/how-protect-yourself-online).

Note that the FCC warning also mentions the notion of erasing your data when you sell your own personal car.

I’m betting that many people neglect to do so. I know this for a fact because I bought a “previously owned” (let’s say it more plainly, “used”) car, and it had all sorts of data from the previous owner. What makes this more insidious is that the data covered a multi-year period of time. In the case of a rental car, presumably it would likely have less data, though it also depends upon how much has been retrieved from your smartphone.

I’m sure there are a lot of people though that when selling a car are more likely to think about their smartphone data that’s on-board the car. I would guess that it is something that you would be inclined to consider. A rental car is maybe less likely to be on your mind in terms of having paired your smartphone to it. For a car that you owned, you would be much more cognizant about having used the car’s on-board systems, it would seem.

Here’s an added twist for you, what about when your car gets wrecked and it is hauled off to a salvage yard.

Would you be thinking about the data that you’ve left in your wrecked car?

Probably not.

What Happens to a Wrecked Car

If you are car has gotten so wrecked that it cannot be repaired, the odds are that you are mentally and physically done with that car. The car is probably disfigured. It looks horrible. Nobody wants to try and deal with their now contorted and bruised car. It is like losing a loved one, in a sense, since we often grow fond of our cars. I am not saying it’s the same as a person or a pet, and merely trying to point out that many times we get emotionally attached to our cars.

I did so. One of my first cars was a nifty sports car. I had wanted that car for many years and saved up to buy it. I was pretty happy the day I bought it. Several years later, the car got stolen. I was devastated at first. My prized car was gone. I got angry. How dare thieves steal my car! I wanted revenge. I hoped the police would find the car thieves and, well, let’s just say that street justice seemed to be a fine way to deal with them, if you know what I mean.

I was told by the police that the odds were pretty high that the car was stolen by a local gang. The gang would joyride the car until they had enough of the fun or until the car itself was no longer able to run. Apparently, there was a rash of gang initiation rights that involved stealing a car, and my kind of sports car fit the profile of what was needed to get into a gang. Who knew?

After a few days of being despondent and hoping to get my car back, I gradually changed my mind about the matter. I didn’t want the car anymore. It had become soiled by the intrusion of the gang, if indeed that’s what had occurred. The car would never be the same, even if the gang somehow decided to park it someplace and walk away from it. My emotional attachment to the car became detached.

Amazingly, about ten days after the car had been stolen, I got a call from the police department, my car had been discovered. I went right away to go see it. The police had it at the official police impound. When my eyes saw the wreck that was left of my car, I knew at that moment that I probably should not have come to see it. It looked lifeless. Plus, the gang had driven it until a tire blew, and they kept driving on the rim, and ultimately rammed it into another car. The poor thing was a mangled and nearly unrecognizable variant of my prized sports car.

The gang had apparently zestfully stripped everything out of the interior once they had decided to abandon it. I mean everything was gone. There wasn’t much of anything inside leftover, not even the flooring mats and carpets. This sucker was picked clean. Imagine a skeleton of a car, prior to the auto maker putting the guts into it.

Believe it or not, I had never paired my smartphone to the car. I know this seems nuts, but it was just one of those get-around-to-it kinds of things that I had not done. Fortunately, there wasn’t any personal info in the car, other than the car registration had been in the glovebox, which was now gone, along with everything else that had been taken.

In discussing the car with the insurance company, they advised that the cost to repair the car would be excessive and recommended that the car be considered totaled. I quickly agreed. As mentioned, I was over the car by now. And, upon seeing it as a now picked over corpse, I could not imagine ever driving it again, in spite of whatever astounding repairs and fix-up that possibly could be undertaken.

That’s the last I ever saw of my sports car.

When I gently and hesitantly asked the insurance agent what would happen to the carcass (I’m wasn’t exactly sure that I wanted to know), he explained that it would be hauled off to a salvage yard. Some people call them junkyards, others refer to them as scrapyards. A rose by any other name. In the end, my car would be dismantled.

Any usable parts would be potentially resold onto the used parts market, or in some cases the scrapyard hangs onto the parts or to the carcass and allows prospective used-parts buyers to come and pick over the skeletons. There seems to be a thriving market of people needing to fix up cars and wanting to find the original parts that fit to the same brand and model of car that they own. Often these are car collectors.

My insurance agent explained that the cost of buying a new part from an auto maker is likely going to be a lot pricier than getting a used part that was once on a no-longer operating car. Some scrapyards remove the reusable parts and place them into a salvage warehouse, nearly arranged. More often, the scrapyards just pile up the “deceased” cars and allow car part seekers to roam around and find whatever they think they need.

He also explained that the unusable elements could be turned into scrap that can be sold at bulk prices, especially scrap metal. The front windshield was smashed, but the other windows were still intact, and so those could be removed and potentially sold as-is. My front bumper was ripped off the car entirely and the headlights were pretty much goners too. Meanwhile, the taillights seemed to still be workable, along with the mirrors, the exhaust system, and so on.

I decided that perhaps my sports car would make a better life for someone else, doing so by my “donating” them to the salvage yard. Well, okay, I didn’t actually donate the car, I instead got a check from the insurance company that covered the insured value. I just say in my own mind that I donated it, similar to providing donated organs for science. I’d like to imagine that my banged up, destroyed, tainted sports car had become a helpful source of parts that would make others happy.

The insurance agent told me that likely 75% of the average wrecked car can be put to some other use. I really had no idea what would happen to a wrecked car and the idea that it is “recycled” in this manner seemed generally impressive. Better than it all just sitting in a big heap and rotting away for years upon years.

Have you ever had a car that was scrapped?

According to statistics by the federal government, there are about 15 million cars per year in the United States that end-up in a scrapyard. There are an estimated 250 million cars in the United States. Thus, as you can see, only about 6% of the cars in-hand seem to go to scrapyards each year. I apparently am one of the “lucky” few to have it happen to their car. At least I wasn’t in the car during a car accident that ultimately might have wrecked the car and gotten it to go to the wrecking year. Having a gang steal it was an “easier” way to have it end-up at a salvage yard.

The Case of AI Self-Driving Cars

What does this have to do with AI self-driving cars?

At the Cybernetic AI Self-Driving Car Institute, we are developing AI software for self-driving cars. One aspect that few of the auto makers or tech firms are considering is what will happen to the data that’s on-board an AI self-driving car once the self-driving car ends-up in a salvage yard.

Allow me to elaborate.

I’d like to first clarify and introduce the notion that there are varying levels of AI self-driving cars. The topmost level is considered Level 5. A Level 5 self-driving car is one that is being driven by the AI and there is no human driver involved. For the design of Level 5 self-driving cars, the auto makers are even removing the gas pedal, brake pedal, and steering wheel, since those are contraptions used by human drivers. The Level 5 self-driving car is not being driven by a human and nor is there an expectation that a human driver will be present in the self-driving car. It’s all on the shoulders of the AI to drive the car.

For self-driving cars less than a Level 5, there must be a human driver present in the car. The human driver is currently considered the responsible party for the acts of the car. The AI and the human driver are co-sharing the driving task. In spite of this co-sharing, the human is supposed to remain fully immersed into the driving task and be ready at all times to perform the driving task. I’ve repeatedly warned about the dangers of this co-sharing arrangement and predicted it will produce many untoward results.

For my overall framework about AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/

For the levels of self-driving cars, see my article: https://aitrends.com/selfdrivingcars/richter-scale-levels-self-driving-cars/

For why AI Level 5 self-driving cars are like a moonshot, see my article: https://aitrends.com/selfdrivingcars/self-driving-car-mother-ai-projects-moonshot/

For the dangers of co-sharing the driving task, see my article: https://aitrends.com/selfdrivingcars/human-back-up-drivers-for-ai-self-driving-cars/

Let’s focus herein on the true Level 5 self-driving car. Much of the comments apply to the less than Level 5 self-driving cars too, but the fully autonomous AI self-driving car will receive the most attention in this discussion.

Here’s the usual steps involved in the AI driving task:

•         Sensor data collection and interpretation
•         Sensor fusion
•         Virtual world model updating
•         AI action planning
•         Car controls command issuance

Another key aspect of AI self-driving cars is that they will be driving on our roadways in the midst of human driven cars too. There are some pundits of AI self-driving cars that continually refer to a utopian world in which there are only AI self-driving cars on the public roads. Currently there are about 250+ million conventional cars in the United States alone, and those cars are not going to magically disappear or become true Level 5 AI self-driving cars overnight.

Indeed, the use of human driven cars will last for many years, likely many decades, and the advent of AI self-driving cars will occur while there are still human driven cars on the roads. This is a crucial point since this means that the AI of self-driving cars needs to be able to contend with not just other AI self-driving cars, but also contend with human driven cars. It is easy to envision a simplistic and rather unrealistic world in which all AI self-driving cars are politely interacting with each other and being civil about roadway interactions. That’s not what is going to be happening for the foreseeable future. AI self-driving cars and human driven cars will need to be able to cope with each other.

For my article about the grand convergence that has led us to this moment in time, see: https://aitrends.com/selfdrivingcars/grand-convergence-explains-rise-self-driving-cars/

See my article about the ethical dilemmas facing AI self-driving cars: https://aitrends.com/selfdrivingcars/ethically-ambiguous-self-driving-cars/

For potential regulations about AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/assessing-federal-regulations-self-driving-cars-house-bill-passed/

For my predictions about AI self-driving cars for the 2020s, 2030s, and 2040s, see my article: https://aitrends.com/selfdrivingcars/gen-z-and-the-fate-of-ai-self-driving-cars/

Wrecked AI Self-Driving Cars Are a Data Treasure Trove

Returning to the topic of AI self-driving cars that end-up in a salvage yard, let’s consider why this might happen and what makes it different from a conventional car that is hauled into such a resting place.

First, the big reason that an AI self-driving car differs from a conventional car in terms of the salvage yard is that an AI self-driving car is chock full of sensors and computer processors.

A conventional car is likely to have a limited set of sensors, often not nearly as powerful and full-bodied as those that would be used on a true AI self-driving car. And, the computer processors in a true self-driving car need to be top-of-the-line, superfast to handle the AI running aspects, more so than the processors on a conventional car.

I am not saying that today’s modern conventional cars don’t have some semblance of sensors and processors. Instead, I am pointing out that on a Level 4 or Level 5 self-driving car, the odds are they are a step-up in terms of capabilities, along with often higher costs too, at least when purchased new.

Furthermore, the amount of on-board system memory is likely a lot more than you would have on a conventional car.

This is where the concern really focuses about having your wrecked AI self-driving car towed into a salvage yard. Remember my earlier story about car rentals that are turned-in and the renter has left personal data in the on-board systems? Magnify that kind of leftover info a thousand-fold, and you have the situation we are facing with AI self-driving cars.

An AI self-driving car is likely to have captured video streams that are left intact in the wrecked AI self-driving car. There is a treasure trove of telematic data about the activity of the self-driving car. There could be data that was transmitted back-and-forth via the OTA (Over-The-Air) electronic communications that might have taken place between your self-driving car and the cloud of the auto maker. There could be V2V (vehicle-to-vehicle) electronic communications stored in the on-board systems, involving your self-driving car communicating with other self-driving cars.

All of this then is in addition to whatever you might have placed into the self-driving car via your connected smartphone.

Things get even worse.

If your AI self-driving car has a voice activated Natural Language Processing (NLP) system that allows you to give verbal commands to the self-driving car, those might also be stored in the on-board systems. If the self-driving car is a Level 2 or Level 3, in which you co-shared the driving task, the odds are that there might be captured info about your driving and the driving aspects of the AI system.

Tesla Examples Found by Researchers

Let’s consider the Tesla cars.

According to Tesla’s owner manual, here’s the kind of Telematics info that could be kept on-board the car:

“To improve our vehicles and services for you, we may collect certain telematics data regarding the performance, usage, operation, and condition of your Tesla vehicle, including: vehicle identification number; speed information; odometer readings; battery use management information; battery charging history; electrical system functions; software version information; infotainment system data; safety-related data and camera images (including information regarding the vehicle’s SRS systems, braking and acceleration, security, e-brake, and accidents); short video clips of accidents; information regarding the use and operation of Autopilot, Summon, and other features; and other data to assist in identifying issues and analyzing the performance of the vehicle.” (source: https://www.tesla.com/about/legal).

Plus, this kind of data too:

“Data about accidents involving your Tesla vehicle (e.g., air bag deployment and other recent sensor data); data about remote services (e.g., remote lock/unlock, start/stop charge, and honk-the-horn commands); a data report to confirm that your vehicle is online together with information about the current software version and certain telematics data; vehicle connectivity information; data about any issues that could materially impair operation of your vehicle; data about any safety-critical issues; and data about each software and firmware update.”

In case you are thinking that this is merely an abstract problem and would not occur in the real-world, there is a fascinating study that was recently released about a computer security company that bought some wrecked Tesla cars at a salvage yard and examined those cars to see what they could find (for an article and a video of what they found, see: https://www.cnbc.com/2019/03/29/tesla-model-3-keeps-data-like-crash-videos-location-phone-contacts.html).

The researchers pored into four cars that they obtained, specifically a Tesla Model X, a Tesla Model S, and two of the Tesla Model 3 cars. Of course, they found paired data from smartphones. I’d say that’s pretty much to be expected of any modern-day car, and not especially surprising or unusual. This included nearly a dozen phonebooks of contact info, and various GPS navigation locations.

What’s more interesting is the aspect that for one of the Model 3’s, the researchers extracted the video of the Model 3 of when it had crashed. The car had veered off the road and crashed, which the front cameras recorded. Tying this to the GPS data, the researchers could ascertain the location, Orleans, Massachusetts, occurring on Manequoit Road, and the day and time of the crash. The airbags also deployed. They also tied the crash to the smartphone that was plugged into the car at the time, being able to figure out presumably the person driving the car.

They also looked at the log of the phone use and could see that a phone call from a family member (a contact in the database) had called the driver of the car, moments before the crash occurred.

I think we would all be rather shocked to find out that our private details could be so easily gleaned from our wrecked car. You would normally likely assume that those kinds of details would need to be gotten by a court order or a subpoena of some kind.

Also, you would likely assume that the data would be secured in some manner, making it hard for just anyone to retrieve. According to the researchers, by-and-large the data collected was unencrypted. There was no need to try and crack any difficult ciphers or codes.

I don’t want to seemingly be picking on Tesla, and it should be pointed out that the Tesla licensing does have some warnings about a salvaged Tesla, including this:

“An unsupported or salvaged vehicle is a vehicle that has been declared a total loss, commonly after extensive damage caused by a crash, flooding, fire, or similar hazard, and has been (or qualifies to be) registered and/or titled by its owner as a salvaged vehicle or its equivalent pursuant to local jurisdiction or industry practice. Salvage registration/titling typically can never be removed from the vehicle so that all future persons understand the condition and value of the vehicle. Tesla does not warrant the safety or operability of salvaged vehicles. Repairs performed to bring a salvaged vehicle back into service may not meet Tesla standards or specifications and that is why the vehicle is unsupported. Consequently, any failures, damages, or injuries occurring as a result of such repairs or continued operation of an unsupported vehicle are solely the responsibility of the vehicle owner” (source: https://www.tesla.com/about/legal).

In a manner of speaking, presumably it is the duty of the car owner to cope with the matter of having their own car salvaged and taking any needed steps.

According to the researchers, Tesla apparently reported to them that:

“Tesla already offers options that customers can use to protect personal data stored on their car, including a factory reset option for deleting personal data and restoring customized settings to factory defaults, and a Valet Mode for hiding personal data (among other functions) when giving their keys to a valet. That said, we are committed to finding and improving upon the right balance between technical vehicle needs and the privacy of our customers” (as stated in: https://www.cnbc.com/2019/03/29/tesla-model-3-keeps-data-like-crash-videos-location-phone-contacts.html).always

You can interpret the response by Tesla as befits your own views about what responsibility the car maker has versus the car owner.

Coping With AI Self-Driving Cars Once Wrecked

As the advent of AI self-driving cars continues to increase, there will be more and more circumstances involving wrecked AI self-driving cars.

Right now, the Teslas, which are considered pretty much a Level 2, those are the most prevalent of any semblance of an AI self-driving car and so it is logical that those would be getting wrecked, in the normal course of being on the roads, and end-up in salvage yards.

With the emergence of Level 3’s, once those become relatively popular, they will ultimately get into wrecks, sorry to say, but it’s a fact, because they are cars, and that’s what happens with cars, and so those too will eventually get piled into scrapyards.

The Level 4 and Level 5 self-driving cars are right now working in experimental modes and prove-of-concept (POC) modes, and are not owned by individuals per se. Instead, they are being crafted by auto makers and tech firms. This means those self-driving cars are lovingly tended by a slew of expert mechanics and AI professionals. If those self-driving cars get into a wreck, it isn’t as though they will just tow the self-driving cars to the nearest salvage yard and junk them there.

Nope. Those babies lead a pampered life, right now.

My point being that the auto makers and tech firms have not had to deal with the end-of-life aspects as yet of self-driving cars. We are still so much at the start of the life-cycle that thinking about the end of the life cycle is nearly unimaginable. AI developers that I talk with are oft to scoff at the end-of-life of their creations, doing so because they are harried and knee deep into just trying to make AI self-driving cars that work, being able to have the AI drive around without hitting anything or anyone.

For my article about reverse engineering of AI self-driving cars, see: https://www.aitrends.com/selfdrivingcars/reverse-engineering-and-ai-self-driving-cars/

For what happens when an AI self-driving car gets into an accident, see: https://www.aitrends.com/selfdrivingcars/accidents-happen-self-driving-cars/

For the burned-out AI developer aspects, see my article: https://www.aitrends.com/selfdrivingcars/developer-burnout-and-ai-self-driving-cars/

For my article about the egocentric AI developers’ aspects, see: https://www.aitrends.com/selfdrivingcars/egocentric-design-and-ai-self-driving-cars/

You might be tempted to suggest that at least the on-board data should always be encrypted.

By doing so, it would mean that even if the wrecked self-driving car was given to a salvage yard, it would be arduous or perhaps infeasible for anyone to readily pluck the data out of the car in terms of knowing what the data actually contained (they might be able to grab it, but it would appear to be undecipherable).

Though this is a good idea, it also offers the downside of having to be continually encrypting and potentially decrypting data to make use of it to drive the self-driving car by the AI system.

This means that the on-board computer systems are going to do a lot of added computational work. The data being collected by the sensors would need to be turned from plaintext or plain-data into encrypted data. Would this happen only once the data is stored? That’s data in-rest or in-place. Would it also occur when the data is flowing throughout the on-board system, which is data-in-motion?

There are lots of questions to be considered. Would the added computational effort dilute the on-board computational processors and distract those processors from the “real work” of running the AI to drive the car? Would the time it takes to encrypt and decrypt create a potential delay in having the AI be able to readily make driving decisions, which are real-time and life-or-death kinds of matters?

Some say that maybe have the data encrypted at the end of a driving day, thus only the data that might so happen to be “live” when a wreck occurs would be potentially unencrypted.

For more about the cognition timing aspects, see my article: https://www.aitrends.com/selfdrivingcars/cognitive-timing-for-ai-self-driving-cars/

For the backdoor security matters, see: https://www.aitrends.com/selfdrivingcars/ai-deep-learning-backdoor-security-holes-self-driving-cars-detection-prevention/

For the role of Event Data Recorders, see my article: https://www.aitrends.com/selfdrivingcars/event-data-recorders-edr-self-driving-car-need-black-box-relook/

For my article about privacy concerns of AI self-driving cars, see: https://www.aitrends.com/selfdrivingcars/privacy-ai-self-driving-cars/

Another suggestion is that the self-driving car should have a “wrecked mode” that would automatically kick-in when the self-driving car gets into a crash of some kind. This would either encrypt the data at that juncture, though you need to hope that the processors and systems are working sufficiently that this could actually occur after the crash has happened, or the wrecked mode might erase everything, similar to my Mission Impossible comment earlier (again, this assumes that the AI is still working sufficiently).

One concern about the erasing of data would be whether the data might be needed for purposes of establishing any legal claims about a crash that has occurred. Whether or not our society would allow the auto makers or tech firms to summarily have a feature that would automatically erase everything, well, that’s a pretty big if.

You could say that it is up to the owner of the self-driving car to take proper action with their wrecked car. Thus, if someone is “stupid enough” to handover their wrecked car to a salvage yard, and leave all of their personal data in it, that’s their own act of being a dolt.

Some would have more sympathy toward the owner of a wrecked car. Would the owner understand that it is their responsibility to deal with the data? Would they realize that the data was even being collected? Would they realize that it wasn’t automatically being encrypted for them? Would they understand that it is something they need to take overt action about?

I think we can likely agree that having something in an owner’s manual is not quite the most broadcast way to inform car owners. How many of us actually read the owner’s manual? It is akin to those that download and use an app, which has a 50-page online licensing contract, and for which most people just click yes and agree to the terms. If the app then gives up all their personal data and sells it to the dark web, do we merely say that those people were dolts?

It could be that some might argue that the salvage yards have an obligation to not allow the data from the towed-in self-driving cars to be handed out. Perhaps their should be legislation that requires salvage yards to protect your data and inform you about it. I doubt that many salvage yards will welcome such an added burden onto their shoulders.

You might say that it should be on the shoulders of the auto maker and tech firms that make the AI self-driving cars. That’s again something that has yet to be ascertained in terms of what the range and nature of their duties are. Much of this is still an open market approach and there is little yet in the way of regulatory rules about it.

I would guess that we’ll likely see lawsuits that will also arise due to these matters. Someone that has had a wrecked AI self-driving car that reveals private aspects will launch a lawsuit against the auto maker or tech firm, perhaps at the insurance firm, perhaps at the salvage yard, and maybe at anyone or anything in the life cycle steps after a self-driving car has gotten wrecked.

For my article about responsibilities and AI self-driving cars, see: https://www.aitrends.com/selfdrivingcars/responsibility-and-ai-self-driving-cars/

For federal regulations about AI self-driving cars, see my article: https://www.aitrends.com/selfdrivingcars/assessing-federal-regulations-self-driving-cars-house-bill-passed/

For whether we are creating a kind of Frankenstein, see: https://www.aitrends.com/selfdrivingcars/frankenstein-and-ai-self-driving-cars/

For the soon to emerge lawsuits bonanza, see my article: https://www.aitrends.com/selfdrivingcars/first-salvo-class-action-lawsuits-defective-self-driving-cars/

Things Will Get Worse In Terms of What’s On-Board

I’ll add more fuel to the fire.

It seems likely that true Level 5 AI self-driving cars will have cameras pointing inward and be recording the audio and video of whatever happens inside of the self-driving car. Why this kind of intrusion? It can be to help the AI figure out what the human passengers are doing and what they want the AI to do for them.

There’s another equally practical reason, namely for ridesharing purposes. Most would agree that the AI self-driving car of a Level 5 will be used for ridesharing purposes. Even if you own your own Level 5 self-driving car, you will likely let it roam and be a ridesharing vehicle while you are at work or asleep, allowing your self-driving car to make money for you.

By having the cameras that point inward, you can keep track of those pesky ridesharing passengers that might decide to trash the inside of your shiny AI self-driving car. Or, perhaps it could be that someone is having a heart attack and needs urgent help, which the AI might be able to detect by scanning the interior video and then contacting 911 or routing the self-driving car to the nearest hospital.

The overall point is that this kind of private data would also be presumably kept on-board the self-driving car. Once again, it might be accessed once the self-driving car is relegated to a salvage yard, if not otherwise protected or erased.

I’ll scare you about the outward facing cameras too.

As your AI self-driving car goes down the street in your neighborhood, it is capturing video, along with possibility audio, and radar, and LIDAR, and ultrasonic waves, which could be kept on-board the self-driving car. It might be sitting in there, a view of all of your neighbors, their dogs and cats, their comings and goings.

When you park your AI self-driving car in your garage, it might still be recording. This could occur in that the AI self-driving car might be setup to wait for you to ask it to do something, so it is sitting there in a semi-alert fashion. It is akin to Alexa or Siri, listening for a prompting word. Though in theory the listening mode is not recording, you never know how it might really have been established.

Some believe that the AI of the self-driving car will be a kind of therapist, allowing you or your children to interact with it on your daily commute. The AI might try to help you with that problem at work, or difficulties with your spouse. Or, your children might confide that they are failing in their classes and want to run away from home. All of this potentially could be recorded by the AI system.

This AI would use a mixture of NLP, socio-behavioral techniques, and possibly Machine Learning and Deep Learning. Whatever methods or technologies used, it all depends upon having data, including collecting it and keeping it around, in some manner, whether in whole or in a compressed or selected manner.

We really haven’t as yet established what the boundaries are going to be about the recording of such data.

I know some pundits claim that the voluminous data is so voluminous that it would not make any sense for the self-driving car to keep it on-board. The amount of on-board computer memory would be overly costly, use up too much power, and be large and heavy, weighing down the AI self-driving car. They say that this data either won’t be kept, or it will be shunted up to the cloud via the OTA.

We’ll have to wait and see how this plays out.

For my article about Machine Learning and AI self-driving cars, see: https://www.aitrends.com/selfdrivingcars/machine-learning-ultra-brittleness-and-object-orientation-poses-the-case-of-ai-self-driving-cars/

For the use of socio-behavioral techniques and AI, see: https://www.aitrends.com/features/socio-behavioral-computing-for-ai-self-driving-cars/

For the rise of ridesharing and AI self-driving cars, see my article: https://www.aitrends.com/selfdrivingcars/ridesharing-services-and-ai-self-driving-cars-notably-uber-in-or-uber-out/

For my article about the affordability of AI self-driving cars, see: https://www.aitrends.com/selfdrivingcars/affordability-of-ai-self-driving-cars/

For my article about how IoT plays into this, see: https://www.aitrends.com/selfdrivingcars/internet-of-things-iot-and-ai-self-driving-cars/

Conclusion

If I was sad when my sports car went to the salvage yard, imagine how I might feel when my true Level 5 AI self-driving car (of the future) ends-up there too. My sports car could not interact with me, and yet I considered it my friend. For the Level 5 self-driving car, presumably it will be a friend, a confidant, a father confessor, a butler, and probably know more about me than any other living human being. Yikes!

In any case, we do need to all start considering what to do about AI self-driving cars and the data they are going to be collecting. The focus herein was what happens to the data when the self-driving car gets junked to a salvage yard.

That’s just the tip of the iceberg. While the self-driving car is still fully active, we need to be worrying about the data and how it is being collected and who can access it.

The next time you drive past a scrapyard, look at the pile of cars, and think to yourself about the hidden secrets that will someday be there, embedded into the computer memory of those AI self-driving cars that were unceremoniously dumped there. Perhaps we’ll prevent that data dumpster treasure trove from happening, if we take heed now in the design and development of AI self-driving cars.

Copyright 2019 Dr. Lance Eliot

This content is originally posted on AI Trends.