From 50efb38ccc18234db8295a103334bd8c5deb13af Mon Sep 17 00:00:00 2001 From: Feanil Patel Date: Fri, 22 Jan 2021 13:05:55 -0500 Subject: [PATCH] Add Anonymous ID related ADR. For a given course/user tuple, anonymous ID will not change once it has been generated and saved. --- .../0001-anonymous-user-id-generation.rst | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 common/djangoapps/student/docs/decisions/0001-anonymous-user-id-generation.rst diff --git a/common/djangoapps/student/docs/decisions/0001-anonymous-user-id-generation.rst b/common/djangoapps/student/docs/decisions/0001-anonymous-user-id-generation.rst new file mode 100644 index 0000000000..ea42c73855 --- /dev/null +++ b/common/djangoapps/student/docs/decisions/0001-anonymous-user-id-generation.rst @@ -0,0 +1,56 @@ +Anonymous User Id Generation +-------------- + +Status +====== + +Accepted + +Context +======= + +The student app provides a mechanism to generate multiple anonymous ids for a +student. The anonymous ID can be independent of all courses or it can be +course specific. To generate the anonymous ID, we currently hash the user's +``id`` with the Django ``SECRET_KEY`` and a course key if provided. The +mapping between the anonymous ID and user ``id`` are saved in the +``AnonymousUserID`` table. + +As it stands, if the ``SECRET_KEY`` is rotated students would get new anonymous +IDs starting immediately after rotation. This can cause downstream issues +where the IDs are output from the system. For example, the IDs are in tracking +data and could be used to track a user's activity through a course for research +purposes. + +Decisions +========= + +Once an anonymous ID is generated for a user in a particular LearningContext +(either a course or some other unit of learning), it will remain that way even +if the secret used to generate the ID changes. For any context where an +anonymous ID does not already exist, a new ID will be generated using the +latest ``SECRET_KEY``. + + +Consequences +============ + +By keeping old IDs static, we increase the risk that if the salting +data(``SECRET_KEY``) is leaked, then it can be used to determine and correlate +all anonymous IDs associated with a particular user across all courses. We +believe that this is a worth while risk to not break downstream services that +are using anonymous IDs during the lifetime of a course. + +Rejected Alternatives +===================== + +Make Anonymous IDs Randomly Generated +------------------------------------- + +The function that generates anonymous IDs, has the option to not persist the +newly generated ID. In this case, it would give a new anonymous key each time +the function was called, instead of being consistent other than at key +rotation. The downstream consequence of changing the SECRET_KEY that often are +unclear so we opt not to do so at this time. In the future if we can ensure +that the newly generated IDs are always persisted, we could more safely use +random generation.