On 2012-03-26, Mike Perry mikeperry@torproject.org wrote:
Thus spake Robert Ransom (rransom.8774@gmail.com):
Provide information about bridge sources to users
BridgeFinder MUST provide complete information about how each bridge was obtained (who provided the bridge data, where the party which provided the data intended that it be sent to users, and what activities BridgeFinder extracted the data from) to users so that they can make an informed decision about whether to trust the bridge.
I like the idea of passing bridge authentication + attribution up to Vidalia via POSTMESSAGE somehow. However, encoding it properly is likely to be problematic and situation-specific.
Perhaps you should have called your IPC command “+POSTMESSAGE”.
It also feels weird to have this be a MUST, especially if we're not sure how it can be done right..
It must be done, even if it requires a more thoroughly designed and specified IPC protocol than you expected.
BridgeFinder MUST authenticate, for every piece of discovered bridge data, the party which provided the bridge address, the party which prepared the bridge data in BridgeFinder's input format, and the time, location, and manner in which the latter party intended that the bridge data be distributed. (Use of an interactive authentication protocol is not sufficient to authenticate the intended location and manner of distribution of the bridge data; those facts must be explicitly authenticated.) These requirements are intended to prevent or mitigate several serious attacks, including the following: * A malicious bridge can 'tag' its client's circuits so that a malicious exit node can easily recognize them, thereby associating the client with some or all of its anonymous or pseudonymous activities. (This attack may be mitigated by new cryptographic protocols in a near-future version of Tor.) * A malicious bridge can attempt to limit its client's knowledge of the Tor network, thereby biasing the client's path selection toward attacker-controlled relays. * A piece of bridge data containing the address of a malicious bridge may be copied to distribution channels other than those through which it was intended to be distributed, in order to expose more clients to a particular malicious bridge. * Pieces of bridge data containing the addresses of non-malicious bridges may be copied to other-than-intended distribution channels, in order to cause a particular client to attempt to connect to a known, unusual set of bridges, thus allowing a malicious ISP to monitor the client's movements to other network and/or physical locations. BridgeFinder MUST warn users about the above attacks, and warn that other attacks may also be possible if users accept improperly distributed bridge data.Warning users about technically complicated potential attacks is unlikely to substantially protect them in practice, and will have many negative consequences wrt usability... There is a right place to document this stuff, but I'm not sure the BridgeFinder app itself is that place.
I expect that a bridge datum's distribution channel will need to be ‘fuzzy-matched’ to the location where a user received it. That will require, at a minimum, telling the user where/how the datum was intended to be distributed, where/how it actually was distributed to the user, and that if those items do not match, the user should throw away that datum.
Warning in the event of unexpected behavior that actually happens is a good plan. But this again is something that requires another channel through Vidalia. I doubt most BridgeFinders will have guis :/
We could define a new POSTMESSAGE type "Alert" for example, so Vidalia can inform the user of something fishy on behalf of BridgeFinder? But that brings up localization issues... Do we leave it to BridgeFinder implementations to specify error codes to be sent over POSTMESSAGE, or do we leave it free-form?
I like the R6RS ‘conditions’ system as a way to handle error codes in protocols. You probably don't need a fancy encoding that can handle arbitrary S-expressions; a list of strings should be sufficient, with conditions which have associated data (e.g. a fallback message in English for use if the controller doesn't have a better message that matches the error) represented as the condition type followed by a colon followed by the associated data (e.g. “message-en:The sky is falling!”).
Exercise care with where things are written to disk
The Tor Browser Bundle is designed to not leave traces that it has been run on a computer outside the directory in which it was unpacked, and, to the extent possible, to mitigate any such traces left by the operating system.
BridgeFinder MUST NOT write data to disk outside the Tor Browser Bundle directory at any time. BridgeFinder MUST NOT use any operating system features which are known to write data to disk outside the Tor Browser Bundle directory.
If BridgeFinderHelper operates as an extension of a program which the user has installed on his/her/its computer, it (or configuration data needed to cause the non-Tor Browser to load it) may need to be installed outside the Tor Browser Bundle directory. However, BridgeFinderHelper SHOULD NOT write data to disk or cause data to be written to disk outside the TBB directory.
BridgeFinderHelper MUST NOT be installed outside the TBB directory, and MUST NOT write data to disk, unless the user has explicitly permitted that.
The above paragraph makes many otherwise useful BridgeFinderHelpers impossible to implement in practice. It also contradicts the preceding paragraph in terms of MUST vs SHOULD.
In specific, Chrome addons are installed into the user's Chrome profile directory (unless you run them in 'unpacked' mode, which no one will do). I believe WoW addons are similar wrt restricted installation paths. There likely won't be a way to run BridgeFinderHelper plugins for these platforms from inside of the TBB dir.
Unless this is just a typo and you meant BridgeFinder above?
It's not a typo. Those BridgeFinderHelpers MUST NOT be installed unless the user has explicitly permitted that they be installed. Even if the user has explicitly permitted that a BridgeFinderHelper be installed and write data to disk, it SHOULD NOT write data to disk if that is not absolutely necessary.
BridgeFinder, BridgeFinderHelper, and their installation routines, MUST warn users that traces written to a disk cannot be erased without erasing the entire filesystem before asking for permission to write outside the TBB directory. (The user has already chosen to leave traces of TBB in the directory it was unpacked into.)
Do not stick beans up the user's nose
Deployed versions of BridgeFinder and BridgeFinderHelper MUST NOT have any debugging features which cause them to log sensitive data to disk. Someone *will* turn them on, whether by accident or by malice.
Development versions of BridgeFinder and BridgeFinderHelper which have such debugging features MUST warn users that they are development builds and should not be used by non-developers.
Requiring users to run special development builds to get any logs is going to mean we won't ever get any logs when things break. I think we're hamstringing ourselves development-wise with this rather silly compile-time requirement.
Or it will mean that the logs you get (and which were written to the user's disk before the user had any idea what would be in them) will not contain sensitive data.
Or it will mean that a user will have to collect logs in memory with a debugging tool, and then paste the logs into their MUA. This sounds *more* useful to developers than spamming the user's disk with sensitive data.
Perhaps instead we should recommend a log scrubbing mechanism similar to the ones used by Tor and Torbutton.
That is one way to not write sensitive data to disk.
Robert Ransom