I think it makes sense for some more complex obfuscation strategies to be aware of the context in which they are operating. Even simple ones. Some examples
You have a table of phone numbers which must be unique and valid after obfuscation. One way to achieve this would be a caesar cipher or a simple rotation. Neither of these do a particularly good job of obfuscating the data though. An approach we have used in the past is essentially to replace the first 7 digits of the record with the ID so "415-000-0000" would become "415-123-4567" for user record 1234567
You have a table with some sensitive data and some not. Perhaps your users table. You wish to obfuscate emails only of non-engineers. To do this you need the context of the record.
You store phone numbers both normalized and "pretty". You need to consistently transform the number in both cases so that the normalized and pretty number are the same.
My thought is that one would modify lib/polo/translator.rb#L50 to pass new_field_value(field, strategy, instance), and call strategy with an optional second argument of strategy.call(value, instance). I believe this would be backwards compatible too.
I'm happy to build this myself, just want some assurance maintainers are open to it.
I think it makes sense for some more complex obfuscation strategies to be aware of the context in which they are operating. Even simple ones. Some examples
My thought is that one would modify lib/polo/translator.rb#L50 to pass
new_field_value(field, strategy, instance)
, and call strategy with an optional second argument ofstrategy.call(value, instance)
. I believe this would be backwards compatible too.I'm happy to build this myself, just want some assurance maintainers are open to it.