Not really. Samsung was the first with this, but their reasoning had absolutely nothing to do with security. It was because their phones slowed down over time and their solution was to give users the option to reboot it at specific intervals. You could even make the argument that the Samsung solution is still the superior solution because you get to set the interval.
Because it's an effective tactic against exploits that can't survive a reboot, which is somewhat common from my understanding. The idea being that police can confiscate your phone and just keep it on and charged until they can buy or develop an exploit targeting your current device and software.
I was admittedly confused about this distinction at one point too. It's a trade-off (although few people effected by this own phones with truly free, user-respecting soft/hardware in the first place).
As the GrapheneOS docs note, the feature is better implemented in init and not in system server or the app/services layer like Google has done here? Though, I am sure Google engs know a thing or two about working around limitations that GrapheneOS developers may have hit (in keeping the timer going even after a soft reboot, where it is just the system server, and the rest of the userspace that depends on it, that's restarted).
Huh, I have GrapheneOS and I never noticed it rebooting. (And when i manually reboot, the "BIOS" prevents it from booting without acknowledging that I'm aware it's a non-Google OS, so how does it work?)
The feature is not enabled by default. Also, the boot doesn't wait for you indefinitely - it just gives you a few seconds to glance the checksum and halt it, before it proceeds automatically.
You don't have to acknowledge anything. The boot screen shows a warning which you can interrupt. If you don't do anything it'll continue to load as normal.
No. Play Services is Google's way to make Android closed source. Many new features don't get implemented in Android, but Play Services. Many apps don't work (correctly) without Play Services.
Being closed source is not the goal. Update speed, consistency across the ecosystem, and feature development speed are key reasons things are implemented via play services. Also dependency on google services, but that's not relevant here. AOSP is greatly improving in its ability to tackle these things, so the choice to implement things in play services won't be as compelling as it is today for things not ultimately tied to Google.
Play services is how Google delivers many Android updates now so that all users can get security updates without waiting for the device vendor to publish it for each device.
Fully agree. But instead of having "the government have full control over people's money", I think, setting this up as a federated cheap-to-run payment system would be even better. This would allow multiple existing banks to offer the service to their existing customers. This could reduce the risk of a fully decentralized solution a little bit.
It's private for the user. Transactions are only between you and the merchant. Credit card networks, PayPal, etc are all third parties with insight into all Payments going through them globally.
It's offline. Neither you nor the merchant have to have a connection to the bank for the transaction to happen.
Usually, in the context of these privacy-preserving payment systems, online vs offline refers to whether the merchant has to be online to check if the 'coin' they received is valid (authentic and not doubly spent). The user usually has no reason to be online at all, since they withdrew the coin already in the past.
By that definition neither the wallet holder nor the merchant would have to be online for a real 'offline' system.
GNU Taler e.g. is an online system on the other hand, where the merchant has to be online for pragmatic reasons. It's kind of sad to see them being categorically excluded by this requirement. Their the best we currently have afaik.
Chaum designed and tried to commercialize an anonymous + offline payment system in the 90s already.
Basically he used (and invented) blind signatures to allow the bank to sign a 'coin' without knowing what they signed. The customer takes the blindly signed coins from the bank, pays at a merchant and later the merchant deposits the coins at the bank again, where the signature is checked.
In this context offline just means that the merchant can verify the authenticity of the coin without immediately needing a connection to the bank. At some point in the future, however, the merchant will have to connect to the bank to get their money.
Check out his original paper for details[1].
Offline systems have drawbacks, though. E.g the GNU Taler people made the pragmatic decision to have an online system. See chapter 1.2.1 'Offline vs Online' of Florian Dold's Phd thesis for a discussion on why[2].
Just be aware that your pipeline prompt should not contain any secrets and you should expect that users will be able to subvert your pipeline prompt! I think the most popular name for these attacks is currently 'prompt injection'.
reply