Ok, let's try to distill your comments down into some action items for the proposal. Thus spake Robert Ransom (rransom.8774@xxxxxxxxx): > On 2012-03-26, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote: >> 3. 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â. Because you want to make it multi-lined? I'm not sure that's a good idea... It certainly complicates parsing and controller logic.. Line-driven command-based controllers who use this system can be pretty dumb in how they treat the control port. If we bust into multi-line events and commands, things will get way more complicated for them. I think it should stay 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. > > 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. Ok. So can/should we encode this as an additional free-form keyword for the SETCONF commands? It turns out Proposal 180 already allows this for both Bridge and ClientTransportPlugin commands in question. Tor might also want this info, but based on my read of 180, it should be free to ignore it. Also remember that POSTMESSAGE is freeform wrt Tor.. We don't have to specify "POSTMESSAGE Request" all up-front. More can be added later, so long as we have a way to easily pack more in later, and we can recommend the general approach that people can use to convery additional info like this... Based on these, my thinking is to suggest that arbitrary keyword=value pairs may appended to the SETCONF lines that may hold informational and other hints hints that signify bridge origin, and Vidalia and Orbot can figure out how to extract and present this info later (once it actually exists). > > 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!â). Ok, this sounds great to me. Can you succinctly state this for the proposal? I am not familiar with R6RS and will probably cite it wrong, especially since we don't want anything more complicated from it than to define a list of strings with English alternatives. We want it possible for these parsers to be very, very dumb and yet still easy to prove correct. Again, I don't think we need to over-specify here. We can leave it at recommendations, so long as we properly prefix the POSTMESSAGE body with "Alert" and leave room for keywords. > >> 5. Exercise care with where things are written to disk > >> > >> 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. Ok, then the proposal could use better wording to convey that user confirmation is what you want, here. Can you fix that? > >> 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.) > > >> 8. 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. Ok, I think these are worith suggesting for clarity then. If you would rather I do that (since I was the one who was confused), I'll get to it once you handle the above issues? -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev