Delivery-Date: Sat, 04 Oct 2014 02:50:35 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 32CD11E0B76;
	Sat,  4 Oct 2014 02:50:34 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 484A330FDF;
	Sat,  4 Oct 2014 06:50:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C351730FD4
 for <tor-talk@lists.torproject.org>; Sat,  4 Oct 2014 06:50:24 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Z_NOtgQ3Cb2o for <tor-talk@lists.torproject.org>;
 Sat,  4 Oct 2014 06:50:24 +0000 (UTC)
Received: from services.tengu.ch (services.tengu.ch [46.4.46.73])
 by eugeni.torproject.org (Postfix) with ESMTP id 79EF52E8E6
 for <tor-talk@lists.torproject.org>; Sat,  4 Oct 2014 06:50:24 +0000 (UTC)
Received: by services.tengu.ch (Postfix, from userid 103)
 id 690D310070A; Sat,  4 Oct 2014 08:50:21 +0200 (CEST)
Received: from [10.10.0.128] (84-73-112-2.dclient.hispeed.ch [84.73.112.2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by services.tengu.ch (Postfix) with ESMTPSA id 0D80B1000FB
 for <tor-talk@lists.torproject.org>; Sat,  4 Oct 2014 08:50:20 +0200 (CEST)
Message-ID: <542F98AC.1090207@tengu.ch>
Date: Sat, 04 Oct 2014 08:50:20 +0200
From: CJ <tor@tengu.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <542E5246.5070006@tengu.ch> <20141003222706.GF9509@torproject.org>
In-Reply-To: <20141003222706.GF9509@torproject.org>
Subject: Re: [tor-talk] orWall 1.0.0 released!
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 04/10/14 00:27, Mike Perry wrote:
> CJ:
>> Hello!
>>
>> just a small update regarding orWall: it's released 1.0.0!
>> There's still *one* annoying issue regarding the tethering, but it
>> should be OK next week. Just have to take some time in order to debug
>> this for good.
>>
>> orWall provides now a brand new UI in order to be easier to handle.
>> There's also an integrated help (as a first-start wizard we might call
>> later on).
>> There are many new features and improvements, like:
>>
>> - ability to disable all rules and let the device access freely the Net
>> - for each app, the possibility to access some advanced settings
>> allowing to bypass Tor, or tell orWall the app knows about proxies or Tor
>> - better management for the init-script
>> - better management for iptables rules
>> - translations in French, German and Italian are almost done
> =

> Hey CJ, just wanted to let you know that I've tried OrWall and it's a
> huge improvement! Way better user experience on just about every front!
> =


\o/ I'm really glad I could do something more userfriendly

> I also have not detected any leaks on my upstream router, either.

thanks to the init-script and a better iptables management ;). DROP
policy is just the key.

> =

> When I get a chance, I will update the original blog post to recommend
> OrWall instead of my crazy Droidwall hack scripts.

Wow=85 Thank you!

>  =

>> Any feedback from Tor/Orbot users interest me in order to improve
>> orWall. I think the current release is pretty good, but as the main dev
>> I'm maybe not that neutral regarding this statement ;).
> =

> The one thing is that I find the long-press options for "Connectype
> type" confusing: =

> =

>  - "Force connection" to what? I assume through Tor's transproxy because
>     of the REDIRECT text, but this will not be clear to users who are
>     unfamiliar with iptables.
>     How about: "Redirect all network activity"

hmmm yes. Why not, I think it's a sentence people will understand indeed

> =

>  - What does "native capacity"/"fenced path" mean? Does that mean only
>    access to the local SOCKS/HTTP proxy ports in Tor's case?
>    How about: "Only allow local proxy port access"
> =


Same thing. As this box allow all local connections (no port filtered
for now, I'll maybe add it later), text will be correct.

> These are complicated ideas to convey, though. I'm not sure my
> suggestions are the best ones either.
> =


True :/. It's a bit explained in the wizard though. But I think the
wizard might be worked out a bit more, it's painfully long and full of text.

> =

> I also suggest soliciting input about the DNS issue we discussed where
> DNS queries are done by root on Android 4.3+ unless the
> 'ANDROID_DNS_MODE=3Dlocal' environment variable is set. Perhaps someone
> will come up with a clever hack to set this env var in a persistent way
> that we haven't thought of, or find some way to write a shim on the DNS
> resolution filesystem socket to enforce what we want.

yup. This part is hard, and I don't think I'll be able to find a
solution alone. I'll open an issue on the github tracker and place a big
"help wanted" in it :).

> =

> You could list this on a known issues or FAQ page, or in your bugtracker
> I guess. Making root/UID 0 handle DNS is also a security risk, and I'm
> very surprised the Android team thought this was a good idea. :/

Oh, well, they also decided to follow Oracle JVM Cipher list, you know=85
Nothing surprises me now ;).

> =

> =

> Also looking forward to the "Logs" window doing something :)

Same for me. This part will be complicated due to different kernel
capabilities:
some supports LOG target, other NFLOG, and the latter doesn't provide
any nflog reader in the ROM (heya, Cyanogenmod, you're brain-dead on this!).
Thus it means:
- detecting which kind of log is supported
- create some UI in order to activate logs (already have some ideas)
- inject some binary in the system for nflog support
- =85 and many other things.

Maybe this can be avoided, as AFWall+ is considering providing some
intents as API end-points. This would mean:
- install orWall
- install AFWall+
and you'll get the best of both worlds, as AFWall will take care of the
iptables and log interfaces, just executing orWall orders=85

Thanks for your feedback!

Cheers,

C.

> =

> =

> =

> =

> =

-- =

tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

