GrapheneOS is ready to break free from Pixels
Almost nobody cares about privacy, and this is going to be super expensive. I might be fine with paying extra, but the economy might not work out, like it didn't for Blackphone. Fairphone is barely alive as well. Seeing as phones are just source of ad money Google can drop the prices on their phones as well.
Some European countries and banks already require crap like Play Integrity for essential apps. So far it's possible to hold out, but for how much longer?
There's legitimately zero reason to allow 2FA only on your own propreitary app. You can't even make a financial argument - allowing other TOTP methods is cheaper because now you don't need an app!
That's because they're stupid or doing something suspicious, probably both
Small comfort for whoever needs to use that bank. This is the disconnect geeks and Free Software needs to bridge to make any headway.
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
Article 7 Requirements of the elements categorised as possession1. Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.
2. The use by the payer of those elements shall be subject to measures designed to prevent replication of the elements.
However if you can get so far as to get the secret from the TOTP app, you can as well back up the entire phone and restore elsewhere, can't you?
"Unextractable keys" works with hardware that you don't "truly own".
You can still get a plastic card, however it requires paying extra and some additional forms, the reasoning being it is not environment friendly.
Edit: https://en.wikipedia.org/wiki/Chip_Authentication_Program
I could cut myself off from the modern financial world and just use online banking like it's 2010 but that's a pretty big ask.
These apps, by design, track how people spend their money.
That depends - In India, for example, I am free to use either (1) a private company's app (like PayTM, Google Pay, PaisePe etc.) (2) a Government app or (3) my Bank's app to make digital payment using the Unified Payment Interface (UPI) (or all 3). And, if I don't want to use any mobile app, I can still make offline payment through my mobile phone over USSD - https://razorpay.com/blog/how-to-make-offline-upi-payments/ ...
(You are right though that it is prone to abuse in the absence of strong privacy and data protection laws - digital payment does allow new form of surveillance capitalism to the corporates and new avenues of authoritarian control to the government).
I want to be able to run software on my device, not fulfill some nuts low-rent fantasy that they're a rebel against the government.
Maybe the better approach would be focusing on getting postmarketOS to work, and use an emulation or recompilation layer that is running Android in a box (pun intended). Anbox and others were still too painful to use for daily usage, but maybe you can get rid of everything except the things that Play Integrity checks against? Maybe we can make waydroid work?
in fact statements from graphene suggest they hope to eventually move away from linux on the host
Play Integrity API doesn't impact GrapheneOS as much as other alternatives not focused on privacy and security in a similar way. A subset of the apps using the Play Integrity API are explicitly permitting GrapheneOS via hardware attestation including multiple banks like Swissquote. We're working on convincing more banks to permit it. Our hope is for regulators to invalidate the current approach and require defining clear security standards which need to be fairly enforced. The status quo of some banks banning using a much more secure OS that's even much more heavily using hardware-based security features while permitting a Google Mobile Services OS with no patches for 6 years is a massive antitrust issue. It impacts every alternative hardware platform and OS since Android app compatibility is important for competing. The obstacles to getting approved should also not be unreasonably high. It's better if apps don't do this but we can accept they are going to do it if it's a fair system permitting competition, unlike the Play Integrity API.
https://github.com/PrivSec-dev/banking-apps-compat-report
https://privsec.dev/posts/android/banking-applications-compa...
You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.
GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.
Location Scopes is a planned replacement for the standard Android Mock Location feature which is rebranded in /e/ as their own feature. /e/ does not have features similar to Contact Scopes or Storage Scopes. It doesn't provide the current generation standard Android privacy protections or patches since it's always very far behind on updates. Most privacy patches aren't backported to older releases, but they lag far behind on backports and don't fully apply them despite claiming to provide a much newer patch level than they do.
/e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
Is this you? https://privatephoneshop.com/why-we-no-longer-sell-phones-wi...
The company you've linked was scamming people who wanted GrapheneOS phones by selling them end-of-life devices no longer supported by it and devices near end-of-life while pretending they were perfectly fine and would last years. They were misleading people about what they were getting and violating our trademark. Despite profiting from selling devices with GrapheneOS, they were also actively misleading people about it with many inaccurate claims. Their response to us politely bringing it up was blocking our project account and attacking us. When we warned our community, they responded by joining in with spreading fabricated stories about our team aimed at directing harassment towards us. The videos linked in the article are harassment content filled with fabrications and misrepresentations. The initial video is from someone responsible for encouraging repeated swatting attacks towards our team and the 2nd is from someone who openly uses Kiwi Farms which they directly personally involved to target us.
/e/ leadership spent years trying to mislead people about GrapheneOS including highly inaccurate claims about privacy and usability. We began debunking this and posting accurate technical criticisms of /e/. Despite spending years attacking us with little to no response from us, /e/ has responded to us informing people about it by joining the harassment you've tried to promote. Their CEO / founder has directly participated in it. It's a very typical pattern from /e/ and their community for the response to accurate technical information to be fabricated stories aimed at targeting us with harassment.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
/e/ always uses multiple Google services and builds in privileged support for Google apps and services so the branding as a degoogled OS doesn't really make sense. GrapheneOS doesn't brand itself that way but doesn't make connections to Google servers by default and doesn't provide privileged access to Google apps and services.
There's a reason ROMs like LineageOS develop their own alternatives. Most ROMs seem to use those open source alternatives rather than the apps Google abandoned with AOSP.
They have made major usability improvements like eSIM support and network-based location. They have also been forced to work on things due to unrelenting popular demand like Android Auto support, sandboxed-google-play and the compatibility layer and Google Messages & RCS support.. to the cost of working on other security/privacy enhancements. At the end of the day, this is more a question of resources available.
I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world.
I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world
I agree completely. I don't expect one small team to carry the weight of building an ideal OS. I'm just disappointed that while there's loads of work being done spinning up interesting desktop OSes with new paradigms for UX and system management, the same can't be said of the mobile space. Everything there is basically some slight variation on iOS.
I prefer the iOS model, though it’s not without its own issues. For iOS, if no media is playing, the volume buttons control the ringer/notification volume. If there’s music or a video actively playing, the controls adjust the playback volume. Honestly, my biggest gripe is not being able to easily set ringer volume while something is playing - I just did a quick test with Spotify open, and going to the settings app and adjusting the ringer stopped playback for the ringer sample to play.
I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience.
i agree with the sentiment, but not for the features part. just getting the core functionality working across devices (securely of course) is already a lot of tedious work. just look at the dearth of supported devices that do not run a specific soc or from a famous brand.
for vast majority of features, one can personalize themselves by getting apps. most don't need rooting or any technical know-how. it will be unproductive to spend time ricing the os for users when they got their own personal preferences regardless. which is why it is fine to focus on getting the core things right first.
I suspect the answer is "no" but I want to believe...
FWIW I have run several banking apps on GrapheneOS without any issues whatsoever, never had any blocks or compatibility issues. Might just be luck of the draw but just to say you probably do have options.
Google Play Protect
Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.
Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).
These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.
GrapheneOS can not do anything about that.
I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.
Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.
GrapheneOS can not do anything about that.
GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
The issue is more that GrapheneOS still allows apps to view OS attestation information[0], which is similar how Play Integrity API attempts to prevent you from running on your own OS. The specific feature I'm referring to which is the problem is the Play Protect API which allows apps to inspect the host system bootloader/TPM state essentially. The problems with giving any apps(even webapps) access to this sort of attestation information are well documented[1] as it encourages app developers to lock out legitimate users who want to run unofficial operating systems. Effectively breaking this app verification capability is what is needed to prevent app developers from enforcing arbitrary security requirements on the host OS. Essentially GrapheneOS just wants app developers to trust their keys in the same way Google wants you to trust theirs(using the Play Integrity API).
[0] https://grapheneos.org/articles/attestation-compatibility-gu...
[1] https://en.wikipedia.org/wiki/Web_Environment_Integrity#Rece...
If you don't like their requirements, you need to take the liability yourself. You could use PayPal or a stablecoin to store your money.
We're in this funny situation where the hacked and outdated device is considered more "secure" by Google because Google controls it
Your money is far more at risk with scams and phishing than it is with whatever boogeyman spyware you may try to think of that does not exist in real life.
GrapheneOS can not do anything about that.
OEM support is a step toward passing integrity, and that's what those apps are looking for.
Google Play Integrity
Essentially a Google API that App Developers integrate that checks if the device runs an Operating System signed by Google as "Play Certified". This can go as far as being backed by a hardware trusted platform module. I doubt Google will certify GrapheneOS given their modifications towards sandboxing the play services. This can be faked to a degree but GrapheneOS choses not to do it and to fake the TPM part you need leaked keys. For more details on how to fake it look at this thread: https://xdaforums.com/t/guide-how-to-pass-strong-integrity-o...
Fingerprinting the Device OS
This can very from app to app and just tries to fingerprint the device in many ways to see if it's running a custom rom of some kind. This does things like check to see if the bootloader is unlocked or if root is installed. I think this is something an official grapheneos phone might fix since the phone vendor could allow grapheneos to sign their releases as native equivalent
Banning GrapheneOS by Name
Some Apps Developers literally ban GrapheneOS by name.
Failures due to Google Play Sandboxing
Since GrapheneOS sandboxes Google Play Services there might be compatibility issues that prevent the app from working right. This would likely be unaffected by a GrapheneOS Phone.
Failures due to Advanced Security Features
Some Apps just don't "like" the advanced security features like the hardened malloc and other protections and just fail. This can be disabled most of the time
This would of course be contigent on GrapheneOS growing their market- and mind-share in the general public, while also taking several years to impact the least move-fast-and-break-things industry (consumer banking).
But still, a man can dream.
But being certified by Google of course precludes not preinstalling or sandboxing their GMS apps.
Hopefully they select an OEM which supports pKVM - that's the one Pixel feature I'd really like to see being implemented on other Android devices.
Edit: Looks like there's an updated workaround now, but this is what I mean - it's really unacceptable that an essential feature like VoLTE - which is required to make phone calls - may not work depending on your carrier/region.
Yes, Pixels should probably be sold in all markets. But if you're explicitly circumventing that you shouldn't be surprised.
It's perfectly possible for VoLTE not to work in regions where no carrier provisioning information is available while foreign SIM cards work fine.
In theory a phone can just be provisioned by the network to use VoLTE, but in practice the spec allows for all kinds of incompatible configurations. Carriers and phone manufacturers won't just apply an untested configuration, and for good reason. Software upgrades have broken telecommunications from iPhones to Androids, sometimes edge cases such as calling 111/112/911/999 turn out not to work.
Falling back to 3G or even 2G on unknown networks in unsupported markets will get you voice calls, at least for the coming years.
Google is the only major OEM (that I'm aware of) that has these deliberate draconian roadblocks to prevent VoLTE - an essential feature - from working. On OnePlus and Xiaomi devices for instance, you can always go into the engineering menu via the dialler and enable VoLTE on unsupported networks. Xiaomi even has an official code to disable carrier checks. Samsung takes it a step further and partnered with the GSMA[1] to enable VoLTE globally by default on all their Android 15+ phones. So I think it's fair to criticise Google for going in the opposite direction as other Android OEMs.
[1] https://www.mobileworldlive.com/gsma/gsma-samsung-team-on-vo...
But it's obviously not for everyone so I can't really recommend it to everyone. And to be honest I can't in good faith recommend any Android phone these days, I hate what Google and other OEMs have done to the ecosystem.
I'm quite bullish on Linux phones though, like the FuriPhone FLX1, the Volla Phone Quintus, and the Jolla C2 - obviously again they're not for everyone, so for normies I would recommend an iPhone, and for techies I'd suggest giving the Linux phones a try (or maybe get a OnePlus/Nothing phone and load LineageOS+Magisk if you don't mind playing the cat-and-mouse game with Play Integrity).
They range from 300 to 1000 EUR. I personally am fond of the "lower end" and slender Xperia 5 and 10 lines and the customary 21:9 screen ratio.
[1] https://developer.sony.com/open-source/aosp-on-xperia-open-d...
The devices with our OEM partner will be Snapdragon flagships with Gunyah rather than pKVM. It should still be able to support the same things. It even has official Windows guest support upstream.
[1] While it might not be an official requirement, being granted a Google apps license will go a whole lot easier if you join the Open Handset Alliance. The OHA is a group of companies committed to Android—Google's Android—and members are contractually prohibited from building non-Google approved devices. That's right, joining the OHA requires a company to sign its life away and promise to not build a device that runs a competing Android fork. Acer was bit by this requirement when it tried to build devices that ran Alibaba's Aliyun OS in China. Aliyun is an Android fork, and when Google got wind of it, Acer was told to shut the project down or lose its access to Google apps. - https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
To me that sounds like devices with GrapheneOS preinstalled is not gonna happen.
7. For a period of three years ending on November 1, 2027, Google may not condition a payment, revenue share, or access to any Google product or service, on an agreement with an original equipment manufacturer (OEM) or carrier to preinstall the Google Play Store on any specific location on an Android device.
8. For a period of three years ending on November 1, 2027, Google may not condition a payment, revenue share, or access to any Google product or service, on an agreement with an OEM or carrier not to preinstall an Android app distribution platform or store other than the Google Play Store.
https://storage.courtlistener.com/recap/gov.uscourts.cand.37...only real benefit to running a pixel
Not a phrase I expected to read, whew. Tough customers.
I've been very happy with several generations of pixels at this point compared to the alternatives.
However the regular pixel or the pro haven't been competitive in several years. This year is particularly bad because it's very close to iPhone price for less storage, less performance, worse battery life, and less easily accessible help (tech support/warranty/repair).
The usual comeback is the the pixel is fast enough so it doesn't matter. And it's kinda true. But it doesn't change the fact that it's poor value, midrange hardware for premium price.
According to one estimate, there are about 250k total GrapheneOS users https://discuss.grapheneos.org/d/12281-how-many-grapheneos-u...
This source claims Google shipped 10 million devices last year https://coolest-gadgets.com/google-pixel-smartphones-statist...
If we generously assume every GrapheneOS user bought a new phone in the last year, 2.5% of those Pixels are running Graphene.
[1] https://discuss.grapheneos.org/d/21946-grapheneos-popularity...
E-waste is bigger problem for me than few security improvements.
Pixel 7a is still good for 2 years and 6 months (until 01 May 2028)
Pixel 8a for 5 years from today (until 01 May 2031).
These are great numbers. I love this project.
It's why 5-7 years of support are one of the requirements our OEM partner has to provide to meet our official list of requirements published at https://grapheneos.org/faq#future-devices. We'd like to require 7 years of support to match Pixels but didn't want to raise the bar too high. We can settle for 5 and have OEMs work towards 7 for later devices after starting with a 5 year commitment.
I am interested in why the LineageOS patches are causing security issues, though. Do you know where I can read more about this?
https://www.kuketz-blog.de/lineageos-weder-sicher-noch-daten... (use browser's or google's translate)
GOS developers have many numerous comments about this, if you google "LineageOS grapheneos" you should also find plenty of them.
GrapheneOS didn’t reveal the name of its new partner, but said that those devices will be priced in the same range as Pixels
Boo
Dual eSIMs when travelling have failed me too many times.
Fairphone 4 and Pixel 6 both launched October 2021. Fairphone 4 has an end-of-life Linux 4.19 kernel which stopped getting LTS updates vs. launching with Linux 5.10 and moving to Linux 6.1. Fairphone 4 is still on Android 13 which is end-of-life soon. Fairphone 4 lacks proper privacy/security patches since it's just getting partial backports to Android 13 which they ship 1-2 months after the official date. OEMs are allowed to ship them up to 3 months before the official date and have at least 1 month early access, so that's a longer delay than it seems. Is the way these devices marketed ethical when considering the lack of privacy, security, long term support and sustainability? Do the claims about fair treatment of workers and fair sourcing of resources have more substance? Is it better or worse than the ethics of an iPhone, which has very efficient per-unit production and far better long term support?
This is the 'ethics' I was referring to.
But also remind me, since you mentioned the iPhone (even though it's completely unrelated) and fair treatment of workers... Wasn't there a series of suicides of workers producing Apple products? To a point where factories had to install netting to catch people falling? https://assets.bwbx.io/images/users/iqjWHBFdfxIU/idXSwvPwl2G...
Also speculating on this issue is quite low priority for me that I didn't want to spend actual brain cycles.
Lastly I do try to find new ways to try and test ChatGPT to see how and when it works.
I arrived at the OnePlus thing not by reading any speculation threads or anything. I was just thinking about it, just 'cuz. Thinking for the love of the game, for enjoyment. I wasn't searching for an answer -- obviously there _isn't_ one, it's all just speculation. So, already, the idea of searching the internet for other people's speculation seems pointless and antithetical the point, which is to think about it for myself.
I _certainly_ didn't think about it from the perspective of "spending actual brain cycles." As far as I know, "brain cycles" is a pretty reductive way of looking at the brain, and is fundamentally wrong in the same way that Trump was when he said that "exercise uses up the body's finite energy:" it's overly protective in a way that results in the exact opposite of what you think you're achieving. To put it more simply: "use it or lose it." I'm not worried about "spending brain cycles" (to the extent that "brain cycles" is an accurate model at all), because thinkin' 'bout stuff is precisely how I get _more_ "brain cycles," not _less_.
Which is all to say: do you seriously engage with all your potential thought avenues from this perspective? Weighing which ones are "low priority," etc? For work/programming/etc, I can understand that to a degree, but for something that can only be classified as "recreational thinking," I just do not get this _at all_.
You said in another comment in this thread that while ChatGPT does something, it frees you up to do something else. What did it free you up for?
To add more context I don't follow the smartphone tech news that closely. If you ask me to name a model that was released within the last 12 months from Sony, Xiaomi, OnePlus and some other makers I wouldn't know where to start. Much less about the differences in their behavior between how open their devices are. From cases where you can't even install LineageOS to cases where you can but without locking the bootloader, up to the pixel devices where you can install GrapheneOS with a locked bootloader.
Educating myself on all those nuances to make an informed speculation about which company could be interested based on past policy looked like more effort that I was willing to commit to. Honestly if LLM's weren't an option I m not sure I would have performed a web search for it, given that for specialized topic you need to dive deep in search results to find what you need.
Instead of spending 5-10 minutes searching and evaluating posts on the internet I got an answer in like 20(?) seconds.
I m surprised you classify that issue as recreational thinking. I was a bit reductive of it myself as I just considered it bad curiosity. That's why I used the word speculation. It's one thing to ask ChatGPT how good a research paper that made the news is without even bothering to read the summary and another thing not to want to evaluate other people's speculations. And I am saying this is speculation, since, to the best of my knowledge, the parties involved are not speaking about this. I think that difference in the classification of this task is one of the key parts why we preferred different actions over this "case/scenario".
I disagree with your brain cycles comment but there is indeed some nuance that both my post and "Trump's" example miss. Mental bandwidth is a thing and is indeed limited. But it's not a static thing. The (not necessarily good) way that I understand it, is like this. It's a muscle that can only do so much at a time. Like a daily budget of mental (or physical) activities. If you use that budget in a good way you can expand it. And if you don't it can decrease. If you try to go over budget, you can also "crush" under the weight of what you are trying to do. For example if I'm playing Starcraft 2 and I am trying to attack in 3 separate places at once I am going to mess things up because I m not that good (unlike the pros). It would have been better if I focused on one location because that's the extent of my capabilities. I can mentally keep track of only so many things while playing SC2. But if I had time to play SC2 > 3 hrs a day and review my games afterward to evaluate my decision making then I could develop that capability within some months (I hope :p - also SC pros do more things than "just" being able to fight simultaneously at 3 separate locations).
I would have guessed HMD, but they just pulled out of the US market: https://www.androidauthority.com/hmd-global-leaves-us-market...
However, Motorola/Lenovo seems the most logical partner, they were previously in the Android One program (which was sort of the successor to the Nexus line).
Some of their Xperia Compact models have been excellent, but they haven't been making them like that in recent years. Dare I hope for a return of their truly compact flagship phones and GrapheneOS support?
[1] https://github.com/chenxiaolong/avbroot/issues/299#issue-232...
As far as I'm aware, their flagship Xperia phones do support bootloader re-locking[1].
The last one I tried (xperia z1 compact) bricked itself when I tried to re-lock the bootloader. Maybe it's safe on newer models?
If they ever make another good compact model, I suppose I should look for re-locking reports on it. Thanks for the link.
Which is, generally, not that good for Linux mainlining. Qualcomm SoCs are "meh" when it comes to mainline Linux support - some parts are there, but a lot of them aren't. It has been getting better for the last bit though?
GrapheneOS didn’t reveal the name of its new partner, but said that those devices will be priced in the same range as Pixels
which means what?
~300€ like the "A" models?
~1000€ like the pro models? both?
I still remember CyanogenMod powering the first OnePlus One as Cyngn Co.
Lineage OS raised from the ashes of CyanogenMod.
On top of this, any ad blocking and "privacy first" project just shutters in pieces when the hardware manufacturer gives you a bunch of binary-only closed-source modules to be stuck into the kernel.
Stop using apps and run Firefox or any other open source browser. That type of privacy can be (almost) achieved that way.
But if your os runs non-auditable binaries directly into the kernel, then it's clear we are talking about dreams, not reality.
There are no closed source components in kernel space for Pixels and won't be for other devices we support either. Hardware and firmware is closed source in practice for all modern computers. Open source doesn't mean something is inherently more private or secure. In the case of hardware, you also can't verify it matches the sources in a similar way as software.
Firefox has poor security, but especially on Android where it doesn't implement sandboxing yet let alone site isolation. It has much worse exploit protections and other security protections than Chromium-based browsers.
Using web apps over native apps makes sense for reducing their access but has privacy downsides too such as trusting the servers rather than having signed releases able to provide more meaningful end-to-end encryption. Not everything can be done with web apps, especially in Firefox where there's no WebUSB, etc. as alternatives to installing native apps providing much less access to other things beyond what's required. For example, Firefox can't be used to install GrapheneOS on a device via the easy to use web installer due to lack of WebUSB despite Mozilla coming up with the early version of it as part of FirefoxOS.
I suspect there will be a Pixel 11, maybe a Pixel 12, but that'll be it.
No one buys pixel devices anymore
From the numbers I've read, Pixels are doing just fine: https://www.phonearena.com/news/google-top-five-premium-smar... and https://www.androidcentral.com/phones/google-pixel/google-pi... both claim Pixel sales shot up this very year.
Google will lose maybe one percent of sales on GrapheneOS dropping Pixels, but that's not going to make a dent into their sales figures.
https://security.googleblog.com/2024/10/pixel-proactive-secu...
I don't have all the links to post here but I recall this being a big factor.
Pixel 6 through Pixel 9a are essentially Exynos SoC devices using standard Cortex and Mali cores. Certain components are custom including a Trusty OS TEE and secure core, a separate hardened secure element chip, image processing, TPU for neural network acceleration, etc. Tensor was mostly standard Exynos. Pixel 10 moved away from Exynos other than the cellular radio chip, but it's not clear if that is good or bad for security. It gives them more independence, choices and control to an extent but they largely licensed the IP for the components and it's not necessarily more secure. Perhaps PowerVR GPUs have better security than Mali, but that's unclear. It does appear they got GPU virtualization support through it, but Qualcomm cares a lot about virtualization too especially since they support laptops with Windows, etc.
I believe you're right that the idea is for people to download the apps they want (from wherever they choose). GrapheneOS has a complicated history with F-Droid though. Unfortunately, unless their approach was different in a lot of significant ways, it is unlikely GrapheneOS will include F-Droid in their Apps app repository.
Even the cameras are starting to fall behind.
I had a pixel, and it just stopped working out of nowhere. I just can't justify spending 800$+ on a phone with mid-range hardware at best Yes their software is the best, but with such hardware it just can't compensate anymore.
I don't think I will be able to wait til GrapheneOS announces their new supported phones, probably will pick up a OnePlus with battery life that doesn't suck.
I am still very surprised that any OEM is willing to commit to monthly security updates and OS upgrades for a minimum of possibly five years. I think it would be a good thing for GrapheneOS to have more than one partnership in future for the Android ecosystem as a whole.