zlacker

I am the first to be on the "I own my phone let me do whatever the heck I want with it" but recently something hit me.

DJI forces you to side load their app for their Air Units and Drones. And this is scary. It looks like the rule they violate for the play store is that their app can self modify.

Let that sink in ... Any tension or whatever political bull crap happens and you have a state controlled malware on your device that can do anything it wants with your drone.

Millions of people installed this without really understanding what could be the consequences...

>>gbin+(OP)
I don't know why you're getting downvoted when its very possibly true.

Just one month ago they found intentionally embedded Kill Switches in chinese provided solar panels [0][1].

Not even complex apps require capabilities of such self-modification, the fact that a DJI drone app, requires such capabilities, is quite suspicious especially as they are heavily involved in PLA Drone Warfare R&D and Capacity building.

[0](https://www.reuters.com/sustainability/climate-energy/ghost-...)

[1](https://www.rickscott.senate.gov/2025/6/sens-rick-scott-mars...)

>>gbin+(OP)
Nations already work with tech giants to get this in via OEMs. Blocking side loading only prevents hackers from disabling this malware.

>>gbin+(OP)
This is why "do whatever the heck I want with it" ought to apply to software, not just hardware. This is one thing I think Richard Stallman got right, all the way back in 1988:

> the freedom to change a program, so that you can control it instead of it controlling you; for this, the source code must be made available to you.

We're a long way from that ideal today. Software controls us all the time. Usually that just leads to anti-consumer annoyances like lock screen ads or DLC seat heaters. But when the one controlling the software that controls you is a communist government...

Not sure what the short term practical solution to this is though.

>>gbin+(OP)
self-modification doesn't imply much when you can embed v8 in your app, which they take no issue with at all

>>gbin+(OP)
The solution to this is better controls over what the DJI apps can actually do, not having Google pretend to check all apps for malicious code.

Google clearly knows this. IMO the motivation here is obvious, and it isn't security.

>>IshKeb+Ge
I find it interesting that all the things Apple did from the start in the name of security, Google is slowly needing to do over time in the name of security. Meanwhile, various parties (the EU being the big one) are pushing to have Apple role back some of these controls.

>>Groxx+Yb
The difference is that V8 is sandboxed.

>>Groxx+Yb
The difference is, in theory if DJI were discovered to be doing something malicious, it could be taken down from the Play Store. If 0% of its current users were side loading the application, that means 100% of their users would be unable to install the app the normal way, and there would be substantial friction to migrate them to sideloading (a google of "install dji app" would probably return a bunch of news articles about whatever the problem was before dji's install instructions).

By making it "normal" to install the app via sideloading, there's little Google could do in the event of malicious app behaviour, and the majority of users would not find out about it (at least, not immediately).

>>al_bor+Fp
When a design decision has potential motivations that are based in security or anticompetitive behavior, my first guess as to Google's primary motivation is not security.

>>lblume+Ir
I haven't seen a single widely used sandbox that has never leaked.

>>lblume+Ir
then replace "v8" with "arbitrary binaries" because that's true too. embed a lisp and do whatever you like, for example. Golang, C, Rust, Dart, etc are all quite common too, and nobody would call C "sandboxed".

all self-modifying really prevents you from doing is stuff like dynamically changing your permissions. which is a broadly reasonable restriction because it'd complicate the approval UI (and the actual enforcement mechanisms) quite a bit further.

>>al_bor+Fp
The parent is telling you what the obvious, correct solution is: secure the runtime. That's how MacOS stops attackers, that's how Windows stops attackers, and there's no reason to pretend that smartphones are some unique situation. Runtime security should not ever be treated as optional.

US Senators like Ron Wyden would probably tell you that Apple's approach harms your security overall. After all, he was the one that whistleblew Apple's hidden and warrantless Push Notification surveillance pipeline. Forcing you to rely on a first-party service you can't replace is never a secure option, not in the US nor Europe.