So many Tesla crash into a tree in the early morning hours, it’s getting hard to tell them apart.

The fatal NJ crash reported August 18th is not to be confused with this one reported August 20th.

Haas was the passenger in a Tesla Model Y that left northbound Lanwin Boulevard last Tuesday, Aug. 20, at about 3:45 a.m. West Windsor police said in a statement that patrol officers arrived to find the car crashed into a tree near Providence Drive, in a residential neighborhood, and the passenger side suffered major intrusion damage.

Experts reviewing the IAAI auction page say the Cybertruck wreckage looks like a vehicle built in the 1960s.

Fifty years of standard safety design improvements are missing, meaning it’s safer to drive any other vehicle made after the 1960s than the Cybertruck (even a Pinto).

Police haven’t revealed much, but a leading theory is that the driver was trying to test the “survivability” promises of Elon Musk. Driving off-road near Houston they died almost instantly after crashing in the first ditch.

Related: the official Tesla first responder page for at least ten months has not had any information at all on the Cybertruck.

Also related, here are the far too many other Cybertruck wrecks currently up for auction.

Right in the middle of the fresh new announcement of the U.S. vehicle to everything (V2X) deployment plan, is the following brief section on security concerns.

Secure Deployment: Cybersecurity and Privacy Principles Successful V2X deployment requires cyber resilience so its communication services remain available and all users have confidence in the integrity of V2X data as well as trust in the confidentiality of data exchanged via V2X communications. This requires applying principles of secure by design — considering cyber and privacy risks at the outset and integrating cybersecurity principles when V2X is developed and deployed. Secure and resilient V2X depends on investment in cybersecurity and adopting a comprehensive approach to manage and reduce cyber risk.

Cybersecurity is critical to ensure V2X technologies — and the information they provide — can be used and are trusted through standard procedures to validate that information is correct. Secure V2X deployment includes ensuring Personally Identifiable Information (PII) is protected while also allowing parties to secure the data needed to advance a safe and efficient transportation system. Privacy of individuals must be considered and the collection and use of PII and potential PII must align to the purpose of the program. Participants must be informed of privacy practices and provided with understandable notice and provided options for consent. PII collected should be the minimum necessary for the purpose for which it is collected, maintained for the shortest time practical, and not used for any other reason than for which it was initially collected.

The DOT is cognizant that realizing secure V2X deployment requires implementing cybersecurity and privacy principles in a clear and practical way. The ITS Cybersecurity Research Program website documents DOT and modal agencies’ resources. The DOT commits to developing and maintaining cybersecurity resources for the V2X community, as well as a detailed and testable definition of secure V2X deployment in support of this Plan.

Here’s a related presentation about $238M, earmarked for vehicle safety innovation and “foundational” cybersecurity, as described by Federal Highway Administration’s Shailen Bhatt:

The Department of Transportation (DOT) highlights the critical need for cyber resilience, data integrity, and user trust in V2X systems. At first glance, the W3C Solid architecture (solidproject.org) appears to align well with these objectives and offer enhancements. Solid’s decentralized approach to data storage—distributing it across a network of vehicles—and its emphasis on user control over personal information inherently reduce attack surfaces and limit the impact of potential breaches.

A DOT concern clearly is the protection of PII while facilitating essential data sharing to save lives. Solid addresses this balance better than most by allowing users to store data in personal data wallets, which only disclose specific information when and where necessary. This approach adheres to the principle of data minimization for maximum benefit, as V2X applications can request only the data required for their functions. Solid’s permission system ensures that data is used strictly for its intended purpose, as specified during the consent process.

Furthermore, the DOT emphasizes the importance of transparent privacy practices. Solid’s standardized consent mechanisms facilitate clear protocols for data access requests and permissions. Users have the ability to easily view and manage which applications can access their data.

Additionally, Solid’s interoperability aligns well with V2X requirements, enabling seamless data exchange between various systems and stakeholders. This ensures scalability as V2X adoption grows and supports a diverse network of transit vehicles. By enhancing user control over data while meeting data protection requirements, Solid helps build public trust and supports advancements in V2X technologies.

Considering these benefits, V2X-specific extensions to the Solid protocol could be a promising next step. Solid-compatible applications might start with small-scale deployments to validate these advantages (unless Bhatt is serious that he wants to start deploying immediately at scale). The following code example illustrates how vehicles could use Solid to securely share personally controlled location data with nearby vehicles:

