-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/05/14 04:06, Hans-Christoph Steiner wrote:
What's the earliest version of Android that supports 4096-bit
keys? I'm going to generate a new signing key for Briar soon and
I'd like to continue supporting Android 2.1 (APK version 7).
We
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'm getting a 404 error when trying to follow the (non-onion) link to
the F-Droid repo.
Cheers,
Michael
On 16/06/14 22:52, Hans-Christoph Steiner wrote:
I've been using it and enjoying it. Nice to have all my feeds
going through Tor by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
I've been thinking about a way to implement remote wipe for mobile
apps with encrypted local storage. The idea isn't suitable for Briar
because it requires internet access, but I thought it might be a
useful addition to CacheWord. Probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
There was a BlackHat talk about reverse-engineering Apple's multipeer
protocols - perhaps that's been used to build an interoperable
implementation on Android?
...@guardianproject.info wrote:
A random idea... Bluetooth device names can be up to 240 characters
apparently. What if we just used that as a messaging transport?
Essentially just staying in constant discovery mode.
On Tue, Sep 30, 2014, at 10:50 AM, Michael Rogers wrote:
-BEGIN PGP SIGNED MESSAGE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/10/14 14:29, Nathan of Guardian wrote:
So, this should work:
Intent discoverableIntent = new
Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE);
discoverableIntent.putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION,
0);
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/10/14 17:53, Nathan of Guardian wrote:
Interesting results... here is what my hacking has wrought:
https://github.com/n8fr8/gilgamesh
It is based on the Android-17 BluetoothChat sample, but changed to
use the getName() as the message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/10/14 17:53, Nathan of Guardian wrote:
Interesting results... here is what my hacking has wrought:
https://github.com/n8fr8/gilgamesh
A couple of quick bug reports:
* At startup it prompts to turn on Bluetooth but doesn't prompt to
make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/10/14 19:20, Nathan of Guardian wrote:
* It leaves the device name changed after I stop using the app.
Now my devices are all called things like Huh and Cool. ;-)
That is part of the fun... it also means your last message hangs
around
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/10/14 21:07, Chris Ballinger wrote:
However, I think it would be beneficial to utilize other transports
for Android--Android and iOS--iOS for increased overall range /
mesh quality. The iOS MultipeerConnectivity framework uses Wifi /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/10/14 07:22, Nathan of Guardian wrote:
I have implemented support for Wifi Direct, using the same device
renaming hack I used with Bluetooth:
This is so cool! What's the max length of a device name?
For aDTN we'd need to cram a signed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
I've been experimenting with small changes to Tor to improve the
performance of mobile hidden services. Attached are patches for Tor
(https://git.torproject.org/tor.git, tor-0.2.24 tag) and jtorctl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/08/14 01:00, str4d wrote:
This seems like an excellent time to announce that I have pushed
the first release of the I2P Android client library to Maven
Central (net.i2p.android:client:0.1). For now, it simply bundles
our standard Java APIs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I wonder if we could capture the discovery frames with airodump-ng and
explore them with wireshark...
Cheers,
Michael
On 09/10/14 18:43, Hans-Christoph Steiner wrote:
If there is DNS communication, that means there is IP communication
already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Resurrecting this thread to mention an idea that came to me last
night. I don't have time to try it out at the moment, but it might
allow us to create a Wi-Fi Direct connection between two devices
without any user interaction:
* Alice creates a
tracking low memory conditions is creating
onTrimMemory() and onLowMemory() in an Application subclass.
Android should call those when memory is getting low as the first
step before killing things. That's how I understand it at least.
.hc that's Michael Rogers:
Sorry if I'm misunderstanding
, Tim Bray wrote:
When I was in the Android group at Google, the dogma was always
that you can't count on on destroy() being called. The actual code
that does this should be part of AOSP...
On Dec 1, 2014 8:33 AM, Michael Rogers mich...@briarproject.org
mailto:mich...@briarproject.org wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/02/15 16:51, Nathan of Guardian wrote:
On Mon, Feb 2, 2015, at 05:09 AM, Hans-Christoph Steiner wrote:
Sounds intriguing. If you want to do the wifi service discovery
on android-16, there is jmdns. We had problems with the
Android
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/02/15 16:33, Nathan of Guardian wrote:
In both cases, the Bluetooth MAC address is published in a DNS
TXT record via Wi-Fi Direct service discovery. Reverse
engineering the rest of the FireChat protocol is left as an
exercise for the
On 13/04/15 14:55, Nathan of Guardian wrote:
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
A few quick comments:
1. You're calling a blocking method from the UI thread. Don't do that.
Instead, call the blocking method on a background thread and post the
results back to the UI thread when it returns. That's how the code I
posted yesterday works. If you want to collect all the results
You could use a CountDownLatch to manage the counter, but I'd probably
do something like this instead:
public void getReachableClients(final ReachableClientListener listener,
final int timeout) {
ListClient clients = getClients();
if(clients == null) return;
Executor executor
Hi Daniel,
Sorry if my comments yesterday came across as blunt - it was a long day. :-)
On 13/05/15 15:00, Daniel Martà wrote:
On Wed, May 13, 2015 at 12:25:25 +0100, Michael Rogers wrote:
A few quick comments:
1. You're calling a blocking method from the UI thread. Don't do that.
Instead
On 14/05/15 16:46, Daniel Martà wrote:
On Thu, May 14, 2015 at 11:55:29 +0100, Michael Rogers wrote:
Sorry if my comments yesterday came across as blunt - it was a long day. :-)
No problem. It was me who was asking for help.
Thanks man!
Yup, waiting on a background thread is the important
On 10/04/15 22:17, Hans-Christoph Steiner wrote:
I don't know the details of iOS, so I can't really say much there. So correct
me if I get any of that part wrong. But I think you get the gist of the idea.
And to be clear, when I say 'zerobin', I mean any instance of the zerobin
software,
On 14/04/15 15:11, Nathan of Guardian wrote:
On Tue, Apr 14, 2015, at 06:58 AM, Michael Rogers wrote:
On 13/04/15 14:55, Nathan of Guardian wrote:
Making some tiny changes to external/Makefile and jni/Application.mk
means we can now build the tor, polipo and xtables binaries, along
On 09/03/16 20:51, Nathan of Guardian wrote:
> ... and one for Briar and other apps with their own tor daemon
>
> 2973eac change how we look for processes to kill. fixes tor trac #18502
Fantastic, thanks for the quick fix!
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
s-Christoph Steiner
> <h...@guardianproject.info <mailto:h...@guardianproject.info>> wrote:
>
>
>
> Michael Rogers:
> > On 01/08/16 16:50, Nathan of Guardian wrote:
> >> Three years ago in Thailand, I bought a $50USD 6 inch wifi only
>
On 06/09/16 11:54, Hans-Christoph Steiner wrote:
> Have you run tests yet of HTTPS verification using your technique? You
> can take code from the NetCipher tests if you want.
Thanks, that's a good idea. We've tried it with a few HTTPS sites but
haven't done any testing in depth.
> I don't
On 06/09/16 10:48, Hans-Christoph Steiner wrote:
> Could we use this approach in NetCipher? I think Torsten that said this
> approach requires android-14 at least, but we could just use HTTP
> proxies to support older platforms.
As far as I know this should work on any version of Android, but
On 10/10/16 11:34, Chris Croome wrote:
> I was considering getting a 2016 Nexus to run CopperheadOS on, thinking
> that Google might sell last years phones off a bit cheaper after
> lanuching their latest ones, but they simply pulled the old phones from
> their site.
It looks like the whole Nexus
On 28/09/16 15:33, Hans-Christoph Steiner wrote:
>
> I just had a thought: since Briar and Orbot both are building tor and
> need regular updates, we could package the tor daemon binary as an AAR
> and publish it on maven repos. Then there can be a neat and clean build
> for just the tor daemon,
Hi arrase,
Thanks for discovering this bug. Can you describe how Briar's Tor daemon
conflicts with Orbot? What problems does it cause? Our goal is for Briar
to be able to operate on the same device as Orbot without problems.
Thanks,
Michael
On 15/11/16 00:32, arrase wrote:
> I have reviewed the
On 22/03/17 12:54, Nathan of Guardian wrote:
> On Wed, Mar 22, 2017, at 08:23 AM, Michael Rogers wrote:
>> Following up on an old thread to let you know that unfortunately the
>> approach we found for getting OkHttp to use a SOCKS proxy isn't safe. In
>> some cases OkHtt
On 06/03/17 14:34, Nathan of Guardian wrote:
> For now, Orbot does prompt you to disable the battery optimization
> features for Orbot when you enable a hidden service. Otherwise, I think
> it is up to the app server/process itself to handle their own wake lock
> needs, depending on what kind of
On 06/09/16 10:48, Hans-Christoph Steiner wrote:
>
> The Briar folks are working on getting HTTP connections on Android to go
> through Tor via SOCKS. They used a custom SocketFactory and Socket
> subclasses, with their own SOCKS handling.
>
>
It's interesting that this is happening at the same time Apple is
introducing bitcode, which similarly allows Apple to optimise the app
and sign the optimised version. This makes it very hard for developers
to verify that their users are receiving their apps without any
added/removed
On 16/05/17 21:34, Nathan of Guardian wrote:
>
>
> On Tue, Apr 11, 2017, at 02:39 PM, Kevin Gallagher wrote:
>> Please forgive me if this is not the correct place for this question. I
>> was wondering if Orbot checked for network connectivity every time it
>> attempts to build a Tor circuit or
On 10/05/17 19:57, Greg Troxel wrote:
> I agree that doze is pesky, but I don't think we're really going to have
> a great outcome with wakelocks for more than very brief intervals.
> Sure, if someone wants to run a server on a device that happens to be
> Android, with power, that's one thing.
;>
>> - Sent from my phone
>>
>> Den 19 maj 2017 16:12 skrev "Nathan of Guardian" <
>> nat...@guardianproject.info>:
>>
>>> On Fri, May 19, 2017, at 07:29 AM, Michael Rogers wrote:
>>>> Paranoid people might suspect that this simultane
Hi Hans-Christoph,
I hacked this together based on the PNG specification, which
distinguishes between ancillary chunks that can be removed without
affecting the image data, and critical chunks that can't. It's been
tested on exactly two PNGs so far. :-)
v3?
>
> .hc
>
> Michael Rogers:
>> Hi Hans-Christoph,
>>
>> I hacked this together based on the PNG specification, which
>> distinguishes between ancillary chunks that can be removed without
>> affecting the image data, and critical chunks that
, allowing us to read the stream twice?
Cheers,
Michael
On 28/03/18 19:43, Hans-Christoph Steiner wrote:
>
> Ah cool! It would be awesome to have the EXIF stripping work on a
> stream, rather than a file.
>
> .hc
>
> Michael Rogers:
>> Fantastic!
>>
;
> This is all it does:
> ExifInterface exifInterface = new ExifInterface(imagePath);
> for (String attribute : getExifAttributes()) {
> if (exifInterface.getAttribute(attribute) != null) {
> exifInterface.setAttribute(attribute, null);
> }
> exifInterface.saveAttributes();
>
Hi Hans-Christoph,
As far as I can tell, "javac --patch-module" won't get you where you
need to go. You could create (perhaps using symlinks) the directory
structure it's expecting, where the root of the package namespace is
inside a directory named after the module (e.g.
On 22/06/2020 15:53, Marcus Hoffmann wrote:
> Hi,
>
> (I work on F-Droid)
>
> On 22.06.20 13:20, Mark Murphy wrote:
>> On Sun, Jun 21, 2020, at 22:20, John Sullivan wrote:
>>> Just a quick comment on that last part. It may be worth mentioning for
>>> a fuller picture that F-Droid signs the
For what it's worth, the Briar team is planning to register a few
placeholder apps with signing keys that we can use for publishing future
apps beyond the deadline. Might be worthwhile for Guardian to do the same?
Cheers,
Michael
On 28/04/2021 20:06, Amogh Pradeep wrote:
Hey Nathan,
Here
On 25/07/2022 15:50, Nathan of Guardian wrote:
OnionShare Android also uses the tor-android library, but I believe it runs its
service in a separate Android process:
https://github.com/onionshare/onionshare-android
You can see this here:
48 matches
Mail list logo
