Re: [tor-dev] bridge:// URI and QR codes

[Nathan Freitas]

On Wed, Jul 20, 2022, at 1:15 PM, Nathan Freitas wrote:
> I believe in Orbot today we do promote the user after they scan a code 
> or click on a bridge link. Definitely agree there should be that step.

I  meant *prompt* the user.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] bridge:// URI and QR codes

[Nathan Freitas]

On Wed, Jul 20, 2022, at 8:01 AM, meskio wrote:
> Quoting Torsten Grote (2022-07-19 14:54:01)
>> On Monday, 18 July 2022 13:47:21 -03 meskio wrote:
>> > What do you think of the proposal? How can we improve it?
>> 
>> A slightly unrelated question:
>> 
>> Was there any consideration about deanonymization attacks by giving the user 
>> a 
>> bridge controlled by the attacker? I worry that those get more likely when 
>> getting bridges via links and QR codes becomes normalized.
>> 
>> Apart from the source IP address of the user and their Tor traffic pattern, 
>> is 
>> there anything else an attacker can learn from operating the bridge?
>
> At least from my side there was not consideration on this topic yet. Thank 
> you 
> for bringing it, I think is a pretty valid concern and we should do some 
> planning on it.
>
> I wonder if we should only accept bridge URIs/QR codes when the user 
> clicks on 
> 'add bridges' inside the tor related app. Or will be enough to accept 
> bridge 
> URIs on any moment but communicate to the user clearly what is 
> happening and ask 
> them for confirmation. We should never change the bridge configuration 
> silently 
> from a bridge URI without any user intervention.
>
> I think we should add something about it to the "Recommendations to 
> implementers" on the proposal.

I believe in Orbot today we do promote the user after they scan a code or click 
on a bridge link. Definitely agree there should be that step.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Orbot 16.2.0 RC-1 (tor-0.4.2.7)

[Nathan Freitas]

Now with integrated MOTE bridge request support, just like on Onion
Browser iOS, courtesy of Benjamin Erhart (aka tla).



 Forwarded Message 
Subject:Orbot 16.2.0 RC-1 (tor-0.4.2.7)
Date:   Mon, 4 May 2020 12:03:13 -0400
From:   Nathan of Guardian 
Organization:   Guardian Project
To: Guardian Dev 




Orbot 16.2.0 RC-1 (tor-0.4.2.7)

Tag: https://gitweb.torproject.org/orbot.git/tag/?h=16.2.0-RC-1-tor-0.4.2.7

APKs:

-
https://github.com/guardianproject/orbot/releases/tag/16.2.0-RC-1-tor-0.4.2.7

- Universal:
https://guardianproject.info/releases/Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed732a3-fullperm-universal-release.apk
(.asc)

- ARM64:
https://guardianproject.info/releases/Orbot-16.2.0-RC-1-tor-0.4.2.7-1-geed732a3-fullperm-arm64-v8a-release.apk
(.asc)

- F-Droid soon...


Thanks to the fantastic contributions by @bitmold @tladesignz and
@Hashik-Donthineni

Highlights

    Resolved many issues related to startup of Tor and Obfs4/Meek
bridges on Android Q/10
    VPN fixes resolved through unifying 2 background services
(TorVPNService, TorService) into one (OrbotService)
    Update tor to 0.4.2.7 and obfs4proxy to 0.0.12 latest
    Brand new "beta" integrated bridge fetch feature through Tor's MOTE
service (just like in Tor Browser)
    Brand new custom bridge configuration, setup UI
    Zulu language random switch bug FINALLY fixed now the language
you choose remains! (sorry, Zulu!)
    and much more...

/** 16.2.0-RC-1-tor-0.4.2.7 / 4 May 2020 / 0a3a4f7 **/

0a3a4f7 (HEAD -> master) update version code to 16202001
a631077 (HEAD -> master, origin/master, origin/HEAD) Merge branch
'tladesignz-master'
875f18a (tladesignz-master) Merge branch 'master' of
https://github.com/tladesignz/orbot into tladesignz-master
85e027c update version code
cabf328 don't start tun2socks/VPN if it is already running
718bb42 Issue #324: Implemented CustomBridgesActivity analogous to Onion
Browser iOS.
12a3f4a (tag: 16.2.0-BETA-4-tor-0.4.2.7) remove TorVpnService from
manifest to address #327 crash
22d7ef8 (tag: 16.2.0-BETA-3-tor-0.4.2.7) update to 16201003
22bd248 update binary install scripts, to fix pdnsd install - now pdnsd
is packaged as libpdsnd.so to work on newer platforms
e93c8bc (tag: 16.2.0-BETA-2-tor-0.4.2.7) update version code to 16201002
d0fec8e update tor and obfs4proxy binary libs to address #326 hopefully
3ac5a70 Issue #309: Activate newly required bridges, fixed accidental
reset through Tor status notification.
e1425d3 Issue #309: Also disable CAPTCHA solution EditText, as long as
there's no CAPTCHA to solve and while letting it check.
ff7cbcf Issue #309: Error alert button should say "OK" instead of
"Cancel", since there's nothing to cancel, really, just to acknowledge
the error.
54f5f31 Issue #309: Hide refresh option menu item instead of disable,
because Android doesn't visualize that adequately. Additionally: Fix
issue where you couldn't refresh after a network error.
3bfaa8a Issue #309: Fixed potential crash, when activity went away.
c41d453 (public/master) fix unneeded includes
4f4300a (tag: 16.2.0-BETA-1A-tor-0.4.2.7, tag:
16.2.0-BETA-1-tor-0.4.2.7, ghdev/master) update version to 16201001
7d7b2e9 remove app updater code to address concerns in #323
ec47151 major VPN refactor with Android Q updates for #263 #261 #151
#316 and #303 - integrate TorVPNService directly into OrbotService, so
just one service now - removed VPNEnableActivity, and just have
VPN activated by service now - changes address start on boot with VPN
enable - also improvements to managing PDNSD daemon
d64b4d0 (tag: 16.1.5-BETA-2-tor-0.4.2.7) update version code to 16150001
d5bc374 update to SDK 29
919c211 improve pdnsd pid checking
e78c27b remove unneeded commands in tor config and startup
5cd6cc8 update tor to 0.4.2.7
785fa8f Merge branch 'master' of github.com:guardianproject/orbot
93a0786 Merge pull request #322 from bitmold/AboutDialogCrashFix
b24750e Fixes #321 IlleglaStateException on about dialog
2e6c9b1 (tag: 16.1.5-BETA-1-tor-0.4.2.5-rc) small tweaks to request
bridge strings
3c80df0 Merge branch 'bitmold-compile_erorr+refactor'
08de553 (bitmold-compile_erorr+refactor) Merge branch
'compile_erorr+refactor' of https://github.com/bitmold/orbot into
bitmold-compile_erorr+refactor
df847ff Merge branch 'tladesignz-master'
b2646a3 update AndroidPT to latest 1.0.8 with fixes for obfs4 and meek
on Android 10
feedb3b fix string variable values
155980f Change from using String resources for a bundle key in Onboarding
ec0ad26 Fixes compile error on master branch right now
f2c8473 Merge branch 'master' of https://github.com/tladesignz/orbot
into tladesignz-master
732c153 Merge branch 'master' of https://github.com/guardianproject/orbot
09ded59 (githubgp/master) Merge pull request #311 from
bitmold/email_bridges_fix
b1049ca Merge branch 'master' of https://github.com/guardianproject/orbot
b9804c1 Merge pull request #305 from
Hashik-Donthineni/AppIntroOrientationFix
410ae03 tweaks to app data storage and 

Re: [tor-dev] reproducible builds for Android tor daemon

[Nathan Freitas]

On 9/13/19 3:51 AM, Hans-Christoph Steiner wrote:
>
> teor:
>>
>> It's not always safe to have apps share Tor: a malicious website in one app
>> can use various caches to discover activity in other apps. And there may
>> be similar data leaks in other shared data structures or network
>> connections.
>>
>> How do these data leaks affect your use cases?
> With Orbot, all apps are already sharing one tor daemon, so this isn't a
> new development.
>
> .hc
>
Most the use cases for Tor outside of Tor Browser and Briar tend to be
related to anti-censorship, reduction of passive surveillance, and
opportunistic access to onions (nytimes, DDG, facebook, etc).

Also has hc said, we are talking about non-browser type applications.

Since these are also applications you already have installed on your
phone, they already can know a heckuva a lot about you and your device.
Thus, with the threat model scope for this work, the app itself is not
our adversary, just the network.

+n






signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] New Orbot, tor-android and AndroidPluggableTransport updates

[Nathan Freitas]

On 9/13/19 6:25 AM, Georg Koppen wrote:
> Nathan Freitas:
>> A new Orbot is out, with a bug fix related to obfs4proxy installation,
>> and a new tor!
> Good stuff! Is it intended that I only see an x86_64, x86, and arm64-v8a
> version but no armv7 one available? It seems suddenly Orbot is not
> compatible anymore with my device (and I suspect a bunch of other users
> have a similar problem)

That was not intended, and not sure where you mean exactly.

Anyhow, we are definitely releasing armv7 (aka "armeabi-v7a") binaries
still, both for Orbot and the underlying tor-android-binary releases.

Release here:
https://github.com/guardianproject/orbot/releases/tag/16.1.2-RC-2-tor-0.4.1.5-rc

with this APK:
https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-0.4.1.5-rc/Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] New Orbot, tor-android and AndroidPluggableTransport updates

[Nathan Freitas]

A new Orbot is out, with a bug fix related to obfs4proxy installation,
and a new tor!

We've also updated the tor-android library, with the latest 0.4.1.5
release, and all is working well.

https://github.com/guardianproject/tor-android/releases/tag/tor-android-binary-tor-0.4.1.5

and we updated our AndroidPluggableTransports library, which was at the
root of our "Orbot Bridge" bug, not properly installing the binary from
the APK bundle.

https://github.com/guardianproject/AndroidPluggableTransports/releases/tag/1.0.7

These libraries and versions are available via our Guardian Project
gradle/maven repo hosted on Github:

