Reconsidering how to handle consent

[Abby-Wheelis]

It has been mentioned a few times, but we may need to reconsider how we handle collecting and storing consent from the user.

Future: I think we can remove this in the future. The consent "number" is currently an IRB protocol number from UC Berkeley's Committee for the Protection of Human Subjects (CPHS). Since I am no longer at Berkeley, this no longer applies to us. And I had some vision initially that the CPHS protocols could change, and we would require people to consent to the new protocol, but that has never yet happened in practice.
We should think about changing terms and conditions midway through a data collection period, but I don't think this is the solution.
We should remove this and redesign it better. (e-mission/e-mission-phone#1009 (comment))

I'm starting the process of rewriting 'splash/startprefs.js`, which has about 5 different functions related to marking, storing, and retrieving the consent. Since I'll be working on these functions anyway, it might be useful to go ahead and re-consider our handling of consent, as I noted in #977 (comment).

[Abby-Wheelis]

At a very high level, I'm thinking about how we need to make sure that the user has consented to the terms "recently enough" that they are up-to-date with the terms and conditions. What I'm thinking is that we could store the date that they last consented, and then if we ever change the conditions, we will just need to check that their consent date is at least as recent as the last time we updated the conditions.

Would that work? There could be a consideration that I'm missing, but this seems like our main goal is to ensure that they have agreed, and have a way to check if they are out-of-date with the agreement, rather than needing to store a specific protocol number.

[Abby-Wheelis]

Right now, the consent required, and stored, is {"protocol_id":"2014-04-6267","approval_date":"2016-07-14"}. With what I was envisioning, I'm thinking about requiring and storing something along the lines of {"last_updated":"2023-10-1"}. In this scenario, I would imagine that the "last_updated" is the date that we last updated the policy. Periodically, we could check the json file for what's required against what is stored, and if the dates are out of sync then we ask for consent.

Stepping further into this hypothetical situation, I think it could make sense to check, as we do with permissions, each time the user opens the app. If the stored date is earlier than the required date, then we take them back to that screen. I think we'd be able to leverage the existing onboarding stack for this -- set the "agreed to protocol" variable to false, and go back to the that page, then be able to skip the rest of the pages since the other variables that control that state will be unchanged?

With the changes from #1006, we'll need to ensure that the new consent does get saved to storage, since we're now doing that upon fixing permissions and logging in... so maybe we log them out just enough that they have to reconsent and are "logged in" (to save the new consent) but don't have to get through the QR page or the survey?

[Abby-Wheelis]

In our meeting today, we decided the best plan would be to remove re-consent for now, and then potentially restore it later once we know how we need to handle updating those conditions in the NREL paradigm

[Abby-Wheelis]

@shankari If I take out "reconsent" do you want me to take the "check consent" out of the profile (for now)? I've been experimenting with showing a message about the last date they consented if the consent is stored, and sending them back into the onboarding flow if consent is not stored. I believe this would only account for the case of "missing consent" rather than "reconsent", though missing consent should not be possible if someone has cleared the onboarding flow. What do you think?

[shankari]

@Abby-Wheelis they might run into the situation with missing consent after clearing the onboarding flow if we run into the situation with the local storage being reset (e.g. )?! Or do we store the consent with de-duplication between plugin and browser localStorage as well?
e-mission/e-mission-phone#1003

[Abby-Wheelis]

@shankari, the consent is stored in both native and local storage when we call markConsented, with the calls to writeConsentToNative and to storageSet. When the consent is read it does use the getUnifiedValue function in storage.ts. So I believe yes, we do store the consent redundantly in both local and native storage, and the de-duplication happens when we get the value.

export function markConsented() {
  logInfo("changing consent from " +
    _curr_consented + " -> " + JSON.stringify(_req_consent));
  // mark in native storage
  return readConsentState().then(writeConsentToNative).then(function (response) {
    // mark in local storage
    storageSet(DATA_COLLECTION_CONSENTED_PROTOCOL,
      _req_consent);
    // mark in local variable as well
    _curr_consented = {..._req_consent};
  });
};

[Abby-Wheelis]

If we are convinced that there is no duplication because of the storage in both local and native, would we then be comfortable removing the "check consent" button from the profile? I can think of three options for how to proceed:

1. remove "check consent" completely, at least until we decide how to handle reconsent
2. keep "check consent" and if no consent found, have a message to log out and log back in with the same code
3. keep "check consent" and find a way to jump back into that onboarding flow stage to re-gather consent - or just go to that page and regather consent and return? I'm not sure exactly how this would work, but it should be possible.

[shankari]

the consent is stored in both native and local storage when we call markConsented, with the calls to writeConsentToNative and to storageSet. So I believe yes, we do store the consent redundantly in both local and native storage, and the de-duplication happens when we get the value.

I agree that the data is stored in both the native cache and in local storage. However, the keys are not the same.
markConsented uses the config/consent readwrite document (IIRC), while storageSet calls local storage with DATA_COLLECTION_CONSENTED_PROTOCOL

When the consent is read it does use the getUnifiedValue function in storage.ts

Right, I do believe that the UI will read the de-duplicated value. However, the UI is not the only component that checks the consent. We use isConsented in multiple locations in the native code, and I believe that only checks the config/consent object, which is not deduped.

And if isConsented is false, then I believe that the tracking will stop.

A principled fix might be to unify the two checks (UI and native code) by having the native isConsented also check the value in native storage. But until we do that, the app may not be collecting any data because it can't find the consent. So we should go with (ii) until we implement the principled fix.

[Abby-Wheelis]

keep "check consent" and if no consent found, have a message to log out and log back in with the same code

This was implemented, and on staging, when I click "check consent", I get the message about "consented to ...".

The next step is to implement a principled fix such as

A principled fix might be to unify the two checks (UI and native code) by having the native isConsented also check the value in native storage. But until we do that, the app may not be collecting any data because it can't find the consent.