Yes, let's abandon a very mature OS that is still open source, has millions of apps, and billions of users by one one that was designed for desktops, with a security posture fitting the 90s, virtually no phone apps unless you emulate said very mature OS, and which will have all the same problems with remote attestation, etc. </s>
The whole security embargo things seems incredibly stupid. OEMs are always too late rolling out security patches. So Google thought, "let's create an embargo of months so that the OEMs have time to integrate the patches". Anyone could see it coming that nothing would change and the OEMs would still wait until the very last moment.
So now everybody is off worse. Not only are OEMs still slow with security updates, while CVEs float around for months among those within the know (or reverse engineering skills) for months.
What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer
I see your point, but it would be very misleading, since the phone would still have a lot of known holes. Only the OS would get updated, typically not the drivers, driver firmware, possibly not the kernel. The phone would still be easily compromised through all the known RCEs. So you tie up non-profit projects in a lot of extra work to get an improvement that does not really matter.
This is a mess created by the OEMs and they will continue to create this mess until people will stop buying from OEMs that only give lip service to security updates (roll out Android Security Bulletins to show a high patch level, while in reality the phone the phone has many known CVEs).
The GPL is the only reason they even get that. More enforcement would certainly be good, but it's not like the GPL is worthless without a legal team backing you up.
There has been a long discussion about this a while ago on HN when these delays came up. The relevant blurb:
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Many people argued that 'customarily used for software interchange' is worded-as is to always be relevant to the times when the license is applied and that providing access to a Git repository is customary nowadays. In fact:
- The upstream Linux tree is distributed through Git.
- The relevant Pixel kernel sources used to be distributed through Git.
IANAL, so I am not sure how this part of the license will hold up in court, but the spirit is clear. Providing a Google Drive link is not customarily used for software interchange.
Also, I think it is fairly clear that the procedure is put in place to make everyone's life difficult, given that the relevant source used to be distributed through Git.
That's true, however, under all the recent pressures, everything is much more fluid. Especially because 'associate member' does not exist yet as a status, I think they could do things much more incrementally compared to full memberships.
To be honest, I am happy that a somewhat influential account is raising these issues. I have tried to explain for probably two decades now that the Linux desktop has poor security and the Linux kernel has issues. But somehow a significant portion of the Linux community lives with the delusion that the Linux desktop is the most secure OS. The whole idea that a vulnerability in some image parser that their Mastodon client uses could give an attacker access to their full user account, simply doesn't occur to them.
I want the open source desktop to succeed, but we can only make progress if we accept that there are a lot of security, UX, and UI issues and start tackling them.
When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.
Yeah. There it's clear that there is a lot of organized disinformation, probably by government actors and certainly by other open source and phone vendors that try to sell privacy/eurowashed phones (one Volla astroturfer outed themselves accidentally on Mastodon by sharing information only an employee could know).
From leaked Cellebrite presentations, it seems GrapheneOS is more secure. But it's easy for Apple marketing to move the goal posts by adding words like 'consumer'. They do this all the time in their marketing, like:
Force sensor with volume swipe arrives on AirPods 5, a first for the open-ear form factor, adding the ability to quickly adjust volume by swiping up or down on the stem.
Add some qualifiers so that you can call yourself 'first'.
I think the chart exactly shows the weakness that some people have pointed out. Apple's PCC servers at some point in time know the signing identity for a photo and Apple's generated replacement signature. The relevant steps from your chart:
- verifies each link and its certificate chain, sensor signature over pixels, SEP signature, device manifest signature
- PCC Submits the commitment (the JPEG hash) to Apple's signing service.
So, at some point in time, Apple's servers have both the original certificate chain and the new replacement signature. If this is recorded, Apple can deanonimize photos and check whether two photos were from the same device/sensor.
Apple's system protects against most state actors, except Apple and the US, unless you fully trust that their PCC is watertight.
(Remember that Apple was part of PRISM and probably also its successor.)
I don't think law enforcement needs it, because when sending/posting a picture, people leak so much metadata anyway.
But people outside the US should certainly distrust these systems.
reply