-
Notifications
You must be signed in to change notification settings - Fork 3
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
Limit activations #1367
Comments
Sounds reasonable. We should definitely implement some limitation. Since we don't have a testing scheme for the mobile app i actually have to reactivate my card quite often if i do some local tests on my device. |
On the other hand copying a pdf is even not a big deal (which can be done atm). I think we should display the message "Please check also for a valid id card/passport" (which we do only for static cards at the moment) in any case. |
This is already what we communicate so far. For 100% certainty, an "amtlicher Lichtbildausweis" must be checked (we even have this hint in the 3-step instruction of the verification dialog).
Imo, we should save this for the static codes, as these can copied super easily, and it is even more important to check the Ausweis.
Yes, it is currently possible, but it's not as easy as clicking on a link. You'd have to scan a qr code (so you need at least a second screen or a physical copy of the PDF). But yes, the "problem" already exists here in a slightly milder variant. |
@dkehne we should maybe also talk to the customer about this and discuss the amount of activations |
Maybe it could be also an option to store the "LastActivationDate" and limit it to a particular time period @michael-markl ? |
@f1sh1918 Can you elaborate on that? I do not get it yet. |
As we set a |
So you propose to allow at most one activation per week (or a similar time period). I think a slightly higher number of activations in a substantially longer period (e.g. 5 activations per year) could be more effective when it comes to preventing abuse while at the same time allowing to reactivate in the case of a phone switch / app reinstall / other activation problems without having to wait for a week until the next activation is allowed. |
As the entitlementcard is only valid together with an ID card i don't see a big problem from the non-technical perspective. I would discuss that limitation earliest we have a practical abuse case... |
@dkehne Taking this perspective, a dynamic element on the screen would be completely unnecessary. I agree, there is formally no necessity to do it (as we say the card is only valid with a passport), but I think not doing it questions the dynamic element alltogether. [Also, currently, we cannot detect whether there is any abuse. Maybe we can implement some detection mechanism (e.g., count the number of activations per card and check for outliers) before we implement a limit] |
Yeah sounds good as well. maybe we count the amount of activations first and in a second step we implement some kind of alert if it becomes a three digit number or sth. like that |
Is your feature request related to a problem? Please describe.
Currently, an activation code can be used arbitrarily often to activate a device.
This enables owners of a card to "share" the same card with others by simply sharing the activation code:
Whenever one of the non-owners wants to benefit from the shared card, they can simply activate the card using the activation code before walking into the accepting store.
With the introduction of the deep link activation workflow this is as easy as clicking on a link.
This type of systematic abuse should be avoided.
Describe the solution you'd like
Base solution: We can simply limit the number of allowed activations, e.g. a maximum of 5 activations are allowed per year per activation code.
Possible extension: After human review, the number of allowed activations can be raised for a specific activation code (e.g. for cases when the user switches his phone often or deleted and reinstalled the app often)
Describe alternatives you've considered
(none)
Additional context
#1244
The text was updated successfully, but these errors were encountered: