Appcenter: Use App Center Crashes while supporting User Privacy

[james1301]

Is your feature request related to a problem? Please describe.
We allow users to specify whether App Center sends data to our App Center Instance, this information is obtained at login. The problem is that if they do not wish to send data, then we cannot use the App Center Crashes logic to handle our crashes. We still want a message with the crash information to be shown to the user when they restart the application regardless of whether they want this information sending to App Center. Discussed more on microsoft/appcenter-sdk-dotnet#1231.

Describe the solution you'd like
To be able to have Crashes be enabled with no data being sent to App Center. So we can use the ShouldAwaitUserConfirmation event and display the GetLastSessionCrashReportAsync.

Describe alternatives you've considered
The alternative is to use our existing unhandled exception logic and not use yours but presently this is stopping the Crashes being registered correctly in App Center because we are handling the unhandled exceptions wrongly.

Additional context
This is to support our privacy policy where the users have the right to not send the data.

[ahdbilal]

Thanks @james1301 for the request! We will be reviewing this in our weekly meeting and I will provide you more details on it after the meeting. Thanks

[james1301]

Any news from the meeting @ahdbilal?

[guperrot]

Why using ShouldAwaitUserConfirmation does not work for you? It's executed every launch (as long as SDK is enabled and not using "always send") and you will always have GetLastSessionCrashReportAsync returning the crash report even if the user selects "Don't send". We don't send the data with that user action but still expose the report via the getter.

If ShouldAwaitUserConfirmation returns true and if the SDK is enabled, we don't send the crash report, it's on hold. If you later call NotifyUserConfirmation we either send or discard the data based on the parameter value (send or don't send).

I think there is a confusion in microsoft/appcenter-sdk-dotnet#1231 discussion as this is about disabling the SDK, we don't need to disable the SDK to support putting crash sending on hold (this is not like analytics). Here you want to keep the crash SDK enabled but use the callbacks to delay sending then confirm or cancel sending later.

In practice, set ShouldAwaitUserConfirmation to return always true before calling AppCenter.start. This won't block any thread or task, this is asynchronous: the SDK will just send or discard the data only after you call NotifyUserConfirmation and just keep storing new crashes locally should they occur before that decision is taken.

[MatkovIvan]

@guperrot The main point here is to send no (any) data before confirm. So, the issue is about start service logs that SDK sends from core

[james1301]

yeah thanks @MatkovIvan.

[ahdbilal]

Thanks @james1301 for the follow up. This has been added to our feature backlog. We are seriously considering this feature and we might consider this in the next iteration. I will post an update here once I have new information.

[bewster]

Is this still languishing in the backlog?

Although this many not strictly be covered by GDPR - I am not expert - as it doesn't include user identifiable information.
In my view, it is a form of session cookie the end user has not consented to.

From what I have observed, the crash logging and submission process doesn't need the STARTSERVICE data submitted to AppCenter to work.

[AnastasiaKubova]

Hi, @bewster ! Thanks for getting in touch with us!
We are working on this issue. I will notify you when we will have any updates.

[pfandrade]

Also looking forward to being able to control whether this start service log is sent or not.