I really don't understand this. My line of thinking is that if someone is technical enough to root his phone he understands the risks. Why would they force banking apps to detect and not work on rooted phones? Why would the government care so much?
It's not to protect the user; it's DRM. Using a non-rooted phone means all apps get DRM for free. You can't simply press 'record screen' when the software sets a flag; you can't view the data that the app processes about you or make backups thereof; you can't control what the device does such as skipping any checks. Fraud detection and CAPTCHAs rely on security through obscurity.
> if someone is technical enough to root his phone he understands the risks
You're looking at this from the user's perspective. Indeed, the narrative is "for your safety, you cannot export your security tokens from your device's storage" or "software that runs as root can bypass all permissions, an attacker might exploit that!", as though users can't make that choice themselves on purchased-to-own hardware. Dropping privileges (https://en.wikipedia.org/wiki/Privilege_separation) has been a thing since as long as I'm alive. Don't be fooled that this "protection" is for you :(
A phone given for repair by a non-technical person can be rooted without their knowledge. The repair person potentially can install malware. We cannot assume the owners of the rooted phone themselves have rooted the phone.
Practically, verified boot is hard to not have a "this phone has been tampered with" message on boot, the backups generated often have encrypted user data that is usually wiped on boot-loader unlock, you'd also need to unlock the phone or have the user give the pin over and most of the apps that implement root checking SDKs would prevent them from working.
I'm not saying its impossible but it is hard to do at present in a way where if I came and picked up my phone again, I'd not know something happened to it.
The only ways I know to take a full backup of an Android device require it to already be at least bootloader unlocked. There are unprivileged ways to take backups, but they don't work for all apps.
Assuming the owner gave the shop the pin. If so, the shop can already steal a lot of data from the phone. Why bother with persistent malware at this point?
You already have to trust the repair shop with your data. Installing persistent malware on phones is already illegal. What's the point of this extra software protection in this case? To prevent a 0.00001% chance hack? The type of hack that would put the repair men in jail?
Not to even mention that modern phones are basically unfixable.
I think it has more to do with the phone being tied to an individual, the banking and spending activities being tied to the phone, and the government having some hardware attestation about how people are spending their money and with whom. If you root a phone, you can change things like the MAC addresses. You may be able to futz with a softSIM/eSIM. That makes you harder to track.
I don't think this is actually happening. There is an enormous loss to scams mostly by tech illiterate people using the preinstalled operating system. I don't think the losses that involve user installed OSes are in any way significant.
"detect unauthorized interference with the Mobile Banking application"
I wonder if this has become a feasible avenue for scammers to interfere via other apps they could convince someone to install on rooted phones. Or if they are worried about skilled people being able to debug/MITM and find vulnerabilities on the banks.
Though from that statement alone, sounds more of a measure to protect banks than customers.
It's a reliable signal for fraud. The legitimate users are simply noise against this backdrop. The police only think in one direction and never consider the broader consequences of their enforcement perogatives.
Like most people in this thread people who root their phones are clueless about how much of a security risk it is. So they are protecting people from making dangerous choices.
Somewhat. The most popular banks are SOEs owned by ministries, but private sector banks that are local (eg. SCB) or foriegn like Shinhan or HSBC, along with private sector fintech is booming.
> My line of thinking is that if someone is technical enough to root his phone he understands the risks.
Kinda like the Wall Street concepts of "Accredited" and "Sophisticated" investors - who could never possibly fall for a Ponzi scammer like https://en.wikipedia.org/wiki/Bernie_Madoff ?
Not to say I'm a fan of Vietnam, or familiar with their ban - but when people are having their money stolen at scale, there's a very strong tendency to blame the gov't and/or financial system. And it's extremely rare for stolen-at-scale funds to not be "reinvested" in further criminal activities - which again, the gov't is expected to deal with.
> My line of thinking is that if someone is technical enough to root his phone he understands the risks.
That is a terrible assumption. I had a rooted phone when I was 12 to pirate games. Friends asked me to root theirs. Rooting isn’t hard and lots of people do it (absolute not relative terms)
And the idea that so-called “technical” people know what they’re doing and are hack-proof is hot garbage machismo BS. Modern attacks use social engineering and extremely technical people fall for it all the time. There were several stories on here just this week.
A rooted phone is more capable of modifying the banking app itself and has 'freer reign' over the APIs that the app uses to interact with the bank.
Whereas previously the app displays a 'whitelisted' set of UI options to the user, the rooted user could use employee only methods. Somewhere or other every bank has methods that set balances on accounts.
To be honest a law like this makes security by the extremely modest obscurity of not having an "increase your balance" button on the app UI much more tempting.
I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me.
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
Isn't that what Svelte was aiming to do? It's moved on a ways since then, but you can still see the fundamentals in its demos: https://svelte.dev/playground/hello-world
That’s a good comparison — Svelte also started from the “write less, ship less” idea, and I have a lot of respect for it.
The big difference is that Svelte achieves that by compiling away the framework, whereas Dagger.js avoids compilation entirely. You don’t install a CLI, you don’t run a build — you literally drop a <script> from a CDN and wire up directives in plain HTML. It’s closer to Alpine/htmx in that sense, but with a focus on working alongside Web Components.
So in spirit, yes — both try to reduce overhead. Svelte optimizes post-build output; Dagger.js tries to remove the build step altogether.
Thanks for your comment.That's right — the compiled/optimized end of the spectrum is powerful, and I think Prepack showed just how far you can push that. However, dagger.js is intentionally the opposite: it trades the simplest usage for zero build, instant setup. My focus is “drop in a <script> and go,” not competing with compiler-driven stacks. In practice I see them as complementary — one for squeezing every byte/cycle, the other for minimizing friction and complexity.
> I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible
Right, but that is what basically every JS framework is going for these days. Its refreshing to see somebody trying to go back to old school non-compiled js/html where every front-end is open-source(ish)
Really appreciate that. The “old school” vibe is deliberate — I wanted to lower the barrier so that you can share a snippet or inspect a page and actually learn from it, the way we used to with plain HTML/JS. Frameworks are great, but sometimes it’s nice to have a path that prioritizes openness and simplicity over machinery.
I’m in a similar boat like you. I would love for a React-like library that compiles down to direct JavaScript DOM transforms. Of course Svelte exists but I don’t want to mark what is reactive or not and I can’t go back to html templates after using typed JSX. Also I don’t really like the “island” like template syntax of Vue, Svelte, etc
Solid is definitely in that “compile-to-direct-DOM” camp, and I think it’s awesome — it shows how far you can push the reactive model with JSX + fine-grained updates.
dagger.js is coming from the opposite direction: no compiler, no JSX, and also no signals. just plain HTML with attributes like +click / +load. You drop in a <script> from a CDN and it wires up behavior at runtime. It’s more about zero build friction and “view-source-ability”than squeezing out maximum perf.
So if Solid is about compiling React-like ergonomics down to efficient DOM transforms, dagger is about skipping compilation entirely and letting you glue components together with HTML. Two very different trade-offs, but complementary ends of the spectrum.
Thanks for your comment. — typed JSX ergonomics are really nice, and most compile-time frameworks today make you choose between that and some sort of template DSL.
However, dagger.js takes a different angle: it doesn’t try to be “React-like compiled,” it tries to be no-compile at all. State is just plain JS, DOM transforms happen directly via attributes (+click, +load, etc.), and everything is HTML you can literally view-source.
So it’s not competing with React/Svelte on compile sophistication — it’s aiming to be the lightweight “glue” around whatever components you like, while keeping the HTML open and approachable.
I really hope you will try using dagger.js and come back to tell me how you feel about it.
Thanks!
I also meant more advanced optimizations beyond what svelte does, like: inlining, loop unrolling, partial evaluation that would trickle down to the frameworks as well. I am aware that some of these and others are very hard to do on javascript as prepack shows.
Yeah, totally — once you start talking about inlining, loop unrolling, partial evaluation, you’re basically in compiler-research territory. Prepack showed both the promise and the difficulty of doing that well in JavaScript.
dagger.js isn’t trying to chase those kinds of deep compile-time optimizations. Its focus is the opposite trade-off: keep things build-free, HTML-first, and easy to drop into a page. I’d rather leave the heavy lifting to whatever compiler or bundler someone pairs it with, and make sure the runtime layer stays simple and transparent.
So in my mind these approaches complement each other: advanced compilers make large apps faster; Dagger tries to make small apps and prototypes friction-less.
From what I know it can't be "rotated losslessly" in all cases, only if the dimensions of the images are multiples of the MCU which are block of pixels whose size is determined by the chroma subsampling. Ex.: With the common "4:2:0" subsampling the MCU is 16x16 the image's height and width must be exactly multiples of 16, otherwise I think it's just visually lossless and uses some tricks that I'm still not sure how they work.
Unpopular opinion: I think I’m going to wait for version 4 /jk. But honestly, I’ve been spoiled by modern languages like Rust, Go, and even TypeScript with modern tooling, strong typing, stability, and performance out of the box. Right now, I’m just interacting with LLMs, not building them.
That said, I remember writing myself a note a few years ago to avoid Python projects. I had to clean up code from all over the company and make it ready for production. Everyone had their own Python version, dependencies missing from requirements.txt, three way conflicts between 2 dependencies and the python version, wildly different styles, and a habit of pulling in as many libraries as possible [1]. Even recalling those memories makes my stomach turn.
I believe constraints make a project shine and be maintainable. I'd prefer if you throw at me a real python instead of a python project.
[1] Yes, I'm aware of containers, I was the unlucky guy writing them.
Much more capable and reliable type system, paired with comparatively sane package management. This is getting better in the Python world (thank you Astral), but it's still not anywhere near the same.
I was thinking about buying an incinerator, I recycle my trash but recently found that everything gets mixed back together in the end by the privatized trash company and no recycling happens.
I have a bottle of soap that has this actual notice on the back:
"This bottle, after pump is removed and discarded in garbage, may be collected in your local community, but actual recycling rates in the USA are currently very low."
I really dislike when people don't see this. They try to cut 10 grams of CO2 per day while other industries (shipping, aviation, rails) produce hundreds of tons per day and even this transportation modes are less that 20% with most CO2 produced mainly being in energy production and used by industry.
Plastic bags and papers straws is not about CO2 emissions and I wish people would stop repeating this like it's some "gotcha", it's about landfill and natural area pollution and damage to wildlife and natural areas, and that's how it's always been talked about by policy people who have advocated on this stuff.
This makes sense and I'm with you, people that are polluting beaches and natural areas should face harder punishments. That being said I'm missing plastic straws for drinking cold coffee.
Nothing stopping you from carrying your own reusable straw around with you.
Finally, most of the (local, not even thinking about the developing world) pollution is not deliberate. It blows in from other places, usually. I live rural and I'm continually picking up plastic garbage from my ditch or back forest or fields that blows in from the nearby highway and roads, especially after garbage pickup day.
Rituals define a school of thought (or a religion). These are rituals of folks who want to prevent catastrophe through conservation. To each their own.
Ultimately, individual habits do add up. But with climate, one would be hard pressed to find evidence that conservation is the path forward. It does not work, unfortunately.
That's exactly how I started using them as well. 1. Give it just enough context, the assumptions that hold and the goal. 2. Review answer and iterate on the initial prompt. It is also the economical way to use them. I've been burned one too many times by using agents (they just spin and spin, burn 30 dollars for one prompt and either mess the code base or converge on the previous code written ).
I also feel the need to caution others that by letting the AI write lots of code in your project it makes it harder to advance it, evolve it and just move on with confidence (code you didn't think about and write it doesn't stick as well into your memory).
I think at some point the number of tabs doesn't matter because the tab is unloaded and the state is maybe stored on disk. As long as you don't open them, having them open shouldn't slow the browser down.
