Salta al contenuto principale


Similar to iOS lockdown mode, Android 16's Advanced Protection feature is misguided. It adds security features exclusive to it which require using all of the other features. This prevents people using new security features if they need to avoid 1 feature.

security.googleblog.com/2025/0…

Maronno Winchester reshared this.

in reply to GrapheneOS

Most of the features already existed. The new ones are cloud-based intrusion logging, inactivity reboot (hard-wired to 72 hours), a new mode of USB protection and disabling auto-connect to a small subset of insecure Wi-Fi networks. Production MTE support is also essentially new.
in reply to GrapheneOS

GrapheneOS added locked device auto-reboot in July 2021. We proposed it to Google for Android in January 2024 as part of reporting exploitation by forensic data extraction companies. They implemented several of our other proposals, but not this until iOS added it in October 2024.
in reply to GrapheneOS

Both GrapheneOS and iOS enabled lock device auto-reboot by default, at 18 and 72 hours respectively. It can be set between 10 minutes and 72 hours on GrapheneOS along with having an opt-out. Putting this behind a feature barely anyone will use makes the real world impact minimal.
in reply to GrapheneOS

The Advanced Protection mode support for the ARM Memory Tagging Extension (MTE) is misleading. It won't be using it for the kernel, most of the base OS or 99.999999% of apps. It will only be enabled for certain base OS components and a tiny minority of apps explicitly enabling it.
Questa voce è stata modificata (4 mesi fa)
in reply to GrapheneOS

Certain apps like Molly opt-in to MTE, but this doesn't really do anything since so far Android isn't providing any production MTE support. This tiny minority of apps enabling the feature will finally have it on certain devices for < 0.001% of users using Advanced Protection.
in reply to GrapheneOS

Chrome / Chromium provides a very misleading "V8 Optimizer" toggle which contrary to popular belief does not disable the Just-In-Time compiler and therefore cannot block dynamic code generation. It's not a default JIT disable like iOS lockdown mode or default GrapheneOS.
in reply to GrapheneOS

Chrome's "V8 Optimizer" toggle started out as a JIT toggle. However, Chromium's WebAssembly support currently requires JIT and they quickly crippled the setting in an emergency update. It now only disables the highest 2 tiers of the JIT, so a lot of the security value is missing.
Questa voce è stata modificata (4 mesi fa)
in reply to GrapheneOS

Microsoft implemented a simple WebAssembly interpreter for Microsoft Edge as part of their earlier JIT disable feature. Microsoft submitted their WebAssembly interpreter to Chromium and got it merged after a long time. Chrome / Chromium doesn't use it, maintain it or test it.
in reply to GrapheneOS

Since they aren't maintaining or testing it, other Chromium-based browsers can't use this feature without taking on the responsibility of maintaining it. Google could easily start maintaining it to fix their very misleading "V8 Optimizer" toggle but so far has neglected to do so.
in reply to GrapheneOS

It's entirely possible to provide the new security features standalone and then group them together in a mode enabling all of them, but with the option to disable certain features. That could then show up as a warning that the mode isn't fully enabled. Instead, they copied iOS.
in reply to GrapheneOS

Part of enabling Android's Advanced Protection feature is disallowing users from installing apps from outside of the Play Store. This can currently be bypassed using Android Debug Bridge via developer options, but that's awful for security and they'll likely crack down on it too.
in reply to GrapheneOS

Apps coming from the Play Store doesn't make them trustworthy, safe or secure. Most malware apps on Google Mobile Services devices are installed from the Play Store. Similarly to the Play Integrity API, it's Google reinforcing their monopolies with security as an excuse for it.

Domenico De Treias reshared this.

in reply to GrapheneOS

Google was already blocking competing app stores with their Advanced Protection Program required to properly secure a Google account, but now they're tying Android device security to this. Want proper encryption security via inactivity reboot? You cannot use competing app stores.
in reply to ṫẎℭỚ◎ᾔ ṫ◎ℳ

@TycoonTom It won't negative impact GrapheneOS users since the Advanced Protection feature largely won't be available in GrapheneOS due to not having privileged Google Play services integration. We can provide any of the future useful features tied to it as standalone features. Some of the features will likely be possible to use. It's possible to use their theft protection features automatically locking the device by giving Google Play services basic admin access but we should provide our own.
in reply to GrapheneOS

I totally love the GrapheneOS's Contact Scopes #privacy feature that allows me to grant apps access to specific contacts or groups of contacts rather than granting full access to my entire contacts list. I love having control over contact permissions, and more privacy by limiting the information the apps can access. 👏🏼 :clap_claw: 🏆 You guys are the best👍🏼 #infosec
Questa voce è stata modificata (4 mesi fa)
in reply to GrapheneOS

Google has taken a similar path with the extraordinarily anti-competitive Play Integrity API, which disallows using any hardware or OS not licensing Google Mobile Services (GMS). Licensing GMS forces shipping Google apps with invasive access and limits allowed changes to the OS.
in reply to GrapheneOS

OEMs licensing GMS are blocked from including many features in GrapheneOS. They obviously can't provide sandboxed Google Play, but less obviously can't provide our Storage Scopes, Contact Scopes, Sensors toggle, Network toggle, much broader/better MTE integration and far more.
in reply to GrapheneOS

reading all this makes me so happy I made the switch to your OS last year. Crazy the amount of crap they will do to keep you trapped within there bubble so they can just cash in on data
in reply to GrapheneOS

I hope long term you have/make a plan, because while what you are describing are legally questionable anti-consumer practices, I don't see them being challenged any time soon. It only gets tighter over time with these monopolies.

Wish I had something more positive to say, but you all are great and I wish you the best in your mission o7 ❤

in reply to GrapheneOS

Can one of github.com/k2-fsa TTS projects be helpful?
in reply to GrapheneOS

What is the Advanced Protection Program and why is it required to properly secure a Google account?
in reply to Anselm "Two Sheds" Schüler

@anselmschueler It forces using secure 2-factor authentication (hardware-based 2-factor) and disables easy account recovery through customer support. It makes it much harder to bypass authentication through customer support, so it's quite important for properly protecting an account.
in reply to GrapheneOS

