Embed the source guide in the source interface?

Bonjour,

It seems useful to add part of the source guide in the source interface. Are there reasons not to do so ?

Cheers

1 Like

Whoaaaa I like that idea a lot… especially if it gives the organization a chance to inject additional language to the guide.

There may be historical finger-printing reasons preventing us from implementing this idea that aren’t apparent to me. Perhaps @redshiftzero can chime in here ?

1 Like

This is a good idea - the concern in the past with linking to the source guide had been in providing timing information to third parties (the page hosting the docs) about sources accessing SecureDrop. The concern with just copying information from the source guide was with UX (walls of text are scary to users) and maintainability (i.e. how we would keep the content DRY). Kushal had a great idea recently about this: include the SecureDrop Source Guide as a link in the footer. We need to weigh the risk of providing timing information with the risk of OPSEC failures or just being scared off if the process is not explained well. In my view, providing timing information about any Tor user accessing the source guide to a third party is less important than sources otherwise not knowing to access our source guide and read the information there. Also curious what you think @mickael on this.

1 Like

Are the docs available through a Tor Hidden Service? This would likely reduce an adversary and/or a third party’s ability to fingerprint, though hosting docs (or subset of) as-is on the source interface would likely be best from a UX/internationalization point of view.

I am also apprehensive of allowing orgs to modify source-interface-hosted docs, as stated by Mike (not only SD instance but potentially which SD instance). Validating contents (no js, images, urls…), limiting length and adding padding makes this less trivial to implement.

Could you explain more about this please ?

One way of fingerprinting traffic could be via traffic volume over time. If, for example, a hosted user guide is larger than others, it would be easier for an adversary to distinguish it.

That troubles me.

The source connects to the source interface and loads the index page, the size of which varies depending on the locales that have been activated and the logo being replaced or not. All of which is trivially measured by visiting the source index page. In that case I see how it would be possible for an adversary to fingerprint the first access to the source interface by matching the size of the payload in the time interval it takes to load it.

I understand the same reasoning applies to the source guide, for the same reasons. I understand why further modifying (i.e. in addition to the logo and the list of supported languages) the documentation would make it slightly easier to fingerprint because it would change the size of the payload transmitted when loading it.

I do not understand why content validation, length limitation (I don’t know what it means sorry for my ignorance :wink: would help ? I intuitively understand how random padding would help avoid this problem however.

Thanks for educating me :slight_smile:

Sorry if I was unclear, length of added text influences the size of the docs and thus would likely require enforcement of a global doc size limit.

Some work has already been done on the broader fingerprinting issue, though I am not yet familiar with it: https://github.com/freedomofpress/fingerprint-securedrop

1 Like