[Fim4l] Scopus

Peter Schober peter.schober at univie.ac.at
Fri Jul 19 15:08:52 CEST 2019


Hi Meshna and thanks for chiming in.

* Koren, Meshna (ELS-AMS) <M.Koren at 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



More information about the FIM4L mailing list