maven { url
"https://raw.githubusercontent.com/guardianproject/gpmaven/master; }

implementation 'org.torproject:tor-android-binary:0.4.1.5-rc'

implementation 'info.pluggabletransports.aptds:apt-dispatch-library:1.0.7'
implementation 'info.pluggabletransports.aptds:apt-meek-obfs4-legacy:1.0.7'

Everything is building again in our CI pipeline here:
https://gitlab.com/guardianproject/orbot/pipelines
and we nearly have automated on-device testing working via the cloud
services Bitbar and/or Browserstack.

Life is good, again.

+n


 Forwarded Message 
Subject:Orbot 16.1.2 RC-2 with tor-0.4.1.5-rc
Date:   Tue, 10 Sep 2019 00:42:56 -0400
From:   Nathan of Guardian 
Organisation:   Guardian Project
To: Guardian Dev 



Orbot 16.1.2-RC-2-tor-0.4.1.5-rc
https://github.com/guardianproject/orbot/releases/tag/16.1.2-RC-2-tor-0.4.1.5-rc

* Found and fixed bug related to bridges not working
(https://github.com/guardianproject/orbot/issues/242)
* Updated tor to 0.4.1.5

ARM64 APK:
https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-0.4.1.5-rc/Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk
ARMEABI APK:
https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-0.4.1.5-rc/Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk

@n8fr8 n8fr8 released this 5 minutes ago · 0 commits to master since
this release

c2e679d (HEAD -> master, tag: 16.1.2-RC-2-tor-0.4.1.5-rc) update to
16.1.2-RC-2-tor-0.4.1.5-rc
1d45a3d update APT Pluggable Transport library to 1.0.7 - this should
fix one issue with installing the correct ofbs4proxy binary - also small
changes to ensure no lock states and reduce log noise
efec61d (tag: 16.1.2-RC-1-tor-0.4.0.4-rc, newport/master) update to
16.1.2-RC-1-tor-0.4.0.4-rc
237b388 yet another attempt at fixing the phantom zulu locale bug!
a9efc3c disable tests for now in CI build
918bcca (origin/master, origin/HEAD) remove unused layouts for app-mini
08b670f update paths for app-mini code
cefac58 putting classes back into main app package, and not "mini"
97d2aac improvements for bridge handling for #242
0e40c07 update badvpn tun2socks library
034844a remove fileprovider from app-mini since it is used just for HS
d95f197 make keystore props reading not fail if not present
d0640c6 remove output from repo
e8f3158 remove binaries from repo
5845a4c update build tools to 29
003d9ea update build tools to 29
9c6de06 update build tools to 29
a266c65 add new functionality to allow for checking connections against
app blacklist
d98e5fb update changelog for 16.1.1-BETA-2-tor-0.4.0.4-rc-orbotservice
Assets 6
Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk 10.3 MB
Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk.asc 833
Bytes
Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk 9.94 MB
Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk.asc
833 Bytes





signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Orbot 16.1.1... now with 64-bit tor

[Nathan Freitas]

Orbot 16.1.1 was just pushed out publicly to everyone on Google Play
after a long multiple RC and beta period. YES, Orbot is still going to
exist, with a really exciting roadmap ahead. More on that soon!

Thanks to @bitmold @sisbell @pgerber and @eighthave for all the great
work, not to mention the core Tor dev team making all things mobile
better every day!

Highlights include:

* True arm64 tor binaries now!
* Key fixes to VPN mode to handle loss of network access
* Improvements to Tor idle/sleep behavior and resume after network drops
... and much more!

Github (with APKs):
https://github.com/guardianproject/orbot/releases/tag/16.1.1-BETA-2-tor-0.4.0.4-rc

APK:
https://guardianproject.info/releases/Orbot-16.1.1-BETA-2-tor-0.4.0.4-rc-fullperm-universal-release.apk
(.asc)

F-Droid: soon!

/** 16.1.1-BETA-2-tor-0.4.0.4-rc / Wed Aug 7 13:33:30 2019 -0400 /
bbf5fcb3fb346e9bba712d12bf4934cf925cb2bd **/

bbf5fcb3 (tag: 16.1.1-BETA-2-tor-0.4.0.4-rc) update service for VPN mode
and startup fixes
ea7f3f10 update gitignore
cf19750d update fastlane and gradle to support split apks builds, CI and
more
cd80e850 (tag: 16.1.1-BETA-1-tor-0.4.0.4-rc) update to
16.1.1-BETA-1-tor-0.4.0.4-rc
bfb5eab1 Merge branch 'master' of github.com:n8fr8/orbot
d02fb582 instead of DisableNetwork, let's try NEWNYM when the network
returns - we've had issues of losing connectivity setting
DisableNetwork, so we are trying a new approach - now using
DormantClientTime
out settings, to have client go to sleep when it is not used - when we
receive a network connectivity notification, we call NEWNYM to refresh
circuits
d5e570a5 Merge pull request #247 from bitmold/low_dpi_launcher_icon
767a8596 Launcher icon was out of date on low resolution devices.
7d11984b (tag: 16.1.0-RC-3-tor-0.4.0.4-rc) update to
16.1.0-RC-3-tor-0.4.0.4-rc
e146f703 make sure to kill existing pdnsd, and set the new ports properly
c6bfc491 send ports on start request, even if tor is already running
d3963516 keep apps around as static variable, enable user to refresh
be5b8d88 make sure we don't have any orphaned pdnsd processes
72ff7dd2 Merge branch 'ejo4041-mergeDebugJniLibFolders_issue'
07e34239 (ejo4041-mergeDebugJniLibFolders_issue) Merge branch
'mergeDebugJniLibFolders_issue' of https://github.com/ejo4041/orbot into
ejo4041-mergeDebugJniLibFolders_issue
be6feea8 Merge branch 'master' of github.com:n8fr8/orbot
d2005234 update gradle
929cb6b6 pdnsd must be named with a .so extension to be included
c0afffeb don't build plain armeabi anymore
4321ae49 update native libs
c7e9b01f Merge pull request #244 from bitmold/vpn_app_ui_glitch
fc0b035a After following the BUILD file, could not build the apk because
of a issue mentioned in #217: Execution failed for task
:orbotservice:mergeDebugJniLibFolders. This change fixes that.
7b832f19 Fixed VPN App UI for apps that were disabled or uninstalled
d084aa6c (tag: 16.1.0-RC-2-tor-0.4.0.4-rc) update to
16.1.0-RC-2-tor-0.4.0.4-rc
79afbe05 bind pdnsd to virtual address within VPN
9ff0b00c fix VPN code to support dynamic DNS port for Tor
f1e572e8 use standard string keys for intent values
361ea26d ports can be set to "auto" so allow letters as well

/** 16.1.0-RC-1-tor-0.4.0.4-rc / 8 July 2019 /
e60c07ed0ffc8360db4dfcdeffd8578945b38d0b **/

Thanks to @bitmold @sisbell @pgerber and @eighthave for all the great
work, not to mention the core Tor dev team making all things mobile
better every day!

e60c07ed (HEAD -> master, tag: 16.1.0-RC-1-tor-0.4.0.4-rc,
public/master, origin/master, origin/HEAD) update to
16.1.0-RC-1-tor-0.4.0.4-rc
9e54cd6e set PDNSD server IP to 192.168.200.1 for local VPN network
0.0.0.0 allowed outside access to DNS port in some cases
b7d100ca fixes #239 #229 #227 #205 and other VPN / DNS issues moved
PDNSD daemon to load from the .so native path
f9c1486c Merge pull request #241 from bitmold/fix_hs_dialog_crash
f1b00157 Merge branch 'sisbell-sisbell_236a'
65ee380d (sisbell-sisbell_236a) Merge branch 'sisbell_236a' of
https://github.com/sisbell/orbot into sisbell-sisbell_236a
1c386959 Fixes #236: Separate Constants For VPN, TOR and MAIN_APP
ce85e951 Fixed crash I introduced with the NoPersonalizedLearningEditText
324b35ea (tag: 16.1.0-BETA-6-tor-0.4.0.4-rc) update to
16.1.0-BETA-6-tor-0.4.0.4-rc
b6135386 Merge branch 'sisbell_236a' of https://github.com/sisbell/orbot
into sisbell-sisbell_236a
124273fd (newport/master) Merge branch 'sisbell-sisbell_237'
43d807fd (sisbell-sisbell_237) remove minSDK from OrbotService manifest
45369a2a Merge branch 'sisbell_237' of https://github.com/sisbell/orbot
into sisbell-sisbell_237
4a79476e Merge pull request #234 from bitmold/vpn_request_cancel_bug_fixes
b0cf7424 Merge pull request #233 from bitmold/no_vpn_refresh_btn
e448c18b Merge branch 'bitmold-remove_orfox'
f3211aca Fixes #236: Separate Constants For VPN, TOR and MAIN_APP
8c232f73 Fixes #237: Upgrade to Gradle 5.x
2ebd3384 Fixes VPN Request Cancel Bugs
cde49d1a Removes the refresh button on the VPN Selection screen
351ef96f 

[tor-dev] Fwd: Orbot 16.1.0-BETA-1-tor-0.4.0.4-rc

[Nathan Freitas]

Tor 0.4.0.4 working well on Android. We've updated the tor-android
library to 0.4.0.4-rc, and included it in the latest Orbot beta. It is
available via Gradle at the usual spot (see below):

https://github.com/guardianproject/tor-android/releases/tag/tor-android-binary-tor-0.4.0.4-rc

maven { url
"https://raw.githubusercontent.com/guardianproject/gpmaven/master; }

implementation 'org.torproject:tor-android-binary:0.4.0.4-rc'


 Forwarded Message 
Subject:Orbot 16.1.0-BETA-1-tor-0.4.0.4-rc
Date:   Fri, 31 May 2019 16:25:20 -0400
From:   Nathan of Guardian 
Organisation:   Guardian Project
To: Guardian Dev 



/** 16.1.0-BETA-1-tor-0.4.0.4-rc / 31 May 2019 /
417e4fcd0720be57328d63a96d2c9fc0e119330f **/
TAG:
https://gitlab.com/guardianproject/orbot/tags/16.1.0-BETA-1-tor-0.4.0.4-rc

Thanks to @bitmold @sisbell and @eighthave for all the great work, not
to mention the core Tor dev team making all things mobile better every day!

APKs posted at: https://guardianproject.info/releases/

[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-arm64-v8a-release.apk   
2019-05-31 15:17     12M     
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-arm64-v8a-release.apk.asc   
2019-05-31 15:17     833      
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-release.apk   
2019-05-31 15:18     12M     
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-release.apk.asc   
2019-05-31 15:18     833      
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-v7a-release.apk   
2019-05-31 15:18     12M     
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-v7a-release.apk.asc   
2019-05-31 15:18     833      
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-universal-release.apk   
2019-05-31 15:18     32M     
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-universal-release.apk.asc   
2019-05-31 15:18     833      
[ ]    Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86-release.apk   
2019-05-31 15:18     12M     
[ ]   
Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86-release.apk.asc   
2019-05-31 15:18     833      
[ ]    Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86_64-release.apk   
2019-05-31 15:18     12M     
[ ]    Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86_64-release.apk.asc


417e4fcd update version to 1613 aka 16.1.0-BETA-1-tor-0.4.0.4-rc
7ae000d0 fix pdnsd/VPN support
dde1957d Merge pull request #219 from bitmold/delete_minimalperm_manifest
a251d52f Merge pull request #218 from bitmold/ndk_app_platform_warning
eda464bb remove incorrect torFile assignment
a1c5806a update tor-android to 0.4.0.4-rc
ad2e875b We no longer use the minimalperm product flavor so there's no
need to keep this manifest file in app/src
917e49f5 Removes warning on ndk-build where the target API for NDK (16)
is greater than the sdk version defined for the project. Since nothing
was specified in the manifest it defaulted to 1 but we can set
 this to Orbot's minSdkVersion of 16 to get rid of this warning
f83a98f4 Merge branch 'sisbell-issue_199'
ff7d3dd5 (sisbell-issue_199) Merge branch 'issue_199' of
https://github.com/sisbell/orbot into sisbell-issue_199
7c2cfc3e Merge pull request #212 from sisbell/issue_211
1316fd65 Merge branch 'bitmold-no_personalized_learning_kb'
e3fd4afa (bitmold-no_personalized_learning_kb) Merge branch
'no_personalized_learning_kb' of https://github.com/bitmold/orbot into
bitmold-no_personalized_learning_kb
aa8ad867 Merge pull request #204 from bitmold/unreferenced_classes
16826a49 Merge branch 'bitmold-removed_obsolete_version_checks'
17154609 (bitmold-removed_obsolete_version_checks) Merge branch
'removed_obsolete_version_checks' of https://github.com/bitmold/orbot
into bitmold-removed_obsolete_version_checks
0e4b42a7 add close bracket
4cee987c Merge branch 'master' into removed_obsolete_version_checks
08c35bd3 Remove unused resources.
ae4ce1c9 Fixes #211: Resource Not Found on Command Line Build
2fb7e05a Merge pull request #210 from eighthave/fastlane
57120100 rename all metadata locale dirs after the Fastlane/Play names
baced180 setup Fastlane to upload to Google Play
d2feefdd Removed Obsolete @TaretApi Annotations for API Levels that are
lower than Orbot's minimum, API Level 16
a32452e7 Make text inputs in Orbot declare that they do want to opt out
of IME personalized learning. Of course, IMEs may ignore this request,
but it's a nudge in the direction of Tor's general philosophy
on user privacy, particularly with regards to minimizing the footprint
that a Tor app leaves on the user's device.
7d8e41a6 Removed Constraint Layout Dependency
5d04d418 Removed Unused Classes
2b6abd7e Removed Obsolete Version Checks
cd6560fa Merge pull request #202 from bitmold/no_constraint_layout
a5d5c99f (public/master, gl/master) remove unused launcher art
9257b66f don't shrink or minify for now
56917567 (tag: 16.0.6-BETA-2-tor-0.3.5.8) many small changes to support
new binary loading, startup and more - improved handling of port
conflicts - fixed loading of 

[tor-dev] Orbot and Tor on Android Q

[Nathan Freitas]

Orbot 16.0.6-BETA-1-tor-0.3.5.8

https://github.com/n8fr8/orbot/releases/tag/16.0.6-BETA-1-tor-0.3.5.8

is out (binaries on Github for now) for testing, specifically on Android Q.

It is built on a new release of:

tor-android-binary-tor-0.3.5.8-rc

https://github.com/n8fr8/tor-android/releases/tag/tor-android-binary-tor-0.3.5.8-rc

This now uses the method of bundling the tor executable as a tor.so
library, allowing the Android runtime to unpack them into the /data/libs
read-only space within the app's private directory. We then can just
execute it there, without needing to unpack it, copy it, etc.

The word is that this will work on Android Q still. I have tested on an
emulator, but not a real device yet. I don't have a Pixel of any kind,
at the moment, so please let me know if you do and can test.

Otherwise, we are working to move tor and other important binaries, like
obfs4proxy, into actual in-process libraries. We've recently made great
progress with this on our iOS work with Onion Browser, and so it should
now be possible on Android.

New commits below


***

ATTENTION ANDROID Q / PIXEL TEST USERS: We've made changes just for you!
WARNING: Meek/Obfs4 bridges WILL NOT work on Android Q yet, just plain Tor

fb14c76

fixed strings with two many \ escapes
4557577

updating to tor-0.3.5.8-rc to add support for Android Q
22d5ffd

update gradle tools
76796fe

Merge pull request #200  from
eighthave/fastlane-supply
6ba0cec

add .gitlab-ci.yml setup with errorprone
3face00

build gradle to 4.4.1, and make gradlew verify the download
69bd7fe

move app store graphics into fdroid/fastlane file layout
f93c11e

Merge pull request #190  from
SkewedZeppelin/master
8ab13f6

Fixup bad indentation from 6e4b700

12b91c4

Expose PreferIPv6 and NoIPv4Traffic options
8ad7668

Move Google repo above jcenter
d4befad

cleanup and binary loading fixes

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Orbot 16.0.3-BETA-2 (tor-0.3.4.8) release for testing

[Nathan Freitas]

Highlights
- Tor 0.3.4.8 / OpenSSL 1.0.2p with dirauth module disabled (not used
for client devices)
- Updated Obfs4/Meek pluggable transport support and built-in bridges
- Simplified (less memory, network & battery intensive) notification
with "New Identity" button

APKs up here:
https://github.com/n8fr8/orbot/releases/tag/16.0.3-BETA-2
https://guardianproject.info/releases/Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk
(.asc)


@n8fr8 n8fr8 released this just now
Assets 6

    Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-armeabi-release.apk 8.77 MB
    Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-armeabi-release.apk.asc 862
Bytes
    Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk 17.8 MB
    Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk.asc
862 Bytes
    Source code (zip)
    Source code (tar.gz)

f06939b (HEAD -> master, tag: 16.0.3-BETA-2-tor-0.3.4.8, public/master,
origin/master, origin/HEAD, dev/master) update build 16030020
9d3bd82 udpate default bridges
c207a1e update new simpler notification with "new identity" button
bcae003 add permission to service manifest
a7130ab update to latest tor android 0.3.4.8
a5d1978 update default bridges
ffda769 update NDK build script
3349454 update to latest Pluto obfs4proxy builds
048ed9f Merge branch 'master' of github.com:n8fr8/orbot
84e0433 (tag: 16.0.3-BETA-1-tor-0.3.4.8) update version to
16.0.3-BETA-1-tor-0.3.4.8 and build to 16030010
66cc8ad improve service checking for running Tor instance
6bc161b update to Tor 0.3.4.8
0ff8d7c Merge pull request #173 from haghighi-ahmad/patch-1
772e0db Improve Persian translation and fix grammar.
129b55a Merge branch 'master' of github.com:n8fr8/orbot
1bef963 Merge branch 'Unpublished-deprecated_torrc'
b2bf3d9 Merge branch 'deprecated_torrc' of
https://github.com/Unpublished/orbot into Unpublished-deprecated_torrc
06c343c update launcher web graphic
3433112 update launcher graphics
bd61739 update version and constrains library
9a866aa update gradle tooling
31238af update tor to 0.3.4.7 RC

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor browser for Chrome OS

[Nathan Freitas]

On 07/13/2018 02:02 PM, Keifer Bly wrote:
> So I am wondering, are there plans to develop a version of tor browser that
> will run on Chromebooks? I though that might be a good idea as those are
> getting somewhat popular in the US. Thanks.

Orfox browser for Android (and Orbot along with it) run on Chrome OS
devices that support Android apps. It works quite well in fact!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Running Tor with a 15MB memory limit

[Nathan Freitas]

I am currently supporting the iCepa project, an effort to get Tor to run
as a Network Extension VPN on iOS.

https://github.com/iCepa/iCepa

The good news is that, after a long time, we have the whole thing
somewhat working. The bad news is that after browsing a few pages
through Tor, the extension is shutdown due to going over the extremely
tiny 15MB available heap. More on this at:

https://forums.developer.apple.com/thread/73148
https://developer.apple.com/documentation/networkextension

My question is, does anyone else have experience running Tor within some
extreme memory limits? Any guidance on configuring torrc for this? Any
thoughts on build flags or changes that might reduce memory usage?

We have already identified that the new compression features available
in recent versions of Tor consume more memory, and we may have to
disable those for now, for instance.

Thanks for any thoughts!

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Fennec now builds with clang instead of gcc

[Nathan Freitas]

For those working on Tor Browser for Android...

- Original message -
From: Nathan Froyd 
To: "dev-platform" ,
mobile-firefox-...@mozilla.org
Subject: Fennec now builds with clang instead of gcc
Date: Sun, 29 Oct 2017 19:15:50 -0400

Hi all,

Bug 1163171 has been merged to mozilla-central, moving our Android
builds over to using clang instead of GCC.  Google has indicated that
the next major NDK release will render GCC unsupported (no bugfixes
will be provided), and that it will be removed entirely in the near
future.  Switching to clang now makes future NDK upgrades easier,
provides for better integration with the Android development tools,
and brings improvements in performance/code size/standards support.

For non-Android platforms, the good news here is that compiling Fennec
with clang was the last major blocker for turning on C++14 support.
Using clang on Android also opens up the possibility of running our
static analyses on Android.

If you run into issues, please file bugs blocking bug 1163171.

Thanks,
-Nathan
___
mobile-firefox-dev mailing list
mobile-firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Alternative Implementations of Tor

[Nathan Freitas]

On Wed, Aug 17, 2016, at 11:01 AM, Alexander Færøy wrote:
> There is, to my knowledge, currently only one implementation of Tor that
> is actively in use on the production network, which is the C
> implementation. I'm aware of a Haskell implementation made by Galois,

Not sure how widely implemented it is, but Orchid was a formally
implemented version of Tor in Java, by the Toronto-based Subgraph group:
https://subgraph.com/orchid/index.en.html

It was, at one point, integrated into the Martus human rights
documentation platform.

The developers are likely on this list, or if not, easily reachable to
ask for any lessons learned.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Using Tor Stealth HS with a home automation server

[Nathan Freitas]

On Fri, Jul 8, 2016, at 10:38 PM, ban...@openmailbox.org wrote:
> On 2016-07-08 18:53, Nathan Freitas wrote:
> > I've been working on some ideas about using Tor to secure "internet of
> > things", smart devices other than phones, and other home / industrial
> > automation infrastructure. Specifically, I think this could be a huge
> > application for Tor Hidden Services and Onion sites configured with
> > Hidden Service Authentication and "stealth" mode.
> > 
> > Earlier this year, I published some ideas on the subject here
> > https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Onion%20Things.pdf
> > showing how you could use Orbot and IP Camera apps to build a 
> > cloud-free
> > Tor-secured "Dropcam" style setup.
> > 
> 
> Nice! An interesting Orbot feature to have is making QR Codes of 
> authenticated Hidden Service info so mobile devices can easily add each 
> other to a trusted network.

That is a great idea. I am thinking of writing a module for the Home
Assistant platform that would handle the tor install and setup, and it
could autogenerate this QRcode as well.

Any thoughts on a format? torhs://clientname:authcookie@foo.onion looks
decent.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Using Tor Stealth HS with a home automation server

[Nathan Freitas]

Now published here:
https://home-assistant.io/cookbook/tor_configuration/

On Fri, Jul 8, 2016, at 12:53 PM, Nathan Freitas wrote:
> I've been working on some ideas about using Tor to secure "internet of
> things", smart devices other than phones, and other home / industrial
> automation infrastructure. Specifically, I think this could be a huge
> application for Tor Hidden Services and Onion sites configured with
> Hidden Service Authentication and "stealth" mode. 
> 
> Earlier this year, I published some ideas on the subject here
> https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Onion%20Things.pdf
> showing how you could use Orbot and IP Camera apps to build a cloud-free
> Tor-secured "Dropcam" style setup.
> 
> Now, I've taken the first step to setup my own instance of Home
> Assistant "an open-source home automation platform running on Python 3.
> Track and control all devices at home and automate control. Installation
> in less than a minute."
> 
> Instructions on this are below. It all seems to be working well, but I
> would love any feedback, comments, thoughts that you might have. I would
> also like to ensure that any work on next-gen HS designs includes these
> kinds of use-cases.
> 
> ***
> Pull request for the new "Tor cookbook" example for Home Assistant:
> https://github.com/home-assistant/home-assistant.io/pull/627
> 
> ***
> 
> Tor Onion Service Configuration
> 
> This is an example about how you can configure Tor to provide secure
> remote access to your home assitance instance as an Onion site, through
> Tor’s Hidden Service feature. With this enabled, you do not need to open
> your firewall ports or setup HTTPS to enable secure remote access.
> 
> This is useful if you want to have:
> 
> Access your HA instance remotely without opening a firewall port or
> setting up a VPN
> Don’t want to or know how to get an SSL/TLS certificate and HTTPS
> configuration setup
> Want to block attackers from even being able to access/scan your port
> and server at all
> Want to block anyone from knowing your home IP address and seeing your
> traffic to your HA
> Background and Contact
> 
> This configuration is part of an effort to apply strong cryptography
> technologies (like Onion Routing and End-to-End Encryption) to
> technology we increasingly depend on in our day to day lives. Just like
> when WhatsApp enabled end-to-end encryption messaging for everyone,
> every home automation and IoT platform should do the same, because A)
> the technology is all there, freely licensed and open-source and B) up
> to this point, all the commercial manufacturers have been doing a
> horrific job with security.
> 
> You can learn more about how Tor can be used to secure home automation
> and IoT platforms through this short set of slides on the Internet of
> Onion Things
> 
> This configuration was provided by @n8fr8 (github, twitter) of Guardian
> Project and Tor Project. You can send questions, feedback and ideas to
> supp...@guardianproject.info.
> 
> Hidden Services and Onion Sites
> 
> Tor allows clients and relays to offer hidden services. That is, you can
> offer a web server, SSH server, etc., without revealing your IP address
> to its users. In fact, because you don’t use any public address, you can
> run a hidden service from behind your firewall. Learn more about Hidden
> Services on the Tor Project website.
> 
> Onion sites are websites that run on a Tor Hidden Service node. “dot
> onion” sites are an IETF recognized special use domain name.
> 
> Setting up Tor on your Home Assistant
> 
> First, install Tor. On a Debain-based system, you can install the
> package easily:
> > sudo apt-get install tor
> 
> You can find more instructions for downloading and installing Tor on
> other platforms on the Tor Project Download Page.
> 
> Next, modify Tor’s main configuration file /etc/tor/torrc to include the
> following lines:
> 
> ...
> HiddenServiceDir /var/lib/tor/homeassistant/
> HiddenServicePort 80 127.0.0.1:8123
> HiddenServiceAuthorizeClient stealth haremote1
> ...
> The “sleath” entry above ensures traffic to and from your HA instance
> over Tor, is hidden even from other nodes on the Tor network. The
> “haremote1” value is a generic client name entry that you can modify as
> you please.
> 
> Then, restart Tor: >/etc/init.d/tor restart
> 
> Then read the new generated authentication cookie from the Tor-generated
> hostname file:
> > sudo more /var/lib/tor/homeassistant/hostname
> 
> The output of that command should look something like this, but with
> your own unique “dot onion” domain and authentication cookie:
&

[tor-dev] Using Tor Stealth HS with a home automation server

[Nathan Freitas]

I've been working on some ideas about using Tor to secure "internet of
things", smart devices other than phones, and other home / industrial
automation infrastructure. Specifically, I think this could be a huge
application for Tor Hidden Services and Onion sites configured with
Hidden Service Authentication and "stealth" mode. 

Earlier this year, I published some ideas on the subject here
https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Onion%20Things.pdf
showing how you could use Orbot and IP Camera apps to build a cloud-free
Tor-secured "Dropcam" style setup.

Now, I've taken the first step to setup my own instance of Home
Assistant "an open-source home automation platform running on Python 3.
Track and control all devices at home and automate control. Installation
in less than a minute."

Instructions on this are below. It all seems to be working well, but I
would love any feedback, comments, thoughts that you might have. I would
also like to ensure that any work on next-gen HS designs includes these
kinds of use-cases.

***
Pull request for the new "Tor cookbook" example for Home Assistant:
https://github.com/home-assistant/home-assistant.io/pull/627

***

Tor Onion Service Configuration

This is an example about how you can configure Tor to provide secure
remote access to your home assitance instance as an Onion site, through
Tor’s Hidden Service feature. With this enabled, you do not need to open
your firewall ports or setup HTTPS to enable secure remote access.

This is useful if you want to have:

Access your HA instance remotely without opening a firewall port or
setting up a VPN
Don’t want to or know how to get an SSL/TLS certificate and HTTPS
configuration setup
Want to block attackers from even being able to access/scan your port
and server at all
Want to block anyone from knowing your home IP address and seeing your
traffic to your HA
Background and Contact

This configuration is part of an effort to apply strong cryptography
technologies (like Onion Routing and End-to-End Encryption) to
technology we increasingly depend on in our day to day lives. Just like
when WhatsApp enabled end-to-end encryption messaging for everyone,
every home automation and IoT platform should do the same, because A)
the technology is all there, freely licensed and open-source and B) up
to this point, all the commercial manufacturers have been doing a
horrific job with security.

