Allow for defaulting to private attributes

[bianchidotdev]

Hey hey 👋

Is your feature request related to a problem? Please describe.
No. We would like to be able to assume user attributes are private unless explicitly marked public. This would reduce the likelihood of accidentally exposing customer data.

Describe the solution you'd like
Some mechanism to have all attributes defaulted to private attributes with the ability to mark something as public.

Specifically, we could still use the all_attributes_private configuration setting, but add in additional logic in LaunchDarkly::UserFilter#private_attr? to allow for an attribute to be explicitly marked as public.

Example Usage:

config = LaunchDarkly::Config.new(all_attributes_private: true)
client = LaunchDarkly::LDClient.new("SDK_KEY", config)
user = { key: "somekey", custom: { ssn: "xxx-xx-xxxx", totally_ok_attr: "benign!" }, publicAttributeNames: [:totally_ok_attr] }
client.variation("feature_flag_name", user, false)   # sends totally_ok_attr, but not ssn

Describe alternatives you've considered
Unsure. The existing model either relies too much on any given developer's perfection or doesn't allow for any metrics in LD at all.

Additional context
N/A - But I'd be willing to help with a PR to push this through. For now, we are creating a custom class inheriting from LDClient and injecting this behavior in a sub-optimal way.

[eli-darkly]

Your rationale for wanting this makes sense. However, there are some issues regarding any kind of change to the user data model, making it tricky for us to do so on a per-SDK basis.

In the server-side SDKs, the user model basically belongs to the SDK in the sense that the SDK is doing all the flag evaluation logic, and the SDK is also responsible for applying the private attribute logic. So in that sense, we could add this behavior in Ruby even if none of the other SDKs nor the LaunchDarkly services know what publicAttributeNames means.

However, that's not the case for the client-side SDKs, which send the user properties to LaunchDarkly. If they tried to do that with a user that has publicAttributeNames, the feature wouldn't work, because LD doesn't know what that is. And so far it has always been the case that the user model in the server-side and client-side SDKs is the same, so it has always been safe to have back-end code pass user information to front-end code (like, by embedding the user JSON in web page metadata, or returning it from an internal REST call) which could then pass that user to the JavaScript SDK. That would no longer work if we did this, and since in Ruby the user is just a Hash rather than a specific user type, there's no way for us to even do any validation of it.

[eli-darkly]

In other words, if we did add this feature in Ruby, we would have to be very clear in stating that it will only work in Ruby code, and not if the same user properties are passed to any other kind of LaunchDarkly-enabled code. We might decide that that is OK, it's just not a kind of change we've ever done before, so I wanted to be clear on why that is.

[eli-darkly]

Another option would be to add the publicAttributeNames option to the SDK configuration, rather than to the per-user properties. I'm not sure if that would be adequate in your use case, or if you need to be able to set it differently for each user.

[bianchidotdev]

Hey @eli-darkly, that makes a lot of sense. The publicAttributeNames wouldn't work as well for us since we sometimes have different user objects derived from different types of user contexts (not always an end-user).

I'm comfortable maintaining this with a custom solution for now as I understand the desire to make SDKs reasonably in sync. Is there any way to make this a feature request for the LD SDKs generally?

[eli-darkly]

@michaeldbianchi I think the best way to submit a general product-level feature request is just via the support form - you can include a link to this issue so you don't have to explain it all over again, and then they will add it to the issue tracker for feature requests. That also keeps track of who made the request, so that if it does get implemented in the future, we can bring it to your attention.

[bianchidotdev]

This has been added as a feature request for launchdarkly sdks in general. I'll close this ruby-specific issue