Recording Privacy Violations: Exploring Solutions for Package Control and Enforcement

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Privacy enforcement comes with a lot of interesting questions regarding what they mean and how to record them.

For example, if a team has a package and believes the API is complete, they should be able to prevent privacy violations. In this scenario, privacy violations are more problems of the consuming team then of the owning team. For the problem side of this anlysis, you would think that the todo should be recorded on the violating package’s side (which is what we do today). To allow the owning team to have better control and be able to prevent privacy violations, they are likely better suited for the package defining the API (we don’t have this).

If, however, the API is not complete and the team has privacy violations on a package, those are more the owning packages problem and the consuming team should likely not get bugged that they are violating privacy (although they might want to know…)

Likely, we have to refactor how packwerk does package_todo to support this. The cool thing is, we got lots of time with Rafael from Rails Core team and shopify to talk through this and he sees the same issue and is on board with finding ways to solve this

What if we created the capability to record privacy todos in two places?

It might look like this:

  • We require different todo keys, like incoming_privacy (in the provider) and outgoing_privacy (in the consumer).
  • Privacy configs might be
    • false: as today
    • incomplete_and_enforce: record only incoming privacy
    • complete_and_enforce: record incoming and outgoing privacy
    • strict: don’t allow any todos

Hi @stephan, sorry I’m just seeing your comment now!

We definitely see this problem at GitHub and even view it as the highest priority issue with Packwerk for us currently. I’m happy to report we have come to the same conclusion as you and agree that, depending on where in the lifecycle of a particular package you are, the todo items might make sense belonging to different teams.

Short term, we’re planning on a bit of custom tooling to do bidirectional tracking, (essentially complete_and_enforce as described above but with generating an additional todo type file) but hopefully in the future this sort of logic can work itself upstream.

Thanks for sharing and starting this discussion!