By what method does it block third party app stores? Does it also disable fallback codes?
Questa voce è stata modificata (4 mesi fa)
in reply to Anselm "Two Sheds" Schüler

@anselmschueler It requires having at least 2 dedicated hardware security keys. You can also use the secure element within phones as extra keys. It disables regular backup codes. It does have a legacy way of authorizing one device from another but it requires using one of the security keys and seems to require that both devices have a shared IP address (we have not tested it with IPv6). This is a legacy thing but they still permit it to work around devices missing security key support.
in reply to GrapheneOS

@anselmschueler The interface for authorizing one device from another is g.co/sc. This will go away eventually since it's a significant hole in the system.
in reply to GrapheneOS

Just out of curiosity, do you have any surces for this specific info? Not accusing you I actually just wanna read up on the source I find this one interesting.
in reply to GrapheneOS

@J3317 I have heard that malware from the play store is on the rise as of recently. I only have sideloaded one thing. E-speak, because Google removed it from the store, and i needed it. Everything else on my phone, however, is from play.
in reply to Alexis

@lexipic @J3317 Play Store is a secure way of obtaining legitimate apps, but there are a lot of sketchy apps including outright scams/malware. It's hard to even define malware clearly when so many apps do privacy invasive or other unwanted things including many mainstream apps.
in reply to GrapheneOS

@J3317 that makes a lot more sense. So far, I haven’t gotten anything super funny from the play store, but they always tell you to be aware of what you’re grabbing from there. I do scan my phone every so often, but other than a commentary, a PK that was a children about two years ago, nothing serious has happened on my S 21.
in reply to GrapheneOS

@GrapheneOS, iOS design is shite. IMO, it's a deliberate choice to make the feature unusable for 99.99% of users, whilst still being able to brag about it on every billboard
in reply to GrapheneOS

Apple also implemented a WebAssembly interpreter in iOS 18.4
in reply to GrapheneOS

Is the security win from removing JIT compiler bugs as an attack surface, or is it from preventing exploits from generating machine code? Browser exploits can use JS for their logic, so it isn’t necessary to write the sandbox escape entirely in ROP as might be the case for other exploits.
in reply to GrapheneOS

how about with enterprise policies like DefaultJavaScriptJitSetting=2?
in reply to xyhhx 🔻

@xyhhx Don't know that without doing research. They initially shipped a real JIT toggle and then watered it down to a toggle for the 2 optimizing tiers of the JIT after they realized they were losing WebAssembly support. However, Microsoft had a WebAssembly interpreter which they upstreamed later on. That's upstream now but repeatedly gets broken and has to be fixed over and over. Google isn't using or testing it for Chrome or Chromium. They could use that and fix their JIT toggle...
in reply to GrapheneOS

Did you mean to write "9.9[…]%" or is this a typo of "99.9[…]%"?
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@wmd It won't negative impact GrapheneOS users since the Advanced Protection feature largely won't be available in GrapheneOS due to not having privileged Google Play services integration. We can provide any of the future useful features tied to it as standalone features. Some of the features will likely be possible to use. It's possible to use their theft protection features automatically locking the device by giving Google Play services basic admin access but we should provide our own.
in reply to GrapheneOS

On top of that, all the features have this "data hoarding" stench disguised as "security feature". Oh, we collect all this data to keep you safe. I don't like it because I have trust issues with Google.
in reply to RejZoR

@rejzor The intrusion logging feature is supposedly end-to-end encrypted but there's no clear description of what they mean by that. If it's end-to-end encrypted with a key protected by the device's lock method, that would be good for privacy, but quite bad for being able to recover it and that's likely not what they mean. There's a high chance it's based on the Google account password in which case it's something regularly sent to them as part of logging in so that's hardly proper E2EE.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@SupportGrapheneOS_667 That's for the Google account rather than Gmail specifically, and it has an impact on Android for the stock OS when logged into a Google account. Several of the Android Advanced Protection features are existing Google Advanced Protection features impacting Android including blocking installing apps from outside the Play Store.

It's possible to use other mail clients but they must implement the modern authentication support which likely requires using a WebView for this.

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@SupportGrapheneOS_667 @BucciaBuccia It's something people should use if they have a Google account and it's awful that they tied it to disabling installing apps from other sources on Google Mobile Services Android devices. There's no similar downside to GrapheneOS users enabling it since sandboxed Google Play isn't capable of controlling the OS but rather can only do what sandboxed apps can do.
Unknown parent

mastodon - Collegamento all'originale
Buccia
@SupportGrapheneOS_667 Actually it only works with Apple Mail and Mozilla Thundebird if i recall correctly.
in reply to Buccia

@BucciaBuccia
Never used "Advanced Google Protection" and hopefully never will.
(Thanks for the reply)
in reply to GrapheneOS

@wmd hi, i am blind, does your OS have a screenreader i can turn on during setup to setup and use the OS? Androids screenreader is Talkback
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@J3317 @evilcookies98 @wmd eSpeak NG has restrictive GPLv3 licensing that's not appropriate for GrapheneOS. It also doesn't really meet the robustness or security requirements.

RHVoice doesn't implement Direct Boot support so it can't work Before First Unlock. A text-to-speech implementation can of course be installed on GrapheneOS.

We have our own fork of the open source TalkBack included but there hasn't been a text-to-speech app we can include yet and they also mostly require setup too.

Unknown parent

mastodon - Collegamento all'originale
Joshua
@evilcookies98 @wmd ah, can't they just include espeak or something?
in reply to Joshua

@wmd @J3317 it’s there, but there’s no TTS engine installed out of the box since the Google services don’t come packaged with.
in reply to GrapheneOS

@wmd @J3317 well something needs to be implemented. I know you’re trying to be cautious, but not all of us have somebody we can trust on hand to set up our phones. It just doesn’t work like that. I’m not trying to tell you how to run your business. I’m just saying this is extremely frustrating.
in reply to GrapheneOS

