Review "phoneParsersToUse" parsing parameter

[wladimirleite]

As discussed in #2005 (comment).

Main ideas are:

• Have a parameter per application/parser;
• Review default options;
• Evaluate the creation of new subcategories to separate "internally" and "externally" parsed chats.

[wladimirleite]

@lfcnassif, it would be nice if we can close this before 4.2 is released.
It is more a matter to decide what (and if) we are going to change anything.
My suggestions, based on my own usage and feedback I have been receiving from other users (both forensic experts and analysts), are below.

1. Accept (and use as default) "perParser" (or some other string) for "phoneParsersToUse" parameter.
2. Set "all" as default for WhatsApp and Telegram parsers.
3. Create 3 subcategories for WhatsApp and Telegram Chats: "Internal Parser" (probably there is a better description), "External Parser" and "Other".

[lfcnassif]

Hi @wladimirleite,

I totally agree with the per parser configuration proposal.

it would be nice if we can close this before 4.2 is released.

I agree, unfortunately I'm not having enough time to even review what is ready and already scheduled for 4.2...

1. Accept (and use as default) "perParser" (or some other string) for "phoneParsersToUse" parameter.

Fine. But the per parser configuration itself would go into ParserConfig.xml, right? Or in another easier place for users?

2. Set "all" as default for WhatsApp and Telegram parsers.

I'm aware there are results differences between our and UFED parsers (both have their own advantages), but I'm not sure about changing the default to "all". Since it duplicates not only the conversation previews, but also instant messages, messages in the communication graph, the timeline chart, search hits, number of case items and storage requirements of course, some of previous points maybe can lead to wrong interpretations...

3. Create 3 subcategories for WhatsApp and Telegram Chats: "Internal Parser" (probably there is a better description), "External Parser" and "Other".

I generally agree. What would go into "Other", the app databases?

[wladimirleite]

Fine. But the per parser configuration itself would go into ParserConfig.xml, right? Or in another easier place for users?

I thought about using ParserConfig.xml.

I'm aware there are results differences between our and UFED parsers (both have their own advantages), but I'm not sure about changing the default to "all". Since it duplicates not only the conversation previews, but also instant messages, messages in the communication graph, the timeline chart, search hits, number of case items and storage requirements of course, some of previous points maybe can lead to wrong interpretations...

That are important points to consider.
So we can keep the current defaults, but create the new options.

I generally agree. What would go into "Other", the app databases?

Currently there are other files being included in these categories. As far as I remember, databases for WhatsApp and other types for Telegram. Maybe these files shouldn't be included in the chat category in the first place, but I suggested "Others" to avoid changing the current classification.

[wladimirleite]

By the way, I mentioned including in 4.2 because chats (especially WhatsApp) are among the most relevant evidences in many cases, and the changes should be simple to implement and review, once we decide what to do.
But I totally understand that there are ready PRs to be reviewed and not enough time to deal with everything.

[lfcnassif]

Currently there are other files being included in these categories. As far as I remember, databases for WhatsApp and other types for Telegram. Maybe these files shouldn't be included in the chat category in the first place, but I suggested "Others" to avoid changing the current classification.

I've already considered to move WhatsApp and other apps databases to the "Databases" category.

By the way, I mentioned including in 4.2 because chats (especially WhatsApp) are among the most relevant evidences in many cases, and the changes should be simple to implement and review, once we decide what to do.

I agree!