You can learn more about how Tor can be used to secure home automation
and IoT platforms through this short set of slides on the Internet of
Onion Things

This configuration was provided by @n8fr8 (github, twitter) of Guardian
Project and Tor Project. You can send questions, feedback and ideas to
supp...@guardianproject.info.

Hidden Services and Onion Sites

Tor allows clients and relays to offer hidden services. That is, you can
offer a web server, SSH server, etc., without revealing your IP address
to its users. In fact, because you don’t use any public address, you can
run a hidden service from behind your firewall. Learn more about Hidden
Services on the Tor Project website.

Onion sites are websites that run on a Tor Hidden Service node. “dot
onion” sites are an IETF recognized special use domain name.

Setting up Tor on your Home Assistant

First, install Tor. On a Debain-based system, you can install the
package easily:
> sudo apt-get install tor

You can find more instructions for downloading and installing Tor on
other platforms on the Tor Project Download Page.

Next, modify Tor’s main configuration file /etc/tor/torrc to include the
following lines:

...
HiddenServiceDir /var/lib/tor/homeassistant/
HiddenServicePort 80 127.0.0.1:8123
HiddenServiceAuthorizeClient stealth haremote1
...
The “sleath” entry above ensures traffic to and from your HA instance
over Tor, is hidden even from other nodes on the Tor network. The
“haremote1” value is a generic client name entry that you can modify as
you please.

Then, restart Tor: >/etc/init.d/tor restart

Then read the new generated authentication cookie from the Tor-generated
hostname file:
> sudo more /var/lib/tor/homeassistant/hostname

The output of that command should look something like this, but with
your own unique “dot onion” domain and authentication cookie:
abcdef1234567890.onion ABCDEF1122334455667789 # client: haremote1

You are now done with the HA Tor server configuration. Make sure your HA
instance is running, and now you can move to client configuration.

Tor Client Access Setup

Using this setup, you can access your HA instance over Tor from your
laptop or mobile device, using Tor Browser and other software.

Add the authentication cookie to your torrc client configuration on your
laptop or mobile device. Using the sample values from above, it would
look like this:
HidServAuth abcdef1234567890.onion ABCDEF1122334455667789

For Tor Browser on Windows, Mac or Linux, you can find the torrc file
here:
/Browser/TorBrowser/Data/Tor/torrc-defaults
Once 

Re: [tor-dev] [GSoC 2016] Orfox - Report 3

[Nathan Freitas]

On Thu, Jun 30, 2016, at 03:49 PM, Spencer wrote:
> > Amogh Pradeep:
> > we have a new logo for Orfox :D
> Is there a reason for the malalignment of the stroke?

... because perfection is boring? ... because I had five minutes to do
it? ... because there is a secret hidden meaning?

You choose! :)

Otherwise, will look into it.
 
> And that one permission 'Download files without notification', or is 
> this out of the scope of your work?

Is there a ticket or thread on this?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [valencia2016] Leif's important piece on update golden keys

[Nathan Freitas]

On Sun, Mar 6, 2016, at 11:44 AM, Holger Levsen wrote:
> Hi,
> 
> On Montag, 29. Februar 2016, Spencer wrote:
> > > [auto update] a threat model we must
> > > take more seriously.
> > > we are making real progress.
> > Like what?
> 
> https://reproducible-builds.org has the very long answer and 
> https://reproducible.debian.net shows the status for Debian in great
> detail.
> (And these pages have links to the status of other projects as well.)

... and also:
https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds

+n
___
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

[Nathan Freitas]

The issues in this timely story came up a number of times today at Tor Dev as a 
threat model we must take more seriously. Fortunately, thanks to Tor Browser, 
Lunar, Holger, Hans, Fdroid and others, we are making real progress.

 
http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-key-backdoor-its-called-auto-update/___
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!

[Nathan Freitas]

Mozilla is adding some new runtime installation features to reduce the
size of the mobile Firefox APK. Is this happening at all on desktop? It
makes me nervous as the "default" config could very much more greatly,
not to mention having a new centralized attack channel.

- Original message -
From: Sebastian Kaspari 
To: "mobile-firefox-dev" 
Subject: Downloadable content: Fonts!
Date: Fri, 19 Feb 2016 11:56:42 +

Good news, everyone!

Our first step to downloadable content has been enabled in Nightly: This
means we now stopped to ship fonts[1] in the APK and instead download
them
at runtime (Bug 1194338 [2]).

With that we reduced the size of the APK by roughly 6.4% (~ 2.7MB) [3].
​
Without having the fonts downloaded (yet) our users can still browse
websites but they may look less nice. And in fact, as things go, a bug
caused just that to happen in Nightly (We don't download any fonts): bug
1249354 [4].
So if websites are currently looking a bit weird on Nightly then that's
because of that. The bug should be resolved soon and after that let me
know
if you see any new weird issues related to (wrong) fonts. :)

Our plans for the future:
* Right now we ship the list of fonts and the location to download with
the
application. We want to synchronize this catalog of content from a Kinto
instance: https://bugzilla.mozilla.org/show_bug.cgi?id=1201059
* We want to download hyphenation dictionaries at runtime too:
https://bugzilla.mozilla.org/show_bug.cgi?id=1095719
* Eventually we might even want to download (some) localization files at
runtime: https://bugzilla.mozilla.org/show_bug.cgi?id=945123

Best,
Sebastian

[1] https://www.youtube.com/watch?v=6J2rrFiN1Jw
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1194338
[3] https://twitter.com/Anti_Hype/status/699905577196134400
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1249354
___
mobile-firefox-dev mailing list
mobile-firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: [guardian-dev] RC-7 is out - try to repro? Re: towards reproducible Orbot

[Nathan Freitas]

On Thu, Jan 28, 2016, at 02:27 PM, Ximin Luo wrote:
> Hey, thanks for this!
> 
> I'd like to ask please upload this (or 15.1) to F-Droid soon. The version
> currently in F-Droid is RC-4 and is broken with orwall -
> orwall-allowed/redirected apps see no internet, but tor is connected and
> orfox can access it. RC-7 fixes this issue, I just tested it out.

Yes, will do. Thanks for testing.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: [guardian-dev] RC-7 is out - try to repro? Re: towards reproducible Orbot

[Nathan Freitas]

With this release and updates to our build process, we are close to
having Orbot be reproducible.

Otherwise, this should be the last RC for v15.1, and it now includes
built-in Obfs4, Obfs3, Scramblesuit bridges from TBB, plus a few new
ones from Nima. This will make it much easier for users in places who
need bridges to be able to use them without taking an extra step.

- Original message -
From: Nathan of Guardian 
To: guardian-...@lists.mayfirst.org
Subject: [guardian-dev] RC-7 is out - try to repro? Re: towards
reproducible Orbot
Date: Thu, 28 Jan 2016 10:12:59 -0500



On Wed, Jan 27, 2016, at 10:10 AM, Hans-Christoph Steiner wrote:
> > Then anyone will be able to run this to verify the build:
> >
> > git checkout 15.1.0-RC-4
> > ./make-release-build
> > ./compare-to-official-release ~/Downloads/Orbot-v15.1.0-RC-4.apk \
> > bin/Orbot-v15.1.0-RC-4.apk

I've just posted RC7 built from make-release-build. I haven't attempted
to run the compare script yet, so if someone out there wants to try,
that would be great. My bet is that I didn't do something right, and it
won't match, but I would love to be proven wrong!

APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-7.apk
Sig: https://guardianproject.info/releases/Orbot-v15.1.0-RC-7.apk.asc

/** 15.1.0-RC-7 / 27-January-2016 /
91225ab053d0ffec4a414be461ee41e6465446bd **/

* fd45fa3 enable TransProxy and DNSPort by default without root - some
users run their own iptables transproxy scripts with AFWall and
 n

/** 15.1.0-RC-6 / 27-January-2016 /
a8dbdacbcb2412bb08c4a665145371c3ac4abef1 **/

Fixes to enable/attempt reproducible builds for this release
* 226d92e make-release-build: env vars need to be first on the command
line
* 20c16ae ignore more files generated by the build
* 9883a89 faketime is only needed when building, not when cleaning
* eaa2dde explicitly indicate we are building armeabi
* 1b76c36 add make calls for both armeabi and x86 with clean
* 75eb36e remove lib binaries
* 3be93a0 only build for x86 and armeabi

...and one small UI bug:
1839b8f add-in missing "break" for Meek Google




-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Orbot v15.1.0-RC-4

[Nathan Freitas]

Orbot update with new built-in bridges (currently using the TBB default
list, randomly shuffled!) and some other small fixes for the user
interface, reproducible builds, and VPN feature. 

- Original message -
From: Nathan of Guardian 
To: guardian-...@lists.mayfirst.org
Subject: Orbot v15.1.0-RC-4
Date: Mon, 25 Jan 2016 22:48:01 -0500


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Fixes based on feedback from our RC-2 release this will be up on
Play and F-Droid shortly, and from the link below right now.

/** 15.1.0-RC-4 / 25-January-2016 /
80491ea95bd62346bf3f3a579d3302dbd84f4ca9 **/

APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk
SIG: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk.asc

Improve Bridge selection to support built-in default bridges
* c235e3e tweak the string about bridges a little bit
* 2a72814 choose up to 2 bridges from default list randomly
* 1dbe5ea make bridge allocation shuffle randomly to distribute load
inspired by this work: https://trac.torproject.org/projects/tor/tic
* cf1a644 add support for loading default bridges from asset file

VPN mode now uses Google's DNS (tunneled through Tor) as default
* 9af00fe change VPN mode DNS to use Google's 8.8.8.8

Other UI fixes
* ba83559 this should be kbps in fact
* ab8709d add orfox icon to replace orweb
* 6eb0a93 improvements to Locale changing in app
* 0669add re-add appcompat, update to latest, move to Android 23 to
build - this is required for latest appcompat, and to address the bu
* c05d8e7 remove appcompat, and just support support-v4

Fix our stpcpy implementation to ensure no buffer overruns
* 4913b0c better implementation of stpcpy for pre-Android 21 NDK

Make the build process better and more reproduceable
* 735b298 make-release-build: remove faketime from `ant release`
* 461e35d make-release-build: freeze time when running ndk-build
* 5c86b5c make-release-build: make sure ndk-build can be found
* 58d53ea make-release-build: use strip-nondeterminism to get
reproducible build
* 5ce1f5f make-release-build: make sure tag signers exist before
verifying tags
* 72eab39 build jtorctl directly, using a symlink to point to its source
code
* a6ac016 use symlinks to provide alternate folders for Hebrew and
Indonesian
* 5fb4e9b update ndk-builds to NDK 4.8 toolchain


- --
  Nathan of Guardian
  nat...@guardianproject.info

- --
  Nathan of Guardian
  nat...@guardianproject.info
-BEGIN PGP SIGNATURE-
Version: Mailvelope v1.3.4
Comment: https://www.mailvelope.com

wsFcBAEBCAAQBQJWpuxcCRCoARg+abN6qQAABa8P/2AlGCzBOBWhb4rVTvfE
64af8Pw031oJyyFDvtlUeETS1Ct95Zz7prP41ywhItPi/6eLCTwkbcbDA+Zl
xDK6eSy6NhyMgh2qrC3US45HvQGjSCA7496IM5T3lL71wEL71sxAIaPh2abP
1akDEiXiJTnRUqFGui0aQkt0rJKQ0GShqJXmDM6qvuMCoiJSJ/ehc6Rnkyam
3/m4j5+IZ5JNpPKPDFjmW5cNFSDr+11SSdWlzjC9QfE8Ebo0rceMgpFASqH+
alzl6dB7y2rA+QeQcFQfwTlckKELq/cNofruV4UYmEIIlt/3dPZkIoIPlxBT
i/ozTkmSPyEUurnxmAJQMVhergN/0WzGOWST5ceLABjjuVsoVrCZ7ai4eKiX
M2zHxPQdjeLnc1HG5IXYLQcABJ9j9ol84oIH4VfcMPBCSjb205S42ChBx8Tm
9LGSSkn1i7JmVR2BaXaxmhbgoU5X+abumy3fH2uwDS5WCMDAExVw43sb8qM9
pGbDxK/wYd4aBaYZQK9VO7nA48eiv7yIw7uoKOhA7JFOnLg8he0DcngikCIx
VNEqaO231Kgj1kN8Uc8+ombelRxb++997gnWfqE2ZHsEt3BpRpSAephJMJyq
pxOeW/0tQL860oObACLjIp9xZ5FecZPWB4QqDEBRdOtT4MsgjDRP/Wty8Rzt
UF2G
=9Fk9
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Release: obfs4proxy-0.0.6

[Nathan Freitas]

On Mon, Jan 25, 2016, at 09:38 AM, Yawning Angel wrote:
>benefit is that it is a lot easier to package than meek-client + the
>external helper, and this can probably save binary size on things
>like Android.

Yes, I've been waiting for this. It is especially useful since we will
be including both ARM and x86 builds shortly, so the size of PT storage
in the app is already going to double.

Thanks for the continued hard work on this.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Does Orbot use default obfs4 bridges?

[Nathan Freitas]

On Tue, Jan 19, 2016, at 03:33 PM, David Fifield wrote:
> On Tue, Jan 19, 2016 at 03:29:38PM -0500, Nathan Freitas wrote:
> > 
> > On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote:
> > > Does Orbot have a list of default built-in obfs4 bridges? Or do users
> > > fetch them dynamically? I looked in the source code and found default
> > > meek bridges but not default obfs4.
> > 
> > No we have no default Obfs4 bridges built-in. It has been on my list to
> > get done, because we really should, obviously to make the user
> > experience better, and to alleviate meek traffic.
> > 
> > > I'm asking because we recently added a few new high-capacity default
> > > obfs4 bridges.
> > >   https://bugs.torproject.org/18071 (1 bridge)
> > >   https://bugs.torproject.org/18091 (2 bridges)
> > 
> > I will get this built-in ASAP.
> 
> The list of Tor Browser built-in bridges is here:
> https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js

Fantastic. Those will be built into the next release.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Does Orbot use default obfs4 bridges?

[Nathan Freitas]

On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote:
> Does Orbot have a list of default built-in obfs4 bridges? Or do users
> fetch them dynamically? I looked in the source code and found default
> meek bridges but not default obfs4.

No we have no default Obfs4 bridges built-in. It has been on my list to
get done, because we really should, obviously to make the user
experience better, and to alleviate meek traffic.

> I'm asking because we recently added a few new high-capacity default
> obfs4 bridges.
>   https://bugs.torproject.org/18071 (1 bridge)
>   https://bugs.torproject.org/18091 (2 bridges)

I will get this built-in ASAP.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Orbot 15.1.0-RC-1

[Nathan Freitas]

- Original message -
From: Nathan of Guardian 
To: guardian-...@lists.mayfirst.org
Subject: Orbot 15.1.0-RC-1
Date: Fri, 15 Jan 2016 15:34:20 -0500


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Orbot v15.1 is out as a release candidate. It includes Tor 0.2.7.6, a
very reliable VPN mode (full device or app-specific), a major update to
Orbot icon, and many more important improvements.

APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-1.apk
Sig: https://guardianproject.info/releases/Orbot-v15.1.0-RC-1.apk.asc
Code:
https://gitweb.torproject.org/orbot.git/commit/?id=f541e9ffe14a2719863327bf262b48de135ee0fd
Changelog:
https://gitweb.torproject.org/orbot.git/tree/CHANGELOG?id=f541e9ffe14a2719863327bf262b48de135ee0fd

/** 15.1.0-RC-1 / 15-January-2016 /
f541e9ffe14a2719863327bf262b48de135ee0fd **/

We updated the essentials
* 317405d update external versions of Tor 0.2.7.6 and OpenSSL 1.0.1q

We made the ability scan QR codes from bridges.torproject.org work
again!
* 8f7165c fixes for settings processing and QRCode scanning of bridges -
support new JSON array form bridges.torproject.org - only en
ab

We fixed the DNS leak bug in the VPN feature and improved the usability
overall (no Orbot restart required)
* 76b2171 update pdnsd and tun2socks to Android-16 add stpcpy function
not present before Android-21
* 39244a6 fix the ability to select per app VPN routing
* d839b15 fixes for VPN service UI to work on Android6
* 3691cca native binary asset building fixes move pdnsd exec to assets
* f369652 add code to kill pdnsd daemon when VPN is stopped
* f1fcec3 add support for PDNSD DNS Daemon for VPN DNS resolution Tor's
DNS port doesn't work well with the VPN mode, so we will use
PD
* 8d8fe0c updates to improve VPN support
* 699b60d add linancillary for badvpn tun2socks update for DNS

We added the controversial ability for the user to easily set their exit
country, with the default to the whole world
* 52acf68 move "World" string to resource
* 3b41365 allow country exit node select to persist
* b208178 add initial support for easy exit country selection

We now recommend Orfox over Orweb
* 51205b8 update for Orfox
* 0a5dd08 use a browser constant here, with the new constant being Orfox

We made some new graphics
* c54ab18 deleted these graphics
* 534c2fb update style, icons and graphics

We improve the build process, updated localizations and links to other
repos:
* 3240367 clean shouldn't clean assets, so we can easily builds for
multiple platforms
* 0081d00 remove Pluto Go building form this Makefile for now
* 2288210 update to OpenSSL's github mirror
* dfc5101 update tfx config
* eaf49da update store and app translations
* fe9119d update jenkins-build script
* 6dc8cf6 update makefile for new pluto builds
* 0261236 change this to "browser button"
* 3462cbd small updates to icon and strings
* bb7 update installer to get PLUTO binaries from assets
* 7d213e2 delete pluggable transport binaries here; build with Makefile
use the external/pluto project
* 6cf1201 update makefile to support PLUTO builds
* 871701e add link for new icon
* 6fb4f0c update binaries
* cd0bfd3 [Trivial] Fixed broken reference to Main Activity in 
WALKTHROUGH
* 0cde639 fix translations for common issues
* 2acdd29 update localizations for strings and app description

- - --
  Nathan of Guardian
  nat...@guardianproject.info
-BEGIN PGP SIGNATURE-
Version: Mailvelope v1.3.3
Comment: https://www.mailvelope.com

wsFcBAEBCAAQBQJWmVe+CRCoARg+abN6qQAAdksP/2REHo8U2M42/cBLD9Pd
wKnPxGTNMnLYsv0Nq7hJMwmMky/7BNopBW9T2pjIiLSxj3soNUdw7LJAgA57
ns0bI2BNqILcai/gK3j9tw1dOQdfvYmfKL4omZuJpGSOSotGW/F9nVnv8SBn
l8ddE0rU5FUyrJ3Si+QNgkCB4heij6oNOAFqrUb6YRQcUuu08tl18b3IGr1N
VfWk4504FjwJIKX1LiYLVHRL2Se49UGYOmeg+cZtKcVV/6zmcl66hsaAdqZD
+7IhcUivlGPU37v/IP3Af9hbpLIcW/eyW6Arf3kKD8Pv08mwg5gHQDblOcD0
j5Ai29Tig+75RHjmCdkIBnc4dhByGbNaiY49t12gBq2/m9zNwgqibmxozG3Y
gTecvL5rGxgYdOYby1Hd9ndSF7x5R2L/IREAbotsvph4TxUhHh2AAnumAU9a
YitErhaNE3vim6ywP8Il92WJ3gIDUlQimXAJuVmsOQcnXRLIq2LcJUW2IkfJ
1+D+Z4z1xJePDAOaguxK1WHb3TerG4y/CT7btQb2ibTf6u0pMgCYK7+bRf1S
pPlkzr6sh+DWkihom+rU+vrLsqAhuGfVydsVy3RS+n6ea+dEpqY92YGaFXxZ
XbwYrNOsBDD+rlzvKJr/51GgxmtGvVTfeh+P0bxClnIkwoyuDSH7MftONFeY
OxI3
=16US
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot roadmap feedback

[Nathan Freitas]

On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote:
> On 12/01/16 16:16, Nathan Freitas wrote:
> > The broader idea is to determine which Tor torrc settings are relevant
> > to the mobile environment, and that could use a more intuitive user
> > interface than the empty text input we currently offer in our Settings
> > panel. This may also mean implement a slider type interface mechanism
> > similar to Tor Browser. In addition, users are interested in being able
> > to control which network types (wifi vs 3g) Orbot runs on, in order to
> > conserve spending on bandwidth.
> 
> Briar's TorPlugin has an option to disable Tor when using mobile data,
> feel free to backport it to Orbot. Likewise for the plugin as a whole,
> if it would be a suitable basis for LibOrbot. We've benefitted a lot
> from your work and I'd love to send some contributions back upstream!

Is TorPlugin already a distinct library / module?

+n
___
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

[Nathan Freitas]

I've got big plans for Orbot in 2016... any thoughts on the roadmap
below, particularly how it aligns with Tor core roadmap, would be
appreciated.

- Original message -
From: Nathan of Guardian 
To: guardian-...@lists.mayfirst.org
Subject: Orbot roadmap feedback
Date: Mon, 11 Jan 2016 22:58:05 -0500


Here is my current set of brainstormed ideas for Orbot that I am
currently working through... please add, edit, improve and prioritize as
you are willing and able.

- Continued inclusion of the latest and greatest pluggable transports
(Obfs*, Meek, ???)

- Improved support for requesting and configuring Obfs4 bridges -
directly integrate with BridgeDB to provide streamlined way for people
to get bridges where Tor is blocked

- More Orbot VPN features including better UI for enabling/disabling Tor
routing, blocking specific apps, ports and/or hosts, and general
"firewall" or little snitch type features within the Orbot VPN

- 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)

- OrbotRelay/Bridge: improved UI for running a bridge or relay from
within Orbot, including support for scheduled times (night only) or
states (only when plugged in, on wifi, and screen is off, etc)

- Removal of Polipo, in favor of new streamlined in process HTTP proxy
(less memory use, and more stable)

- Creation of LibOrbot module/library for use by any app to embed Tor
into their app

- 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.

- OrbotWear / OrbotTV: Should we expand Orbot support to other Android
platforms like watches and Smart TVs? Perhaps Orbot relay/bridge mode
could run on a TV or set top box?

- Some sort of "Pro" or Donation-ware version to allow a
pay-what-you-can concept within the app

Good, bad, ugly? Let me know!

-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot roadmap feedback

[Nathan Freitas]

