I tried to get myself a custom "Brave Origin" some time ago, but just like upstream Chromium, some related code are just poorly guarded, it's not really trivial to do it and keep it up with upstream.
It is a bit different. My app doesn't rely on 3rd party services at all. It just provides functionality.
It is not about breaking into someones account.
I just know that the app can just be cracked - there are plenty of sites that do that for android. Because you can't just load your app on iOS - this is just not possible (well perhaps there are a few percent of some jailbroken iPhones, but that is neglibile).
On Android though, you can soon see such app stolen and on some of the apk warez sites. It just breaks the model.
The only difference between iOS and Android when it comes to loading code onto your device is that, on iOS:
- You have to setup a developer account with Apple first, and dev-signed apps can only be installed onto specific provisioned devices only[0]
- The free tier of that developer account is inconvenient for actually using dev-signed apps as a daily-driver, and won't let you use certain entitlements
- Apple's dev tooling is designed to make it feel like you can only sign code you're compiling yourself
On the surface level, this might seem like a big difference, because Android has a command that lets you load arbitrary APKs with no particular fanfare or ceremony, while Apple's dev signer is buried inside of a compiler/IDE suite. But people have built tools to make it easy to take an arbitrary .ipa, sign it using your dev account, and resign it once the free tier's 7 day limit expires.
Of course, this still requires you actually go and obtain an .ipa of the app you want to use, and Apple distributes App Store[1] app binaries[2] encrypted. That part requires actually having a jailbroken device to dump the app binary with. But once the app is cracked anyone can install it.
If you want an actual "uncrackable" app you need to put a critical part of your app's workflow onto a server, and then have your app send an iOS DeviceCheck or Google Play Integrity attestation that the phone is running the actual App Store/Google Play version of your app. But that's also incredibly draconian behavior towards your customers as it basically forces your app to be always-online... which is why a disturbingly high number of games do this.
[0] Yes, I know about Enterprise signing, but Apple specifically forbids distributing Enterprise-signed apps outside of your organization and those apps get revoked all the time. Signing with your own dev account is way more robust and that's what most iOS power users actually use.
[1] I have no clue if FairPlay encryption applies to EU-DMA-compliance signed apps.
[2] ONLY binaries - all your resources are unencrypted and can be downloaded off the App Store CDN and inspected by anyone. Code signing signatures do apply to resources, AFAIK
> Because you can't just load your app on iOS - this is just not possible (well perhaps there are a few percent of some jailbroken iPhones, but that is neglibile).
No, smart normies are sideloading with the 7-day limit and leveraging automation to have their pirated apps automatically re-sign and re-push. If you pay the $99 to Apple for a dev cert (or like $10 to a service that'll sell you a cert off someone's account), it'll even just sign out for the year for you. No screwing with Xcode or anything, just drag-drop-sign. Even gives you the options to patch the app out at resigning so you can do hacks and mods like the good old jailbreak days.
The crypographic flow that allows payments to work is straight up pub/priv key encryption with one time use tokens. It's not something you can hack. As soon you see the token it's already been used and thrown away. So whatever nonsense about decompiling literally doesn't matter.
So your professional opinion is that the attack surface of mobile banking apps is limited to tokenized payments? Honestly, I'd be appalled if tokens were routed through my banking app. There is no reason the local client needs that data.
My professional opinion is that APKs can be de-compiled regardless and that has nothing to do with tokenized payments themselves which are like you said handled through server-server communications at the payment processor level. Your phone simply sends a one time use token to authorize the transaction.
What exactly was my example? You agreed with me already. Kind of odd to flip around now.
> which are like you said handled
Also, I corrected your misstatement about payments. They have absolutely nothing to do with decomp, and certainly can't be used to dismiss the entire attack surface of a mobile banking app. Your example is complete nonsense.
He said his app is a one time payment. Presumably there isn’t a backend and he relies on App Store purchases. I know, it’s shocking an app could just be an actual application rather than a web view.
The payment doesn't happen on the device. It happens at the VISA/Mastercard/AMEX level. So "the app" should be doing the validation upstream on the server side and simply reporting yes/no to the app. If you hack the yes/no okay but most payments are for physical things IRL so the payment gateway that is not on your phone is gonna be like ??? - in other words it's on the app not to trust a raw true/false signal and instead rely on server side checks. This is all irrelevant. I make regular massive purchases on my linux box where I can read the memory. It doesn't change anything.
Ah I see you are focusing on apps that have some web component that would enable ongoing authorization. I was thinking about apps that offer a trial but you can upgrade with an in-app purchase and there is no ongoing service component.
This is one of the most ignorant comment I ever read on Hacker News. Are you from VW?
Obviously VW broke the app for GrapheneOS (or any other custom ROM) on purpose, and ironically, things usually works fine for custom ROMs than some Chinese OEM customized ROMs, and when it works, it means the developer went extra miles to implement workaround to cater the flawed OS.[1]
Legal reminder: it is not allowed to steal someone else's creation and make money from it. Yes, getting money from your Patreon followers to instead of selling directly your Ocarina of Time remake is not allowed.
What do you mean by open and closed? ChromeOS is based on ChromiumOS, which is open source. I guess macOS is based on Darwin technically, but the ratio of open source to proprietary is much higher for ChromeOS than macOS, no?
What is it that you want to install on ChromeOS that you are unable to? All of the usual Linux and open-source stuff works fine on the built-in Linux environment on it. Possibly even a little better than MacOS in some cases, since you don't need to worry about Apple app signing. There's not literally nothing you can't do, but the list is a lot shorter than most people think, especially those who haven't really tried ChromeOS in a decade and think they're all a glorified web browser on $200 hardware.
I'm willing to bet it's easier to set up a Linux VM on a Chromebook than on a Mac. But the other side is that anything not explicitly requiring Linux will work natively in macOS, where you also get a nicer terminal. Like I've not needed a Linux VM in years, and the author doing web dev probably won't either.
Crostini is built into the Chromebook, vs macOS where I hear a different container solution every time someone asks about it. Colima is a new one to me. Maybe it works great and the others do too, but full 1P support is a step up.
Well, then you can only put it in dev mode and use chromebrew. Which I am glad exists, but even installing node can be a pain and the way to get it running changed over the years.
But how? You can install Linux and android apps on chrome os. I understand this perspective might intuitively make sense, but we need to analyze if it's actually true.
You can even install linux on Chromebooks, and ChromeOS has upstreamed / opensource many of their codes.
In other perspective, ChromeOS supports running Linux apps w/ GUI without much differences. You just open your terminal, type `apt install XXX`, then `XXX` should work out-of-the box.
I don't see any reasons that ChromeOS is less open then macOS
The entire system firmware is open source, so it’s relatively straightforward to replace the system firmware with Coreboot and EDKII to boot normal UEFI Linux. It works excellent. mrchromebox.tech and docs.chrultrabook.com have all the nitty gritty details.
ChromeOS is the absolute last desktop operating system I would choose to use for myself. Linux, macOS, and Windows would have to be completely dead and buried before I would switch, and at that point I might just consider abandoning tech altogether and joining an Amish commune or something.
When was the last time you tried ChromeOS, out of curiosity? I'd always reach for Linux first, but I'm hard-pressed to put Windows or macOS in second place when both are so miserably bloated.
...except the operating system. And the silly notch. And the weird keyboard. And the hard palm-cutting corner. And the reflective screen. and the finger-print-magnet materials. And the small amount of RAM. and the small SSD. And the weight.
Other than that, it's perfect!
(On the blance,still better than any other laptop)
