Hi All,
Thanks for this really interesting discussion. That is exactly what I envisaged in this group: technical and political discussions between different interest groups.
We should always make a distinction between actual practice and our recommendations for libraries. Of course it will be ideal, if everyone will adhere to the recommendations ...
I more or less side with Peter S. on the point that permanent targeted Identifier should be sufficient for personalisation (without being addressed by name). Getting consent from the user via "activate personalisation" sounds good and GDPR compliant to me as well, if the user gets informed that
"by pushing this button, I agree that the service provider stores my person related data (ID, affiliation, entitlements sent by my IdP, my IP address sent by my client, and my actions on this platform). Only if I want to receive emails from the service or if I want to be addressed by my name, I will add my email address and name respectively, but this is not needed for any other personalisation features like 'point me to the last document and its last page I read', 'my last searches', <include your personalisation feature here>, etc. Whenever I wish to, I may request to see and to have deleted all these data stored about me."
I propose that we address this use case in more detail in our recommendation than it is by now.
If the service decides for trading personalisation features with name and email address it should make this also transparent. But we would not recommend such a trade in our recommendations.
Once again: Thanks a lot for this really fruitful discussion.
Cheers,
Peter G.
Am 19.07.19 um 15:08 schrieb Peter Schober:
Hi Meshna and thanks for chiming in.
- Koren, Meshna (ELS-AMS) M.Koren@elsevier.com [2019-07-18 22:18]:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
In your service, OK. Some of the issues I mentioned are specific to sites where account creation includes setting Yet Another Password, which IMO has too many drawbacks to be a viable option only in order to get access to personalisation functions. Lets ignore that since it's not applicable here.
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place.
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products
You'll understand that all we have to go on here is your word that this is the case (and that it is the case Right Now). Because you fully have ability to perform such tracking once an institution releases a suitably persistent identifier. Will that remain that way a few weeks down the road, a few years? E.g. if someone discovers thi a new way to generate "usage patterns" from the current site(s)? What if management and/or ownership changes?
I fully believe you when you state the above but you'll have to realise that this may not be good enough for everyone.
And IDPs would have to /always/ send an identifier along that technically /already/ allows you to track all users' every move -- just in case one of them ever decided to "activate personalisation" and provide (even) more information about herself.
Speaking of personalisation: Wouldn't it suffice if I just let you know that I want to activate personalisation, without also providing more personal data? I don't see why the former would require the latter.
Sure, email notifications won't work without providing an email address. But maybe that's fine for me a I'm not interested in recieving emails? And I certainly don't need to be greeted by my own name and you don't need my name in order to provide a personalised UX. So the whole "because GDPR" isn't all that convinging if you force me to reveal more data than necessary for procesing (if I wanted peronsaliastion) and then use my freely given (?!) consent as justfication for that processing?
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Sure, completely agree.
But IDPs are still confronted with the hard question of whether the potential for hypothetical, individual activation of personalisation features justifies always releasing data to the SP that factually allows it to track every subject's every move (whether the SP promises to do that today or not).
The main -- or in fact *only* -- argument to always take that risk as an IDP (and arguably lessen all users' privacy) is exactly the above: The nightmarei-sh UX subjects will be exposed to /if/ they positively need personalisation features but the IDP doesn't release a suitable identifer. That's to be balanced with the number of subjects who don't care about personalisation (or who are not prepared to accept the added requirement for personal data, in your example) and for whom always sending along a suitable identifier increases their exposure and lessens their privacy.
Happy to hear counter-arguments or dissenting observations!
Best regards, -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l