On Tue, Jan 12, 2016, at 10:48 AM, Georg Koppen wrote:
> Nathan Freitas:
> > - 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.
> 
> Could you explain that point a bit more, what you currently have and
> what you plan to do? Especially the exit country selector seems kind of
> scary to me but maybe I am just missing some bits. I looked at the
> changelog you sent to tor-talk (in the alpha 1 release mail) but did not
> find anything related.

The broader idea is to determine which Tor torrc settings are relevant
to the mobile environment, and that could use a more intuitive user
interface than the empty text input we currently offer in our Settings
panel. This may also mean implement a slider type interface mechanism
similar to Tor Browser. In addition, users are interested in being able
to control which network types (wifi vs 3g) Orbot runs on, in order to
conserve spending on bandwidth.

The Exit country selector option (basically a list of countries that
starts with "World" as the option) is definitely controversial, but it
is also something that comes up over and over again as a feature
request. It is expected especially of a VPN-style app, which Orbot now
is. It may be we only enable it when the VPN feature is enabled, and
disable it when Tor is used directly via SOCKS from the Orfox browser.
We may also need to just sufficiently warn and inform the user so they
can decide for themselves what to do.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Pluggable Transports v1 spec rewrite.

[Nathan Freitas]

On Thu, Oct 29, 2015, at 09:19 AM, Yawning Angel wrote:
> Hello all,
> 
> In an attempt to make Pluggable Transports more accessible to other
> people, and to have a spec that is more applicable and useful to other
> projects that seek to use Pluggable Transports for circumvention, I have
> drafted a re-write of the spec.
> 
> This is not intended to alter existing behavior, but instead make it
> clear that the whole "Pluggable Transports" thing isn't just for Tor.
> 
> Unless people have serious objections, this will replace the existing
> PT spec, to serve as a stop-gap while the next revision of the PT spec
> (that does alter behavior) is being drafted/implemented.
> 

Any small or big changes to highlight that push us to the more
accessible goal?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

[Nathan Freitas]

On Thu, Oct 1, 2015, at 01:15 AM, Andreas Krey wrote:
> On Wed, 30 Sep 2015 17:12:53 +, Tim Wilson-Brown - teor wrote:
> ...
> > Are there any use cases that:
> > * need NAT punching,
> > * don???t need service location anonymity, and
> > * would benefit from lower latency?
> 
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing a NAT.
> 
> Like the webcam raspi I'm just booting up.

I have been looking at the use of Tor and Onion Services for Internet of
(Onion'd) Things applications, but broadly I haven't thought how and
when single onions could add extra benefit. Mostly in IoOT (IoO?) the
goal is to remove the centralized corporate clouds that are currently
used, and to protect your endpoints (house, car, office, etc) from
becoming easily discovered and compromised.

Accessing a home webcam ("dropcam" or "baby monitor" in the common
parlance) is the best example I can think of where you want all the Tor
goodness, and lower latency is also needed. Most of the other apps I can
think of can deal with async messaging and high latency (i.e.
change/check your thermostat settings).

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Orbot v15.0.1 beta 3 and NetCipher update

[Nathan Freitas]

- Original message -
From: Nathan of Guardian nat...@guardianproject.info
To: guardian-...@lists.mayfirst.org
Subject: Orbot v15.0.1 beta 3 and NetCipher update
Date: Fri, 26 Jun 2015 10:19:49 -0400

*** Orbot v15.0.1 beta 3 released *** 
From: https://dev.guardianproject.info/news/233

See our previous news update (https://dev.guardianproject.info/news/231)
for the more data or review the changelog here:
https://gitweb.torproject.org/orbot.git/tree/CHANGELOG?id=e00f830ecadbca1b02eff2bfee804cd1e7b920e9

We've pushed the release to our Google Play beta channel
(https://play.google.com/apps/testing/org.torproject.android) and our
/release folder here.

APK: https://guardianproject.info/releases/Orbot-v15.0.1-beta-3.apk
PGP Sig:
https://guardianproject.info/releases/Orbot-v15.0.1-beta-3.apk.asc

You can also use FDroid to subscribe to our nightlies repo here (please
uninstall any other version of Orbot first):
https://dev.guardianproject.info/debug/org.torproject.android/fdroid/repo

*** NetCipher library updated (v1.2) ***

We've also updated our NetCipher library to support the update Intent
API in Orbot that supports background starting, improved status messages
via broadcasts and more. NetCipher also includes clearer code for
support HttpUrlConnection proxying, TLS socket hardening, and has been
re-organized a bit for clarity.

https://github.com/guardianproject/NetCipher

The sample app shows how to use these classes:
https://github.com/guardianproject/NetCipher/tree/master/sample



-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Services and IP address changes

[Nathan Freitas]

On Thu, May 21, 2015, at 07:16 AM, Martin Florian wrote:
 I think I've found one or more bugs that appear when Tor clients
 hosting HSes change their IP address during operation. I'm slightly
 overwhelmed from reading the Tor source code and not sure how to best
 fix them.

Thanks for bringing this up. I know Michael from Briar has definitely
focused on solving this at some point, and Yaron from the Thali Project
(who build this library:
https://github.com/thaliproject/Tor_Onion_Proxy_Library), as well. I've
been implementing an OnionShare-type app myself, and had hoped this was
solved by some recent changes, but it seems not, from your experience.

 The central issue that I discovered can be reproduced like this
 (assuming Tor clients A, B and C):
 1. (Setup) A hosts the HS X and A, B and C are all booted up.
 2. B connects to X - it works!
 3. A changes its IP address.
 4. B tries to talk to X again - doesn't work!
 5. C tries to talk to X (for the first time) - works like a charm (so
 X IS working)
 
 I digged through the Tor log and source code and have now arrived at
 following hypothesis for why this particular error happens:
 - - after A changes its IP addresses, it never establishes a circuit to
 the old RP with B again.
 - - B, on the other hand, keeps trying to talk with A through that RP,
 saying that it is an Active rendezvous point. B never stops trying
 to use that RP.

I wonder if B also was running a hidden service, if it would be possible
at the application level for A to tell B that it has changed IP
addresses, and then through some interaction with the Tor Control Port,
to fresh the RP?

 So, they appear to be two sides to this:
 a) A not notifying B or the RP about its IP address change.
 b) B not considering the possibility that the RP might not be active
 anymore.
 
 b) seems easier to fix. Some logic needs to be included for forgetting
 about RPs that have failed once. I identified
 connection_ap_expire_beginning() as one potential place to do this. Am
 I on the right track? Is this a good idea? And how do I forget about
 RPs? These are some of the questions I'm struggling with...
 
 I should also probably open a bug report, but I thought I might first
 ask for some advice here.

I think there is a bug report somewhere, but I am not sure the exact
number or state of it.

 PS: Why this is important: HSes/Onion services running on mobile
 devices will very often have to deal with IP address changes. I'm
 thinking about applications like Briar or our own hacky attempts to
 enable generic P2P application development on top of Tor hidden
 services (https://github.com/kit-tm/PTP).

Definitely an important topic.

+n

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!

[Nathan Freitas]

On Mon, Apr 13, 2015, at 02:05 PM, Daniel Martí wrote:
 Possibly stupid question, but wouldn't a static linux/x86 binary work
 just fine as long as you're executing it directly? As far as I know the
 Android port is just for all the bindings involved in e.g. writing a
 game in Go that does OpenGL calls back to Android.

There a few more changes in there, as well, such as how DNS works on
Android, and few other small underlying differences.

 
 For example, I found this bit in a blog post online:
 
  Copy myexectuable under your Android project’s ./libs/armeabi/ folder.
  If you’re targeting one of the rare x86 Android devices, build to
  x86/Linux and copy the resulting binary to ./libs/x86 (and yes, you
  can include both in a single APK, and it will deploy whichever one is
  appropriate).
 
 But then this would mean that we wouldn't need android/arm either, since
 we could just use linux/arm instead :)

We were previously using linux/arm for the PT compiling, and it mostly
worked, but it turns out there are enough small differences in the
Android API from Linux, that it does matter to target Android
specifically. This is similar to why we need the Android NDK for tor
cross-compile, and not just a generix linux ARM build.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!

[Nathan Freitas]

On Mon, Apr 13, 2015, at 12:57 PM, Yawning Angel wrote:
 On Mon, 13 Apr 2015 10:14:43 -0400
 Nathan Freitas nat...@freitas.net wrote:
  One interesting issue is that GoLang 1.4.1, which we are using to
  cross-compile the Meek and Obfs4 pluggable transports to Android, only
  supports targeting Android ARM for right now... I assume that will
  change soon, but if not, we may have to add Obfsclient back into Orbot
  for supporting x86 devices.
 
 Hmm, maybe I should add obfs4 support to obfsclient.  I have code for
 all of the crypto I would need to add.

Let me reach out to the GoLang Android community and see what the
blocker is... I was thinking the same thing though, it wouldn't be hard
to still support Obfsclient, along with the Go-based PT's.

Thanks!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!

[Nathan Freitas]

- Original message -
From: Nathan of Guardian nat...@guardianproject.info
To: guardian-...@lists.mayfirst.org
Subject: Orbot v15 RC3... now with x86/ATOM-power!
Date: Mon, 13 Apr 2015 09:55:44 -0400

Making some tiny changes to external/Makefile and jni/Application.mk
means we can now build the tor, polipo and xtables binaries, along with
the tun2socks.so for any necessary chip architecture. I've added support
for x86 in this release, which only added a few MB to the overall APK. 

Somehow, devices with Intel ATOM chips were able to run Orbot v14
releases, even though we didn't target x86. I think ATOM has some sort
of light ARM compatibility mode, but we broke that in the update for
v15... anyhow, this is better, as it is officially supported and tested.

One interesting issue is that GoLang 1.4.1, which we are using to
cross-compile the Meek and Obfs4 pluggable transports to Android, only
supports targeting Android ARM for right now... I assume that will
change soon, but if not, we may have to add Obfsclient back into Orbot
for supporting x86 devices.

The most popular x86/ATOM devices we have heard people complaining about
seem to be Galaxy Tab 3 and the Asus Zenphone and Padphone devices.

Anyhow... details below...



APK: https://guardianproject.info/releases/Orbot-v15.0.0-RC-3.apk
Sig: https://guardianproject.info/releases/Orbot-v15.0.0-RC-3.apk.asc
Tag: https://gitweb.torproject.org/orbot.git/tag/?id=15.0.0-RC-3

/** 15.0.0 RC 3 / 13-Apr-2015 / b941a1c7d5588db7efd9fab672ec518a69f76f84
**/

b941a1c show warning about bridge limits on Intel x86/ATOM devices
325ca1f only ARM chips can support the new Obfs4, Meek bridges so hide
the UI options that promote them, and just request standard br
i
3c6f173 make buttons not resize weirdly with long strings
421764b make socksbypass local port random
4ab1854 update resource installer to handle different architecture
e7a7d8c support variable arch builds to support x86 move asset builds to
/assets folder
74deb39 support building tun2socks for x86
933b2e9 Small VPN and socket monitoring related fixes
-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: [guardian-dev] Orbot v15 RC 2

[Nathan Freitas]

- Original message -
From: Nathan of Guardian nat...@guardianproject.info
To: guardian-...@lists.mayfirst.org
Subject: [guardian-dev] Orbot v15 RC 2
Date: Thu, 09 Apr 2015 13:24:46 -0400

Orbot v15 RC2 is out addressing some critical and *odd* issues with copy
and paste of bridges, VPN refresh on network switching, dumb bug fixes
related to root and transproxy settings, and one or two other odds and
ends.

WARNING: If you are using the email for bridges feature on Android,
and you copy and paste the bridge lines into the Bridges setting box,
you might not notice that Android somehow removes some spaces in the
string. Make sure to put a space back in between the server:port and the
key portion of the string. If you scan the QR codes from
bridges.torproject.org this shouldn't happen.

APK: https://guardianproject.info/releases/Orbot-v15.0.0-RC-2.apk
SIG: https://guardianproject.info/releases/Orbot-v15.0.0-RC-2.apk.asc
Source tag: https://gitweb.torproject.org/orbot.git/tag/?id=15.0.0-RC-2

/** 15.0.0 RC 2 / 9-Apr-2015 / 60f19ca **/
d6c51bc Fixes for bridge setup, and root/shell interaction 
- If you paste bridge addresses from Gmail, you get some strange
characters
c39cdcb improve root access check for transproxy
7d8eea2 switch back to DNS on 10.0.0.1, update after VPN refresh
690a8c3 Improved handling of VPN and Tun2Socks on Network Switch
9974654 fix for setting root and transproxy preferences

/** 15.0.0 RC 1 / 8-Apr-2015 / 280f69dfa10c38d880e98e71954526c68f1b3df5
**/
776b7af use loopback address
e6fe252 auto-restart Tor when config changes
384fe1c fix handling of network connectivity state management
02a42e4 update translated strings
628c9d8 update tor to 0.2.6.7
906ec7f v15-beta-2 small fixes for VPN
d6eb1dc fixes for network switching with VPN enabled
f37b935 modifications to bridge setup strings



-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!

[Nathan Freitas]

On Fri, Mar 20, 2015, at 04:05 AM, isis wrote:
 Nathan Freitas transcribed 0.8K bytes:
  On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote:
   What would it take to get some screenshots that show how to turn on
   pluggable transports? I would like to add a guide to
   https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and
   instructions to
   https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howtousepluggabletransports
   .
   
   Or do you have such a guide I can just link to?
   
  
  We're still finalizing the UI for the new features (QR code scanning,
  meek bridge type selection, etc) so once that is completed, we'll do a
  round of screenshots, guide updates, etc. This will most likely happen
  in early April.
 
 Wow, this is awesome!  Great work, to all of you!
 
 Let me know if there's anything more I can do to help.

In thinking about how users on phones/tablets will actually get
obfs3/4/scramblesuit bridges, I realized that going to
https://bridges.torproject.org on their mobile device will not be a
great experience. The QR code scanning if they or a friend also has a
PC, but in a pure mobile environment, it doesn't help so much.

I can create a ticket for this, but just to lay out the idea, I think we
need to have the bridge:// (or the improved proposed obfs4:// obfs3://
type specific scheme URLs) as a clickable link in both the bridges.tp.o
site and the gettor email response messages. 

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!

[Nathan Freitas]

On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote:
 What would it take to get some screenshots that show how to turn on
 pluggable transports? I would like to add a guide to
 https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and
 instructions to
 https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howtousepluggabletransports
 .
 
 Or do you have such a guide I can just link to?
 

We're still finalizing the UI for the new features (QR code scanning,
meek bridge type selection, etc) so once that is completed, we'll do a
round of screenshots, guide updates, etc. This will most likely happen
in early April.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!

[Nathan Freitas]

- Original message -
From: Nathan of Guardian nat...@guardianproject.info
To: guardian-...@lists.mayfirst.org
Subject: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
Date: Thu, 19 Mar 2015 11:12:59 -0400


Orbot v15 alpha work is nearly done... 

APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk
SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk.asc

Highlights:

