-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Per event user-consent. #933
Comments
Thanks, @stima. I am unsure if I would classify this as a bug since we have no cross-SDK rule about user consent. In general, most users will expect that this is a global setting, so applying this to each event will always happen in the context of a global setting to make sure we don't retroactively give consent. |
By the way, if you mean for users to give consent per event (and not only prevent retroactive sending), that would be yet another design since it would require that we provide an API for the crash context (to allow the user to make the decision based on the contents of what would be sent). This is different from what the user-consent functionality is currently supposed to implement. |
cc: @kahest |
We're talking about 2 different things here:
About the second point: an event captured while consent was not given should not be sent, even if consent is given afterwards and the event is still present. This seems like an edge case though. @supervacuus wdyt? |
@kahest yes you are totally right, that is mostly about that global consent can not be used when event already generated |
@stima cool, thanks for confirming - I think this is unintended and we'll discuss how we'll proceed with this. We won't implement consent per event if not necessary - if you have other use cases for that, feel free to add here |
This is an edge case because it is not stably reproducible using an integration test (that follows the steps to reproduce). Right now, there are two places where consent is checked:
First, let's consider the capture envelope path: this is responsible for sending any envelopes, including regular events, crashes, and transactions. There is no way for this path where you could give consent, and it would retroactively allow the sending of envelopes where previously consent was revoked because the check happens synchronously. Of course, suppose you "give" consent on one thread and send an envelope on another. In that case, it is possible that global consent If we need to prevent this, we must track consent per event or block/ignore consent changes during any envelope capture. I wouldn't consider this a bug because at this point it is also unclear to any user at which boundary they have given consent or not. Of course we can move the boundary further out, but it is essentially the application that must make sure that consent is given at a point in time where the user knows which envelopes their consent applies to. Of course, we can talk about this scenario, but consider using a mutex to prevent concurrent consent-mutation and envelope-sending, then we still cannot guarantee which thread acquires the mutex first, leaving the correct order again up to the application. Which brings us to the path that the client cannot control: crashes will be sent during With the upload thread in the @stima, do you use the |
Platfrom: Windows @supervacuus I guess the second scenario describes my case. Usage is quite trivial:
e.g. consent may be given faster then crashpad uploading thread started. Nevetheless, there is another "edge case" related directly to Sentry Native (not tested but this is according to code):
I would like to mention that for some usecases this is quite critical (goverment, banks, etc) to provide confidence that nothing would be send from user PC if user directly disallowed it. I would also like to say, that I think that trivial guarantees for "per-session" consent on startup is enough (e.g. nothing related to MT during run and chaning it) |
Yeah, as I wrote above, that is totally possible; the
From the perspective of the current implementation, this is a hypothetical use case since the options typically do not change once the development reaches a stable configuration. Do you need to change the user-consent requirement in your application when deployed to production?
I am aware, and I agree that it is crucial for some scenarios (I would also say that there are many more than tighter user consent bounds for many uses of the Native SDK). Please don't read this as pushing back on the topic. But this must be balanced between the consequences for the 99-percentile clients and providing change for specific applications. There are many ways in which we can help:
Please consider my responses in this context and, as a result, the question of how we can prioritize our actions with respect to other needs.
I will have a look if we can adapt the initialization and pruning of crashpad records in a way that would eliminate any uploads that the |
For reference: per event consent has previously been discussed and is tracked here #110 Created issue to add docs for the feature: getsentry/sentry-docs#8848 |
I cannot reproduce the issue following the above implementation on any supported platforms since the This can only happen when the If you have a repro for this case where the |
I can't share the code, but I will try to investigate myself. |
Description
Move consent from "global state" to "per event state".
When does the problem happen
Environment
Steps To Reproduce
Log output
The text was updated successfully, but these errors were encountered: