dji4321234

https://www.rcfp.org/wp-content/uploads/2026/04/FAA-drone-ad...

The effort from the EFF is to get the original restriction called back up and vacated - essentially, they want a post-hoc determination that it was illegal, but the restriction is already gone.

This would almost surely work there too, though.

Make that point, then! Nothing in your original comment suggested this, just hostile dismissal.

Now that you’ve written a more substantive comment I think we actually agree overall. Most operations in the Ukraine-Russia war are manual piloting. Autonomy is over-hyped overall so far. However! A large number of autonomous systems have still been deployed and interest in autonomy is only growing. Both things can be true at the same time.

> Oh gosh.

Come on, read the whole sentence please. Lock on targeting modules are absolutely being superseded by fiber optic as it becomes “easier” to acquire than it used to be.

https://understandingwar.org/backgrounder/battlefield-ai-rev... was posted by a sibling commenter and is a fairly accurate summary to my knowledge, including a substantiation of the notion that depending on how you look at it, lock on modules were a stop-gap before fiber became available or fiber is a stop-gap before good autonomy becomes widespread.

Rather, it is you who does not know what you are talking about. Here is a real frontline video characterizing these systems. Yes, it is all still analog FPV. The lock-on system selects a target and overlays the reticle on the analog video. As the FPV flies closer and encounters the jamming from the target, the lock-on unit ensures it is still a hit.

These have fallen out of favor as fiber optic is a little easier to get than it used to be but they are still in wide use.

A large number of front-line FPV drones are equipped with automated last-second targeting systems like https://www.youtube.com/watch?v=coUwYOyIoAU , based on Chinese NPU IP / CCTV systems and readily available as full solutions on Aliexpress. The basic idea is that if the drone loses control or video link due to EW countermeasures, it can continue to the last target.

Loitering and long-range fixed wing reconnaissance drones have been fully autonomous since the beginning. One common recent technique taken from traditional "big" militaries is the use of loitering autonomous high altitude base stations with Starlink or LTE on them providing coverage to the battlefield below, since it's much harder to jam things when they are flying high above the ground.

Inside-out SLAM strategies and on-device ML are much more interesting and are starting to trickle into COTS drones. For example, the latest DJI drones all use SLAM for return-to-home even when GPS denied: https://www.facebook.com/reel/440875398703491 , and the latest Matrice 4 enterprise drones also have end-user ML model runtimes that can fine-tune flight plans using user-provided logic.

Inside-out last-second targeting is also very popular in Ukraine, with off-the-shelf "find the nearest car/person in analog video, lock to it on signal lost, and send Betaflight MSP stick commands to hit it" modules readily accessible on Aliexpress.

802.11 is not a good fit for FPV video and trying to use it has held non-proprietary-Chinese video systems back quite a lot.

It's not really non-standard so much as it is new-standard or different-standard. Aarch64 officially supports 4K, 16K, and 64K pages. This flexibility in the aarch64 ABI means that most compilers already produce 64K aligned load segments for aarch64, so it's not a huge deal except for software that works at a low level and makes assumptions about mmap (for example).

The main software that's truly affected beyond just needing recompilation or tweaks is x86/x86-64 emulation software, since x86 is pretty tightly coupled to 4k pages.

They're foot-nuking themselves this way, as well. Due to their poor security, DJI are also easily compromised by Western interests and collect a ton of data about Chinese drone operations. I suppose someone could argue they decided that this is worth the cost of the operation, etc., but it seems... odd.

> hire product managers from a pool trained on CCP-sponsored university programs and industry media sources, that have those product managers parroting "useful" beliefs like "more analytics is always better."

The CCP don't need to do any work to make this happen. I totally agree that they benefit, thus my "indistinguishable from malware" comment. But this is how product management works worldwide. Maybe the modern obsession with product telemetry has been a years-long deep intelligence op, but I think it's easier to attribute to standard corporate behavior.

My points were:

* DJI's use of Secneo on Android isn't hiding a "sendAllYourPhotosToTheCCPServerNow" function. This seems obvious but I've seen this take everywhere.

* However, DJI's apps are loaded with telemetry that's indistinguishable from malware. They ARE full of shady things.

* I wouldn't run a DJI app on my own phone.

* I would use a standalone DJI remote for most low to medium assurance applications, because while the shadiness remains in many ways, the threat model is easy to understand and boundaries are pretty easy to draw.

That is, if you opt out of data collection, they seem to be earnestly _trying_ to disable data collection. Unfortunately their apps are a spaghetti monster disaster and it's very difficult for them to get things right, so DJI frequently introduce new features or libraries which contain telemetry they've forgotten to disable. In my experience they do this more often in consumer apps than enterprise apps. I think they might actually have some kind of automated testing or audit applied to their enterprise apps.