import { SolidDataset, Thing, createSolidDataset, setThing } from '@inrupt/solid-client';
import { fetch } from '@inrupt/solid-client-authn-node';
import jwt from 'jsonwebtoken';
import { v4 as uuidv4 } from 'uuid';
import crypto from 'crypto';

// Generate DPoP proof for secure requests
const generateDpopProof = (url, method, privateKey, accessToken = null) => {
  const payload = {
    htu: url,
    htm: method,
    jti: uuidv4(),
    iat: Math.floor(Date.now() / 1000),
    ...(accessToken && { ath: crypto.createHash('sha256').update(accessToken).digest('base64url') })
  };
  return jwt.sign(payload, privateKey, { algorithm: 'ES256', expiresIn: '5m' });
};

// Retrieve access token from token endpoint
const getAccessToken = async (privateKey) => {
  const tokenEndpoint = 'https://oidc-provider.example.com/token';
  const dpopProof = generateDpopProof(tokenEndpoint, 'POST', privateKey);
  const response = await fetch(tokenEndpoint, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded',
      'DPoP': dpopProof
    },
    body: new URLSearchParams({
      grant_type: 'client_credentials',
      client_id: process.env.CLIENT_ID,
      client_secret: process.env.CLIENT_SECRET
    })
  });

  if (!response.ok) throw new Error('Token request failed');
  const { access_token } = await response.json();
  return access_token;
};

// Share vehicle location with a recipient URL
const shareVehicleLocation = async (vehicleId, { latitude, longitude }, recipientVehicleUrl) => {
  if (latitude < -90 || latitude > 90 || longitude < -180 || longitude > 180) {
    throw new Error('Invalid coordinates');
  }

  const privateKey = process.env.PRIVATE_KEY;
  const accessToken = await getAccessToken(privateKey);
  const url = `${recipientVehicleUrl}/vehicleLocations/${vehicleId}`;
  const dpopProof = generateDpopProof(url, 'PUT', privateKey, accessToken);

  const thing = new Thing(`vehicle-${vehicleId}`)
    .addLiteral('https://schema.org/latitude', latitude)
    .addLiteral('https://schema.org/longitude', longitude)
    .addDateTime('https://schema.org/timestamp', new Date().toISOString());

  const dataset = setThing(createSolidDataset(), thing);

  const response = await fetch(url, {
    method: 'PUT',
    headers: {
      'Content-Type': 'application/ld+json',
      'Authorization': `DPoP ${accessToken}`,
      'DPoP': dpopProof
    },
    body: JSON.stringify(dataset)
  });

  if (!response.ok) throw new Error('Failed to share location');
  console.log('Location shared successfully.');
};

// Example usage
shareVehicleLocation('V123456', { latitude: 37.7749, longitude: -122.4194 }, 'https://example-vehicle.pod')
  .catch(error => console.error(`Error: ${error.message}`));

Yes, latitude 38 because… go Giants!

The code takes a key aspect of V2X communication, where vehicles can share location data to improve safety and traffic management, and adds a Solid data wallet to store and control access to location information without needing to operate a centralized database. DPoP tokens are shown to prevent unauthorized access and ensure data integrity

Some potential Solid extensions for V2X include specialized ontologies, efficient geospatial queries, and real-time data exchange mechanisms.

Here’s an Intersection OWL Ontology to define some basic classes and properties relevant to V2X interactions, such as vehicles, traffic signals, and signal phases:

@prefix v2x:  .
@prefix schema:  .
@prefix xsd:  .
@prefix owl:  .
@prefix rdfs:  .

# Define the Vehicle class
v2x:Vehicle a owl:Class ;
  rdfs:subClassOf schema:Vehicle .

# Define the hasSpeed property
v2x:hasSpeed a owl:DatatypeProperty ;
  rdfs:domain v2x:Vehicle ;
  rdfs:range xsd:decimal .

# Define the hasDirection property
v2x:hasDirection a owl:DatatypeProperty ;
  rdfs:domain v2x:Vehicle ;
  rdfs:range xsd:decimal .

# Define the TrafficSignal class
v2x:TrafficSignal a owl:Class .

# Define the hasPhase property
v2x:hasPhase a owl:ObjectProperty ;
  rdfs:domain v2x:TrafficSignal ;
  rdfs:range v2x:SignalPhase .

