Log statistics about javascript support of whistleblowers submitting information

[fpietrosanti]

Following the Javascript/Non-Javascript discussion i think that we need to move out from the "subjective and philosophical point of view" and move to an "objective and analytical approach".

I am in favor of extensive use of Javascript due to that capability it does provide for security and usability.

I think, but that's a subjective point of view, that 99.99% of whistleblowers submitting information to a SecureDrop platform use the stock Tor Browser Bundle with Javascript enabled.

If 99.99% of users approaching a SecureDrop installation have Javascript turned on, i think it would be a reasonable understanding, that it's not required to have a Javascript-free submission interface, with all the limits that it provide.

The experience we had with 32 media on GlobaLeaks is that not a single user even blamed for the system being based on Javascript, but it's possible that who was working with javascript disabled, just enabled it. So it's not a valuable statistics.

This ticket is to propose the server-side logging of statistics of access by the whistleblowers, to detect how many users have Javascript turned on and how many users have javascript turned off.

Those kind of statistics should be exposed with a public OpenData feed (just writing to a .csv file) aggregated data, updated on a daily or weekly basis (to prevent time pattern correlation on the amount of submission).

Given that statistics the SecureDrop project would have a set of data to be analyzed to objectively evaluate if the denial of use of Javascript is reasonable or not.

[garrettr]

not a single user even blamed for the system being based on Javascript

Most users aren't aware of Javascript, let alone the associated features/risk tradeoff.

The statistics you suggest collecting would not be useful. We know only a small fraction of users understands, chooses to disable Javascript as a result of, the security risks it entails. Trying to determine if users should be encouraged to disable Javascript based on the number of users who have Javascript disabled is self-defeating circular logic.

I do not think it can even be argued that, given our threat model, our user's security would benefit from disabling Javascript - the question is, should we enforce it, encourage it, or leave it totally up to them?

It would be interesting to do a UX study on #101. Should we even allow users to upload files with Javascript enabled? Should the warning be big and scary, or subtle and unobtrusive? Should we ask them questions, as Globaleaks does, to try and determine if they understand the tradeoffs involved?

[fpietrosanti]

@garrettr Due to the current approach i'm ok with encouraging users to disable javascript as per #101 , but i'm pointing out that we don't have any data that tell us if this "security measure" is effective or not.

So, we need to collect this end-user behaviors:

• Log how many users approaching the submission interface have JS disabled
• Log how many users after having saw the Javascript warning, effectively submitting information, have JS disabled

Only with this kind knowledge of user behavioral data we will be able to determine in a scientifically non-questionable way if HTML only interface is effective or not (where effective means that is having an effect in improving the whistleblower security).

[garrettr]

I agree with the above comment. Would you support renmaing/redirecting this issue to "Design user research study on effectiveness of JS warning UX" or similar?

I'm not sure if we should deploy the "JS-blocking UX" logging on production sites or sponsor a user study instead. While this specific kind of data would not be especially identifying (and, as you pointed out earlier, we can aggregate/normalize to mitigate timing analysis), I am afraid it at least technically contradicts our no-logging stance and might make some users uncomfortable.

[fpietrosanti]

@garrettr Ok for renaming the ticket :-)
Regarding the logging, it's always a matter on "how logging is done", it should just be specified how to do it in a way that preserve 100% the integrity of privacy .

For example we may completely avoid "generating logs" but simple counters to be incremented and written into database (being sqlite or a flat file):

• 1 counter: how many access to the submission interface with JS enabled browser
• 1 counter: how many access to the submission interface without JS enabled browser
• 1 counter: how many submission done from browser with JS enabled browser
• 1 counter: how many submission done from browser without JS enabled browser
• 1 counter: how many lookups (WB coming back) has been done from browser with JS enabled browser
• 1 counter: how many lookups (WB coming back) has been done from browser without JS enabled browser

Those data would be simple integer with no timestamp correlation of any kind, so not representing any logging/privacy risks, while still providing very valuable data about the whistleblower browser JS/no-JS capabilities.

We may tweak the interface in a way so that, if the browse have javascript enabled, the submission forms will get added 1 single parameter (that will cause incrementing the counter of action/JS-ON rather than action/JS-OFF).

What do you think?

[garrettr]

Well put, @fpietrosanti. I am convinced that we could put this on production deployments without compromising any of our security goals (although we should check with each deployment owner anyway). Let's finish #101 and then revisit this.

[Taipo]

to objectively evaluate if the denial of use of Javascript is reasonable or not.

@fpietrosanti I am not sure myself whether this is a correct gauge of whether or not it is reasonable for a SecureDrop have javascript used in a manner that makes it required by its users.

Yes I agree that people that use javascript enabled browsers to submit for example government level leaks are putting themselves at a 'certain level' of risk that is for certain irregardless of the amount of sources that do so. Having javascript enabled for example and also using client side addons which are fairly specific to SecureDrop could be used against them in a court of law as a means of generating the grounds for further interception warrants, and in some countries might be enough to indite a source.

The real general risk to anyone using any web browser however is having both javascript enabled and installing and enabling flash, which can be done on the firefox side of the TBB by users not aware of the pitfalls ( Evercookies / FOXACID type attacks ).

But none of that is my primary concern as it can at least be attributed to the non-optimal opsec practices of the user rather than their security being compromised because of the opsec of SecureDrop. A simple warning could be suffice there.

My concern is having a method for a third party ( concerned citizens or even a SecureDrop monitoring facility or application ) to determine whether or not a EGOTISTICALGIRRAFE type of exploit has been inserted into a SecureDrop.

We will lose that potential tool of client side verification by any potential source, if javascript is used.

[fpietrosanti]

@Taipo the whistleblower does not have the capability to do that kind of verification step.

Any security feature or design that's not effectively in the hands of the average user of the software implementing those feature, it's just ineffective. The security is measured by "how much" a measure is effective in the "context of use" and not by it's own theoretical design.

I am confident that the approach to security will change moving from a theoretical security (like it's done when evaluating encryption algorithm) to effective security (like it's done when evaluating overall security measure of a complex system).

The analysis of effective user's attitude within the respect of Javascript use, i'm confident will be a first step towards this evolution.

[garrettr]

Leaving this open. We should consider performing user research on the effectiveness of our "disable javascript" UX. I still believe that it is important to disable Javascript and do not anticipate reversing our stance on avoiding the use of Javascript in the source interface.

[justintroutman]

@garrettr Have you considered hosting a small "UX onboarding" demo, where invitees run through the SecureDrop process and provide feedback? That can be an easy way to reach a consensual view on what the real bottlenecks are, including the JavaScript disabling issue.

[garrettr]

@justintroutman I think that's a great idea! I've never done anything like before. Might you be interested in advising or helping out? 😄

[justintroutman]

@garrettr It would be my pleasure to both advise and help out! Let's connect on this soon.

[eloquence]

We discussed this on our old issue review today. We're closing this for now as the original issue (logging of JS usage) is not something we anticipate doing -- both due the perceived/actual sensitivity of logging, and the relatively low utility of the information for development purposes. We'll certainly want to investigate the UX and security aspects of JS usage further, and may create separate issues for that.