* Updated to tor-0.2.6.4-RC
* VPN / full device Apps mode is fully implemented and stable - no
root needed to run all apps on your device through Tor
* Meek and Obfs4 pluggable transports are now included and working quite
well, even with the VPN mode
* Easy scanning and sharing of bridge address QR codes from
bridges.torproject.org
* Removed integrated webview/webkit for now, since Android WebView is
generally p0wn3d

More at: https://gitweb.torproject.org/n8fr8/orbot.git/tree/CHANGELOG

Thanks to nickm, isis, yawning, fifield, sandro, team psiphon and many
others for all the various amazing pieces coming together to make Orbot
v15 a very important and big release.

+n

-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!

[Nathan Freitas]

On Sat, Feb 14, 2015, at 03:04 AM, CJ wrote:
 
 
 On 14/02/15 08:58, Nathan Freitas wrote:
  
  
  - Original message -
  From: Nathan of Guardian nat...@guardianproject.info
  To: guardian-...@lists.mayfirst.org
  Subject: Orbot v15-alpha-3 with VPN and Meek!
  Date: Sat, 14 Feb 2015 02:57:34 -0500
  
  
  More progress on Orbot VPN support, and now, thanks to our new PLUTO
  library (https://github.com/guardianproject/pluto), support for Meek
  (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4
  as well.
  
  Currently you can use Meek or you can use VPN, but you can't use both
  together... still working on that, as I can't get Meek to talk to the
  passthrough HTTP proxy I use to allow socket connections out of the VPN
  filter.
  
  To use Meek, just enable the Bridges button on the home screen,
  without using any bridge config info, and it will default to using the
  Meek Azure instance. If you set the bridge line to 0 it will use Google,
  and 1 it will use Amazon, and 2 it will use Azure.
  
  The VPN mode is just as easy, just enable VPN using the homescreen
  toggle button, then start/restart Orbot. All apps on your phone should
  now be running through Tor.
  
  Remember, Bridges and VPN don't work at the same time, for now... but
  please test both features separately, and let me know how well they work
  for you.
  
  APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk
  SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc
  
  Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or
  https://github.com/n8fr8/orbot/tree/v15-dev
  
 Hello Nathan!
 
 Glad seeing this VPN part going further! I just have concerns regarding
 my app compatibility (orwall): does orbot still opens ports on
 localhost, and are they still the same, or shall I detect orbot version
 and/or probe for opened ports?

Everything is the same as usual. 

I don't think we can support both Orwall and VPN at the same time, so
that will be another choice the user will have to make.

The VPN doesn't fulfill the requirements of advanced users who want the
level of protection provided by Orwall and what Mike Perry originally
outlined. It is tricky to start on boot, there is no guarantee system
services can't route around it, and it can be killed if Orbot crashes.

Root and IPTables will still be required for that. VPN mode is really
just for circumvention of app blocks by novice users.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[Nathan Freitas]

On Fri, Feb 13, 2015, at 07:45 PM, Yawning Angel wrote:
 Yes, this means that if you run kittensomgmewmew.onion and are scared
 of the NSA's persistent attempts to extract your hidden service key,
 via ultrasonic laser beamed from their satellites, you could run your
 tor instance entirely in a ram disk, and load the HS key manually each
 time from a USB token you wear around your neck.

A very practical use of this in the Orbot context, is that we can now
store all HS identity data in an IOCipher encrypted volume, which the
user can unlock with a strong passphrase when they want to start up
their onionsites. Currently, all HS data is stored in the standard Tor
data paths, only protected by the per-app user permissions on Android.
This means the data can be accessed by rootkit capable malware apps and
forensic extraction tools. With IOCipher, that would make that a great
deal harder, and impossible if they were in a locked state (i.e. the key
is not in memory).

We are working on adding OnionShare-capabilities to Orbot, so this is
well timed!

+n

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!

[Nathan Freitas]

- Original message -
From: Nathan of Guardian nat...@guardianproject.info
To: guardian-...@lists.mayfirst.org
Subject: Orbot v15-alpha-3 with VPN and Meek!
Date: Sat, 14 Feb 2015 02:57:34 -0500


More progress on Orbot VPN support, and now, thanks to our new PLUTO
library (https://github.com/guardianproject/pluto), support for Meek
(https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4
as well.

Currently you can use Meek or you can use VPN, but you can't use both
together... still working on that, as I can't get Meek to talk to the
passthrough HTTP proxy I use to allow socket connections out of the VPN
filter.

To use Meek, just enable the Bridges button on the home screen,
without using any bridge config info, and it will default to using the
Meek Azure instance. If you set the bridge line to 0 it will use Google,
and 1 it will use Amazon, and 2 it will use Azure.

The VPN mode is just as easy, just enable VPN using the homescreen
toggle button, then start/restart Orbot. All apps on your phone should
now be running through Tor.

Remember, Bridges and VPN don't work at the same time, for now... but
please test both features separately, and let me know how well they work
for you.

APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk
SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc

Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or
https://github.com/n8fr8/orbot/tree/v15-dev

-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] A proposal to change hidden service terminology

[Nathan Freitas]

On Tue, Feb 10, 2015, at 01:13 PM, A. Johnson wrote:
 Hello all,
 
 Several of us [0] working on hidden services have been talking about
 adopting better terminology. 

I agree 100% with the term list and am eager to start using it.

Some of the problems with current terms areh
   1. '''Hidden''' and '''Dark''' have a negative connotations.
   2. '''Hidden-service website''' is too long; '''hidden site''' is too 
 vague.
   3. '''.onion''' (read dot onion) is hard to say and not very 
 descriptive.
   4. There is no general term for the set of available hidden services.
   5. The term '''encrypted service''' is too general. This term refers to 
 a setup (still needing development) in which Tor is required to connect to a 
 service, but the service location is not hidden. Even without server 
 anonymity, this setup can provide enforced client anonymity, secure name 
 resolution, censorship circumvention, and end-to-end-encryption. Making the 
 server location known can allow for improved performance (by shorter 
 circuits) and security (by enabling location-aware path selection by the 
 client).
 
 We’ve come up with the following suggestions for better terms, which we’d
 like to offer up for discussion:
   1. '''onion service''' should be preferred to refer to what is now 
 called a hidden service. If other flavors of onion services develop in the 
 future, this term could refer to all of them, with more specific terms being 
 used when it is necessary to make the distinction.
   2. '''onionsite''' should be preferred to refer to a website (i.e. an 
 HTTP service serving up HTML) available as an onion service. This can be 
 extended to other specific types of services, such as '''onion chatroom''', 
 '''onion storage''', '''onion cloud service''', etc.
   3. '''onion address''' should be preferred to refer specifically to the 
 xyz.onion address itself.
   4. '''onionspace''' should be used to refer to the set of available 
 onion services. For example, you can say “my site is in onionspace” instead 
 of “my site is in the Dark Web”.
   5. '''onion namespace''' should be used to refer to the set of onion 
 addresses currently available or used recently (context-dependent).
 
 We couldn’t decide on the best names for alternative onion service
 setups, because they don’t exist yet! But, we have some ideas about how
 these things might be named:
   1. Some names for a setup in which the onion service location is known 
 but still must be connected to via the Tor protocol:
   * '''Tor-required service''', '''TRS''' for short
   * '''Direct onion service''', '''direct service''' for short
   2. Some names to specify that the onion service is hidden, if that 
 becomes necessary:
   * '''Protected onion service''', '''protected service''' for 
 short
   * '''Tor-protected service''', '''TPS''' for short
   3. Some names to specify that a client connects to an onion service 
 non-anonymously:
   * '''Client-direct access'''
   * '''tor2web mode'''
 
 We’re maintaining an evolving wikipage with the above suggestions [1].
 Some of us are already beginning to use the suggested terminology, to see
 how it works out. One nice goal might be for Tor to choose the new terms
 that it likes (if any) and use them in the rollout of next-gen onion
 services [2]. So we’re bringing up this subject now to a larger segment
 of the Tor community. Thoughts?
 
 Best,
 Aaron
 
 [0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten
 Loesing, and Paul Syverson
 [1]
 https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology
 [2]
 https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
 ___
 tor-dev mailing list
 tor-dev@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Nathan Freitas]

On Sun, Nov 9, 2014, at 07:50 AM, George Kadianakis wrote:
 Hidden Service authorization is a pretty obscure feature of HSes, that
 can be quite useful for small-to-medium HSes.
... 
 For example, it would be interesting if TBB would allow people to
 input a password/pubkey upon visiting a protected HS. Protected HSes
 can be recognized by looking at the authentication-required field of
 the HS descriptor. Typing your password on the browser is much more
 useable than editing a config file.

We have been working on implementing an OnionShare feature for Orbot, as
a plugin/add-on. Since the client and the server are both one simple
app, it seems like we could easily implement the HS Authorization
feature. Since the goal is to share a file with a small audience, the
second client key approach seems to be the best, most secure approach
to me.

Any thoughts?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser

[Nathan Freitas]

On 08/21/2014 06:18 AM, isis wrote:
 Nathan Freitas transcribed 3.5K bytes:

 Nice outcome from GSoC! I think the primary discussion here is whether
 Tor Browser's existing build system can be extended for Android, and
 whether Orfox should exist at all as separate app/project.
 
 Is there somewhere where Tor developers might track the translation between
 the patches on your fork of the mobile Firefox and the Tor Browser fork of
 Firefox? I.e. Guardian Project commits abcdef01 and abcdef02 correspond to TPO
 bug #1234 which maps to Mozilla bug #11223344, etc.

There are tickets, but not mentioned in the commits. I will backtrack
and work through them and make that more clear moving forward.

For now, all of our commits on the gecko-dev repo itself are in the
Android Java code, and no changes have been made to any of the
underlying Firefox core.

 It's a tiny bit hard to track what's going on between your merges of upstream,
 your student's code, your code, and what you are purporting to fix relative to
 what we've already fixed. I apologise for all the extra trouble this would
 place on you, but I think in the long run that it would make collaboration
 between the TB team and Guardian Project's Gecko fork easier for everyone
 involved.

It is exactly what we need to do, and not any trouble. We quickly got to
it works! state, but now need to transition to the long term, careful,
audited approach.

Thanks for the feedback.

 
  Forwarded Message 
 Subject: [guardian-dev] Orfox: New Firefox-based Android Private/Secure
 Browser
 Date: Wed, 20 Aug 2014 12:49:33 -0400
 From: Nathan of Guardian nat...@guardianproject.info
 Organization: The Guardian Project
 To: guardian-dev guardian-...@lists.mayfirst.org


 Based on work done this summer by Amogh Pradeep during his Google
 Summer of Code stint with me, we now have a real working version of
 Firefox/Fennec for Android with all the necessary defaults changed to
 match Tor Browser's defaults as closely as possible. We also remove
 the Android permissions for things like camera, mic, GPS and turn off
 webrtc.

 You can see the primary commits we've made here (many by me, but
 started successfully by Amogh):
 https://github.com/guardianproject/gecko-dev/commits/adaa37949dbba690ed0392c1fd004b006e73bfdf

 We still need to figure out which preferences and features map between
 the desktop mobile browser and the Android version, so there is quite
 a bit of work to do. For instance, even though the preference from Tor
 Browser is set to start in private browsing mode, it doesn't work at
 all in the Android app. Also, we haven't applied any of the lower
 level source patches to the gecko engine yet, or included any of the
 default extensions like HTTPS Everywhere or NoScript. Sorting out and
 resolving these differences is what is on deck for this fall, and
 everyone is welcome to join in. In addition, the recent audit work
 from iSec
 (https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study)
 is also on our minds, and figuring out how we can live up to the goals
 of that study on a mobile device is also very important.

 The current build successfully passes the DNSLeakTest.com tests and
 passed the HTML5 video leak issue here:
 http://xordern.net/why-you-really-shouldn't-use-orweb-anymore.html
 ip-check.info still doesn't see the browser as being Tor Browser, so
 there are some differences yet to resolve there.

 The whole project is automatically building on our jenkins server, and
 you'll find all the links to APKs and our test build repo below.

 Over the next few months we hope to launch this as our new official
 browser for Orbot, and deprecate Orweb as quickly as possible.

 ***
 Main project repo:
 https://github.com/guardianproject/OrfoxFennec

 Our fork of Mozilla's Gecko-Dev:
 https://github.com/guardianproject/gecko-dev/tree/adaa37949dbba690ed0392c1fd004b006e73bfdf
 (which we can rebase on the original as needed)

 Nightly/dev builds direct APK download here:
 https://guardianproject.info/builds/OrfoxFennec/

 OR our fdroid test build repo:
 https://dev.guardianproject.info/fdroid/repo?fingerprint=F8ED4C73C125E7A67F99DB269480DAF50BE1758952E07EE5ABF116FE4B2DB1E8

 ***

 +n
 ___
 Guardian-dev mailing list

 Post: guardian-...@lists.mayfirst.org
 List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev

 To Unsubscribe
 Send email to:  guardian-dev-unsubscr...@lists.mayfirst.org
 Or visit:
 https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info

 You are subscribed as: nat...@guardianproject.info


 ___
 tor-dev mailing list
 tor-dev@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
 
 
 
 ___
 tor-dev mailing list
 tor-dev@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman

[tor-dev] Fwd: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser

[Nathan Freitas]

Nice outcome from GSoC! I think the primary discussion here is whether
Tor Browser's existing build system can be extended for Android, and
whether Orfox should exist at all as separate app/project.

 Forwarded Message 
Subject: [guardian-dev] Orfox: New Firefox-based Android Private/Secure
Browser
Date: Wed, 20 Aug 2014 12:49:33 -0400
From: Nathan of Guardian nat...@guardianproject.info
Organization: The Guardian Project
To: guardian-dev guardian-...@lists.mayfirst.org


Based on work done this summer by Amogh Pradeep during his Google
Summer of Code stint with me, we now have a real working version of
Firefox/Fennec for Android with all the necessary defaults changed to
match Tor Browser's defaults as closely as possible. We also remove
the Android permissions for things like camera, mic, GPS and turn off
webrtc.

You can see the primary commits we've made here (many by me, but
started successfully by Amogh):
https://github.com/guardianproject/gecko-dev/commits/adaa37949dbba690ed0392c1fd004b006e73bfdf

We still need to figure out which preferences and features map between
the desktop mobile browser and the Android version, so there is quite
a bit of work to do. For instance, even though the preference from Tor
Browser is set to start in private browsing mode, it doesn't work at
all in the Android app. Also, we haven't applied any of the lower
level source patches to the gecko engine yet, or included any of the
default extensions like HTTPS Everywhere or NoScript. Sorting out and
resolving these differences is what is on deck for this fall, and
everyone is welcome to join in. In addition, the recent audit work
from iSec
(https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study)
is also on our minds, and figuring out how we can live up to the goals
of that study on a mobile device is also very important.

The current build successfully passes the DNSLeakTest.com tests and
passed the HTML5 video leak issue here:
http://xordern.net/why-you-really-shouldn't-use-orweb-anymore.html
ip-check.info still doesn't see the browser as being Tor Browser, so
there are some differences yet to resolve there.

The whole project is automatically building on our jenkins server, and
you'll find all the links to APKs and our test build repo below.

Over the next few months we hope to launch this as our new official
browser for Orbot, and deprecate Orweb as quickly as possible.

***
Main project repo:
https://github.com/guardianproject/OrfoxFennec

Our fork of Mozilla's Gecko-Dev:
https://github.com/guardianproject/gecko-dev/tree/adaa37949dbba690ed0392c1fd004b006e73bfdf
(which we can rebase on the original as needed)

Nightly/dev builds direct APK download here:
https://guardianproject.info/builds/OrfoxFennec/

OR our fdroid test build repo:
https://dev.guardianproject.info/fdroid/repo?fingerprint=F8ED4C73C125E7A67F99DB269480DAF50BE1758952E07EE5ABF116FE4B2DB1E8

***

+n
___
Guardian-dev mailing list

Post: guardian-...@lists.mayfirst.org
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev

To Unsubscribe
Send email to:  guardian-dev-unsubscr...@lists.mayfirst.org
Or visit:
https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info

You are subscribed as: nat...@guardianproject.info


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] orbot: get its ports from another app

