User trust in the wake of OpenAI – some thoughts

Well, it happened: My beloved “Your data is your data”-ROM decided to implement a data-collecting BigTech API, did not announce anything about it before release, and now, in the resulting user upset, argues with the proxy connected in front of it (which must seem quite helpless with biometric data) and claims to be “super open and transparent”.

For me, this decision represents a breach of trust and the public relations work surrounding it has exacerbated this.

In response to the call for constructive criticism, I would like to explain how a decision of this magnitude, without wanting to put it up for discussion again, could have been accompanied by “super open and transparent” (quote Gäel Duval) public relations work.

BEFORE RELEASE

  • Acknowledgement of the expected conflictual nature of the decision. Preparation for this conflict.

  • Publication of the decision in the community with a strong reference to the anonymization project, response to concerns expressed, reference to the possibility of non-use, reference to expected instructions to revoke the service’s authorizations and to remove the API independently.

  • Take users seriously.

  • Ignore the trolls were possible, trust the users to handle them, ban them were needed.

  • Preparation of instructions to withdraw the service’s authorizations and to remove the API independently.

AT RELEASE

  • Strong reference to OpenAI and the anonymization efforts undertaken.

  • Outlook on plans for the continuation of the API and for the accompanying anonymization projects.

  • Publication of the instructions for revoking the service’s authorizations and to remove the API independently.

AFTER RELEASE

  • Further response to concerns expressed, reference to the possibility of non-use, reference to the instructions provided to withdraw authorizations from the service and to remove the API independently.

  • Continuous outlook on plans for the continuation of the API and for the accompanying anonymization projects

  • Take users seriously.

  • Ignore the trolls were possible, trust the users to handle them, ban them were needed.

So much for my ideas, of cause without claiming completeness. Such an approach would seem really open and transparent to me and would have minimized the (my) loss of user trust.

Please feel free to add your thoughts!

9 Likes

For those missing some context here … The original topic about what this is all about is over there, and still active …


There are some words quoted from Gäel Duval here without using the quote function of the forum, so the context of where they come from is missing, but this is easily fixable …


Context about the mentioned proxy and more is here …

5 Likes

Thank you for adding context! Cross-thread quotations are still to be mastered by me, ha!

Also, this is about communication and claims to it in general. I think it is a separate issue.

1 Like

I agree. I made another thread to ask some very specific questions. After following up later, I got a response that seems like it can’t be true and no explanation as to why that’s the case. Asking clarifying questions has thus far yelded no results.

It should have been very clear upon announcement that this was using OpenAI and the benefits, drawbacks, and the specifics of what data is and isn’t anonymized. There should also be a clear warning upon first use that this feature will send voice recordings to OpenAI. (Murena is claiming otherwise but has yet to explain how they managed to do that.)

I can forgive not thinking through the announcement. I can forgive not asking us first. But the lack of communication after they realized a lot of users were upset and/or confused about the feature is what really gets me. The response from Gaël (linked above) wasn’t actually that helpful, as it didn’t address my main concerns. Again, I could have forgiven this, but there has been nearly complete silence about the questions people still had after the post from Gaël.

I could have forgiven and still trusted Murena after multiple of these blunders. But the fact that they seem to be actively ignoring our concerns causes me to have serious doubts.

I still think they could regain most of the trust if they apologized for not being transparent and actually spoke to people’s legitimate questions and concerns, rather than giving what felt like a canned response.

5 Likes

True indeed! Even just a small hint that something about public communications was not really well thought out and done clumsily would at least demonstrate some awareness of a problem. This offended attitude of a persecuted innocence is certainly not helpful.
Not to mention the contradictions that occur again and again and are not resolved. But that’s more the topic of your thread.

3 Likes

So, I’ll throw my two cents into the mix, for whatever they’re worth. I was thinking of writing an e-mail to @GaelDuval directly, but I’ll put the essence of my thoughts on the matter here, in public, so others in the community can either agree or express their disagreement.

The reason why nearly all of us are here is because of a fundamental distrust of “big tech”, and as many, many articles have shown, there are justifications for it, with the trajectory of Apple, Google, and Microsoft all heading in the direction of further distrust. It’s how most of us settled on /e/OS for our phones, and for a very long time, /e/OS was - and still is - probably the best balance between privacy and usability.

…But for all of the AMAZING strides that /e/ has made with regards to that usability, there are still concessions that every /e/OS user makes in order to run it. For starters, we have to select phones based on what /e/OS will run on. Next, it can take some time to get /e/OS installed. Once running, there are apps that are difficult to get working on /e/OS - banking apps, notoriously, but even Cisco Duo barks. Even if these aren’t issues for a particular user, other things can be. Things like per-device camera functions are inconsistent. I’m sure that Galaxy Note/Ultra users have reduced stylus functionality than the stock ROM. The very issue that involved OpenAI integration is to close the gap between /e/OS by adding functionality that’s a decade old for iOS and stock Android, while being unavailable for /e/OS. Now, obviously, these elements are things that, by definition, either don’t affect /e/OS users, or are things that we’ve agreed are worth the tradeoff for the privacy /e/OS gives us.

What seems to be happening, however, is a string of decisions that are made, implemented in some capacity, are unannounced, and then show up in the forums as eagle-eyed users start asking questions that SHOULD have an answer like, “read Gael’s announcement from three months ago”…but don’t. Even if the response is perfectly understandable and justified, a proper announcement can be helpful to assist with implementation.

