> This makes me wonder: Would it be helpful to start compiling a big
> list of things which could go wrong with a Tor implementation without
> making it obviously broken? I think a checklist like that might help
> people working on compatible implementations to have some idea what to
> look for on
On Mon, Dec 2, 2013 at 11:09 AM, Bruce Leidl wrote:
> To help you decide if Orchid is appropriate for use here's a list of
> important things which have not (yet) been implemented:
>
> * Path bias defense
> * Adaptive circuit build times (also, path bias depends on this?)
> * Stream isolatio
>> Any objections to this approach? Is Orchid ready for this?
>
> It seems like a good architecture to target. I'm not sure that the
> current Orchid codebase has gotten as much review yet as it would need
> before I'd be comfortable making it the default option, but an
> experimental build coul
On Sat, Nov 30, 2013 at 12:02 PM, Nathan Freitas wrote:
> 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 f
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 highe
