Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

On Tue, Mar 28, 2017 at 11:08:29PM +, dawuud wrote: > > > I suggest making sure your UI follows the pricinples outlined here: > > User Interaction Design for Secure Systems > http://zesty.ca/pubs/icics-2002-uidss.pdf > by Ka-Ping Yee > > > for example: > "Path of Least Resistance. The

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

I suggest making sure your UI follows the pricinples outlined here: User Interaction Design for Secure Systems http://zesty.ca/pubs/icics-2002-uidss.pdf by Ka-Ping Yee for example: "Path of Least Resistance. The most natural way to do any task should also be the most secure way." Does your

Re: [tor-dev] Issues With Ticket #7532 - "Count unique IPs in an anonymous way"

Ah, I see - PCSA can actually keep track of unique IP's without actually revealing them. Your first link cleared it up a lot for me. PCSA is a really cool technique! I'd love to work on this as a GSoC project. I'll write up a proposal and send it out soon. On Tue, Mar 28, 2017 at 2:55 PM,

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

On Tue, Mar 28, 2017 at 09:43:12PM +, dawuud wrote: > > Hey, > > Cool project. Thanks! > Yes... write unit tests with pytest. Sounds good but I would > suggest writing tests earlier in the development process next time. I completely agree (and I feel bad for that). > Does your project

Re: [tor-dev] Issues With Ticket #7532 - "Count unique IPs in an anonymous way"

Hi Samir, Brute force does affect Bloom filter/hashed-values as you rightly mentioned, but not Probabilistic Counting by Stochastic Averaging (PCSA). PCSA works on the principle that in an input the probability of n consecutive bits having value '0' from the left side(could be right as well, but

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

Hey, Cool project. Yes... write unit tests with pytest. Sounds good but I would suggest writing tests earlier in the development process next time. Does your project have a specification for this software? Otherwise I have to read the code to learn how it works. Using automat for the fsm

Re: [tor-dev] Issues With Ticket #7532 - "Count unique IPs in an anonymous way"

On Tue, 28 Mar 2017 13:24:15 +, samir menon wrote: ... > IPv6 also solves this (128 bits), but there again, the solution is just to > hash the IP's before storing them No even that. Once you forget the salt the stored-so-far addresses become useless for you, too. So instead of storing current

Re: [tor-dev] GSoC 2017 - Project "Crash Reporter for Tor Browser"

Hi, Georg, Thank you! > We should have a good user interface ready giving the user at least an > explanation on what is going on and a way to check what is about to be sent. I've also thought about that, I suppose we could just put text explanations on Crash Reporter client UI form [1]. I've

[tor-dev] Issues With Ticket #7532 - "Count unique IPs in an anonymous way"

This ticket [1] was suggested as a GSoC project, but I think there might be an issue with the security model/perceived threat. To summarize the ticket and its child [1], basically, we currently store all the IP's seen by a node so that we can count unique IP's. The idea is that this is dangerous;

[tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

Hello, I am a Computer Engineering student at the Federal Technological University of Parana in Brazil and I would like to present you a peer-to-peer privacy enhanced instant messenger called unMessage [0]. I have been working on it for a while with David Andersen [1] (my advisor) and we have

Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

Tom Ritter: > It seems reasonable but my first question is the UI. Do you have a > proposal? The password field UI works, in my opinion, because it > shows up when the password field is focused on. Assuming one uses the > mouse to click on it (and doesn't tab to it from the username) - they >

Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

Although I don't have a concrete suggestion for the UI, I think this is a good idea. Similarly, it would be good to give people a clear way to tell us what exit node they were using at the time (by fingerprint). Maybe this could look like a "report possibly bad exit node behavior" option in

Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it. How would you

Re: [tor-dev] GSoC 2017 - Questions

Hi Krishna, absolutely! We love having new volunteers be it through GSoC or not. Hell, most of us got our start outside the program. ;) I'll leave the crypto parallelism questions to Nick, George, David, and others far more knowledgeable of the core tor codebase than me. On Mon, Mar 27, 2017 at

[tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

Hi all, The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages. Increasingly these

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote: > > On 26 Jan 2017, at 10:19, teor wrote: > > > >>> onion_address = base32(pubkey || checksum || version) > > > > Is the order in which the address is encoded once the checksum is > > calculated. checksum represents (the

Re: [tor-dev] GSOC 2017: Proposal for anon-connection-wizard

anonym: > irykoon: >> Currently, the Tor Launcher is shipped with the Tor Browser Bundle >> and heavily relies on the Tor Browser for its implementation. These >> facts cause using Tor Launcher without having the Tor Browser >> impossible. I agree with the whonix core developer Patrick >>

Re: [tor-dev] Pluggable Transports 2.0, draft 1 Specification

Hi Yawning. Thank you for providing these links. This is very helpful. I will make sure that these issues are discussed at the next specification meeting. On Mar 28, 2017 8:36 AM, "Yawning Angel" wrote: > On Mon, 27 Mar 2017 04:03:47 -0500 > Brandon Wiley

Re: [tor-dev] Pluggable Transports 2.0, draft 1 Specification

On Mon, 27 Mar 2017 04:03:47 -0500 Brandon Wiley wrote: > I am familiar with the dual stack problem generally, where servers > have both IPv4 and IPv6 IP addresses. I was not involved in any > conversations regarding the dual stack problem for Pluggable > Transports