Browser: Automatic Context

[binarylogic]

All of our libraries include automatic context to help identify where the logs are coming from. I'm unsure exactly what's available to us on the browser, but it would be worth including pieces of data like a session ID or an IP address (if possible).

See #46 for the Node equivalent.

[leebenson]

There are libs such as FingerprintJS which give a hint as to what meta data is available to query by client-side Javascript directly:

userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3
language = en-US
colorDepth = 24
deviceMemory = 8
hardwareConcurrency = 8
screenResolution = 900,1440
availableScreenResolution = 877,1440
timezoneOffset = 0
timezone = Europe/London
sessionStorage = true
localStorage = true
addBehavior = false
openDatabase = true
cpuClass = not available
platform = MacIntel
...

The purpose of a lib like this is to create a unique 'fingerprint' hash, to help for fraud detection. It adds ~100-500+ms processing time per calculation, depending on the end-user device. All of this information singularly can be deemed 'meta', but combined can help to identify an (anonymized) repeat visitor.

Session ID would be harder, because there's no canonical/universal definition of what exactly constitutes a session. It would differ from site to site. Many sites wouldn't have any browser concept of a session and would handle it entirely on the server. I think that's best left to user-land code to figure out what's relevant, and expose accordingly.

Re: hostname - this can be parsed from window.location and included with logs. Here's an example from this Github issue page:

"{"href":"https://github.com/timberio/timber-js/issues/47","ancestorOrigins":{},"origin":"https://github.com","protocol":"https:","host":"github.com","hostname":"github.com","port":"","pathname":"/timberio/timber-js/issues/47","search":"","hash":""}"

We could include that by default.

Re: IP address - AFAIK, there's no client-only JS for obtaining the current IP. It'd be quite easy to do by including a CORS-enabled server-side endpoint that parses the request headers, and provides it to the Timber client.

There are three issues with this:

1. It introduces a race condition, since the server may not have responded by the time the request has been parsed. This could be solved by queuing logs until an initial response has been received, but it introduces extra time before logs start hitting Timber.

2. It requires a hosted service. This probably needs to be hosted/maintained by Timber.

3. (Probably the most important of all three)- an IP might be construed as personal data, which in some jurisdictions (e.g. EU GDPR), may require explicit concept before being provided to a third-party service like Timber. This is possibly the purview of a Data Controller and may be better handled in user-land code. I'm not an expert on data protection policy in this regard; might want to speak with someone with experience in this area first.