Why don't you offer Google's TTS engine in the GrapheneOS app repository and use that together with TalkBack as the foundation for an easy accessibility setup wizard?
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@evilcookies98 @J3317 @wmd We won't bundle code with more restrictive licensing than GPLv2. It would limit GrapheneOS usage.

We haven't locked anything out. You can use eSpeak NG, RHVoice, Speech Recognition & Synthesis, etc. on GrapheneOS. Only Google's app could provide a good out-of-the-box experience anyway. Neither eSpeak NG or RHVoice is up to the task of providing a robust and usable implementation that's ready to go out-of-the-box for an easy initial setup for someone who depends on it.

in reply to Joshua

@J3317 @wmd that’s still a little frustrating though. It’s possible to be two security conscious to the point where you lock out every text to speech engine ever and severely limit your customer base.
in reply to GrapheneOS

@evilcookies98 @J3317 @wmd We've seen some newer TTS apps in development based on neural networks and might eventually include one of those if they have permissive licensing for both the software and the speech models. RHVoice has appropriate licensing for the software but not the models and lacks Direct Boot support so it isn't capable of being used with TalkBack properly since it won't work Before First Unlock which is important.
in reply to The Evil Chocolate Cookie

@evilcookies98 @wmd @J3317 There are major issues with the open source options both in terms of robustness and usability along with overly restrictive licensing. Google's app is the only one which really meets the requirements but is a closed source implementation.

We've seen some newer apps in development without the same legacy baggage and may be able to include one of them soon. Including one of them does not mean a device will be usable by blind users after flashing/locking though.

in reply to GrapheneOS

@evilcookies98 @wmd @J3317 We would need to integrate it into the setup wizard including support for having it fetch any needed language models, etc. If it requires manually setting it up as eSpeak NG and RHVoice do, then that's not really making things any more accessible. A blind user isn't going to be able to open those apps, download the language models and configure whatever else is required. It needs to be a smoother experience and needs proper integration into the setup wizard.
in reply to Andromxda 🇺🇦🇵🇸🇹🇼

@Andromxda It really needs to be bundled with the OS rather than requiring setting up an internet connection to install it and obtain speech models. That means speech models also need to be bundled with the OS and need to be possible to easily set up as part of the setup wizard workflow. It's not enough to have the app installed, it needs to be possible to easily enable TalkBack and TTS via the setup wizard. Including a default enabled TTS app with an English speech model would be fine.
in reply to GrapheneOS

@Andromxda Requiring custom setup to switch to another language would be fine even long term. Nearly any blind user that's likely use GrapheneOS is going to understand at least enough spoken English to deal with switching the language. We need TTS that's set up and enabled by default for English at the bare minimum. The setup wizard then needs a very easy way to enable TalkBack which can be done by a blind user without help from someone else after initial install or factory reset.
in reply to GrapheneOS

@J3317 @wmd I personally know someone who made a version specifically with direct boot support. I saw it on their website while looking for something else.
in reply to GrapheneOS

Well, the GrapheneOS installation process isn't particularly accessible for visually impaired people anyway, since there is no TTS in the fastboot interface, which is required to unlock and later relock the bootloader. So unless you buy a phone with GrapheneOS preinstalled from a reseller like @nitrokey, you would need help from another person anyway. I don't think entering a Wi-Fi password would be such a big issue. After that, the setup wizard could start the installation of the Google TTS engine via the GrapheneOS App Store by using some kind of IPC mechanism, or an intent, or something like that. The only issue would be the installation dialog of the unprivileged session installer. Perhaps this could also be bypassed by using the privileged setup wizard for the installation, instead of the App Store? Not sure if the unprivileged App Store could update the app later though.
Questa voce è stata modificata (4 mesi fa)
in reply to GrapheneOS

is there not something to be said about fingerprinting, though? Since it’ll likely only be a small set of users who enable these modes in the first place, it would make sense to reduce their device fingerprint by making them look more similar.
in reply to Marty_Man_X

@amazing_truffle Other than browser attack surface reduction, it's really not relevant to fingerprinting. It's a misconception that there's even any point in being concerned about fingerprinting with iOS and Android apps right now. It would require a major shift to supporting running apps in virtual machines with a much stricter approach to fingerprinting to have any hope of deterring that. They already have plenty of other configuration usable for fingerprinting everywhere too.
in reply to GrapheneOS

thanks for the clarification

In this case can’t be sure why these modes on iOS and Android don’t offer more granular control - might be as simple as: they assume most users, even those who’d benefit from these modes, won’t understand the various elements/what they should enable, so they enable all at once in these modes.

Not saying it’s the right approach just trying to understand if there’s some merit to them.

in reply to Marty_Man_X

@amazing_truffle They don't value privacy and security enough to dedicate more of the user interface and settings to them. Enabling it all at once is entirely possible without having it mandatory to use all of it together. We talked about that in the thread. It's entirely possible to have a high security mode which enables a bunch of recommended options while having opt-outs and then having the high security mode UI warn people about the stuff they've opted out of in a prominent dashboard.
Unknown parent

mastodon - Collegamento all'originale
Joshua
@evilcookies98 @darkyen same, i just like being able to turn on a screenreader and go
in reply to Joshua

@J3317 @evilcookies98 @darkyen We're not aware of a TTS app we could include right now due to the need for licensing acceptable for inclusion in GrapheneOS and the need for direct boot support. That means either permissive licensing or GPLv2 for both the code AND the language models. We won't use something with non-commercial usage licensing for the language models, etc. We also won't include GPLv3 software in the base OS, although we're fine with redistributing it in our App Store.
Unknown parent

mastodon - Collegamento all'originale
Joshua
@darkyen @evilcookies98 oh, thanks for explaining that, so if a tts can't run at boot like most cant, it switches to google TTS, or if you have a Samsung phone Samsung tts when you power on your phone
in reply to Joshua

@J3317 @darkyen still though, you're working under the assumption that all of us have someone trustworthy on command to help us set up our phones. Spoiler alerts, we don't. Since there's no way to push an app to the phone at the same time. Things are flashed, we're screwed. I love what you're doing but that is really putting me off of using it. If I can't set up my phone independently, that's a barrier. I don't always have trustworthy people on hand. I would venture a guess that a lot of us don't. I live with at least one Snoop. We're talking someone who would immediately start going through my messages.
in reply to Joshua

