GrapheneOSIn order to provide better support for blind users, we maintain a fork of the open source TalkBack app fixing serious issues with it, modernizing it and making the builds reproducible. One of the goals of making our own Setup Wizard has also been integrating TalkBack support.
Google unfortunately doesn't publish the source code for each stable release of TalkBack as they do for Android itself. The open source release of the app lags significantly behind. It also has a bunch of missing and broken features. We plan to gradually improve this situation.
In order to use GrapheneOS, blind users need to successfully install the OS and set up the device to be usable with a screen reader. This is an area we've been thinking about and working on improving for a while. Our new Setup Wizard provides a better base for integrating this.
The first barrier to someone using GrapheneOS without sight is installing the OS. We've done what we can to make our web installer as accessible as possible (https://grapheneos.org/install/web). However, users need to interact with the device's firmware interface which the user can see.
Due to the inaccessible firmware user interface, it's difficult to perform the installation correctly and safety, particularly confirming unlocking and then confirming locking. Confirming the verified boot key matches after installing/locking would require OCR on another device.
The next issue is the Android Open Source Project no longer includes a text-to-speech app. Pico TTS used to be included in AOSP but was not what Google Mobile Services devices use. It was quite primitive, awful to use and AOSP removed it after security issues were found.
We've wanted to include a text-to-speech app and bundle a language pack to have it working out-of-the-box for a long time. We could then add a shortcut for enabling TalkBack in our new Setup Wizard to make things accessible from the start of the post-install setup process.
To provide what we need, the TTS app needs to be built into the OS, enabled and set up to work by default without configuration. It doesn't do any good if you need to connect to a network and download a language pack. It also needs to work Before First Unlock via Direct Boot.
Since it will be enabled by default, security is quite relevant. It shouldn't be a bunch of C++ code without a modern coding style, use of sanitizers, decent tests, etc. It needs to be actively developed and properly maintained. This is why Pico TTS had to be removed from AOSP.
GrapheneOS is intended to be a drop-in replacement for the Android Open Source Project usable by companies to make all kinds of products. Due to this, we avoid non-commercial usage licenses. Lots of the language packs for TTS implementations have non-commercial usage licenses.
We also avoid including GPLv3 code in the base OS since it would add restrictions on how it can be used. We do add new GPLv2 licensed code. This doesn't mean we have issues with using GPLv3 code or making forks of GPLv3 projects, we just don't bundle it within GrapheneOS itself.
Fluchtkapsel@GrapheneOS I'd really like to know what specific issues you have with GPLv3. Which restrictions would apply? What could not be done anymore? Why is this more of an issue than accessibility today? Please don't handwave that away.
@fluchtkapsel AOSP does not include GPLv3 code because most tech companies want to avoid it. If we included it, most companies would be unwilling to use GrapheneOS.
Bundling eSpeak NG would not make GrapheneOS more accessible since it would require setup to use it and so would TalkBack. The setup wizard would need to be completed followed by setting that stuff up. Improving this requires significant work on integrating a text-to-speech implementation and adding further integration for TalkBack.
@GrapheneOS Are there really any companies considering the use of GrapheneOS over direct access to AOSP? If it's companies handing out smartphones with GrapheneOS to employees, GPLv3's restrictions do not apply because that is not some kind of distribution requiring source code access or being able to reflash the hardware.
@fluchtkapsel There are companies considering the use of GrapheneOS and talking to us about it. There are companies wanting to build phones we can support. It has been expressed that including GPLv3 code would be a problem because their legal departments were block them moving forward. They would not want to use it with a subset of what we have removed. Bundling GPLv3 code would limit how widely GrapheneOS can be used and significantly reduce interest in it from companies. We aren't doing it.
@fluchtkapsel These attacks on the GrapheneOS project are going to take significant resources away from development, reduce contributions, reduce partnerships and that will need to result in us focusing more on the core OS and adding fewer features. The impact of all these attacks on the project add up and play a significant role in how much we can do. People doing it have themselves to blame for feature development going more slowly than they want, and at least 1 partnership was lost due to it.
@GrapheneOS Without piling more on GrapheneOS, my take is that the pragmatic approach would be to just include espeak-ng until a better solution comes up. If companies want to use GrapheneOS, they can simply remove this component.
Security concerns? IMHO, after initial setup there's no need for espeak-ng anymore and can be replaced by something else.
But of course, that's just my position. I guess it's too late for a pragmatic approach now.
@fluchtkapsel Bundling eSpeak NG would not make GrapheneOS more usable for blind users without forking it and integrating it into the OS. It's also hardly one of the best open source implementations of text-to-speech. The post attacking us is thoroughly misrepresenting the situation as if eSpeak NG is the only option available and as if the only reason we aren't including it is GPLv3 licensing, while also ignoring why GPLv3 licensing is a problem and would FURTHER reduce our resources.
> Security concerns? IMHO, after initial setup there's no need for espeak-ng anymore and can be replaced by something else.
In order for this to work as intended, it must be enabled by default and therefore exposed to apps and content by default. Most people are not going to replace or disable the text-to-speech implementation as their first step of using the OS after completion of the setup wizard. Including a poorly secured implementation of TTS goes against what we do.
@fluchtkapsel People can already install eSpeak NG, RHVoice or many other open source TTS apps on GrapheneOS. They work fine simply installed on the OS. They need to be configured to work including downloading required language packs, etc. and activated in the OS settings for TTS which allows enabling 1 TTS app at a time. Most of the open source ones require special setup by the user and are not designed to work seamlessly from simply being installed. They may also stop working due to issues.
@fluchtkapsel If someone is completely depending on it to use the device, it must keep working without issues. That is a much more important property than being able to do the initial setup without assistance. Suddenly needing assistance at an arbitrary time because it broke is a critical issue vs. needing assistance only for the initial installation and setup process being something people can plan around. It's important for a TTS app we include to be robust and secure at a bare minimum.
@fluchtkapsel Most of these apps were NOT designed with the serious use case of being someone's primary way to use the device. That's why neither eSpeak NG or RHVoice had Direct Boot support. We requested it for both so that users who had them installed could use them Before First Unlock too. The blog post makes it seem as if that's because we were going to bundle eSpeak NG into the OS, but we requested that for SEVERAL of these apps with the goal of improving the open source TTS ecosystem.
@fluchtkapsel Requesting an improvement for several of these apps to make them closer to being usable as a serious TTS app where it needs to always work properly doesn't mean we had specifically chosen one of them to include. There are other options available, and we need to evaluate/review those and choose the best one then integrate that. It's going to take work to fork and integrate it, work we will have less time for with more ongoing attacks on the GrapheneOS project.
James Scholes@GrapheneOS @fluchtkapsel This is a fundamentally inequitable and illogical stance. If blind users cannot install the OS without help, there will be fewer of them to benefit from a robust accessibility implementation, and what blind users do exist today are the subjects of survivorship bias.
It also continues to perpetuate the exclusionary belief that disabled people should need to "plan" (your word) to carry out tasks that others can do on a whim. They do not have an army of helpers available on demand to pick up the work that a project isn't prioritising.
@jscholes @fluchtkapsel This isn't about installing the OS without help. There's no screen reader or text-to-speech in the fastboot firmware and we can't add it there. Android OEMs would need to be the ones adding it there to make the process of using fastboot including to install the OS more accessible. This is not part of installing the OS but rather using it after the initial setup.
Wanting to have a robust, secure and actually usable TTS implementation is not exclusionary....
@jscholes @fluchtkapsel An incredibly dishonest post attacking the GrapheneOS project with spin and fabrications is not going to help us implement this any faster. It will do the opposite. All it has accomplished is demotivating the development team and contributors along with significantly harming the project.
We have put significant effort into maintaining a fork of TalkBack and making sure that's always kept working along with compatibility with TTS apps. We can't do everything ourselves.
@jscholes @fluchtkapsel GrapheneOS receives very little support, very few donations considering how many people use it and nearly no external contributions. We aren't getting any help with forking and integrating a text-to-speech app into the OS. Do you think that an incredibly hostile and dishonest blog and Mastodon post attacking our team is going to accelerate this? It is not our fault that until recently there were major issues with all the available open source TTS apps.
@jscholes @fluchtkapsel There are better options available now, and the process of choosing one, forking it and integrating it into the OS could now begin. Do you think it's more or less likely to happen now that an incredibly hostile post attacking our project and team has been made which steers a bunch of hate towards the project, disrupts development and steers people who may have helped us implement it away from it? Attacking us for needing time to implement features will make it go slower.