We're developing our own implementations of text-to-speech and speech-to-text to use in #GrapheneOS which are entirely open source and avoid using so-called 'open' models without the training data available. Instead, we're making a truly open source implementation of both where all of the data used for it is open source. If you don't want to use our app for local text-to-speech and speech-to-text then you don't need to use it. Many people need this and want a better option.
We are working on TTS first then SST. The TTS training data is LJ Speech and the model used is our own fork of Matcha-TTS.
If people want they can fork it and add/remove/change the training data in any way they see fit. It's nothing like the so-called "open" models from OpenAI, Facebook, etc. where the only thing that's open are the neural network weights after training with no way to know what they used to train it and no way to reproduce that.
Many blind users asked us to include one of the existing open source TTS apps so they could use it to obtain a better app. None of the available open source apps meets our requirements for reasonable licensing, privacy, security or functionality. Therefore, we've developed our own text-to-speech which will be shipping soon, likely in January. We'll also be providing our own speech-to-text. We're using neural networks for both which we're making ourselves.
The LJ Speech Dataset
A public domain speech dataset consisting of 13,100 short audio clips of a single speaker reading passages from 7 non-fiction books. A transcriptio...
For newcomers, this model is a layered pyramid that ranks indicators of compromise by a linear level of difficulty and cost for the threat actor to evade security measures to perform an attack; The bottom of the pyramid being very easy and trivial for the threat actor to change and the top being tough.
This model opens newcomers on how good security strategy is built: Techniques and capabilities over individual actors. Closing out tactics, techniques and procedures are far more important than blocking an IP address or a file hash. You want to protect against a type of attack, not against a particular actor who performs them.
The point of having extensive hardening features is that we need to ensure vulnerabilities that would affect Android are benign, harder to exploit or patched in GrapheneOS before they can be exploited. Android distributions carry the weight of vulnerabilities from upstream. To reduce that weight, we need to make sure a highly sophisticated exploit developer would have to uniquely design their exploit to target GrapheneOS, should they be able to at all.
Without that, GrapheneOS wouldn't be special. It would not be sensible to claim it is more security and privacy focused than Android if it was able to be exploited through the exact same mechanisms with little or no effort needed to port. An Android distribution that is just Android without Google services is mostly as exploitable as Android. Something that is "DeGoogled" (I don't use the term, it's Reddit tier buzzword nonsense) may not necessarily be safer to use either.
To earn the title of being hardened it needs more, but this isn't ever implemented well enough. Projects that have done so to the best of their ability also have died (DivestOS).
Our hardening features are available outside of GrapheneOS. Leading example of this is secureblue, a security hardened Linux distribution (