[Nathan Freitas]

On 07/29/2014 03:03 PM, CJ wrote:
 
 I'm currently developping orwall, a UI over iptables allowing to block
 all IP traffic and forcing selected apps through Orbot (while blocking
 the others), among other things.
 
 I'm wondering if there's a way to ask Orbot, if installed, its SOCKS and
 TransPort configuration.
 I think NetCipher lib may do it, but I'm not that sure.

This feature is underway. You can add a ticket on Github or via our dev
tracker: https://dev.guardianproject.info/projects/onionkit

For most users, it will be default (9040, 9050, etc), but its definitely
possible that people can change them, especially if they have the
dreaded Samsung Link conflict.

As for the implementation, it will simply be an Intent you send to Orbot
and it will respond with the values.

+n



___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Orbot Orfox - GSoC bi-weekly report 4

[Nathan Freitas]

On July 18, 2014 9:21:04 AM EDT, Georg Koppen g...@torproject.org wrote:
Amogh Pradeep:
 Status Report 4
 July 18th, 2014.
 
 Things I am working on:
 
 1)Setting up repos and building:
 After having built fennec, we have now started to try to get it built
 on the jenkins server. Hopefully we will be successful and will be
 able to push out a version of the browser soon.

... and by Jenkins server, he means the Guardian Project build server, which is 
our internal nightlies/CI machine not on the public web.

 2)DNS leak plugging:
 According to dnsleaktest.com , there seems to be a dnsleak in the
 current fennec browser that we've made, working on trying to plug
 this. Suggestions welcome!

Who's we here? Is there a bug anywhere one can follow?

Amogh and I for now.

https://github.com/amoghbl1/Orfox

https://github.com/amoghbl1/Orfox/issues/1

We have a tracker on dev.guardianproject.info as well but for now just using GH.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] jtorctl

[Nathan Freitas]

On 04/04/2014 02:54 AM, Karsten Loesing wrote:
 Wow, JTorCtl is probably not just unmaintained, but also probably
 doesn't have a single application using it since 2009.  There's a reason
 why it's sorted into the Attic group on https://gitweb.torproject.org/.

*ahem* Orbot represents 2 million users of jtorctl, and it works just
fine for us (in our limited use of it).

https://gitweb.torproject.org/orbot.git/tree/HEAD:/external

+n

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [Orbot patch] Properly skip tests when building libevent

[Nathan Freitas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/27/2014 12:30 PM, Daniel Martí wrote:
 This fixes the remaining $(top_srcdir) errors and properly
 generates event2/event-config.h

Thanks. Will review and integrate shortly.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTNGK/AAoJEKgBGD5ps3qptqUP/3Mug+D5pfEY7Iu9HF7QsSYj
VypvUWhpwdN6cAqznG/9XJSfe686OI/lgbF3jItWYAIwseRufiYxkRQvyR5ANBqs
9r04j55rirzZDxMX3sIdYIUx3mnjTR3nM2qMBshheEcJMiA69TCiH/TQx6BZCigR
RoMuh05m9zAKJAqWuGeuNAx+9RfF2RzMo0TEcweJmOY5QRu6ARSlBFESRSAtYm3M
NAAFgmZbOFFLwPec+2V2dNTOXVHpGj4OR+J67EjS3PUDmej+QBVoHWbGil0/3/Na
do4JF1XsOrCju05asHzk96fN2pPiOuCQ00Yx3uEPrXe7T5vyIei0becBo8VLFxBD
Ub7bL77gG9cIlIno1O/dc+4fkURBZHhOSz1GhXtv/Ca1v+cHT0ge7IqU+Ap0oh7x
nSFfnmlunafMKMUFT9WaLWNmBQ32hamgtBCuFNvA2cLBpWZLZGWRAjWIjosxGpEY
MNfxZKRHkjATm5pvPrjgh7zqyVH537+0IYbSU0TwQRaNZAn7o+NvkuNOoimupjVF
ud9f8A1QGYyfANQVi1IdOXPDks/t8RaAV4PiXqT8Ei/OCe1s6hBMFY4cSf5iIQDh
Ac98A3W8VXl641+cT6VndoJeAwOXcFwJqEPs8NsnpUnUneAf51rQX5dx68xdpHh0
DxH0/mt4HLKu+d0L0u5e
=8z1N
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Novel distribution mechanisms (was: s3 alternatives on libtech)

[Nathan Freitas]

On 03/07/2014 02:33 AM, Griffin Boyce wrote:
   I've been working with users who have networks in censored countries
 to expand access to specific software bundles (not just Tor).  My two
 approaches right now are Google Web Store and torrents attached to a
 stable offsite seedbox.

Have you looked into BitTorrent Sync? You can do semi-private (I
believe) Dropbox-like Torrent shares, that could be provisioned based on
emails or other requests from users.

There is a really nice mobile BitTorrent Sync app, so I have
particularly been interested in this as a means to distribute apps to
Iran and China.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Orbot+Orchid redesign

[Nathan Freitas]

Now that Orchid is released at a v1 stage, I have been thinking about having 
Orbot use it by default, and then offering ARM and x86 binaries as add-on 
enhancements. This would make the core Tor on Android experience more 
lightweight for client only use. If people want to run relays, need a higher 
performance option or want the real Tor, they can get the Orbot native APK 
add-on for their architecture.

Any objections to this approach? Is Orchid ready for this?___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: [guardian-dev] Orfox: first step towards Tor Browser on Android

[Nathan Freitas]

First small step towards a true Tor Browser on Android.

 Original Message 
Subject: [guardian-dev] Orfox: first step towards Tor Browser on Android
Date: Sat, 23 Nov 2013 23:18:30 -0500
From: Nathan of Guardian nat...@guardianproject.info
To: Guardian Dev guardian-...@lists.mayfirst.org


Since Android 4.4 replaced the guts of the WebView component with
Chrome, and there is no apparent way to set a proxy anymore (even
through tricks like reflection), I decided to accelerate our move
towards an entirely new approach to privacy-enhanced browsing.

I discovered two projects that provide a full standalone browser
component that you can embed in an app.

ChromeView, based on Chromium, and very much a drop-in replacement for
WebView:
https://github.com/pwnall/chromeview

GeckoView, Mozilla's own attempt to turn their browser engine into an
Android developer component:
http://starkravingfinkle.org/blog/2013/10/geckoview-embedding-gecko-in-your-android-application/

I started with ChromeView, but got stuck just trying to get it to run.
Both approaches require some strange use of putting .so and .pak
binaries into asset folders and such. I don't entirely understand why yet.

I ended up getting the GeckoView project's GeckoBrowser sample running
easily, and very quickly, started hacking in all the privacy-enhancing
Firefox about:config preferences I know. All the SOCKS and HTTP
proxying stuff works well, and I have even gotten to a fairly decent
report back on ip-check.info in terms of cookies, referrals,
user-agents, etc.

You can find the repo here, if you want to build and try yourself. No
binaries posted yet:
https://github.com/guardianproject/Orfox

I am aiming to do a release fairly quickly, at least for the Android 4.4
users who are currently left in a lurch.

Otherwise, if anyone wants to help build the best, most secure and
privacy-enhancing mobile browser in the world, what we need to do from
here is:

1) Start building the GeckoView library from source ourselves, and
figure out which components we really need. It is very bloated, and the
current APK is humongous.

2) Re-implement Orweb's various preferences into the new Orfox app, so
that users can easily choose to turn on/off javascript, clear cookies,
and so forth.

3) Connect with Mike Perry of Tor Project and start figuring out how the
Firefox patches / modifications he makes for Tor Browser can be applied
to the GeckoView builds.

Best,
 Nathan

___
Guardian-dev mailing list

Post: guardian-...@lists.mayfirst.org
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev

To Unsubscribe
Send email to:  guardian-dev-unsubscr...@lists.mayfirst.org
Or visit:
https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info

You are subscribed as: nat...@guardianproject.info


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Apple App Store Redux

[Nathan Freitas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/18/2013 01:39 PM, Erinn Clark wrote:
 * Ralf-Philipp Weinmann r...@coderpunks.org [2013:11:17 10:25
 +0100]:
 Getting TBB into the App Store would definitely help increase
 its visibility on the OSX side. However, I am not really in
 favour of giving a US company a list of all users having
 downloaded TBB plus information whether or not they are
 upgraded to the most recent version...
 IMO this is a very persuasive reason not to put it there.
 

For what it is worth, this is what we effectively do by putting Orbot
in the Google Play store. We heavily promote alternatives (direct APK
download, F-droid repo, etc), but Google Play is where the majority of
downloads come from.

Now, mobile is different, because the behaviors of users looking to
find and install software is quite different than on the web/desktop.

In addition, considering the amount of atrocious free proxy software
being peddled in Google Play, I feel I would be doing our intended
audience a disservice by not offering a quality option like Orbot,
where they are primarily looking to find solutions.

+n

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSimVnAAoJEKgBGD5ps3qpbAYP/3XemdFRrhXOV5J1BUrKPbzP
YyasI66Nirgo7XAzcjukCRYUBR2uF8tNhNyQW7EIL373CgCDKGWsAwebtyIa7ry1
V6jW31VVd0Iory9Vl/ZCTEpTXWKyfp/EhuLpUXZeeASi5H/R/qKQg+3j2/mO4j3h
OpowQFQmm5Z2s6oJ09HFQZ/2UfBExHnxV0oPLmYUOQ3hftRoD/uxsSIrWSO9u+OW
6u6z0HKgyg/+vcm1QXV7ozYaGXboaZ00NuJjhsm1aNQYGbtnn/gpFQfYmiMW85Pr
oM02pS0dk3RDk++9hyv8LAzdNxj/C2kUSvtL1xsgZMgReCC0rBJnBaHf3XESwkeG
njouArjw3RG6r/QNtpY/9lWM+ZFJcDHjkUHXyym7aVUgg520TruVyLwHn4fmzXL5
6EJDQktnPySamaimf1uI3zGUSQJv/nhiU1XNSUnNCEnRsVnNLxHh2+7FRC/gVOIw
XYGgQ0+Afk0sXlZRBB0yaARljWeWDSHhNARvvRSvAxnbtWm+/ltAa55m2CvA1Chg
AZYNwTZDYyzJ3xnDf5jXSeAxAEj0+VFcVM8evEGNiFcguQwBxWG5rzrSm3gR5hqG
dsTASZWa377NNVfNicMlnra+OAgJnPc1kFC3NPXMMlmLMsPwACN1GRd16HdxrDn1
u3gg39s2LoUQJZPOIWPe
=x52u
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Apple App Store Redux

[Nathan Freitas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/18/2013 02:07 PM, Nathan Freitas wrote:
 Now, mobile is different, because the behaviors of users looking
 to find and install software is quite different than on the
 web/desktop.

As a side note, for those interested, we are really investing in the
next 3-6 months in a new project called Bazaar which is about
decentralized but secure app sharing.

https://dev.guardianproject.info/projects/bazaar/wiki

This includes adding Tor support into the F-Droid open repo mobile client:
https://guardianproject.info/2013/11/05/setting-up-your-own-app-store-with-f-droid/

and investigating DropBox-like syncing solutions that work well over Tor:
https://guardianproject.info/2013/11/12/your-own-private-dropbox-with-free-software/

If all goes well, it will be fairly easy for people to socially share
apps like Orbot in a device-to-device manner over Hidden Services, OTR
chat sessions, wifi and bluetooth. Stay tuned!

+n

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSime4AAoJEKgBGD5ps3qp2+QP/0LWlxW5p20OT4m1UKZFSEGL
Cd92kX7ogfjFAIMc2x8BeMc0ic03lfziTLwao+mf3+IvIDnp4AJDyGwlNjyZ/pE2
t0PFioM/h24DTBkwHEd/oD0SUE9Idg8bJH66NadyA3aZLdh3vARFkddpjiVSVMnm
K5m1w46HlD5EcBjMUt0LGyIYCzVncblqI2zkP6YCpt0F4oB8/lCaWZGLAap/Yhn0
eX+P5GOZjL3T3Vy5Cm7Zo44saPoClElSJ2lfJNmUXYe735IO0u6CkomQ8wlB/VpV
ZlTrGd6xcB2g64jjkDUvcgWreKB/5jXJIWu0zi9V8GHZ5S9lSbvhfwoVlGGLWmh1
jUQGB9zsKQqNM6xMxoGsMcXXIKuHuqGW8wZxdff1HMp8ZhI9NVCcxXNdHT3kbduZ
cT50co2j0Td4DifuZohKWSnXAkLtVVBKH9QN21x+qNmSjmNcMlkSfkUDQRQ+fJqL
+zc77i1q/BZoK4Ht4C7l/Yk5RIhpn6H1wRaDr7OZetbbs/I322JZto3NUYZDmNNy
236G/5GmNnJEjQfymino6iRLipTPzr07eBI8FWChxhvWn1q9gs4Koo/yH8WVQ7EE
vr5D2P2NTwdZFSch6PFybyKWA2AIzRevBiS0Fmojsni6w4cZ28V2WP5KonKXrh8V
G1LSfFcwhhxBTj5lcmNF
=gzhF
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] IRC meeting to discuss sponsor F progress on Tue September 3, 18:00 to 19:00 UTC in #tor-dev

[Nathan Freitas]

Sorry to have missed the chat. Just dealing with the +1 in my family :)

Update below:

#16 Make push-to-talk VoIP work
August:
- Unclear.  Asked Nathan in private mail on September 4.

- ChatSecure OTR-Data feature is complete, enabling arbitrary data
stream with mime-type sharing within OTR TLV data:
https://github.com/guardianproject/Gibberbot/pull/261
- See OTR spec with TLV data support:
http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html

- Orbot v12 released, upgraded to the latest Tor RC


September:
- No plans known yet.

- Implementing Audio push-to-talk user interface, as alpha feature of
ChatSecure v12
- Testing, tuning of OTR-Data over XMPP over Tor


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] obfs3 and Android

[Nathan Freitas]

On 05/26/2013 12:48 AM, Abel Luck wrote:

I have experience getting python code working in android using SL4A.
It's relatively straightforward, the main problem is the IPC between a
python script and android app. There is no real way to do the IPC, you
have to roll your own.
There really isn't much IPC needed for obfsproxy fortunately. You just 
need to start it up and shut it down.


For Orbot's existing obfsproxy2 support, we do this easily via 
Runtime.exec() commands.



___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] obfs3 and Android

