Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
I sometimes have a temptation to report some entries from our logs on public fora like StackExchange to get help form the wider community on isolating root causes.
However, I rather refrain from that because they may reveal some details about my employer. This is particularly the case for:
Do you obfuscate such details before publishing them?
Can you recommend any automated obfuscators?
When publishing data into the public you should always anonymize the data, not only log-files. Also e-mails, documents, etc...
You could try the open-source Python based log-anon.
This tool was designed to replace sensitive fields in customer's logs with anonymized values, while generating a lookup table. This is sometimes useful to comply with the following requirements:
- Logs are stored for research or training purposes after the log analysis job has been completed, and no data that allows identification of the customer should be present.
- Privacy laws (ex. informatique et libertés) or regulations prevent the customer from giving over sensitive or personal data.
Look at the examples, it looks promising. You should be able to make a JSON definition of all the stuff you want to anonymize and keep re-using it on your log-files. Be sure to manual check some parts of the file before sending it out. Checking everything might be impossible for extremely large log-files.
Regarding privacy protection in error logs/reports, you may find the following research papers to be interesting, as they present the state-of-the-art of error report obfuscation and minimization:
2008: http://research.microsoft.com/en-us/projects/betterbug/castro08better.pdf
2011: http://www.cercs.gatech.edu/tech-reports/tr2009/git-cercs-09-14.pdf
2014: http://www.gsd.inesc-id.pt/~jmatos/papers/jmatos_esop2014.pdf
2015: http://www.gsd.inesc-id.pt/~jmatos/papers/jmatos-issre2015.pdf
2016: http://dx.doi.org/10.1515/popets-2016-0002
These systems are based on the idea of obfuscating sensitive information while ensuring the reproduction of the faulty execution. This is done by replace the information in the error report by alternative information that results in the same observed failure:
The systems at links [2008,2011] re-execute the application, using symbolic execution, through the original execution of the user that induced the failure; then path condition analysis is used to determine which are the inputs that satisfy such path and replace the user's by an alternative one.
The systems [2014,2015] also resort to symbolic execution, however they re-execute the application while searching for an alternative execution path that also leads to the observed failure. Then an alternative input is computed, also using path condition analysis.
Finally, the last link refers to a different type of approach that targets GUI-based inputs. In short, it consists of minimizing the disclosure of information by removing from the error report all entries that are not required to reproduce the problem.
Hope you find them useful.
Why do you care about what we are doing ?
If for example I work for the NSA I would need 5 different authorizations to publish even a single line (or not, I don't work for them).
On the other hand if your employer is working with open source software then there is nothing wrong with publishing it, one of my previous employers explicitly allowed this as part of their internal opensource training.
I also don't understand why do you need an obfuscator- you are not going to publish hundreds or even ten's of line, why not do it manually ? it will be quicker then installing and configuring an external software.