Whether this is a conspiracy to introduce subtle surveillance bugs or simple hardware-company-making-software incompetence is of course an exercise left to the reader's paranoia level.

Anyway, I just use DJI RCs and forget network credentials. This limits the DJI bug/malice blast radius surface area to an acceptable range to me, and that's the advice I'd give others, too.

It's also worth noting that these restrictions aren't government imposed in countries besides China, and aren't government-linked besides a request-based "please make this location a no fly zone" process - DJI basically just exported a Chinese concept with hope of building goodwill internationally, and the no-fly zones were invented by DJI from public land use data. That's why other drones don't have no-fly zones but are still allowed for sale, there are frequent mismatches between DJI no-fly zones and real no-fly zones (both false positive and false negative), and why DJI disabled their own no-fly zone feature in much of Europe earlier this year (European mandated no-fly rules passed the responsibility to the consumer instead).

Skydio exited the consumer market. Their drones had good autonomy and flight characteristics. However, they struggled with wireless link quality due to the use of consumer WiFi, and had much older, inferior camera sensors compared to even contemporary DJI drones. They were also ridiculously loud and inefficient. Their enterprise drones are comically expensive and loaded with nickel-and-dime cloud features.

Parrot drones struggle with the same issues as Skydio (Skydio actually used a Parrot remote controller for their consumer drones), plus their autonomy isn't nearly as good as even Skydio's, the overall drone behavior is "clunky" (slow boot times, slow connection times, non-responsive flight controls), and even basic flight is more challenging.

The main issues plaguing US consumer drones are imaging sensors and wireless link. LTE and other well-suited long range wireless technologies capable of handling speed differential between the station and access point are locked in a vault of patents. Imaging sensors are legendarily impossible to acquire in low to moderate quantities and image sensor parameters are carefully locked behind a billion levels of NDA (thus why even the Raspberry Pi camera is full of DRM).

> Leaving the door propped open for everyone is also plausible deniability for doing bad things.

We completely agree here, see "sufficient product telemetry is indistinguishable from surveillance malware." I personally don't think this justifies a blanket ban on a technology; if it did, the world would need to be a very different place.

I don't think this is the reason, I think it's more that they're just too lazy to jump through the approval and maintenance hoops that come with an app store, especially because their home market (China) doesn't even use the Play Store.

The iOS version of their app is Apple-approved and present in the App Store.

I do research in this space.

Their consumer apps are loaded to the gills with product-manager telemetry (tap/action tracing, etc., think Firebase/Flurry/whatever), and until recently they had a "sync flight logs" feature that would do what it said: give your detailed flight logs to DJI. It was opt-in, but it was easy to do by accident and many years ago there were bugs in the opt-in toggle.

They just removed this feature from US apps this week (too little too late, and too attached to reality and not attached enough to political pandering).

DJI also have a terrible track record with data security, with their entire AWS account getting ripped in 2017.

I don't think they're explicitly a CCP data-collection front, but sufficient product telemetry is indistinguishable from surveillance malware (this applies to US-based companies and US intelligence, too, of course).

However, their apps run on their own controllers are generally alright, and their enterprise apps run on their enterprise controllers in Local Data Mode are legitimately clean, barring a few versions with small bugs.

I fly DJI drones all the time using DJI RCs with network credentials forgotten, and I wouldn't hesitate to use one of these for consumer use. For the truly paranoid, use a burner email and a VPN to activate the drone.

I also wouldn't worry about using DJI Enterprise drones with the pro controllers in Local Data Mode for even moderately sensitive applications (infrastructure, law enforcement, etc.).

Of course I wouldn't use one for US military applications, insofar as it would be foolish to use any non-allied electronic device in this way.

ps - note that the analysis in the sibling comments are of older apps, DJI Go 4 and Pilot 1, not the newer flagship apps DJI Fly and DJI Pilot 2. The general theme (tons of dirty analytics platforms) remains the same, but the newer apps use more American platforms (Firebase, AWS-hosted proprietary stuff) rather than Chinese, and the "disable telemetry" and "disable data sync" options generally have fewer bugs now.

The goal, I think, is that these organizations will migrate to Skydio or BRINC (as they have the only reasonably viable drones for most of these use cases IMHO).

The reality is that they'll buy Autel (just as Chinese as DJI) or just keep using DJI and hoping the FCC Radio Police don't show up, which is probably a safe bet. Anduril don't really sell into this space.

That said, I don't think this law has anything to do with war, just simple economic protectionism driven by Skydio and other US drone lobbyists. Getting rid of DJI's excellent $7,000 enterprise drones lets Skydio sell their $15,000 + cloud-subscription enterprise drones instead.

By the way, there's no US-written software on Anzu drones. They're just green Mavic 3 Enterprises with a phone app that integrates the DJI SDK. Flying a DJI Mavic 3 Enterprise and an Anzu Raptor using Aloft Air Control will produce exactly identical results in terms of American-ness and data transfer.

