Currently SimpleReport is the only kind of post-analytics we do. This can definitely be expanded.
Some examples of post-processing steps we likely want in the core onionscan base:
Use the new Database functionality to compare reports to automatically find correlations.
Automatically identify new onion services.
Perform site-specific follow on actions e.g. if we know that a site stores all user profiles under /user?name={username} we can use that information to prepare an even more detailed report.
Any analytics performed by OnionScan should be modular and configurable. It might make sense for OnionScan to accept a json formatted config file detailing the exact flow that it should undertake.
At the same time, we should try to minimize the amount of code dedicated to analytics that is best performed by other dedicated applications (one example that comes to mind is stylometry that requires ML models and databases of known samples - we likely do not want to support that).
Currently SimpleReport is the only kind of post-analytics we do. This can definitely be expanded.
Some examples of post-processing steps we likely want in the core onionscan base:
Any analytics performed by OnionScan should be modular and configurable. It might make sense for OnionScan to accept a json formatted config file detailing the exact flow that it should undertake.
At the same time, we should try to minimize the amount of code dedicated to analytics that is best performed by other dedicated applications (one example that comes to mind is stylometry that requires ML models and databases of known samples - we likely do not want to support that).