Rethink Tor log file management

[riastradh-brave]

There are various messages that a web site can cause to appear in the tor daemon log. For example, it can try to load a .exit URL, an old feature of Tor that has been disabled because it served as a deanonymization vector -- and that triggers a log message at log level WARN.

• Denial of service: A web site could cause unbounded growth of the tor log file.
• Breadcrumbs for deanonymization: If a web site could elicit two distinct messages, the site could interpret them as as bits 0 and 1 and use Brave as a binary channel; pick a uniform random 256 bit token and run a web site that writes that token to the log file, with this crafty encoding; and then seize a user's laptop, even if it has been turned off, and use the messages in the log file as evidence the user visited a particular site.

The tor manual recommends level NOTICE and avoids putting sensitive information -- whatever that means -- in the log at that level. We could reduce the log level to WARN, but that would still include the .exit warnings.

We should:

• [ ] consider filtering useless warnings like .exit
• [ ] truncate the log (Tor Browser truncates it to 1000 lines)
• [ ] provide an alternative way to get at the log file (like the Tor Browser's 'copy log to clipboard')
• [ ] avoid writing log file to disk at all

Prompted by https://hackerone.com/reports/578180.

[riastradh-brave]

To keep it simple, we should keep it in memory and avoid writing to disk at all, but we need to investigate how to capture stderr from a subprocess, and where to put a 'copy to clipboard' operation in the UI.

[xiaoyinl]

@riastradh-brave It seems Tor project has no plan to fix this in their code.

According to the manual, messages can be selected by domains. The ".exit" message is in LP_APP domain, so I think we can raise app domain logging level to "err" and keep other domains at "notice" level.

This is my proposed patch: https://github.com/brave/brave-core/commit/e3871e8f7e1f15fe1320e89978bc5478e7ffd3fb