If they do revoke the existing Equipment Authorizations, then the drones become illegal RF transmitters and wouldn't be legal to fly, although enforcement would border on impossible.

He tends to build heavily on the work of others, then use it to shamelessly self-promote, often to the massive detriment of the original authors. His PS3 work was based almost completely on a presentation given by fail0verflow at CCC. His subsequent self-promotion grandstanding world tour led to Sony suing both him and fail0verflow, an outcome they were specifically trying to avoid: https://news.ycombinator.com/item?id=25679907

In iPhone land, he decided to parade around a variety of leaked documentation, endangering the original sources and leading to a fragmentation in the early iPhone hacking scene, which he then again exploited to build on the work of others for his own self-promotion: https://news.ycombinator.com/item?id=39667273

There's no denying that geohotz is a skilled reverse engineer, but it's always bothersome to see him put onto a pedestal in this way.

If you opt into DJI's Flight Record Sync service, you send them your flight records. If you send DJI the additional logs they request for a warranty claim, you send them basically every imaginable bit of data from your drone. Both of these things make sense intuitively.

Overall, DJI appear to be earnestly attempting to respect data privacy, especially in their newer apps, DJI Fly and DJI Pilot 2. DJI Fly overall attempts to honor the user's flight analytics and flight log transfer preferences. DJI Pilot 2 in Local Data Mode genuinely stops using the network entirely. DJI's newer "Clear All Data" feature genuinely (but insecurely) erases all stored historic flight and user data on a drone and controller. DJI's efforts towards obfuscation seem generally directed at preventing reverse-engineering by their competitors, not hiding CCP malware.

HOWEVER:

DJI are a hardware company and lack competence in the software space, so they frequently make egregious mistakes which expose users to information disclosure or device security issues. This is especially bad in their older apps (DJI Go and DJI Pilot 1). They occasionally ship third-party libraries containing their own analytics and forget to disable these third-party analytics. Their information security practice seems quite bad overall, including a very prominent leak where all of their AWS data was downloaded in 2017, including synced flight logs, warranty logs, and app telemetry data.

DJI's consumer apps (DJI Fly) are loaded with product-manager-requested mobile app telemetry, as are most American phone apps of all kinds, and require app login to activate a drone. This enables powerful cross-correlation against a user's activities in the app. Sufficiently advanced telemetry is indistinguishable from surveillance malware. There is no evidence of a massive conspiracy where DJI are trying to siphon data to the CCP, but a malicious actor with access to their mobile app analytics dashboard could definitely infer a lot more information than a sensitive customer would like to disclose, including locations where the app was used, with what drone model and for how long it was used for, and whether or not special no-fly zone authorization was requested from DJI.

My summary of DJI is:

I would use a modern DJI drone, enterprise or consumer, in a casual home or business application. However, I would only use a DJI drone with DJI Remote Controllers (which are Android tablets), not my own phone. I would activate the drone, then forget the WiFi network I used to activate it. This provides an end-run around the product telemetry features present in the app, and avoids security issues on your local device introduced by DJI's poor programming practice.

DJI Enterprise hardware and software genuinely attempts to provide offline functionality. I would use it with one of the professional standalone RC units, even in a moderately sensitive situation (say, Law Enforcement use), after auditing one specific app version's behavior (to ensure they didn't accidentally introduce a library with telemetry enabled, which they've been known to do).

Also, be aware that all DJI drones broadcast a local proprietary beacon, sometimes referred to as Drone ID or Aeroscope (not to be confused with US Remote ID standards), containing drone serial number and current location data. On newer consumer drones, this broadcast is encrypted. Regardless, it should be assumed that if you are flying a DJI drone, it can and will be tracked by nearby parties. This should be assumed for any drone, realistically. In the usual use case, you are controlling a giant RF emitter using another giant RF emitter.

Were we pretending this? Was anyone pretending this? It would likewise be quite wise for China to ban the use of products made by these companies in their own sensitive federal applications, and my understanding is that broadly, they have.

You can see what happens when you try this by putting DJI FPV Goggles in Audience Mode. It's horrible and not suitable for flying. The DJI link is fundamentally two-way and aggressively uses sounding and HARQ.

The solution to flying with DJI FPV users at your field is to not use Raceband 6 at all (DJI uses this for link negotiation), and otherwise look up the Raceband to DJI correlation chart and allocate separate channels as usual.

This is a major advantage DJI and other Chinese drone makers have over US based ones. Technically acquiring an SDR/DSP implemented LTE baseband is not a major difficulty. Getting Qualcomm to let you is quite a challenge.

Looking at FCC listings and product pages you can tell that DJI are also throwing power at the problem. The EIRP on DJI devices is very high. They go up to 33dBm (2W EIRP) on the most modern devices like the Mini 4 Pro.