GDPR compliancy ! May 25th!


#1

Dear IC2/ICVA team,

In order to be GDPR compliant, a few changes are required on the captive portal part of IC:

  • We need to have the possibility to delete data
  • Users must have the choice (by default) to not allow storage of their personal data (no first or last name). Statistical data is still OK-ish

The deadline for application of GDPR is quite close : May 25th 2018

FYI:


Feature Requests for InControl2 and Captive Porthole
#2

Hello,

Clock si ticking, we will need to source external captive portals if Peplink does not change its current implementation.

In short we need:

  • to remove visibility on all the users in the dashboard of captive portal
  • to have an option to not store first and last names but only non identifying info
  • to have the possibility to delete entries
  • to have a specific “data manager” user profile that can export and edit personal data captured

Kr,


#4

As an interim alternative, can’t you just switch to federated identity using one or more of the Social site integrations?


#5

We are currently providing a captive portal option “Allow to Skip Sign-in”:

When it is checked, a “No thanks” link will be displayed at the bottom of the social sign-in page. Clicking it will sign in the service without needing to sign in any social network. No personal data will be collected in this case.

If you do not have the social mode but other modes enabled (e.g. e-mail), you could enable the Open Access at the same time. So if a guest does not want to provide his/her e-mail address, he/she could choose the Open Access mode.

For allowing guests to deleting their data, we have the following proposal. After a guest signed in any one of the modes (except the Open Access mode), the page will display a link “Remove my personal data” at the page’s bottom:
image

Clicking it will remove all the information of the guest that the system collected. What do you think?


#6

Hello,
this is not enough unfortunately.

All data is stored and displayed in InControl without limitation or control. If few days, weeks later a user wants to know which data is stored and to have itremoved, administrator must be able to do it.

We must also be able to detect data leaks. Needless to say that with current implementation, anyone logging into the portal can see all the last social logins with names, age , picture, profile etc… All this should be removed. Maybe add an option on captive portal “store only anonymised information” that would then not store profile link, name etc but only generic infos.

@scuba_steve These federated entities still ransfer part of the info to ICA and ICA stores them afterwards.


#7

In addition to what I proposed, what if we do the followings as well?

  • Change the existing user role “Organization administrator” to “Super organization administrator”. Add a new role “Organization administrator”. Remove captive portal report and social data access right from all user roles except Super organization administrator, Captive portal administrator/report viewers. For non-privileged users, they could only see the social network type (e.g. “Facebook”) and visit counts. Names, birth date, etc will be hidden.
  • In the Social User List of the Captive Portal Reports page (for Super Org Admin and CP Admin), and Client Details screen (for Super Org Admin), display a Delete button to every social user record. They could delete the social user record by clicking the button.

What do you think?


InControl2 getting (and displaying) personal information
#8

Michael,

It seems to fit the need. One specific point, it would be more adapted to assign the role of Captive Portal management to one user (the appointed data privacy officer) than to give full admin rights to this person.

But it is already very good if we can get this in ICVA. Still 2 months to go ^^

Thanks !


#9

You, as an organization administrator, could assign the data privacy officer as a “Captive portal administrator” or “Captive portal viewer”. So only he/she will be able to access the social user information. Even you could not access (unless you change yourself to be a super org admin).

We will work on the required feature as soon as we can.