Incentive system for data leaks

A central component of the technical system at DROPS is the incentive system for data submitters. This serves to provide data contributors with direct feedback as both feedback and reward. The decision was made not to follow the path of classic incentive systems (e.g. bug bounties for software or kickbacks for product recommendations), but to go our own way. In particular, because on the one hand there would be no means to pay data providers, such a payment could quickly create false incentives, and there is no way to verify leaked data. This last point is also the biggest difference to bug bounties for security vulnerabilities in software. With an appropriate description, these can be verified relatively easily by checking whether the described vulnerability actually exists and can be exploited. For leaked data, however, at most a superficial plausibility check is possible. Any further check would not only require the storage of clear data, but would also mean a great deal of personnel effort and, last but not least, increase the possibility of consequential damage, as clear data would not only have to be stored, but people would also have to access it to check it.

For these reasons, we have opted for an incentive model in the DROPS project that recognizes the work and risk of data submitters, but relies on them to act with intrinsically good motives when cooperating with the data trust module. The motives can nevertheless be very different, be it to uncover data leaks, to protect data subjects or generally supporting a good cause. In the system planned and implemented to date, data submitters can then track whether their data submission has been processed, whether data records have been recognized in it and whether these have been used for a warning message. Only a positive or negative response is given in each case, no further details.

In the picture above you can see the input mask(s) for the incentive system. In order to also protect the data submitters and not to create and store unnecessary data, we do not require the creation of a user account for both the submission and the incentive system. The main reasons for this are that we do not want to store unnecessary data in order to avoid having to do so in the first place and thus protect the data submitters. Furthermore, it is also advantageous for the legal situation of the platform to store as little data as possible. The data submitters are assigned an anonymous token after the upload. This is loosely linked to the uploaded data, but not to the data of the data submitter.

In the second screen section, you can see the result at the top after data submitters have uploaded a data set. The uploader can check whether the data has been processed, how many files were included and whether identities were extracted. This is intended to provide feedback to data submitters without creating false incentives or weakening the platform’s security and anonymization concepts.