Re: [tor-dev] Tor and Namecoin
Hi, Yaron Goland: naming experiment extension +1 for awesome usability test!! Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
Hi, Lunar: the size of the address Size *does* matter XD 128 bits long Oh my. IPv6. It's not a usability problem because .. .. no one outside of computer networking knows what it is, or that it exists (: a naming system [vs] random[ness] [regarding] the size of onion addresses after proposal 224 gets implemented Clarity is always a plus (: If the story is that people are remembering their shit, readability increases the probability of associative memory formation. Google search bar of browser Silly redundancy; why have two search bars next to each other q: to access [all the mails] x@y.z in the address bar has been known to prompt sign in. Searching can be a security tactic. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC 2016] Orfox - Report 5
Hi, # Copying Tails-ux once for relevance. Amogh Pradeep: Disabling search widget in Orfox. prefer not supporting it Usability will be improved! Search can easily hijack an interface and, in the context of the omnibar, is quite redundant (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 271: Another algorithm for guard selection
Hi, Nick Mathewson: uniformly at random What does this mean! an adversary who had (k/N) of the network would deanonymize F=(k/N)^2 of all circuits... and after a given user had built C circuits, the attacker would see them at least once with probability 1-(1-F)^C. With large C, the attacker would get a sample of every user's traffic with probability 1. Probabilistic risk analysis (imaginary math). To prevent this from happening, Tor clients choose a small number of guard nodes (currently 3) Except that imaginary math cannot prevent anything XD we can't continue to connect to the Tor network unconditionally. The conditions set herein create a hierarchical system of trust amongst the guards, potentially reducing the likelihood that the selected guards are malicious, correct? Tor should make a best attempt at discovering You mean *deciding*. appropriate behavior, with as little user input and configuration as possible. How can Tor know what the users wants? And, when it comes to what the software does, how do you bridge/close the gap of understanding between those using and those working on Tor? Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC 2016] Orfox - Report 3
Hi, Nathan Freitas: ... because perfection is boring? ... because I had five minutes to do it? ... because there is a secret hidden meaning? You sound a bit butthurt but I like the third option XD I was inquiring because I might want to help, if that's a thing people do. a ticket? I will join your dev tracker, if I am welcome to. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC 2016] Orfox - Report 3
Hi, Amogh Pradeep: we have a new logo for Orfox :D Is there a reason for the malalignment of the stroke? And that one permission 'Download files without notification', or is this out of the scope of your work? Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSOC16] Fingerprint Central - Cookies and localStorage
Hi, Pierre Laperdrix: a "playground" where the user can rerun the test suite It would be dope to have a playground where users can visit and actively be attacked, a purposely malicious .onion, if you will. Rerunning the tests in a sandboxed environment is a step toward this, it seems (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Usability Improvements for Atlas (was Re: Globe is now retired)
Hi, Copying UX@ once for relevance. Iain R. Learmonth: small changes + The 'Home' button is redundant since the logo provides the return function. + When collapsing the window to mobile-size, the navigation doesn't stack well; 'Home' gets stuck floating right of the logo. + The buttons in the middle of the page are redundant and add confusion. It is preferred to have one path to things; the navigation does this. They could be removed. + I am unsure of the value of linking to the torproject.org in the center of the page, maybe elsewhere as a hyperlink. + In 'Authorities', a list of all the flags could be valuable. The icons have tooltips, but that is unneeded work. + Returning from 'Authorities', 'Flag:Authority', or whatever, remains in the search field. + With the title text, maybe say "in the box above" instead of "in the above box", to put the subject before the location. + Columns need some love. Wonderful! Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Update on 259
Hi, > > teor: > or "delete you state file" > Cleaning the state file is a good idea, presuming there aren't any other bits in other package files. > > set "UseEntryGuards". > The right interface is all that is needed (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network
Hi, Nick Mathewson: I should try to clarify! Awesome! questions don't seem to apply to proposal 266 They are about the central control of a [somewhat] distributed network, specifically, the execution of clients on behalf of the operator. So, #264 & #266. I've tried to split the first version of the proposal into 2. I understand the proposals as: prop#264 is for how things _should_ work ; prop#266 is what we do in the absence of client-side support in existing Tor versions. anybody who doesn't know how to die via prop264 will be killable in whatever way we choose for prop266. And would recommend the titles [though obviously not as relevant as the contents]: 'How to ensure client death' 'How to kill clients that wont die' I'm not aware of anything published. Bummer ): reasons: 1) A non-updated Tor is insecure. 2) the bulk of [some older] deployed versions appear to be defunct botnets 3) [Depreciated] features Word. impact is so large it requires this level of action Where can this impact be studied? Given there is no research, there must be a way to visualize the impact. Windows XP clients still running today, making the internet less secure. Business clients pay money to keep MS supporting XP systems, though that doesn't weaken the internet as a whole. every current Tor MAY eventually prove so broken it needs to go away Word. It feels like a decision that the operator should make but I kind of see the issue with abandoned clients. The poison consensus seems fun. Thanks for taking the time to write, it means a lot (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] User Behavior Tracking defenses in VMs
Hi, ban...@openmailbox.org: keystroke dynamics fingerprinting And they say that the cicada puzzles are challenging (i.e., fun). Thanks (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] What is Design?
1 de·sign verb \di-ˈzīn\ To plan and make decisions about [something]; to plan and make [something] for a specific use or purpose, or no purpose at all; to think of [something, such as a plan]; to plan [something]. ORIGIN - late Middle English as a verb in the sense 'to designate'; from Latin designare 'to designate', reinforced by French désigner; the noun is via French from Italian. TL;DR - to designate. --- Copied -dev, -ux, and -teachers once for relevance but, should there be, responses live on -talk. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Leif's important piece on update golden keys
Hi, > > Nathan Freitas: > our goal is to remove any one > person from having the authority > to release an update. > If I understand correctly, this makes sense. > > judicially diverse or robust set of > signatories. > Web of trust for warez; seems like a good idea. > > Can you explain this > Ofc. Using OrFox as an example, a recently depreciated version had auto-update grayed out. The current version resolved this but provides 'Enabled' and 'Wi-Fi only' as the two options, no way to opt-out. In the world of usable security, this doesn't seem like an oversight to users and can degrade trust. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Leif's important piece on update golden keys
Hi, >> >> Holger Levsen: >> https://reproducible-builds.org and >> https://reproducible.debian.net >> Thanks! > > Nathan Freitas: > https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds > Thanks! However, even though reproducible-builds seems to address the manual install as well, which is good, I read the problem as being the actual backdoor of auto-update. Since my Dad will not be able to make this verification, removing auto-update from the package is the only real resolution here. Besides, given the broken/missing auto-update opt-out in packages like OrFox, it is difficult to trust the developers, since it is the user who defines "malicious". Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Leif's important piece on update golden keys
Hi, > > Nathan Freitas: > [auto update] a threat model we must > take more seriously. > Yay! > > we are making real progress. > Like what? Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Downloadable content: Fonts!
Hi, Gordon Robert Speirs: having to deal with Mozilla Seems like a waste of resources at some times. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Downloadable content: Fonts!
Hi, Jeff Burdges: Browsers are extremely complicated. I see. look over and build Servo Will do. Thanks (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Downloadable content: Fonts!
Hi, > > Nathan Freitas: > Mozilla > At what point do the efforts to patch Firefox out weigh the efforts to build a browser from scratch? Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Hashring understanding
Hi, George Kadianakis: Here are some resources Awesome; thanks! read the code to learn :) Will do. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Hashring understanding
Hi, > > George Kadianakis: > Indeed. [The randomly selected guards] > are saved in the state file. Check: > https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html > also see here for another explanation of > how parts of it work: > https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html > Besides these, where is the most information on guards and selection/control. I am interested in overstanding the information in the 'state' file. Also note that your explanations are always very detailed and very clear; thank you (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.
Hi, > > Nick Mathewson: > We should make a chart of what > times we have in common. :) > http://www.when2meet.com Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.
Hi, Lunar: Proposals are all kept in the “torspec” Git repository [and] in Nick Thanks for taking the time to share this!! Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Entry/Exit node selection
Hi, Yawning Angel: You can with the control port. Moving it to a first class feature would be a terrible idea for anyone that isn't a researcher Says a researcher (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Is it possible to specify voluntary delays in my Tor client?
Hi, > > Yawning Angel: > the art [of] link padding > I remember this: eecs.harvard.edu/~htk/publication/2005-jit-cheng-kung-tan.pdf Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Is it possible to specify voluntary delays in my Tor client?
Hi, > > grarpamp: > Higher latency, in and of itself, does not > provide any resistance to traffic > analysis. > Increase one-way and it will become unusable; nothing to see here. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Entry/Exit node selection
Hi, > > Evan d'Entremont: > ... select exit nodes ... > It would be best if people could select their own path (: Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network
Hi, Nick Mathewson: [This is a significantly revised version of the last version of this proposal draft, sent here for comment.] Questions? The last version of this draft was https://lists.torproject.org/pipermail/tor-dev/2015-September/009587.html I asked some questions to this draft [0] that you may have forgotten to answer that still seem relevant; I have sniped them here. Nick Mathewson: Draft proposal -- no number yet: How to safely drop support for old clients. I had made an observation about the title's "fluffy and not reflective of the proposal" nature and offered some options but I feel now like the current title still isn't as clear as it is intended to be. 'Current' suggests there are past or future clients that are being overlooked. 'Obsolete' suggests that the clients are no longer used or have fallen into disuse, which is quite a presumption given the encouragement behind "upgrading" that kinda forces people to show up as current-clients-in-the-wild data points. I still recommend: - How to depreciate support for old clients Though 'Network' is a valuable descriptor (: Frequently, we find that very old versions of Tor should no longer be supported on the network. Where can we find research on the impact? Disabling all versions that don't support this proposal With all due respect, doesn't Microsoft do stuff like this? Is the impact so large that they require this level of action? if we want to disable all Tor versions before today that do not support this proposal. Is the proposal for 5 years in the past, pre this version, or can/will the cutoff be specified willy-nilly? It might be good to make any disable-switches advisory rather than mandatory. Ultimately, if this is the approach, and it is in the hands of each client operator, this will be good. Though it would be great to hear from those who use previous versions to thwart limitations in "upgrades" to Firefox, such as the way media is streamed, windows are re-sized, and so on (: s7r: it'll take quite some time until we are ready to say 'let's disable all Tor versions before today'. How long do you think? Wordlife, Spencer [0]: https://lists.torproject.org/pipermail/tor-dev/2015-September/009601.html ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.
Hi, Nick Mathewson: proposals sit around for a long time Is there a summarized visualization of these, or is it sifting through emails and tickets? contribute usefully to discussions, I will prioritize your nominations [for proposals] more Sounds fair and balanced. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Orbot roadmap feedback
Hi, Georg Koppen: how do you convey the problem that all the other users of the Tor network could be affected You can always say that and link to the relevant documentation. You can also visualize the affect their participation in the network has, inherently addressing this issue as a result. a bunch of users How many is a bunch? anonymity ramifications Like what? Feel free to point. performance/load-balancing implications Like what? Feel free to point. How is a user supposed to make an informed decision in this case? Hopefully by being informed (: The most common usability assumption is that complication and complexity are the same. This becomes an issue when it drives designations and people have their choices made for them, usually in an attempt to make things less complex, when it is complication that is the real issue. Resulting examples are browser windows that decide what size they want to be, ignoring people input. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Orbot roadmap feedback
Hi, > > Nathan Freitas: > I've got big plans for Orbot in 2016... > any thoughts on the roadmap below: > > More Orbot VPN features including > better UI for enabling/disabling > Torouting, > I love the animation when swapping identities but it is challenging to discover. > > blocking specific apps, ports and/or > hosts, and general > It would be nice to have this in Orbot instead of Privacy Guard, then it can also be more "network" centric. > > "firewall" or little snitch type features > within the Orbot VPN > Please yes with a firewall, though, outside applications over Tor, it seems that this would be best implemented at the exit routers. > > OrbotShare: an OnionShare inspired file > sharing and download manager > service to enable easy hidden > service .onion setup and sharing > (including support for new ephemeral > onions) > Yes, please. This could very well be the introduction point to Onion Services for many. > > OrbotRelay/Bridge: improved UI for > running a bridge or relay from > within Orbot. > Yes, please. Same introduction point as above. In theory, a good interface is one that allows people to teach themselves. > > Creation of LibOrbot module/library for > use by any app to embed Tor > into their app > Yes, please. > > Overall improved configuration / > settings UI to make tuning Orbot a > better, simpler experience... this is an > expansion of the new exit country > selector in Orbot v15.1, but also > includes managing things like > network usage and so on. > Yes, please. It would be great to select each node in a circuit in addition to *just* the country. > > OrbotWear / OrbotTV > Yes, please. > > Some sort of "Pro" or Donation-ware > version to allow a pay-what-you-can > concept > Separate versions for the rich and the poor? You could do like LinkedIn and allow more functionality through paid version and charge those who need more security (; Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Quantum-safe Hybrid handshake for Tor
Hi, s7r: quantum computers don't exist... Yet: http://www.amarchenkova.com/about/ Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Scaling Tor Metrics, Round 2
Hi, Karsten Loesing: Ah, I wasn't referring to anyone specifically. I'm also a fan of David McCandless' work and have his book on the shelf here :) There are two; a new one as of last year. (Next to the wonderful books of Edward Tufte and the great ggplot2 book of Hadley Wickham.) These professors have a dry, but excitingly technical, approach to their work; I dig it. Thanks! I will definitely be playing with Wickham's stuff :) Spencer: select the data points and jump offline Can you elaborate on that? It might well be that we're talking about different things. When you said offline I was thinking of somebody downloading a tool, like a Python script, to process data outside of the browser. That's what I meant by building tools for a handful of people. I think if it requires more than the browser, hardly anybody will use it. But it seems you're talking about something different, right? Curious to learn more. Maybe. Downloading the dependencies can cause many usability and security issues, so I agree with the example .py context you provided. If the data can be selected, individually or all, and cached for offline use, it seems that an included .css and .js could style and render everything on the fly. Quick searches show ngraph[0], appcache[1], and Google[2] have some related things. Wordlife, Spencer [0]: https://github.com/anvaka/ngraph [1]: http://sitepoint.com/creating-offline-html5-apps-with-appcache/ [2]: https://developers.google.com/chart/interactive/faq ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Scaling Tor Metrics, Round 2
Hi, Karsten Loesing: I'm not really worried about server load. At least this hasn't been an issue with the current Metrics website. Word. There are indeed great visualizations out there If you know of anyone dedicating their life to dataviz, please point, as it seems David McCandless is the only one going this hard, and I am always on the look out for some fresh illness. having to go back to the server for each change ... is really uncool. I agree. However, given the challenges touched on so far, it seems that a reasonable resolution may be to select the data points and jump offline (or into some sandbox) and go to town on all kinds of combos. Not if we want to build tools for more than a handful of people. :) It is unclear what you mean. Most devices can process the data, I presume, and usability is okay with using downloads in 'Work Offline' mode. I am not sure what issue you are referring to :( Though I am all for the one-stop-shop, it seems that a feed of all the updated data upon request, to be processed at will, might be a nice way to do this :) Food for thought. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Scaling Tor Metrics, Round 2
Hi, Karsten Loesing: We briefly discussed making a JavaScript-free Globe a while ago by using Node.js. I'm not sure whether this would also work for Metrics. It may depend on how interactive graphs are supposed to be. As said later in this thread, .png seems okay. Though I see the load on the server if tons of peeps get at the site; I respect the client-side preference. Thanks :) I think the main option is to keep rendering graphs on the server. Right now, we're using R/ggplot2 for that, but we could switch to server-side JavaScript or really anything else. The main downside is lack of real interactivity. I see the need for interaction :) David McCandless [0] has some cool stuff that isn't very interactive (but uses JS). Can the data be processed offline by each person? Tor Rendering Engine :P Wordlife, Spencer [0]: http://www.davidmccandless.com ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Scaling Tor Metrics, Round 2
Hi, teor: Do David's visualizations already use JavaScript? We could make (another) part of the metrics site use JavaScript. Can the data be processed on the host server and sent to the client JS-free? Or are we waiting to choose a language before doing any new work? What are the options? Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [FWD: Re: Apple developer account + codesigning]
Hi, Conrad Kramer: All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”: Then what is in 'CodeSignature', Apple's signing stuff? Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.
Hi, Nick Mathewson: Draft proposal -- no number yet: How to safely drop support for old clients. I feel like "safely" sounds too fluffy and not reflective of the proposal. - How to force-drop support for old clients. or - How to depreciate support for old clients. The second of these seems the most suitable. Frequently, we find that very old versions of Tor should no longer be supported on the network. Where can we find research on the impact? 3.4. Disabling all versions that don't support this proposal With all due respect, doesn't Microsoft do stuff like this? Is the impact so large that they require this level of action? if we want to disable all Tor versions before today that do not support this proposal. Is the proposal for 5 years in the past, pre this version, or can/will the cutoff be specified willy-nilly? It might be good to make any disable-switches advisory rather than mandatory. Ultimately, if this is the approach, and it is in the hands of each client operator, this could be good. Though it would be great to hear from those who use previous versions to thwart limitations in "upgrades" to Firefox, such as the way media is streamed, amongst other things :) Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
