By GrapheneOS, they mean "official builds of GrapheneOS". If you build GrapheneOS yourself, you won't be allowed to use these banking apps due to remote attestation.
I think this is the real problem here if it's true. The community must absolutely retain the ability to fork the project and reintroduce things like root that the developers are obstinately against. If not, then Graphene will simply become another Google/Apple.
I think root is precisely what most of these apps are trying to avoid. They think (at least the finance app I used to work for thought) that with root, user credentials the app stored would be accessible by whatever uses those root permissions and they didn't want the risk
> I think root is precisely what most of these apps are trying to avoid.
Maybe, but it's necessary when you want to modify some aspect of the system you disagree with. For example, Android has a mechanism that prevents the user, the owner of the phone, from snapping a screenshot of an app he can see with his own eyes. Those kinds of limitations are enraging, and are just one example of why root is needed if the user is to truly own the device.
Well yes, that's exactly the sort of the thing banking apps would want to prevent. Android also blocks overlays on banking apps to prevent a whole class of attacks.
But you can do that. You can go and root it with a fork. You just won’t run banking apps on it, because it introduces undue risk that they don’t want to absorb.
This ‘all or nothing’ attitude in the comments is a bit silly to be honest.
Most banking apps will still work on a fork of GrapheneOS which appears to keep the security model intact to apps. A half dozen apps which work on the official builds won't work on an unofficial build since the bank has chosen to make a list of which operating systems not certified by Google are allowed.
Not necessarily, it depends on how they fixed it. It isn't up to us.
Some of these apps began supporting it by fixing their own anti-tampering code to stop being incompatible with our exploit protections to avoid needing users to opt-out for the app.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
The fact that GrapheneOS digitally signs their releases doesn't make them not open source. This is indeed a bad situation, but the badness is 100% the fault of Google for having a hardware attestation "feature".
GrapheneOS is open source. This has no connection to open or closed source. GrapheneOS has heavily pushed back against apps using remote attestation to restrict which operating systems and hardware can be used. When apps are unwilling or unable to remove it such as due to government regulations, we try to convince them to permit GrapheneOS and other alternatives via a standard Android API instead of only using the Play Integrity API.
Banks are increasingly adding checks for Google certified devices. In the EU, there are regulations requiring banks to start verifying device integrity. It's headed that way worldwide with a growing number of regulations and industry standards requiring it. Apple's App Attest API and Google's Play Integrity API have repeatedly been the only options recommended by the EU which has contributed to the worsening situation in the EU in particular. We convinced the EU to remove those specific examples from several official standards. No one has been able to convince them to stop heading down this path despite a lot of people pushing back against it. We haven't been able to convince them to define actual requirements let alone to require permitting anything which meets those requirements. They give a vague description of what they require doing shaped around the Apple and Google integrity APIs.
We convinced around a dozen banks mostly in the EU to use the standard Android key attestation API included in the Android Open Source Project as an alternative. It allows apps to verify the OS verified boot key hash, patch level, app signing key hash(es) and app version code based on a root of trust. This meets the requirements for the EU standards and enables permitting any alternative with verified boot and a mandatory app sandbox with support for verifying the app's signing key and passing it to the hardware keystores. Other operating systems can publish their signing keys in the signed JSON format we published and ask the same companies to include their keys too.
Once apps implement an alternative to the Play Integrity API to permit a single OS, it's easy for them to add more. The hardest part is getting them to even consider doing it. It's nearly impossible to get in contact with the right people and to convince them to do it. Once we establish that contact and convince them to ship it, it's a lot easier. There has been an ongoing issue of these apps not adding our new verified boot keys which are per-device-model for security reasons similarly to the Pixel OS. We tried to solve that by creating a standard signed JSON format which can be automatically retrieved and used to automatically include the new signing keys. Exactly the same approach can be used to delegate certification and inclusion of arbitrary operating systems to other organizations. It can also be used for handling which roots of trust for non-Google-certified hardware are also permitted.
We would prefer if none of this existed but we don't live in that world and we're doing what we can to convince apps to permit GrapheneOS and other alternatives. We're heavily fighting against it being done in the first place and against more standards and regulations requiring it. We're also fighting against more centralized attestation systems such as the Play Integrity API as opposed to systems with actual standards where anything meeting those standards can be included. It would not be a good thing for there to an EU alternative to the Play Integrity API permitting specific operating systems and devices based on geopolitics and business interests. That would only accelerate adoption of attestation by EU apps which is already happening at a faster pace than elsewhere thanks to both EU regulations and what many of the countries are doing themselves.
If it's impossible build the binary from the source you've been given, then you haven't been given the source. The binary in question is one that passes attestation and secure boot. If I don't have the key, I don't have the source.
MIT allows this (you not giving me the source). GPL2 allows this in some jurisdictions - notably, not in Germany. GPL3 absolutely doesn't, which is the reason Google refuses GPL3 upstreams.
Permissively licensed open source code is open source code. Firmware on a secure element can be open source without it being possible to replace it without the signing key on a production device.
German courts are not bound by precedent in the same way as US courts and you're referring to a specific case in Germany which cannot be broadly applied.
AOSP ships a lot of GPLv2 code (Linux kernel and OpenJDK libraries among other components) but doesn't use GPLv3 for multiple reasons.
AOSP used to use a lot of GPLv3 code as part of the toolchain for building AOSP but that was replaced with LLVM, ToyBox and other permissively licensed projects.
"You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License"
I don't know why some of my comments are being shadowbanned. It might be an AI filter gone awry.
I emailed the moderators about your comment being dead, after vouching failed to bring it back. They said it looks like it was a false positive hit in a spam filter and they have taken steps so it should not hit you with any more false positives.
As far as secure boot and attestation goes, my understanding is that these are based on signatures.
Things like signing keys have generally not been considered to be source code under GPL. Such things before GPLv3 were completely out of scope.
In GPLv3 they were brought into scope, but not by changing the way they define source code. Instead they added a new category, "Installation Information", for "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work [...]".
Section 6 of GPLv3, which is where the part your quote comes from, under some circumstances requires that you must accompany the conveyed Corresponding Source must be accompanied by the Installation Information.
The circumstances where this is required are pretty narrow. Before we get to that we need one more term that was added for GPLv3: "User Product".
>> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
Installation Information must be included when two things are true:
1. The object code conveyance is in, with, or specifically for use in, a User Product, and
2. The conveying is part of a transaction in which the right of possession and use of the User Product is transferred to the recipient.
In short, under GPLv3, if you want use GPLv3 code in the software or firmware you include out of the box on hardware you are distributing you need to include Installation Information.
As far as I know GrapheneOS is only distributed as a third party download you can install on a device you already own, so does not trigger the GPLv3 Installation Information requirement.
Many of our posts about it heavily criticize apps limiting which operating systems and hardware can be used in addition to the Play Integrity API itself. Our focus is mainly on the Play Integrity API because it's the only relevant system resulting in compatibility issues in practice. We don't have to worry about Apple's App Attest API and we aren't aware of any app banning GrapheneOS with the Android key attestation API.
We've convinced dozens of apps to drop using attestation with user pressure. We've also convinced a much smaller number of apps to at least permit GrapheneOS and other alternatives chosen by them with the Android key attestation API instead of only permitting Google-certified operating systems. We aren't aware of any app using the Android key attestation API in a way which reduces compatibility since apps generally only use the Play Integrity API and have to be convinced to either drop it or at least use an alternative where they can permit non-stock operating systems based on verified boot key hash and non-Google roots of trust.
> The thing I admire most about Anglo-American culture is that people will jump off a bridge if you give them a court order that complies with all required procedural formalities.
The president of the United States routinely violates court orders and has little respect for the law or the Constitution. Also, nobody is going to willingly jump off a bridge because a judge told them to. You'll find that the death penalty isn't carried out by asking people politely to kill themselves.
I’m talking about the rule-followingness of your average american, which is the bedrock of civil society. Every society has rot at the top. Few societies can survive rot throughout the base of the pyramid.
My understanding is that watermarking in prose is basically a bias when sampling tokens. For a system that knows the average probability for each possible token in the LLM vocabulary it is possbile to quantify said bias given enough text.
For a human that doesn't reason in tokens and therefore doesn't know anything about their probability distribution, it should be impossible to tell. Relying on fancy words/constructs within sentences should not give you any signal as well, since you don't know if the the prompt included instructions for that.
> Apple's internal justification for this is that the iPhone and iPad are consumer devices designed for maximum comfort and safety, whereas the Mac is a device designed for developers and professionals.
Then why did they recently launch a MacBook that costs less than an iPhone and a marketing campaign targeted at existing iPhone users?
> If you love iPhone, you'll love Mac. Mac is designed to be just as easy to learn as iPhone.
I think the difference is that, on Windows, there are background services that constantly ping Microsoft with the device ID. A device ID on its own is not really harmful if it's not exposed to the internet.
Right, the danger here isn't stable unique data itself--there's already plenty of that--but the OS "telemetry" which steals [0] it and reports to Big-Brother along with too much other betraying information. Every site you visit, every program you run, the serial numbers of all your hardware, etc. Even if the GDID were totally absent, it would still be a correlate-able privacy nightmare.
Ultimately there's no informed consent here: The average consumer is disbelieving and surprised if you tell them what kinds of stuff Microsoft has/can put into a dossier. Nobody thinks: "Ah, Edge on a fresh Windows install, I'm glad Microsoft knows every site I visit, and can tell I'm a friend with someone because we use the same bluetooth speaker."
[0] It seems wrong to use the verb "leaks" when it's so obviously intentional.
> Microsoft has a list of IP addresses that has been used by a computer with a certain GDID, but FBI needs to get the GDID in the first place
What they did was the opposite: ask Microsoft for GDIDs used by attacker-associated IPs within several 24-hour time periods during which attack-related activity took place. Windows pings Microsoft regularly with the GDID, establishing links between your GDID and any IP addresses you use. The IP logs from Microsoft and the VPS provider showed at least 10 instances where a single VPN IP accessed the attacker's VPS and also pinged Microsoft with at least one GDID within a 24-hour period. They found a constant GDID that all instances shared. This seems to have been the most damning GDID-related evidence in the DOJ complaint [1] and yet it wasn't mentioned in the article you linked (or any other articles about this I've seen pop up on HN). It includes the diagram from the complaint (page 18) that outlines this, but devoid of context. The ngrok stuff that the article focuses on was just the cherry on top and was discussed later in the complaint.
What also becomes clear when you read the complaint is that the GDID was just one piece of the puzzle and that they had plenty of other evidence. Attacker-associated IPs were used to access the suspect's Apple, Snapchat, and Facebook accounts, at least one of which was his actual residential IP, not a VPN IP. Once they had revealed the identity of the person who owned these accounts, they were able to all-but-confirm that this was in fact the attacker.
What remains unclear even after reading the complaint is how they were so sure that the GDID they obtained visited specific websites, but honestly, at that point, they were already drowning in evidence, so I don't know if it matters that much. It could be as simple as "he was signed into Edge with his Microsoft account and had sync enabled".
Wait, so it would have, ironically, been safer to allow microsoft telemetry to bypass the VPN entirely and remain associated only with their home network, because it's the phone home to microsoft tunneled through the VPN that tied together all their IP addresses to a single microsoft account. The GDID itself is almost a red herring, as it could have been a session id or username or something only long lived enough to appear comming from several ip addresses to windows update request?
If they'd done their VPN/dirty work in a linux VM/container, with the VPN running in that, they'd have been fine.
Clean-them would have had their GDID on their normal ISP IP or equivalent, and Dirty-them would have had everything through the VPN from their no-telemetry dirty-host.
There is no information about the author of this article, and it has the "AI smell". It's safer to operate under the assumption that it is AI generated unless and until the author reveals themself or at least anonymously confirms that it is not AI generated. This saves you from having made a fool of yourself by spreading it around, if it later becomes apparent that AI wrote it.
reply