[Nathan Freitas]

On 05/25/2013 08:47 AM, Michele Orrù wrote:

In order to run some python code on Android for APAF, I have used
SL4A[1], which is a little tricky, but seems more actively developed
and ports a few external libraries which could be useful - i.e.
pyCrypto.
Yes, I think this might be the route. The plan would be to create a 
standalone app/plug-in for Obfs3 support, instead of bundling it into 
Orbot directly. This would allow us to support whatever complexity is 
needed for Python, without getting the core app too bogged down.


If anyone out there is interested in working on this, please get in 
touch with me directly, and/or just start hacking on code in a public 
repo. :)


+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Fwd: Fwd: Orbot feature for GSoC 2013

[Nathan Freitas]

Is there room for an Orbot developer under Tor's GSoC?

I know that I was completely awol during this process, and not a mentor,
but this is a worthwhile effort!


 Original Message 
Subject:Fwd: Orbot feature for GSoC 2013
Date:   Thu, 11 Apr 2013 17:50:26 +0200
From:   Pavlos onexema...@gmail.com
To: nat...@guardianproject.info
CC: a...@guardianproject.info



Hello,

I talked in #tor-dev and asked about a feature I could implement for
Orbot as part of Google summer of code 2013 and abel suggested the
implementation of the android 4.x's VPN Service as a way to get rootless
transparent torification.
I understand this was created
https://github.com/guardianproject/OrbotVPN but for some reason couldn't be
finished? Is it plausible to implement it? If not maybe there is something
else I could make?

Some words about me:
I'm a CS student at my 5th year. I finished with my courses a year ago and
I'm just enrolled because I'm an intern at CERN and have to be a student.
My github is here: https://github.com/uberspot/
I have worked previously on two android apps (OpenWifiStatistics that
coorelates gps with wifi scan data and AnagramSolver for solving anagrams)
and I have another one almost complete (a lan multiplayer trivia game).

Kindly awaiting your responce,
Paul



___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Fwd: Orbot feature for GSoC 2013

[Nathan Freitas]

On 04/11/2013 01:38 PM, Roger Dingledine wrote:
 But as Damian says, if you show up with a worthwhile project, a student,
 and no mentor in mind, this will not end well.

I understand. Good to know the window is still open. I will work with
the student some more to assess their viability. Abel on my team could
be an excellent mentor, with me as a backup, so long as he is planning
to be within range of radio comms this summer.

+n


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-talk] Mobile Anonymity and Circumvention seems not working

[Nathan Freitas]

Does the check.torproject.org  site return a connected message in the default 
browser?

chandra mohan rkchandramo...@gmail.com wrote:

Hi,

   I tried  Trasparent proying of Orbot  as  mentioned
https://guardianproject.info/apps/orbot/-OTHER
*APPS*  and observed all web (traffic built-in Browser, Gmail, YouTube,
Maps and any other application
that uses standard web traffic)and all DNS requests from my Android
mobile
are not following  Tor
encryprtion.

   Observed with wireshark and above mentioned application traffics
are having DNS request and DNS
response packets  and followed by large number of HTTP packets.

  My Mobile is running on Android 2.2  Kernel which is already root
and I also gave super user
permission for Tor installation.

 what is possibe  issue here?

Regards,
Chandramohan
___
tor-talk mailing list
tor-t...@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Using Tor as a library

[Nathan Freitas]

Christopher Schmidt christop...@ch.ristopher.com wrote:

Fabio Pietrosanti (naif)
lists-BEJ3GKOyH/ewup2xcto...@public.gmane.org writes:
 That's the future of Tor, to be integrated as a library just like an
 encryption library into application.

No, it's not.  Embedding a Tor client in another application cripples
auditability, configurability, updateability etc. of Tor.  So does
embedding a controller.  Even worse, an application trying to outsmart
the user by controlling Tor on its own poses a severe security risk.

Other than an encryption library, there is no well-defined output to an
input that a Tor library should produce.

Tor is a vivid, organic ecosystem of different, replaceable projects
that integrate into each other.  Embedding a static subset of these in
an application is wrong.


On Android, we have developed a library that allows a 3rd party developer's app 
to check if Orbot (and by extension Tor) is installed and running, and if 
either is false provides methods to prompt the user to resolve both false 
states. We also provide simple code for properly proxying app data through 
SOCKS.

Perhaps a similar approach could be taken for desktop and server apps that want 
to integrate with Tor?

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor proposals implemented in Tor 0.2.3.x

[Nathan Freitas]

Nick Mathewson ni...@freehaven.net wrote:

   180  Pluggable transports for circumvention

Happy to say that the trunk/master branch of Orbot supports obfsproxy bridges 
in the version we will push out this week to all .pf our users.

   171  Separate streams across circuits by connection metadata

Gibberbot v9, which is at rc4 now and will be final this week, supports this 
via random user/pwd values in the socks handshake. Thanks to Jake for the help 
on that one.

+n


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Orbot makefile / build update

[Nathan Freitas]

On 05/07/2012 11:55 AM, Fabian Keil wrote:
 Privoxy 3.0.12 was released in 2009, so I wouldn't call it a recent
 release. Did you run into problems with more recent versions? At least
 in theory they should work better. Fabian
I think this time around, I was trying to change as little as possible.
Since Privoxy 3.0.12 has been working quite well, I didn't want to move
forward on that within this Makefile effort.

However, since we now have a clean way to move forward, we'll tackle an
update on Privoxy, especially since our integration with Twitter for
Android depends upon HTTP proxying.

Best,
 Nathan
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Orbot makefile / build update

[Nathan Freitas]

Since the dawn of Orbot, way back in 2009, the onion routing robot app
has been built using an unwieldy combination of tools, based on an
extremely out of date method for cross-compiling C code for Android/ARM.
In the 1.x era of Android, there was no Native Development Kit as their
is now, but thanks to some craft individuals, scripts were developed to
utilize the compilers found within the core Android OS build kit.
However, this mean you had to build the entire Android OS to be able to
build Orbot, and you were potentially relying upon highly unstable
internal libraries.

This week, I finally bit the bullet, and decided to rewrite the build
process utilizing the more proper NDK tools, as well as utilize Git
submodules as a means for managing retrieval and version control of
dependencies. With the help of _hc, sebastian, rransom, vapourEyes, asn
and others, I was able to work through the various issues of porting
over to the more limited NDK environment, and come out with a properly
formatted Makefile for building all native code that Orbot relies upon.

This means that to fully build Orbot (including tor, privoxy, and
obfsproxy binaries, and the jtorctrl java library) you simply need to
ensure you have the Android SDK and NDK setup, and then:

1) git clone git://git.torproject.org/orbot.git
2) cd orbot
3) make -C external
4) android update project --name Orbot --target android-15 --path .
5) ant debug

That's it! (in theory).

At this point, I would love some clean eyes to look at this, try it out,
ask questions and who knows, perhaps submit a patch or two.

Human readme on new build process and prereqs:
https://gitweb.torproject.org/orbot.git/blob/HEAD:/BUILD

Makefile for Orbot and dependencies (openssl, libevent, privoxy, obfsproxy)
https://gitweb.torproject.org/orbot.git/blob/HEAD:/external/Makefile

Successfully executed build on our build server:
https://build.safermobile.org/job/Gibberbot/49/console

happy friday,
  n8fr8

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Obfsproxy client for Android

[Nathan Freitas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/12/2012 01:57 AM, Nathan Freitas wrote:
 I am going to sleep on this now a bit, do some more testing
 tomorrow, post a public build, then ideally about 18 hours from
 now, put a build up for release for Iranian users.

I've posted a signed test build of Orbot-1.0.7.2+OBFS-BY-DEFAULT here:
http://ge.tt/89SjZWD

** This is for EXTERNAL testing only and NOT for inside Iran users
yet. We have one more round of review tonight, and then should be
ready for targeted public release **

Please test on as many devices as you can, and report issues on trac
or via email. I will be offline for about eight hours, but active
again after that.

+n




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk84CbUACgkQhemw+yiNNc4xIQCeJAfmPBLWXNbxxAi/2sJBmbob
S/UAoIV07JOJhWSRFtz2msR9z2FJa2ik
=Sc2M
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Obfsproxy client for Android

[Nathan Freitas]

On 02/10/2012 08:11 AM, Roger Dingledine wrote:
 On Fri, Feb 10, 2012 at 07:56:04AM -0500, Nathan Freitas wrote:
  Thoughts on attempting to port and ship Obfsproxy client functionality
  to Android?
  Where should we begin? Any details on exactly what was done for the new 
  TBB?
 Step one, build obfsproxy for Android. I expect your biggest problem
 will be libevent2 since you won't have any packages for it. See

Happy to say that libevent2 and obfsproxy have been successfully
cross-compiled for Android w/o major patching, and all seems to be
working well with a manually hacked version of Orbot. I have to get some
sleep now, but should have a new Orbot proper build in 24 hours (with
the help of Gsathya and Kensen from GP).

I've posted some test binaries with an Android shell-based how to here:
https://github.com/downloads/guardianproject/Orbot/obfsproxy-20120212a.tar.gz
(.asc)

***
This currently requires root, and Orbot should be deactivated.

1) adb push the files about to /data/local

2) adb shell; su

3) mv the files above from /data/local to
/data/data/org.torproject.android/app_bin

4) chown the new files to the uid of the orbot app (e.g. chmod
app_2.app_2 tor).
find the uid by 'ls'-ing in the
/data/data/org.torproject.android/app_bin folder

5) chmod 700 obfsproxy; chmod 700 tor;

6) export HOME=/data/data/org.torproject.android/app_bin

7) /data/data/org.torproject.android/app_bin/tor DataDirectory
/data/data/org.torproject.android/cache -f
/data/data/org.torproject.android/app_bin/torrc

8) Open Firefox Mobile with ProxyMob add-on, and you should be ready to
roll.


***

Feb 11 03:29:23.275 [notice] Tor v0.2.3.11-alpha (git-9ce9836f853d8a31)
running on Linux armv7l.
Feb 11 03:29:23.276 [notice] Tor can't help you if you use it wrong!
Learn how to be safe at https://www.torproject.org/download/download#warning
...
Feb 11 03:29:31.000 [notice] Bootstrapped 80%: Connecting to the Tor
network.
Feb 11 03:29:31.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Feb 11 03:29:32.000 [notice] new bridge descriptor 'maximatorbridge'
(fresh): $55329E0FB775496D4479AC1E0D2CDE3B98D774C3~maximatorbridge at
212.112.242.160
Feb 11 03:29:32.000 [notice] new bridge descriptor 'ghobfsbridge1'
(fresh): $10D5B1C21544B64EBC2A4275FE32A8D4A40405B5~ghobfsbridge1 at
213.108.105.129
Feb 11 03:29:32.000 [notice] new bridge descriptor 'torbridge42'
(fresh): $9459581B2DA5458D19790C28918CB544B3854C8A~torbridge42 at
85.214.131.213
Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh):
$7C7DC083FFCFE383268B873D2CB046684B615648~Unnamed at 85.17.20.242
Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh):
$478208B87337CAC2E9391AD7B91D125193D5A641~Unnamed at 91.208.34.7
Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh):
$5F88FDA345422B32E1A20F2761182C23CD49EA79~Unnamed at 131.215.158.1
Feb 11 03:29:32.000 [notice] new bridge descriptor 'ndnop0' (fresh):
$9D7259A696F7DAB073043B28114112A46D36CFFD~ndnop0 at 109.105.109.163
Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh):
$00BC5E7111BD00E9AF463BE9BFE6255FE51CFCD9~Unnamed at 109.163.233.195
Feb 11 03:29:33.000 [notice] Tor has successfully opened a circuit.
Looks like client functionality is working.
Feb 11 03:29:33.000 [notice] Bootstrapped 100%: Done.


***

+n8fr8
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Obfsproxy client for Android

[Nathan Freitas]

Thoughts on attempting to port and ship Obfsproxy client functionality
to Android?

We have a good number of Iranian users it seems, and I think we can pull
it off in a few days, if it isn't insanely complex.

Where should we begin? Any details on exactly what was done for the new TBB?

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Size issues with Orbot statically linking OpenSSL

[Nathan Freitas]

On 01/15/2012 07:30 PM, Steven Murdoch wrote:
 Although post suggests that the Android NKD may have the relevant
 options on by default: 
 http://stackoverflow.com/questions/7216543/does-android-ndk-build-with-gc-sections-and-how-to-disable

We are still actually building with our pre-NDK droid-gcc approach,
which most likely means we are not benefiting from NDK optimizations. We
have begun rewriting the build process to be NDK-based, but if it ain't
broke... etc.

+n8fr8
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Size issues with Orbot statically linking OpenSSL

[Nathan Freitas]

On 01/15/2012 03:47 PM, Nick Mathewson wrote:
 Some stuff to try: openssl has lots of optional features and ciphers;
 you could probably disable a lot of them.  There are configuration
 options to do so.  If you're not sure what,  I could try to take a look
 at the list some time this week.

That would be very helpful, or at least, if you can point me to a spec
that indicates which features of OpenSSL that Tor relies upon I can
start there.

 linker to dump the unused ones. I believe it's called gc-segments or
 something. I have no idea if it would work with openssl, but it could be
 worth investigating. I believe there's a ticket for tor to use it by

Yes, will check into this. It seems like Android NDK may do this itself,
so this might accelerate our transition to using its arm cross-compiler.

+n8fr8
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] DuckDuckGo, iOS and other stuff.

[Nathan Freitas]

On 01/02/2012 02:39 PM, caine tighe wrote:
 there is serious value in ensuring Tor is an option for both Android
 and iOS.  Currently we support Tor via Orbot on Android via the HTTP/S
 proxy method since the SOCKS method is known to have DNS leaks.

I agree! As a side note, in Orweb v2, when you type a search in the
location bar, it utilizes the DDG hidden service.

The SOCKS method works fine if you support the right type of SOCKS.
There is inherently nothing wrong with Tor's SOCKS support, and it is
what we utilize for the Firefox Mobile ProxyMob add-on.

 application Covert Browser that claims to properly leverage Tor;
 however, since the source is closed, I remain unconvinced.  This

Regardless of the poor approach to transparency they have taken, it does
seem that Tor integrated into a browser or search app directly is the
only way to go on iOS at the moment. I don't quite understand what
happens when multiple apps with Tor embedded in them are running at
once, with the psuedo backgrounding/multitasking that iOS supports.

It is also true that it is best to keep Tor running and connected as
long as possible in order for it to be able to optimize circuits, update
directories, and so on. If you are constantly starting and stopping it
within one app, the performance may suffer.

 application stands to be both an interface to DuckDuckGo for quick and
 secure searching as well as a Tor enabled browser.

It would be fantastic to have you take this on, as an open-source option
is needed for iOS, and the Guardian Project isn't currently able to
expand to that platform.

best,
+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Uploading video over Orbot

[Nathan Freitas]

On 12/11/2011 11:54 AM, Nathan Freitas wrote:
 Some progress to share on Tor-related efforts with our Secure Smart Cam
 project with WITNESS. (More here:
 https://guardianproject.info/apps/securecam/ )

oops, and the specific repo and test APK app download are here:
https://github.com/guardianproject/sscxfer

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev