Implement bug report

[Irineu333]

No description provided.

[PatrykMis]

I'm against implementing libraries like Crashlytics into the Speak Touch project, even if they were fully open source. The only thing I would consider is fully libre, open-source software that uses fully free (as in freedom) and open services. Given that Speak Touch is an accessibility service, gathering content from the screen and user input, we must prioritize user privacy and security. Here are some key points from my perspective:

Privacy and Permissions

• Crash reporting often requires permissions, such as network access, to send crash reports to a server. This might be perceived as intrusive by some users.
• Additional permissions could make users skeptical about the app's intentions and impact user trust.
• Speak Touch currently operates without requiring additional permissions, contributing to a minimal and non-intrusive user experience. This aligns with best practices for privacy and builds trust with users.

Speak Touch operates effectively as an accessibility service without the need for additional permissions, ensuring a seamless and trustworthy user experience for individuals relying on screen readers. We should focus on accessibility and usability without unnecessary features that may compromise privacy, user experience, and most importantly, security, as we cannot take full responsibility for the security, bugs, and potential vulnerabilities of used libraries.

Security Risks of Internet Permissions

Introducing internet permissions for an app that handles sensitive user input and screen output poses inherent security risks. We need to be mindful of potential vulnerabilities that could compromise the integrity of the data processed by Speak Touch.

While crash reporting tools are valuable for identifying and addressing issues, they introduce additional risks as they interact with various components of the app. It's crucial to minimize potential attack surfaces, especially in the context of accessibility services. Before opting for internet permissions, let's explore alternative security measures, such as comprehensive code reviews, the use of static analysis tools, and regular monitoring for security updates in the libraries we use.

Legal Compliance

• Implementing crash reporting involves collecting and potentially transmitting user data, which can have legal implications.
• GDPR and other privacy laws require transparent communication about data collection practices and obtaining user consent. Implementing crash reporting may necessitate updates to the privacy policy.

User Trust and Optics

• Users are becoming increasingly privacy-conscious, and transparency in data practices can enhance trust.
• The optics of an app requesting additional permissions for crash reporting may be perceived negatively by some users.

Users, particularly those relying on screen readers, will place a high level of trust in Speak Touch. Security vulnerabilities could have severe consequences for these users. It's essential to prioritize their trust and the reliability of the app.

Other

Some crash reporting services may come with associated costs. Evaluate whether the benefits justify the financial investment.

Alternative Approaches

Considering the privacy and security concerns associated with crash reporting libraries, let's explore alternative approaches for gathering feedback and bug reports. One effective method could be establishing communication channels via social platforms such as Matrix (Element) and/or Telegram (like the group which is unofficially already functional but public). These platforms provide a direct line of communication between users and developers, enabling real-time discussions about issues, feature requests, and general feedback. Additionally, we can implement a user-friendly local bug reporting feature within Speak Touch. This feature would empower users to generate bug reports locally, giving them the option to share, save, or send the report via their preferred email application. This approach not only respects user privacy but also allows for more direct and transparent communication, fostering a collaborative environment between the development team and our users. I'm sure good, FLOSS libraries already exist.

[PatrykMis]

After conducting some research, I came across a promising library for crash reporting on Android: ACRA. Considering SpeakTouch's focus on user privacy and security, ACRA seems like an intriguing option. With ACRA, SpeakTouch could potentially have a crash reporting feature without requiring internet permissions, aligning well with our commitment to a minimal and non-intrusive user experience.

It's worth noting that the implementation might involve some manual work, such as creating a custom ReportSender to manage the storage and retrieval of crash reports without requiring internet permissions.

[Irineu333]

Implementing a local bug report is an interesting alternative; we need this data to improve SpeakTouch. However, I believe this idea could be better developed to achieve a pragmatic balance between the need to collect data to improve SpeakTouch and the importance of preserving user privacy and security.

Ease:
Although manual submission through a messenger works, it's not efficient. It imposes some barriers and it's not practical. A more robust solution would be to allow report submission at the click of a button. The user could report directly in an open channel or simply allow automatic submission.

If the user themselves chooses to send the report, or even accepts automatic submission, it solves any legal issue. We can create an API to receive these reports; but the app would need internet access.

Internet access:
I believe this is the most controversial issue here. For greater convenience, the app needs internet access. And I don't know a way to condition this permission; once added in the manifest, as it is a normal permission, the system grants it automatically.

[PatrykMis]

Additionally, we can implement a user-friendly local bug reporting feature within Speak Touch. This feature would empower users to generate bug reports locally, giving them the option to share, save, or send the report via their preferred email application.

I think this will be the best option. Users would have a possibility to do with bug report whatever they want, either sending it by e-mail, saving it to the storage (via SAF, Storage Access Framework of course) or sharing by whatever app which supports sending ZIP files. Unfortunately, like you've said:

For greater convenience, the app needs internet access. And I don't know a way to condition this permission; once added in the manifest, as it is a normal permission, the system grants it automatically.

Unfortunately, Android (up to v14, API level 34) grants network access automatically without user consent or ability to revoke this permission, only GrapheneOS allows this.

[Irineu333]

Could it be done with on demand modules? Or would it still require internet access permission?