That table shows you what all other players finished at. i.e 17 other people made it to 3 letters, and 2 people got stuck on the original word (7 letters)
> I kinda wish I had a chance with some of the other reductions
New puzzle every day!
I thought about making previous puzzles available, but I've decided we've got enough things on the internet trying to hold our attention as long as possible, and that isn't my goal here.
It's not very interesting technically. Standard nextjs / react webstack.
Most of the fun to be had here was in writing the puzzle generation algorithm.
I don't interact with Graphene or any of their folks at all; I'm just a distant observer like most folks here.
Still, I can't help but think that Graphene seems to want to complain about everything and anything that doesn't fit their niche use case. (As much as it seems beloved here, people that flash custom Android OSs are the very definition of niche users.)
My personal attitude to Graphene seems to get a bit more negative with each one of these "rants" and I doubt I'd go far out of my way to help them, even if I had exposure to them.
> that Graphene seems to want to complain about everything and anything that doesn't fit their niche use case
What would you want them to complain about instead? Of course they'll complain about that, just like Googlers will complain about things affecting their stock price, no one is surprised that people care about stuff they're personally involved in, it makes a lot of sense.
Now if these complaints weren't accurate, then I'd walk with you and feel a bit more negative with each piece. But the ones I've looked into, have been spot on, so who cares if it's for their specific niche? I expect them to care about their niche, that's why those people all work together in that organization in the first place.
> As much as it seems beloved here, people that flash custom Android OSs are the very definition of niche users.
Hmm... Let's try reframing this: "as much as it seems beloved here, people that install their own operating systems on PCs are the very definition of niche users"
I'm absolutely certain that's how IBM felt before the clones. But the ability to install what they wanted on a defacto standard platform is what launched the computing revolution. I think we'd still be living in a sterile monopolistic environment with $10k compilers otherwise.
Folks installing their own ROMs on phones are only niche because they've been pushed out at every opportunity using locked bootloaders, embedded security processors, factory installed secret keys, etc.
Despite all that, there's still thriving communities developing and using custom ROMs on their phones. That demonstrates more than niche demand.
> Hmm... Let's try reframing this: "as much as it seems beloved here, people that install their own operating systems on PCs are the very definition of niche users"
I mean yeah, 99% of people never installed an OS and never will, what's your point here?
> 99% of people never installed an OS and never will, what's your point here?
That the 1% who do build visicalc, Linux, the internet, Google, and every application and innovation that happens outside the corporate wall. The entire ecosystem everyone else ends up using.
And that calling that niche is ridiculous, shortsighted, and shooting oneself as a platform owner in the foot.
What are you talking about? You're making zero sense. I've been in the niche of modifying and installing my own ROMs, then to kernels, and now doing the same things commercially.
It is a niche, it always was. There was never a mass community of users, the most installs you used to see on any given AOSP based project is maybe 20-30K for the most popular devices like Redmis, Pocos or Google Nexus phones.
It's still a niche, and things that users do and used to do to their phones are fundamentally incompatible with Android's security model. Root access, magisk, xposed, overall zero or near zero security validation from the security perspective on all ROMs but Graphene (maybe some others, I haven't followed the sphere for a while).
Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC.
Kinda sounds like you might be younger and didn't live through the 8bit micro -> PC transition. Standardization of the platform led to a cambrian explosion.
> Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC.
Couple of things here. Android was never that open to begin with. There were always (and still going) issues with the kernel sources being withheld indefinitely, AOSP side changes are almost never released at all, iirc only Google released anything. Bootloaders were always an issue, not all manufacturers had unlockable (or easily unlockable) bootloaders.
Ironically, Google were always the spearhead of the standartization in the Android world. Project Treble and stuff resulted in the fact that almost any Android device released these days can run a generic Android image, it's not gonna be as functional as the original Android, but it's something.
Yes, I am on the younger side, that's why I know how it was in the Android world. Nobody is interested in reinstalling OS-es on their phones because the amount of effort to create an Android ISO that's as usable as what's preinstalled is truly gigantic. Android flavours are heavily customized for the needs of the OEM, and for the hardware that they're gonna run on.
It's a niche, always was and always will be. A niche powered by a few large players like LOS or GOS, that actually get paid somehow or heavily work for the idea, and an army of teenage unpaid maintainers, who quit the maintainership as soon as they get a properly paying job that takes most of their time (me).
> Nobody is interested in reinstalling OS-es on their phones because the amount of effort to create an Android ISO that's as usable as what's preinstalled is truly gigantic.
It's pretty clear that you have an extremely limited exposure to the custom Android development space, since you never rebutted any of the points I brought up. Custom android was never easy and never will be. And it's fundamentally incompatible with the concept of having a truly secure env on your device (same as in the PC space, ironically enough).
Son, I've been building and installing custom roms since the HTC Dream, was involved in OpenMoko, and have owned nearly every open or Linux-running phone of the last 30 years back to the Sharp Zaurus and iPaqs.
Your custom rom experience sits wholly within a larger category of computer systems experience about which I've been speaking.
The sort of fragmentation you describe is a symptom, not a foregone conclusion.
Perhaps they complain because that's literally the only way to get Google to take notice?
Let's be real, AOSP doesn't exist any more. Google have closed down nearly everything. All the development happens in private, you've stopped addressing bugs raised by the public, the source of patches are only infrequently released, device trees are gone.
All the development happens in private, you've stopped addressing bugs raised by the public, the source of patches are only infrequently released, device trees are gone.
To emphasize this point a bit more: only "QPR0" (major release) and QPR3 are released as part of AOSP. QPR1 and QPR3 are not released at all anymore, but contain fixes for vulnerabilities that are not marked high/critical (so don't end up in ASB). It is not clear to me whether OEMs get access to QPR1 and QPR3, but Google are not only witholding features, but also a set of security fixes.
Besides that, they are torpedoing other systems through Play Integrity.
IMO it would be best if AOSP was spun off from Google into its own org that actually cares about developing an open source system for others (both open source systems like GrapheneOS/Lineage and commercial vendors like Samsung) and that would have an attestation system that is open to vendors that have good device security.
You might not like their style of speech, at least they care about their users. Maybe Google uses nice flowery language that makes the reader feel nice—IDC—actions speak louder than words.
Stock Pixel is an awful experience. So many useless notifications, popups, ads, privacy not by default.
Company: "We care about your privacy" meanwhile 1400 corporations they share data with
GrapheneOS: "There's zero telemetry in GrapheneOS"
The more you read the more you realize they are nearly always correct.
> Stock Pixel is an awful experience. So many useless notifications, popups, ads, privacy not by default.
Huh? What pixel are you on? You only get notifications from stuff you install after the initial setup is done. And even then you can outright mute applications, completely.
I was on stock recent pixel A17 for a few hours before flashing GrapheneOS. They took over the power button for Gemini, there's gemini in Messages, there's 50 apps you don't need. Yeah you can disable notifications but it was constantly giving tips and tricks and other bullshit. The OS feels super bloated compared to GrapheneOS.
I hate the power button change myself, but 1. It was turned into the Assistant button by default for many years now. 2. Can be switched back easily in settings.
> there's 50 apps you don't need
Where are you getting your pixels? Mine came with all the essentials, I don't remember disabling anything in particular. No game demos, no preloaded meta cancer, just the normal google suite.
> The OS feels super bloated compared to GrapheneOS.
When was that ever not the case? When was a stock OS lighter than a custom flavour on any phone? You can't ship Android in the state that custom OS-es do, you won't pass the certification to get Google's goodies like OTA service and preinstalled play store. Don't quite get the Gemini argument either. You're buying a Gemini phone that touts AI everywhere on its promotional page. What do you expect?
If they're just some "niche use case" then why would Motorola partner with them? The way they see it,
> By combining GrapheneOS’s pioneering engineering with Motorola’s decades of security expertise, real‑world user insights, and Lenovo’s ThinkShield solutions, the collaboration will advance a new generation of privacy and security technologies. In the coming months, Motorola and the GrapheneOS Foundation will continue to collaborate on joint research, software enhancements, and new security capabilities, with more details and solutions to roll out as the partnership evolves.
They’re the second largest manufacturer of Android smartphones in the US, and 10% of the global market. Seems a bit unreasonable to dismiss them out of hand on that basis.
I think that's a worthwhile point to consider but it's only relevant if we move the goalposts from "GrapheneOS is only used by Android ROM enthusiasts" to "GrapheneOS is only supported by one small Android phone manufacturer".
To be frank, though, I don't see any of this line of reasoning as relevant; it's just appeals to greater authorities on either end. If AOSP is only for manufacturers there's really no reason for it to be open source in the first place. And then folks who care about actually improving security end-to-end outside of whatever's convenient to implement by those beholden to the quarterly profit metrics are up a creek.
Personally, if this whole GrapheneOS/Motorola thing doesn't improve the state of the ecosystem I'm going back to Apple or whatever other manufacturer makes it clear they take security seriously.
Even in the EU spyware use is prevalent (and i 'd guess everywhere else in the world). There have been many scandals of government authorized commercial spyware been deployed against journalists. Is it really that niche a mobile OS that tries to not be exploitable by them?
GrapheneOS have mentioned wanting to expand the logging/intrusion detection capabilities of their Auditor app but contend with the need to include it as a system app which is against their philosophy (PoLP). It is not accurate to say they don't want to do anything about spyware.
They are also completely against Play Integrity as implemented on principle.
Also your argument about a user inspecting and editing application files feels like a strawman argument. For example many spyware use malicious links to infect the devices, not malicious apps.
Let's say I want to secure my system against an app developer deciding to delete my data stored in their app.
To do that, I wish to store a copy of all the files the app has written to my filesystem, and put that copy outside the app's control. This is explicitly to contain data the app's developer does not WANT me to be able to keep.
A. Is my being unable to do this "more secure"? If so, why is the specific threat I described to my data integrity - an app developer deleting my data - invalid?
B. Does GrapheneOS support this protection, ensuring the device owner is secure against the app developer, or do they instead secure the app developer against the user?
I want to install an app now, and protect against its developer doing a rugpull on my local files later. I do not want to need to review each new app version in advance as I install it.
This is clearly a legitimate case where what the Android security model says I should be permitted to do makes me less secure against an attack by the app developer.
So other projects are not supposed to critize Google? Graphene's focus is on security and they complain about lack of security in your products. Seems valid to me.
Also security and using non-Google OS are not niche usecases. I'm not sure how you are working on Android, the most popular OS while claiming security is a niche usecase. In fact, I have less confidence in security of your work.
Thankfully the project doesn't care about your personal attitude. That "niche use case" literally saves lives in countries where saying the wrong thing can put you to death. Since when is calling something out a rant?
In a world where economics makes security hardly a secondary concern, a situation exploited by both the intelligence and surveillance broker sectors, dogmatic sanctimony for high security is a feature and not a bug.
This doesn't read as a rant to me, but as calm and factual, regarding a genuine security regression that merits public attention. What is your interest in mischaracterizing it?
Could you please explain why supporting MTE/potentially EMTE in production as a goal represents a niche use case? Isn't mitigating memory corruption issues a mainstream ideal? How else would you propose to do it?
> people that flash custom Android OSs are the very definition of niche users.
This is a mischaracterization. The niche isn't Android hobbyists, it's people with what should be a basic expectation for privacy. I wouldn't flash GOS or any other OS if I could safely avoid it.
Maybe if Google did not shove their spyware down people's throats and actually allowed users control of their phones, there wouldn't be a need for projects like Graphene and Lineage. Until then, complaints are more than justified.
Security shouldn’t be a niche use case. There’s a constant trickle of CVEs, and spyware vendors are known to abuse these exploits in their software. All this on devices that are reachable in the US through a text or MMS, sent to an easily located 10 digit number that isn’t easily changed. These are devices that people now use for all kinds of sensitive tasks!
Security should be the number one priority, frankly. Graphene has shown that this is possible, and they have tried multiple times to get Google to integrate their work.
... and my opinion becomes more positive with each rant. We'll have to agree to disagree. The only reason I buy Pixels for myself and my family members is because of GrapheneOS, otherwise it would be used out of date hardware for LineageOS or some kind of Linux phone. I am thankful that they are attempting to diversify with Motorola, being entirely Pixel dependent has been a project vulnerability; anytime Google decided to lock down the boot loader, it would have been curtains for the project.
I've never seen them call it "evil". I've seen them debunk CalyxOS security claims as well as criticism of GrapheneOS, and they usually provide some serious reasoning and technical information when they do it. They know what they're talking about.
Don't take it personally. I'm a huge fan of Linux, and GrapheneOS routinely comes here and calls it a huge security liability. And they are right.
Tbf with all the information that has come to light since then Rossmann and FUTO were also not behaving correctly and it was fair from him to deny coming onto their show (where they have also invited fascists before)
I'm not an AOSP engineer, but that was my thought reading GOS's comments: Why be negative toward the people who you want help from?
What help though? Google has closed off AOSP and only does source code drops twice a year. Google has embargoed security patches for three months and only provides them to OEMs of Google-certified Android phones, not other AOSP-based projects. Google stopped providing git trees of kernel sources and instead requires projects to submit a request for a Google drive link for each kernel version that takes up to weeks to process. Google is shutting out open Android systems through Play Integrity.
Google is not helping anymore, over the last 1-2 years they have tried everything to sabotage AOSP-based projects. The only reason that they are not fully closing AOSP is probably because 1.) they would get in hot water with regulators; and 2.) AOSP will probably get forked.
For zsh users who like this idea and don't want to have to worry about anything leaving the device (not to insinuate that Atuin is doing anything below board, I don't think they are) I built my own version of this for myself called raven:
Raven has no sync component, stores your history in a sqlite, and never tries to move data off the device. It has a similar / large overlap in features with Atuin.
Sharing here in case anyone else could benefit from it, it only supports zsh for the moment since that's what I use.
I am happy Atuin user now, but I was initially worried that it would sync my data unless I explicitly disabled that feature. The fact that it's opt-in becomes clear once you read the docs and understand how it works, but it might be worth emphasizing that on the landing page. Currently it says:
Shell history sync
Sync your shell history to all of your machines, wherever they are
this is my only quip with atuin, despite my endorsement in a sibling comment.
this should absolutely be opted-out BY DEFAULT. not defaulted to opt-in.
if you have someone outright cloning your entire project just to skip this opted-in privacy gap feature, it's a good indicator it's an issue to be mindful of!
Opt-in means that the user needs to actively decide to use the feature, it's OFF by default. That's currently the case for atuin (happy user without sync here).
Opt-out would mean the feature would be ON by default and users would need to actively decide NOT to use it.
Understood. I'm actually thinking about a product design for an aarch64-based industrial controller.
I'd want to run all of the machine interfaces directly on Linux, but am interested in using Android for everything user-facing. Could I get away with running Cuttlefish in KVM (on an aarch64 SOC) and get OK performance? I'm thinking that it could be a good way to keep the important stuff isolated.
AOSP platform dev here. (Filesystem) Opinions my own, I don't speak for Google.
Disclaimer: I don't use nextcloud, and have not looked at their app specifically, this is just a surface level observation from my relatively informed perspective.
My take: SAF would work for this use case, as others have already mentioned.
Google Drive does not have the permissions that next cloud claims Google is giving preferential treatment to, and is delivered via the Play store in the same way nextcloud's app is.
As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
SAF is not an option because it is HORRIBLY slow[1][2][3][4][5], which makes it an absolute no-go for any decent cloud synchronization app.
Excerpt from [1]:
> SAF is slow. Every SAF file IO operation takes like 20-30ms because it uses an IPC call. And sometimes you may want to check whether a lot of files exist on the disk and if they do not then create them (or something similar that requires a lot of file operations). It's so slow that even in google example they use hacks to make it faster.
Excerpt from [3]:
> Just to add a new sample for the performance of SAF vs standard File operations:
> […]
> 15 seconds with SAF, 6 milliseconds with native ls ! And there's only 128 files LOL
Wow the resolution to your link [3] is infuriating:
> We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue (...)
It's all possible excuses all at once: "Thank you for your issue, we are working on it. Also we have no intention to work on it and we are closing it, the problem probably doesn't exist anymore anyways, and if you think it does make sure to open a new issue for us to treat it with the same amount of respect".
Reminds me of some bug reports I was looking at for Chromium regarding SVG rendering the other day.
Some of them are almost a decade old and require constant bumps to keep them alive, or filling new issues. Somehow their bot system considers anything more than a year old "probably patched". Their messages read much the same way as that.
This may be true, may have workarounds, and may be solved on later Android versions, but it also is not why Nextcloud says they are avoiding the framework. And Google Drive provides the same functionality using SAF, so I'm not sure it's a problem for this use case.
There are no good workarounds unfortunately and it's definitely not solved on later Android versions. I agree though that the reason that Nextcloud gives is factually incorrect (they say that SAF is for providing files rather than accessing them, which is plain wrong).
From what I understand, you can resolve most issues by making ContentResolver queries yourself once you have URI permissions for a folder, including data like filename, mime type and file size in the query projection. This reduces an NxM number of queries to N, where N is the number of nested directories in the tree and M is the number of files in the directory.
Obviously this should be solved with a better API at the SAF layer.
> As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
The lack of consideration for this point in this thread scares me. The amount of data that can be taken from a device through a permission like this is likely huge and it’s not just about “protecting users from themselves”. I wouldn’t feel safe enabling it for any app, and while syncing all data on the device sounds very useful, it’s a damned if they do, damned if they don’t scenario for Google.
So scary that I don't know how billions of people in the world manage to have the right to use whatever software they want to access "all" the files in the file system of their computers (PC/mac) and that the civilisations have still not yet collapsed...
Google simply needs to add "I'm an adult" functionality to their phones. I know the author of this app and trust them, I know the functionality I want and I accept the risk because I'm a grown adult and can make my own choices.
But why? Just for the odd app that can't be bothered to use the new API?
Even if you trust the app, if there is a vulnerability in there, the Android sandbox provides an additional line of defense. Most apps don't have defenses of their own, the only apps that self-sandbox are web browsers.
Then don't enable it, no need to take away my ability to do so. Granular permissions are good (especially when the app can't reliably know they were refused), providing I have the ultimate control.
> it’s a damned if they do, damned if they don’t scenario for Google.
Did they consider my scenario above - where the app doesn't know it was not granted a permission?
> especially when the app can't reliably know they were refused
That's the problem. Android didn't do this even though it was obviously what is needed. Android apps can easily tell what permissions they have.
I think Google prioritised UX over power and security here. They were presumably scared about people accidentally clicking the "Silently deny" button and then getting confused when the app didn't work. Big missed opportunity.
Let me guess, loan shark apps, or is there something even worse that I wasn't aware of?
(Essentially ransomware that people "voluntarily" install in order to get a predatory loan, often without knowing how it actually operates. If they fail to pay, not only is their phone locked, but the data from it is used to threaten/extort them, from threatening to send their nudes to their contacts to death threats to relatives identified from the data - https://www.welivesecurity.com/en/eset-research/beware-preda...)
Pretty much every game and every social media app asked for full storage access under the guise of "downloading game files" or "allowing our photo picker to work".
Then they got free access to all your photos and their location data and all your documents and downloads. Yes, including those banking statements downloaded as PDFs. Forever. In background. Whenever.
That's the access Nextcloud demands instead of using the API where YOU choose what it can read.
> As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
I understand that great care should be taken when this permission is granted to new apps, but NextCloud is well known and on top of that it is a file management app. If anything, apps like that should have this permission.
If you plan to phase it out completely, then the alternatives have to be good enough, which judging from some of the child comments, they are not. I have never developed for Android (and likely never will, because of stuff like this), so I cannot judge properly.
It's also my understanding that the Google Drive App is just some UI over cloud storage. All the interesting bits like Backup are not handled through it and Google Drive gets preferential treatment for this. Additional permissions are required to emulate such functionality.
SAF is a terrible solution for anyone trying to make a cross-platform app (and if you're not then why are you targeting Android as your one platform?), because it doesn't work with native code.
Totally unrelated question but since we're talking filesystems on Android here, I have been incredibly annoyed that AOSP devs disabled "special" characters ":<>?|* in file names in Android 11[0], probably to achieve compatibility with NTFS/FAT. Unfortunately, not only does this make some (especially older) applications accidentally crash when I want to use, say, a question mark in a file name, I can also no longer sync all my files from my Linux machine to my phone.
Now, there is probably little chance for this to get rolled back entirely. But maybe one could make it an option in the developer settings to allow ext4 filenames like before? Do you see any chance your team could be convinced of such a move? And where would be the appropriate place for me to raise this issue and/or contribute a patch?
AOSP engineer here; I don't have a deep knowledge of the issue at hand as I don't work on the bluetooth part of the OS, but I did just want to call out that GrapheneOS (while a really cool project!) supports ~11 total device types, and changes in AOSP have to keep a much larger context in mind.
I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
> AOSP engineer here; I don't have a deep knowledge of the issue at hand as I don't work on the bluetooth part of the OS, but I did just want to call out that GrapheneOS (while a really cool project!) supports ~11 total device types, and changes in AOSP have to keep a much larger context in mind.
AOSP also only directly supports the phones/tablets we support. We were only talking about 2 of the devices supported by AOSP. Pixels enabling MTE is not connected to other devices. App compatibility is also not an issue because it can be enabled for the base OS with user installed apps excluded until they opt into it. It can be made opt-out in a future target API level (Android 15) and then the opt-out can be removed in the next target API level. This is entirely doable.
> I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
We're not ignoring it. We're talking about the Pixel 8, Pixel 8 Pro and future Pixels. It's a request for Pixels to enable it, not AOSP to enable it for all devices.
> I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
Performance and memory usage are definitely the only blocker to enabling it for the base OS. It would already be enabled if the security team was in charge of these decisions. It's not enabled because they likely have to prove it's fast enough. Our specific recommendation was enabling it in asynchronous mode for all cores for the base OS and user installed apps explicitly opting into it. We do not think it's a good idea to start automatically opting apps into using it until more Android devices support it. Google could require that ARMv9 devices support MTE as a developer option for Android 15 onwards in the CDD in order to make sure developers have it available for testing. App developers can't be expected to have a Pixel so it's unrealistic to have it forced on app developers via target API level until more devs have devices available to test it. We understand all that and what we are pushing for takes that into account.
That table shows you what all other players finished at. i.e 17 other people made it to 3 letters, and 2 people got stuck on the original word (7 letters)
reply