Does this conversation sound familiar?

  • Hi, we love <<your open source tool>>! We encountered some problems when using it with our data. Can you help us?
  • Sure, can you send us a small example data set to reproduce the problem so we can fix it?
  • Sorry, can’t do that, the data contains sensitive information that we are not allowed to share with anyone.

I’m pretty sure it does. And to remedy the situation, our friends from the Fault Tolerant Systems Research Group have developed the VIATRA model obfuscator.  Ábel Hegedüs tells us more about it. Enter Ábel:

As developers of a model query framework, we strive to support all possible use cases and environments where our users may wish to apply our tool. Since queries are fundamental for any model-driven application, scalability is one of our main objectives. Combining this with the intricacies of modelling frameworks (such as EMF), it is very difficult to tell from limited information whether poor performance stems from EMF, our tool, the model, or the application that actually handles the model.

In many cases, coming up with a minimal example that reproduces the problem and can be shared with the developers is very hard, while sharing the original model that demonstrates the issue is not possible. However, in most cases, the exact information in the model (such as string values storing confidential data) is not relevant, only the graph structure (containment hierarchy, references, number and distribution of instances).

In order to convert confidential models into shareable examples, we developed a simple model obfuscator that can traverse input EMF or XML models and rewrite string values with obfuscated content. Since using the same string values in multiple places in a model often signifies a relation, the obfuscator produces the same output for the same input deterministically. However, the obfuscation uses a seed that is not stored in the obfuscated model and is only available to the user who performed the obfuscation.

The model obfuscator is available under the EPL, including

  • a runtime component that provides the API (available from an Eclipse update site),
  • a simple Eclipse UI integration component for running the obfuscator on any EMF model loaded into the reflective editors (available from an Eclipse update site),
  • a headless console application,
  • and a Maven bundle to use as dependency.

Let’s see how it works:

Before obfuscation (menu contribution at the bottom):

 

And after the warning message (see featured image on top of this post), we get some log information

We get the “after” view (read-only resources are not modified, editor marked as dirty and saving is left to the user):

We hope that our obfuscator can be of use to others and would be glad to for any feedback, questions, suggestions or contributions. Simply open a new topic at the VIATRA Eclipse Forums or send a direct message to me. Finally, if you use EMF, check out EMF-IncQuery to boost the performance of your applications with incremental model queries.

Happy obfuscating!

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This