Interest in implementing a cookie consent feature?

Development
1

The Open edX platform currently doesn’t have a proper cookie-consent screen that allows users to choose whether optional cookies and external scripts are used (for marketing, performance, etc.) This means it’s not compliant with some EU regulations (GDPR, Cookie Law, etc.) and I believe the CCPA as well (a California law). I’m part of a group working on implementing the enforcement side of things, but for 2U’s deployment, I think we’re likely going with a commercial vendor for the frontend components that actually show the consent screen. We’ll have to make that pluggable one way or another. But I’d also like to get in touch with other community members who want to implement this. It would be great to have an open-source option for the frontend so that Open edX deployments can be fully compliant from the get-go.

(In particular I’d love to hear from California or EU deployments that have already tackled this.)

More generally, the work is going to involve:

  1. Presenting a UI that allows users to choose which types of cookies they’re OK with
  2. Setting a cookie that encodes the categories the user consented to in a standardized way
  3. Adding conditionals around code (frontend and backend) that sets or reads cookies or brings in third-party scripts or tracking pixels so that those actions are only done when the relevant category is consented to
  4. Categorization of existing necessary and optional cookies set by the IDAs
  5. Adding monitoring and enforcement code for continued maintenance of cookie categorizations

The work done in the last three steps will be usable by all deployments; the only question is how that code learns what categories the user has consented to. Off-the-shelf UIs probably each have their own cookie format, so there needs to either be A) a translation step where a second cookie is set that contains the same information, but in an edX-standard format, or B) a slot for a plugin for each of frontend and backend that can read the cookie format of the deployment’s chosen consent solution.

I don’t think 2U can commit resources at the moment to evaluating and implementing an open-source option for the consent screen UI, so I’m hoping another deployer can pick up that work. I’d also like to hear opinions on how to do that translation of implementation-specific cookies to category checks.

2 Likes
2

@Tim_McCormack I think if you make a pluggable translation middleware, others could potentially swap it out if they need to. I’m imagining a middleware that’s specific to your solution that translates the cookie data to some standard interface and then the rest of the code interacts with that standard interface (for example a new cookie related setting on the request object.)

  • Have the solution specific middleware not be installed by default but add it in only for the edx.org deployment.
  • Make the interface that it’s implementing be code in the platform that’s documented so others know how to implement a middleware that interacts with the interface. eg. you could have a dummy middlewar that’s on by default that grants zero consent.

Not sure if that’s what you were looking for?

3

Yeah, that’s the approach I’m leaning towards. A middleware is probably a fine approach, although I was wondering if there’s some plugin mechanism or other dependency injection approach that would be less clunky.

(There would also need to be something on the frontend that likewise converts the solution-specific cookie or API to something that can be consumed by implementation-agnostic code.)

4

I would say that creating a filter/event hooks combo before and after the cookie is processed is a solid dependency injection mechanism. Although middleware swapping is also a pattern that has served well for extending the platform in the past.