@J3317 @evilcookies98 @wmd Direct boot aware apps can run in the time between system boot and first unlock. The app needs to be able to run without an access to (most) of its files, since these are encrypted and need unlocking.

I am not sure what exact implication this has for the usability of screen readers, since I haven't needed one.

in reply to Joshua

@J3317 @wmd they could yes, but there’s the issue of finding a version that has direct boot support. If it doesn’t have direct boot support, it’s kind of useless in this scenario anyway. Honestly, I am very strongly pushing for that. I installed it once on my old phone, but sadly had to remove it because play integrity was screwing up my reading app. Now that I don’t need the reading app, I really want it back, but I’m not prepared to handover my phone to someone. I don’t trust to set it up.
in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen We have our open source fork of TalkBack included so all we need is a permissively licensed text-to-speech implementation including the language models (GPLv2 is permissive enough, GPLv3 is not, but we'd prefer MIT / BSD / Apache 2). We'd then need to integrate it so that it's functional by default and add a way to enable TalkBack in our Setup Wizard. We cannot make a TTS implementation ourselves right now, so unless there's a good one we can use, this is blocked.
in reply to GrapheneOS

@evilcookies98 @darkyen oh, well as for a way to enable talkback the android shortcut is hold both volume buttons for 3 seconds, as for tts can't you just use espeak? i remember hearing there was a version that supports direct boot but don't know where to get it
in reply to GrapheneOS

@evilcookies98 @darkyen i just switched to espeak that i got from gethub and restarted my phone and it came up and espeak was talking
in reply to Joshua

@J3317 @evilcookies98 @darkyen eSpeak NG added Direct Boot support after we requested it but it has GPLv3 licensing so we won't include it in GrapheneOS itself. We want something we can include in the OS and have already set up with working English TTS out-of-the-box as a baseline.
in reply to Joshua

@J3317 @evilcookies98 @darkyen No, since it's GPLv3, and we don't include GPLv3 software in GrapheneOS due to overly strict licensing terms. We don't want GrapheneOS to have stricter licensing terms than the Android Open Source Project. We want GrapheneOS to be usable where AOSP is used as a direct replacement for it.
in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen
Would it be a violation of GPLv3 license, or any other licence to which you currently apply, if you include eSpeak NG?
in reply to desirable_dialogue

@desirable_dialogue @J3317 @evilcookies98 @darkyen It would be a violation of the license in GrapheneOS-based systems without support for unlocking the device. We intend to stick to software that's not more restrictively licensed than the Android Open Source Project in order to avoid GrapheneOS having a narrower use case than AOSP. It's important to us for GrapheneOS to be usable anywhere that AOSP is usable. GPLv2 software is perfectly fine because it doesn't restrict how the OS can be used.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen There are better options than eSpeak NG with the permissive licensing we neeed. Regardless of the choice of the app to fork, there's work involved in forking it and integrating it to work seamlessly out-of-the-box without requiring any setup. There's further work to add TalkBack integration into Setup Wizard.

We're not to blame for a project choosing licensing which is broadly known to be something many companies want to avoid. That choice limits usage.

in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen ... so then include espeak and distribute a separate build that omits GPLv3 components like espeak for the AOSP drop-in usecase?
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@joepie91 @J3317 @evilcookies98 @darkyen Better options for a starting point existing doesn't mean we can simply drop it into GrapheneOS as a bundled app right now. That also wouldn't solve any problem without changing the app to have everything required built-in and already configured to work from the moment a fresh install is booted. We could then add a shortcut to the setup wizard for enabling TalkBack. It doesn't do any good if the app doesn't have a seamless auto-configured experience.
in reply to GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen github.com/k2-fsa/sherpa-onnx is an example of a permissively licensed and more modern implementation. We have not reviewed it in depth and far away from being able to bundle a fork of it into the OS. All we know is that it's what many of our users recommend we use when this is brought up.

It also supports speech-to-text in addition to text-to-speech and various other functionality. It's more like Google's speech services app. Doesn't mean it's ready to ship.

in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen Better options such as? And didn't you say two posts ago in this thread that "unless there's a good one we can use, this is blocked", implying that there isn't one?
in reply to GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen If we include this, there are other people who are going to be very angry about it because it's based on neural networks.

bsky.app/profile/stopgenai.com…

bsky.app/profile/stopgenai.com…

This is how modern speech-to-text, text-to-speech, translation, automatic captions, etc. are all implemented. If we tied our hands and refused to use anything using neural networks, we wouldn't be realistically ever able to include speech-to-text, translation, captions, etc.

in reply to GrapheneOS

@darkyen @joepie91 @J3317 maybe listen to the people who actually need this instead of your own idealistic tendencies. I’m not going to back off. I’m going to give you hell until you recognize you’re being awfully exclusionary just because the solution isn’t something you like. I’m not backing down. It’s there, it’s viable, it’s packaged into a nice little IPK, and you are rejecting it. That’s a you problem, not an ass problem. If you don’t stop turning up your nose at working solutions, you’re going to find yourself in a nasty situation because I will take to every platform on the net to let everyone know exactly what you’re doing and why you’re doing it. You’re making excuses. If you’re not going to develop for everyone, then don’t develop at all.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen

> There is already a viable system which can be implemented today, as has been presented to you by someone *who actually uses these accessibility tools*, which is espeak.

No, a dozen people who depend on text-to-speech to use their devices have told us they cannot possibly get by with eSpeak NG as their text-to-speech implementation. They would use it to get from the start of the setup wizard to installing a proper TTS app. We want a decent feature.

in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen There are, to my knowledge, exactly *zero* models in the LLM/GenAI space that are actually open-source by any reasonable definition, and there's good reason to believe that they can't ever be (because this amount of training data is virtually impossible to ethically source), so the idea of this kind of model as an open-source solution is essentially vaporware.

There is already a viable system which can be implemented today, as has been presented to you by someone *who actually uses these accessibility tools*, which is espeak.

in reply to GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen eSpeak NG does not use a license we can use in GrapheneOS. Unless you convince every contributor to the eSpeak NG code to relicense their code as GPLv2 or a more permissive license, we can't use it. GrapheneOS is not going to become more restrictively licensed from AOSP. There are people who actually support our project and help us keep it going who care about this. We're not throwing away a large set of use cases and support for us by including GPLv3.
in reply to GrapheneOS

@joepie91 @darkyen @J3317 why not just admit that you don’t actually give a crap? If you did, you’d realize what we’re trying to tell you. If we want something better will install it on our own later, but we need something that is there to get the darn phone through set up. Nobody said they would have to use it all the darn time. Your willfully ignoring us.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@joepie91 @J3317 @evilcookies98 @darkyen We currently support 16 devices. Building for each device takes around 45 minutes. More importantly, testing each build including the future upgrade path takes a long time. It is not feasible to start making multiple builds of the OS. This is also not the only case where people are suggesting making multiple builds. People also want that for multiple other things. It is not actually a realistic solution. It would take an extreme increase in resources.
in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen I have literally suggested a solution for this several posts up, that would absolutely work.

"Do not want to do this" is a very different thing from "cannot do this".

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen You should check back on the article you spread and attacked us over. The person who published it retracted it and apologized to us for approaching it that way. They want to help us integrate and test something that is acceptable for us to ship instead.

The app which multiple people have recommended to us is github.com/k2-fsa/sherpa-onnx. We would still need to review it, fork it and integrate it to have a seamless out-of-the-box auto-configured experience.

Unknown parent

mastodon - Collegamento all'originale
Sven Slootweg (soft-deprecated)
@J3317 @evilcookies98 @darkyen (Which, incidentally, is *exactly* what the original complaint was about.)
in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen That is just a lot of words to say "we do not want to do this, we do not think that accessibility is worth doing this".
in reply to Sven Slootweg (soft-deprecated)

@joepie91 @J3317 @evilcookies98 @darkyen No, it's not at all. What we're going to do is review, fork and integrate a permissively licensed text-to-speech and speech-to-text implementation. We're not going to double the amount of builds we have to make, which already takes far too long and has required significant changes to the house where most of the builds are done to accommodate the heat, power usage and network transfers. Doubling the number of releases to build and test is not reasonable.
in reply to GrapheneOS

@J3317 @joepie91 @darkyen no one is asking you to build the darn engine from scratch people. There’s an APK already made. I have it. It exists. If you would do your homework, you would know that. Maybe if you don’t have the resources, tell people to quit working on the shiny stuff for a while.
in reply to The Evil Chocolate Cookie

@evilcookies98 @J3317 @joepie91 @darkyen What shiny stuff? We're working on keeping GrapheneOS alive despite having our lead developer forcibly conscripted to fight in a war. Our entire focus has been on Android 16 porting for weeks. The only things we've shipped recently are minor features implemented weeks or months ago which were sitting as open pull requests which hadn't been fully reviewed and tested yet.

We don't even have a real boot animation since our focus is so much on the core OS.

in reply to GrapheneOS

@J3317 @joepie91 @darkyen people, get your priorities straight. Locking people out is more important than any shiny update out. There will ever be. How was that so hard to understand? I swear if I knocked on some heads, they would ring Hollow.
in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen As I have brought up before, that system appears to be based on LLM/GenAI tech and models, which means it cannot ever be open-source.

And what the author of the article decides to do frankly has no bearing on my arguments here. You are still presenting "do not want to do" as "cannot do", which are two very different things.

in reply to Sven Slootweg (soft-deprecated)

@joepie91 @J3317 @evilcookies98 @darkyen

Proposing building and testing twice as many releases as the solution to anything where we cannot do both things at once in the same builds is something we regularly see about multiple topics including root access. It's not something realistic. It would require an enormous amount of resources.

16 separate 45 minute OS builds followed by a long release signing process and then delta generation from previous releases is already a huge amount to be doing.

in reply to GrapheneOS

@joepie91 @J3317 @darkyen here’s what you’re saying. We don’t want to do this because we’d rather work on the shiny stuff. We don’t care if people are mad at us and get left out and have to potentially expose their personal information to someone. They don’t trust just so long as we can get the shiny stuff done.
in reply to GrapheneOS

@joepie91 @evilcookies98 @darkyen is that really a bad thing though?, give us some thing, any TTS just to get setup and once setup we can install a TTS that we like
in reply to The Evil Chocolate Cookie

@evilcookies98 @joepie91 @J3317 @darkyen We're not working on shiny stuff. We're working on keeping what we have now from substantially degrading. We're primarily working on porting to Android 16 so we can continue providing the latest privacy and security updates for GrapheneOS. We're also trying to fix a bunch of different types of regressions including regressed app compatibility from recently added anti-competitive checks for Play Store installation. We have our hands full not adding more.
in reply to GrapheneOS

@evilcookies98 @joepie91 @J3317 @darkyen What shiny stuff do you think we're adding or working on? When have we ever been focused on things like aesthetics or trivial frills? Our focus is consistently on important things. After Android 16, we also need to get several additional non-DNS-related Android VPN leak fixes we've implemented shipped, which we consider high priority but haven't had time to get fully finished and especially fully tested. Many of our users consider that very critical.
in reply to GrapheneOS

@J3317 @darkyen @joepie91 anything that is such a huge priority that it’s worth leaving people literally locked out over is shiny stuff. I tried to be patient with you back in the winter when there was genuinely nothing you could do, but now you can and won’t. We are asking you to bundle an app, not write 10 million lines of code.
in reply to GrapheneOS

@darkyen @joepie91 @J3317 i’ve done some research on this. All you would have to do is put it in the darn package so it would be installed. It doesn’t have to run at the system level. Most of the third-party engines are just regular apps. We installed them, they run. if you can bundle a bunch of fancy stuff that doesn’t even make sense, then you can bundle a TTS engine. You’re ignoring us.
in reply to Joshua

@J3317 @joepie91 @evilcookies98 @darkyen We are going to provide TTS built into GrapheneOS. It's going to be one which meets our licensing requirements. It's going to require us to fork a TTS app and modify it to work for this use case. We're then going to need to integrate our TalkBack fork into the setup wizard. This will require significant work overall. We're currently down our most productive developer and struggling to keep above water by keeping things working and keeping up with updates.
in reply to The Evil Chocolate Cookie

@evilcookies98 @J3317 @darkyen @joepie91 You're asking us to significantly change the licensing for GrapheneOS in a way that we've committed to not doing. eSpeak NG would still need significant changes to turn it into what we would need for a seamless experience. There are other apps available and we are not locked into using any particular one. There are at least around 6 options, most permissively licensed, so we're not going to be using the GPLv3 one. We use GPLv3 outside the OS, not in it.
in reply to GrapheneOS

@joepie91 @darkyen @J3317 i’ve heard that line before. That’s the classic shut up and we’ll deal with you when we feel like it phrase. No, you are being discriminatory, and you’re doing it willingly. Nothing is of such a high priority that it needs to be pushed ahead of the people you were literally locking out. since it doesn’t look like you’re going to listen to those of us who use these things and actually know what we need, looks like I need to take to the video, and Facebook, and literally everywhere else. You’re really gonna have a resource problem then because once people find out you’re willingly leaving us in the dark, you’re going to be sunk. I’m not even trying to be rude here. I’m just telling you that once people know what kind of behavior is going on here under excuses, they’re going to lose respect for you.
in reply to Joshua

@J3317 @joepie91 @evilcookies98 @darkyen Our lead developer for the past couple years was forcibly conscripted into the Ukrainian army due to the ongoing war. They were the one doing 90% of our recent ports to new quarterly and yearly releases. We're very worried about the port to Android 16 we need to do in June and have therefore hardly done anything in May beyond preparing for the port. We don't have early access to A16 because no OEM provided it. That is what we're dealing with right now.
in reply to GrapheneOS

@J3317 @joepie91 @darkyen are you seriously going to act like no one else on your team knows how to put an app in the package? It’s not like you have to rewrite the darn S from scratch. Talk back to his engine bundled, talkback uses engine, problem solved.
in reply to The Evil Chocolate Cookie

@evilcookies98 @joepie91 @darkyen @J3317 We've done significant work on this area including maintaining a fork of the open source TalkBack with significant improvements. We wrote a new Setup Wizard with the goal of making multiple things easier to add including TalkBack integration and device owner integration for enterprise use. Neither has been implemented yet, but we laid the groundwork for it. It often takes us a long time to finish features, that's not specific to this at all.
in reply to GrapheneOS

@evilcookies98 @joepie91 @darkyen @J3317 GrapheneOS had text-to-speech support at launch in 2014 because AOSP provided SVOX Pico TTS. Google had replaced it with their proprietary Google TTS app long before we started GrapheneOS. SVOX Pico was unmaintained, turned into a security nightmare and so they removed it from AOSP. They didn't provide any replacement, they just removed the requirement to have TTS to pass the CTS. That is why we don't have TTS bundled with the OS anymore as we used to.
in reply to GrapheneOS

@joepie91 @evilcookies98 @darkyen ah, ok, mabey you should have figgured out this TTS stuff and making talkback work right from the start, then you wouldn't be having to worry about it now, i'm sorry your main dev is having to fight in the war
in reply to GrapheneOS

@joepie91 @J3317 @darkyen you haven’t even listened to a word we’ve said this entire conversation. We need equal access 5 million years ago, not when you feel like it.
in reply to Joshua

@J3317 @joepie91 @evilcookies98 @darkyen GrapheneOS used to have TTS support: the SVOX Pico implementation dating back to Android 1.6. Google replaced it with their proprietary TTS app. SVOX Pico was completely unmaintained and ended up having severe security flaws. They fixed a few rounds of those security flaws, then dropped it from AOSP instead of fixing more of them. This was something like 8 or 9 years ago. Google dropped TTS as a baseline requirement from the CTS as part of this.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@evilcookies98 @J3317 @joepie91 @darkyen No, the app needs to be forked to work out-of-the-box without configuration. In order for us to use an app, it needs to be something meeting the license requirements. We also need to integrate enabling the screen reader we provide into the setup wizard.

Since this will be enabled by default and handling untrusted input, the security is important.

We're responsible for keeping our users safe and upholding the standards we have committed to providing.

in reply to GrapheneOS

@darkyen @J3317 @joepie91 you have an open source engine right there in front of you, and you’re refusing it because you’re being petty and don’t like the license. If you did that to a regular user and refused to install something because you didn’t like the shape of the icon, then go ballistic you’d fix it, but since it’s an accessibility service that you don’t consider priority, it’s optional.
in reply to The Evil Chocolate Cookie

@evilcookies98 @darkyen @J3317 @joepie91 It is not us being petty. We have license requirements which we are committed to following. There would be serious consequences to us breaking that commitment.

eSpeak NG is not the only open source TTS app.

Regardless of which app we use, we'll make it work at first boot after installation without downloading any language packs, without configuring anything, etc. We need to add setup wizard screen reader integration. We have been working towards it.

in reply to GrapheneOS

@darkyen @J3317 @joepie91 when you reject something that would actually help your users because the license isn’t up to your perfectionist standards, that’s absolutely being petty. That’s like dumping a girl because she has brown hair instead of black. It’s shallow and superficial and ridiculous.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@evilcookies98 @J3317 @darkyen @joepie91 In order for it to be available, it has to be built into the OS. In order to build it into the OS, it has to use the licensing we have committed to using. This is not about idealism, it is about what we need in order to continue GrapheneOS development.

eSpeak NG is not the only open source TTS app. There are multiple apps in the running for being chosen to fork for this purpose. It isn't one of them due to the license, but several others are.

in reply to The Evil Chocolate Cookie

@evilcookies98 @darkyen @J3317 @joepie91 This doesn't have to do with perfectionist standards. We've made a commitment to not using GPLv3 licensing.

Bundling the eSpeak NG APK into GrapheneOS will not providing the accessible experience from the start of the setup wizard you want us to provide. It would only mean it doesn't have to be installed. There is significantly more to making it into a seamless thing which works out-of-the-box including activating TalkBack on the first setup wizard page.

in reply to GrapheneOS

@evilcookies98 @darkyen @J3317 @joepie91 There are multiple open source TTS apps available. We're going to evaluate them and choose the best one for us to use. We're going to make a fork of that, change the app id, review the overall app code and the attack surface, etc. We need to modify the app to provide a seamless auto-configured experience without needing to download a language pack. We need to add TalkBack integration to the Setup Wizard. We have been working towards it.
in reply to GrapheneOS

@darkyen @J3317 @joepie91 there’s already a shortcut. It’s been hardcoded in for ages. How do I know this? Because even Samsung hasn’t managed to fuck it up yet, and they fucked up all kinds of talkback related stuff. I have handled several different android phones. Hold down both volume keys, chatter box. All it needs is the engine. All we need is for you to stop being stubborn, give us an engine, and if we don’t like it, we can replace it. That’s what we do every single day with the Google engine. Not many people like it. We install something else over top of it.
in reply to GrapheneOS

@evilcookies98 @darkyen @joepie91 hold on, so as it is right now you can't even turn on talkback at the setup screan? dam that's bad, i know a blind guy that got graphene installed but most of uss just arn't as smart as him
in reply to GrapheneOS

@evilcookies98 @darkyen @J3317 @joepie91 The reason we made our TalkBack fork is as part of working towards providing this. The TalkBack fork has been getting tested and some major issues with it got resolved.

It often takes us a long time to get features finished. We had no network location included in GrapheneOS from 2014 until late 2024.

It is a non-profit open source project. We accept external contributions and most people we've hired started as external contributors to the project.

in reply to Joshua

@J3317 @evilcookies98 @darkyen @joepie91 We've been missing a TTS engine since after SVOX Pico was removed from the Android Open Source Project alongside them dropping the requirement to have TTS in order to keep AOSP passing the Compatibility Test Suite. This is from before the time of the currently available TTS apps.

It would have been possible to fork SVOX Pico and overhaul it to fix the memory corruption, etc. but that didn't happen. Back then we also had literally 1 developer.

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@J3317 @evilcookies98 @darkyen @joepie91 Google Mobile Services devices all use the standard Google setup wizard integrated into their setup wizard. We made a setup wizard from scratch. There isn't an AOSP setup wizard.
in reply to GrapheneOS

@J3317 @joepie91 @darkyen I know someone who has seen your set up wizard. There’s an accessibility options button right there, so don’t tell me it doesn’t exist.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@evilcookies98 @J3317 @darkyen @joepie91

> you don’t like the license

No, that's not it. It is not about disliking it. We do not have an issue with GPLv3 in general. It's only including GPLv3 code in GrapheneOS that's a problem. We could package the app in our App Store but that isn't going to help with this. We need something built into the OS.

in reply to Joshua

@J3317 @joepie91 @darkyen yeah, that sucks, it really does. At the same time, if you can bundle a bunch of fancy crap that doesn’t even make sense and that nobody can guess the function of because it’s name something out of a Star Trek film, you can take 25 seconds to do five clicks and bundle of TTS engine. it’s basically just a process you have to do every time you release the thing anyway, and yet you’re refusing to help us because you don’t like the license.
in reply to Joshua

@J3317 @darkyen @joepie91 you’re not hearing us. This is not something you can just get to when you feel like it. You have an option. It’s your own idealism that is making you refuse it. You’ve got that web tool. Checkbox exist. If everybody doesn’t want it, that’s what checkboxes are for, but give it to the people who need it and stop making excuses. Since you’re not going to hear me, I guess the rest of the world gets too. It’s time to make a video.
in reply to The Evil Chocolate Cookie

@evilcookies98 @darkyen @joepie91 exactly, for example when i finished setting up my Samsung i installed a different TTS, i don't mind the samsung one but i wanted something different so i got it
in reply to GrapheneOS

@evilcookies98 @joepie91 @darkyen ok, still, i can go on litterly any android phone, turn on talkback at setup, have speech and most of the time be good to go
in reply to Joshua

@J3317 @darkyen @joepie91 I despise Samantha compact on the iPhone and Google TTS, but they get me through set up. Once again, can’t versus won’t. You can’t install nuance vocalizer because we have to purchase the voices before it can work. You won’t bundle Espeak because you don’t like the license.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@J3317 @evilcookies98 @joepie91 @darkyen We used to have SVOX Pico TTS which was incredibly primitive / awful but it was removed from AOSP due to severe security flaws they didn't want to address. It would be theoretically possible to revive that, port it to modern Android and fix the memory corruption but forking an actively developed permissively licensed TTS app is a lot easier.
Unknown parent

mastodon - Collegamento all'originale
Joshua
@evilcookies98 @joepie91 @darkyen don't know what your talking about but i would use it too, litterly any voice is better then no voice at all
Unknown parent

mastodon - Collegamento all'originale
The Evil Chocolate Cookie
@J3317 @joepie91 @darkyen I would use that old voice from the 80s braille note takers. Just do it.
in reply to Joshua

@J3317 @evilcookies98 @joepie91 @darkyen Yes, and those are all Google Mobile Services devices. They can all use Google's full closed source TalkBack implementation and can use Google's speech services app if they don't have their own one.

GrapheneOS doesn't include Google Mobile Services so a bunch of things that provides are missing from what we're starting from and we've had to gradually implement them ourselves.

What we're starting from has no setup wizard, no update app, etc.

in reply to GrapheneOS

@evilcookies98 @joepie91 @darkyen waway has there own screenreader and TTS on there devices and they don't use google play services just saying
in reply to Joshua

@J3317 @evilcookies98 @joepie91 @darkyen They're a huge company. We currently only have a small team and not enough senior developers to review and merge all of the work that's done. There are a lot of things we don't have. We have a bunch of sample AOSP apps we haven't yet replaced. If SVOX Pico was never removed from AOSP, then we would still have that in GrapheneOS.
in reply to Joshua

@J3317 @evilcookies98 @joepie91 @darkyen

We currently have 3 senior devs, but 1 is fully unavailable to work on the project (war) and one is largely unable to work on development right now. 3rd was on a long sabbatical to deal with a major move between countries. They came back due to the emergency, but they were not up to speed on everything.

We have 1 new experienced dev we just hired full time due.

There are ~6 junior devs but only half full time and several are away right now.

in reply to GrapheneOS

@J3317 @evilcookies98 @joepie91 @darkyen We need senior developers to review other people's work and guide them so productivity is very low right now due to the lead developer being conscripted. This hasn't been a good few months to get much done.

Android 16 is right around the corner and we're dealing with unexpected regressions which have come up which is taking time away from important preparation work for it.

Our focus right now is preserving what we have, which takes a lot of work.

in reply to Sven Slootweg (soft-deprecated)

@joepie91 @J3317 @evilcookies98 @darkyen In what sense are the models for RHVoice, etc. open source in a way that these models are not? They're still a form of model with an unclear origin.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@darkyen @evilcookies98 @joepie91 @J3317 We could use github.com/k2-fsa/sherpa-onnx to provide text-to-speech and speech-to-text. Speech-to-text would be very helpful for accessibility and would enable adding automatic subtitles.

How else could we provide speech-to-text than a neural network approach?

Many of the aggressive voices for accessibility at all costs including disregarding licensing and security are going to switching to demanding we avoid including anything using neural networks instead.

in reply to GrapheneOS

@evilcookies98 @joepie91 @J3317 Somebody in this thread already said that something is better than nothing and they can always install their preferred TTS later, so I would't worry too much about it.

I dislike the modern "AI" hypetrain as anybody else, but some things *are* well suited for neural networks, voice interface being one of them.

There might be ethical problems with training datasets, but surely that is better than breaking OSS licenses outright?

in reply to Jan Polák

@darkyen @evilcookies98 @joepie91 @J3317 The issue isn't breaking open source licenses but rather is forbidding using GrapheneOS in ways we have committed to supporting. If people just want something that will work then what we need to do is integrate one of the available permissively licensed options. Ethics of how they trained the models doesn't factor into it if we're expected to prioritize accessibility over nearly everything else. These models exist already and are freely available.
in reply to The Evil Chocolate Cookie

@evilcookies98 @joepie91 @J3317 While accessibility is important, this is an underfunded open source project we are talking about. And they have been very patient, explaining why things are as they are. They cannot compromise security for half assed accessibility implementation and they cannot compromise legal standing of the project for it either. I understand that it's frustrating, but most other OSS project would tell you at this point that "PRs are welcome - goodbye".
in reply to GrapheneOS

@darkyen @evilcookies98 @joepie91 @J3317 However, look at one of the responses we got about mentioning wanting to add text-to-speech and speech-to-text this way:

grapheneos.social/@GrapheneOS/…

If people are going to give us a hard time and try to harm us if we ship speech-to-text which is not really feasible for us to do another way, what are we meant to do about providing those accessibility features?

Text-to-speech CAN be done in the older more hard-wired way but the modern ones have moved on.


@joepie91 @J3317 @evilcookies98 @darkyen If we include this, there are other people who are going to be very angry about it because it's based on neural networks.

bsky.app/profile/stopgenai.com…

bsky.app/profile/stopgenai.com…

This is how modern speech-to-text, text-to-speech, translation, automatic captions, etc. are all implemented. If we tied our hands and refused to use anything using neural networks, we wouldn't be realistically ever able to include speech-to-text, translation, captions, etc.


in reply to GrapheneOS

@evilcookies98 @joepie91 @J3317 You will never make everybody happy. However, the linked people don't want an LLM and as far as I know, TTS and STT are not based on an LLM architecture. They don't have a way to generate new words. It is just a way to compress rules about making human sounding sounds into a data file. So you could still add it without adding any LLMs.

Claiming that an accessibility feature people need is a slippery slope to adding ChatGPT are just petty.

in reply to GrapheneOS

@J3317 @evilcookies98 @darkyen This was about espeak, not RHVoice; and to my knowledge, espeak is algorithmic in nature and not trained on a massive dubiously sourced set of training data, which means it does not suffer from the same problem.

I have my doubts that this discussion is going to be moving in a productive direction for either of us, so I'll leave you with this comment:
The way you've responded to this situation has damaged your reputation in my eyes *far* more than that article ever could have.

You've yelled at a blind person for expressing their frustration with being excluded, you've threatened pausing development on accessibility entirely (which feels rather "look what you made me do!"), you've repeatedly refused to take responsibility for your decisions by framing them as if they are out of your hands, and you've confirmed the long-standing rumours that you call all criticism "attacks" (which is something I'd remained undecided on until now because I didn't have enough information, but now got to see first-hand).

You yell a lot about how that article has "harmed the project", but if you're concerned about harm to the project, I think that you need to be looking inward instead, at the way you interact with criticism.

in reply to Sven Slootweg (soft-deprecated)

@joepie91 @J3317 @evilcookies98 @darkyen

It's clear you've been heavily influenced by attacks on the project and team. If this is your attitude, avoid contacting us.

We haven't yelled at anyone. We were attacked with now retracted false claims, hyperbole and claims that we're cruel because we get things implemented slowly and need to use software meeting our requirements.

GrapheneOS is missing features some people need to use it. That doesn't only apply to blind users. We're working on it.

in reply to GrapheneOS

@joepie91 @J3317 @evilcookies98 @darkyen

Not having features everyone needs to use GrapheneOS despite our ongoing work improving many different areas of usability and accessibility doesn't mean we don't care. It takes us a long time to implement things. We had no network location from 2014 until late 2024. We had no compatibility with apps depending on Google Play until summer 2021. We still have a bunch of legacy AOSP sample apps. We'd have SVOX Pico TTS if it wasn't removed from AOSP.

Unknown parent

mastodon - Collegamento all'originale
Alexis
@dibi58 @J3317 Woe, i didn't know FDroid was a security risk. I use Google play, witchi is probably not much better.