Consider, for example, the MDM client addition. Personally, I think there were multiple ways to avoid the blowback on that, from either making a “business” fork that is effectively a recompile of the existing branch, but with MDM, to making the MDM something that is added during the initial setup procedure if it’s intended for use, to having a dedicated removal tool APK that can delete the MDM if it is in an unactivated state, and those are just options off the top of my head. Most of these apply to VTT as well. At the very least, an automated removal script that can be run from a root adb shell could be provided.

Now, I can very much appreciate that
1.) the excellent dev and management teams deserve to be able to pay their rent,
2.) running the /e/Foundation on donations and phone sales alone is going to make that difficult to do consistently,
3.) offering a business solution opens up doors for expansion without having to excessively panhandle or paywall features to make that possible,
4.) the nature of “privacy” has a very different context in a business setting, than it does in a personal setting, and
5.) it’s a pretty big ask to have the team maintain two codebases.

I get it. I do. I appreciate that the reason we’re here is because the addition of VTT will reduce the number of concessions which /e/OS requires its users to make. That said, I do think that @Sebastian and @Gquirt are fundamentally being reasonable and justified in their response to a trajectory of feature additions which potentially involve privacy concessions. Better to /e/ than Google, granted, but I don’t think it’s unreasonable to request that such features be better discussed with the community prior to implementation, and that they are made more optional than they are.

I raise this because it seems like the current state of affairs is as likely to make /e/OS the worst-of-both-worlds, as it is to make it the best-of-both-worlds. I don’t know how big the market is for a business phone/server vertical that isn’t already serviced by JAMF/Miradore/ClearPhone, but I am sure that chasing it will come at the expense of at least some of the existing community and donor list, leaving /e/OS to eventually be the OS of compromise that requires too many concessions for business users to be viable over JAMF, while having too many sources of concern for privacy-conscious individuals to run on personal phones.

I appreciate the description we ultimately received on the forums. I appreciate the additional discussion that has taken place. I am grateful for ALL of the work that has been performed by the dev team to keep moving /e/OS forward. I will, however, humbly-but-strongly request that the feedback that has come forward be taken into consideration: discussion of potentially-privacy-compromising functions with the community, prior to implementation, along with a means of removal, is the essence of what is being asked for. To me, these are not unreasonable requests, and they are in line with the core tenets of what /e/ stands for.

Thank you for considering it, one and all.

5 Likes

OP post is reasonable: asking for better communication process, esp. on potentially controversial features. Have the help articles on new features ready and public on release day. It’s good feedback. Split on if it’s a fair ask considering company size. But anyway, defuses user uncertainty, whatever the position.

4 Likes

Thank you! Your reasonable and objective voice speaks from the reasonable and objective side of my heart. In every aspect. Of this side. Some orher side still rages…

I’d also add the requirement for clear communication and transparency in the software itself. Features that transmit data to third parties should show an information message when enabled and/or used about which data is sent and to whom. This could avoid users feeling that there are “traps” in the system.

A small informational display like “This recording will be sent to servers run by OpenAI for processing.” when the user presses a voice dictation button would suffice.

Keep in mind that not everyone reads announcements, forums and marketing e-mails. Some people just buy a phone from the Murena store or have the system installed by a family member.

2 Likes

As an outsider looking in (I have dabbled with /e/os in the past but never daily driven) I think some sort of partnership between FUTO and /e/OS could help drive these concepts forward. They have a local AI based keyboard and STT engine that works well as a driver on my daily phone.
I get the need for funding on a OSS based company but siding with a venture company like OpenAI can lead to pain and bad PR in this current climate. (I’m not sure if they are paying based on the info I have seen.)
Overall I would like to see /e/OS succeed where others have failed.
I don’t use STT so I don’t have a huge dog in this fight but wanted to share that FUTO is trying to carve a different path similar to what /e/OS is doing and I think many priorities would align and could bring mutual benefits.

4 Likes

I think you nailed it there. Most of us are here because of our mistrust over big tech. When /e/os starts doing the same kinds things, of course that will breed dissatisfaction.

It’s a really a simple fix, announce changes that may have an impact on privacy and provide a mechanism to remove them if so desired. We’re all reasonable here and as long as we have the option, we’re not going to have a problem. It’s understood that certain features may be deemed necessary to stay relevant or open up new markets. Just don’t take away the option.

8 Likes

With all the criticism I’m expressing, I’ve noticed that I’m sparing with naming good things. I have already expressed my affection to /e/ in other places in the forum, and perhaps I thought that was enough, but to make my attitude to /e/ clear here too, I would like to repeat some of it.

My journey with /e/ started five years ago when it, no kidding, gave me the final push to finally get a smartphone. For me personally, e/OS/ was (and yes, still is) the best compromise between usability, convenience and data protection. I love the idea behind it, can live well with the occasional problems, have great respect for the people in the background who program and maintain this alternative for us and am fascinated by the friendly and helpful community in this forum. It was amazing to see and be kinda part of how /e/ evolved in the past years.

For some time now, /e/ quite obviously has been accelerating its steps to step out of the corner of the slightly nerdy niche product and to develop into a mainstream alternative. In principle, this, of cause, is to be welcomed, but it also harbours some risks, as it requires a certain amount of streamlining. I can totally understand that people want their phone to work with their companies, their health trackers, their cars or whatever. I would welcome it if /e/ would become more widespread. And I see that sometimes concessions have to be made for this. I just can only hope that these concessions won’t get so big that they drive me away one day.

So, please, do better communication work. Make more things optional. And stay aware of your user base. Please.

Because most of us actually really, really like you.
Really.

6 Likes