# Define the SignalPhase class with specific instances
v2x:SignalPhase a owl:Class ;
  owl:oneOf (v2x:Red v2x:Yellow v2x:Green) .

# Define the specific signal phases
v2x:Red a v2x:SignalPhase .
v2x:Yellow a v2x:SignalPhase .
v2x:Green a v2x:SignalPhase .

And here’s a Query to a geospatial index to report nearby vehicle status. This example assumes the use of a hypothetical Solid extension for handling geospatial data:

import { SolidGeospatialIndex } from 'hypothetical-solid-v2x-extension';

const cityIndex = new SolidGeospatialIndex('https://city-traffic.example/index');

async function getNearbyVehicles(lat, lon, radius) {
  const query = `
    PREFIX geo: 
    PREFIX geof: 
    SELECT ?vehicle ?lat ?lon
    WHERE {
      ?vehicle geo:lat ?lat ;
               geo:long ?lon .
      FILTER(geof:distance(?lat, ?lon, ${lat}, ${lon}) <= ${radius})
    }
  `;
  
  return cityIndex.query(query);
}

const nearbyVehicles = await getNearbyVehicles(40.7128, -74.0060, 1000);
console.log(nearbyVehicles);

It is worth repeating that Tesla infamously marketed their Cybertruck as a $100K survival vehicle to withstand the harshest challenges.

“Armor glass can resist the impact of a baseball at 70 mph or class 4 hail.”

Class 4 hail? Not actually a thing. I’ll get to that in a minute.

Armor glass? Uh huh, a basic lamination that doesn’t mean much. Just like “full self driving” can’t drive, the Tesla armor glass… isn’t.

Elon Musk said his armor glass that he falsely promoted as “shatterproof” would have a bulletproof option too.

Elon Musk has long claimed the Cybertruck will be bulletproof, saying he wants the futuristic pickup to be “really tough — not fake tough.” […] Thanks to a patent filed by the company in 2021, we know how that “armor glass” works, with several different sheets of glass layered together for strength and flexibility. This “armor glass” won’t be able to stop a bullet — but Musk’s said that Tesla will offer the option to buy a “beast mode” Cybertruck with properly bulletproof windows.

Instead it has delivered a practically worthless dud, which fails tests at every level. Don’t bet your life on this circus clown.

Owners are basically victims of fraud, allegedly still surprised when they realize the lie.

The burglar immediately puts his glass-breaking tool over the windows and shatters the driver’s side glass. Analyzing the footage, the cop can be heard saying, “It’s a tool the thief pushes in the side; look at the top; he pops it…there you go.”

Here, the assailant can be seen grabbing hold of the shattered glass from the top and peeling down the glass to leave the window completely open.

After pulling down the windows, the burglar climbs into the Cybertruck.

This comes after a basic hail storm cracked a Cybertruck windshield even as other cars weren’t affected.

CT windshield did not withstand a freak sudden hailstorm in Austin, rest of vehicle seems fine. None of the other cars parked next to it had windshield damage…

Fake tough. The first sign of fraud was Elon Musk incorrectly using a roofing shingle reference for glass on a vehicle.

Hailstones aren’t classified by their size or weight. Class 4 hail refers to the UL2218 Impact Rating test conducted by Underwriters Laboratories (UL), a not-for-profit organization that independently tests and certifies roofing products. […] In order for a roofing product to achieve a Class 4 rating, it cannot show any signs of penetration or fracture after a 2-inch steel ball is dropped twice on the same spot from a distance of 20 feet.

Class 4 rating for roofing products. Not a class of hail. Presumably someone in Elon Musk’s circle mentioned their solar panel roofing business (also fraud) had materials measured relative to Class 4 and he used these same words elsewhere without understanding any of them.

Remember this Elon Musk giant scam about his roof shingle business?

• Nov 2016: “Musk Says Tesla’s Solar Shingles Will Cost Less Than a Dumb Roof. ‘Electricity is just a bonus.'”
• May 2017: Elon Musk bets homeowners will pay a premium for resilient panels that look like an ordinary roof.

They’ll cost less! You’ll pay a premium! Up is down. Down is up. They’ll be dumb. They’ll be ordinary. They’ll be so amazingly resilient… whatever, whenever, all lies all the time in constant contradictions.

In reality a 2-inch steel ball is supposed to be dropped twice. On the same spot. From 20 feet. It’s science, meant for roofing material comparisons yo!

And now this. A 2-inch steel ball thrown like a PT Barnum show…