Hi,
On 20/03/2020 15:30, sajolida wrote:
>> In Tails' threat model it is assumed that adversaries monitor the default
>> bridges provided by the Tor Browser, and that our users want to avoid
>> detection of that, so we are not interested in adding the default bridges to
>> Tails
>
> We're not
Hi,
On 09/01/2020 16:15, Patrick Schleizer wrote:
> I am considering to install vanguards by default in Whonix.
>
> Is it sane to mix the Debian 'tor' package deb.torproject.org (buster
> repository) with packages.debian.org buster version of 'vanguards' or do
> you foresee any issues?
I would
Hi,
My comments are inline.
> Filename: 306-ipv6-happy-eyeballs.txt Title: A Tor Implementation of
> IPv6 Happy Eyeballs Author: Neel Chauhan Created: 25-Jun-2019
> Supercedes: 299 Status: Open Ticket:
> https://trac.torproject.org/projects/tor/ticket/29801
>
> 1. Introduction
>
> As IPv4
Hi All,
I'm working on #28322 to improve the monitoring of Tor Metrics services,
but this also has the side effect of monitoring network health. For
example, we'd like to know when Onionoo messes up and starts reporting
zero relays, but we also get to learn for free in the same check how
many
Hi,
On 04/04/2019 23:56, Alessandro Fiori wrote:
> since i have released some Docker images for help people to run their
> own service or relays, i'm releasing some Virtualbox images and scripts
> for who want to run their relays.
>
> Virtual machines are in importable OVA format, and are based
Hi,
>> On 25/02/2019 23:30, teor wrote:
>>> Looks good to me, let's merge it as an "accepted" proposal?
This is now proposal 301.
What is the process by which this becomes "accepted"? Is this just a
matter of someone making that commit?
Thanks,
Iain.
signature.asc
Description: OpenPGP
Hi,
On 25/02/2019 23:30, teor wrote:
> Looks good to me, let's merge it as an "accepted" proposal?
Is there some action I should take here like opening a PR or does
someone just pick up the text and commit it?
Thanks,
Iain.
signature.asc
Description: OpenPGP digital signature
proposal. The
"package" line was always optional and so no client should be
depending on it. There are no known consumers of the "package"
lines (there are none to consume anyway).
A. References
[1] Nick Mathewson, Mike Perry. "Include package fingerprints in
con
Mathewson, Mike Perry. "Include package fingerprints in
consensus documents". Tor Proposal 227, February 2014.
[2] Iain Learmonth, Karsten Loesing. "Towards modernising data
collection and archive for the Tor network". Technical Report
2018-12-001, December
Hi,
On 13/02/2019 16:56, n...@neelc.org wrote:
> I don't think this is the right mailing list.
This is entirely the correct mailing list as it is discussing a
technical policy of the network team. This policy can be found here:
Hi All,
On 04/02/2019 06:35, teor wrote:
> If we add enough noise to protect most users, then we will have privacy by
> design.
I would argue that noise does not help here, as we would have to add
enough noise to protect against a guard discovery attack, which is too
much noise for the stats to
Hi,
On 15/11/18 02:02, n...@neelc.org wrote:
> How would Tor deal with HTTP/3 (a.k.a. HTTP over QUIC), considering that Tor
> is a TCP anonymizer, and HTTP over QUIC (and QUIC itseld) uses UDP? Would we
> need Tor to support UDP? Just QUIC?
One reason we don't support UDP in Tor because it is
Hi,
On 23/10/18 18:15, Alec Muffett wrote:
> But any website that takes an interest (e.g. tracks Cloudflare's
> "xx-tor" country geolocation, or whatever it is called) - regarding the
> reputation of the source IP address will KNOW that the user is coming
> from Tor.
>
> We live in a weird
Hi,
On 20/09/18 17:03, Ian Goldberg wrote:
> To be clear, the place this is used in otr is exactly to build the
> released *source tarball* from git, so that even the source tarball is
> reproducible. The binary package builders then build (reproducible)
> binaries from the reproducible source
Hi,
On 20/09/18 00:51, Ian Goldberg wrote:
> If you make it use, say, the timestamp on the tip git commit of the
> source, then it's (a) automated, and (b) reproducible. But that's more
> of a build date than a release date, of course. (That's what otr uses.)
Please don't make your build
Hi,
Onionoo's protocol was extended and has a major version bump to 7.0.
Download available at:
https://dist.torproject.org/onionoo/7.0-1.18.1/
Protocol changes (also summarized in [0]):
Extended the "version" parameter to support lists and ranges
Removed redundant "1_week" and "1_month"
Hi,
On 28/08/18 13:21, Milan Damjanovic wrote:
> I was late for yesterdays meeting.
You can see what was discussed here:
http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-08-27-14.28.log.html
Thanks,
Iain.
signature.asc
Description: OpenPGP digital signature
Hi All,
I attended ACM's SIGCOMM last week. A few things caught my attention
that I thought might be of interest here:
"CircuitStart: A Slow Start For Multi-Hop Anonymity
Systems" Christoph Döpmann and Florian Tschorsch.
Link: https://dl.acm.org/authorize?N666917
"Design of SOCKS Version 6"
Hi,
On 27/08/18 09:46, Karsten Loesing wrote:
> Would you want to drop by our next team meeting? It happens today
> (Monday, August 27) at 14:30 UTC in #tor-meeting on OFTC.
It looks like this was too short notice. Our next meeting will be
Friday, 7th September at 14:30 UTC.
Thanks,
Iain.
Hi,
A patch release has been made for Onionoo to fix errors with the
searching for relays with unknown AS numbers.
Additionally, we announce today the fixes from version 6.2-1.17.0 which
were released yesterday but not deployed as this additional patch was
ready for release and so we postponed.
Hi,
A patch release has been made for Onionoo to fix an error in the
serialization of history documents.
Download available at:
https://dist.torproject.org/onionoo/6.2-1.16.1/
Software changes are summarized in the changelog [0].
The changes are already deployed on all
Hi,
Onionoo's protocol was extended and has a minor version jump to 6.2.
Download available at:
https://dist.torproject.org/onionoo/6.2-1.16.0/
Protocol changes (also summarized in [0]):
Added an "as" field to details document, deprecated the "as_number"
field, added an "as_name"
Hi,
Onionoo's protocol was extended and has a minor version jump to 6.1.
Download available at:
https://dist.torproject.org/onionoo/6.1-1.15.0/
Protocol changes (also summarized in [0]):
Added a new "os" parameter to filter relays and bridges by operating
system, extended the "as" and
Hi,
On 16/07/18 04:12, teor wrote:
> It MUST NOT attempt to send its bandwidth list file in a HTTP POST to
> other authorities and it SHOULD NOT make bandwidth list files from other
> authorities available.
There is no mechanism specified that could be used to send this file via
an HTTP POST.
Hi,
A new release is available:
https://dist.torproject.org/collector/1.7.0/
The main change in this release is to recognise the new bridge
authority, Serge. There are also additional minor fixes. Full details
can be found in the changelog [1].
This CollecTor release is already deployed on
Hi,
On 13/07/18 16:24, Tom Ritter wrote:
> Ah, that makes sense. You want /foo.html to serve an Onion-Location
> that goes to /foo.html
Exactly! But I might also want that /foo/bar.html goes to /bar.html on
the onion service while /baz/bar.html goes to /bar.html on another onion
service.
Hi,
I've had a go at implementing this for my personal blog. Here are some
things:
> We introduce a new HTTP header called "Onion-Location"
> with the exact same restrictions and semantics as the
> Location HTTP header. Websites can use the Onion-Location
> HTTP header to specify their onion
Hi meejah,
On 02/07/18 06:38, meejah wrote:
> Ah, sorry yes I missed this step. The GitHub release is updated.
Thanks!
I've just looked at updating the Debian packaging with this but
unfortunately I'm blocked by Debian#902766 which appears to be a Python
3.7 issue (async is now a reserved
Hi,
On 01/07/18 16:30, dawuud wrote:
> What's a github release?
> I think you mean a commit which is tagged and I'm
> pretty sure meejah tags release commits.
I mean what GitHub calls a "release" which is different to a tag. It
allows me to base the Debian packaging on a signed tarball from
Hi meejah,
On 30/06/18 06:11, meejah wrote:
> Unfortunately there was a problem when parsing onion services on
> Python2, which is fixed by txtorcon 18.0.1
Is it possible for you to make a GitHub "release" for 18.0.1? For the
Debian packaging I fetch the signatures from here and verify them,
Hi,
On 30/06/18 15:42, nusenu wrote:
> but maybe someone else would be willing to invoke a
> "ln" commands everytime a new new alpha repo is born.
>
> tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie
As an alternative strategy, symbolic links for old alpha repositories
point to the current
Hi,
On 30/06/18 12:53, Jaskaran Singh wrote:
> 0. Motivation and Overview
> We're using Maxmind's (company registered in the US) GeoIP Database,
> which is not just antithetical to the philosophy that one should not
> totally rely on a service/software for all needs, but has some serious
>
Hi,
On 09/05/18 13:08, juga wrote:
> after nick, irl and teor reviewed the last version i sent [1], i paste
> below a new version of the specification versions 1.1.0 and 1.0.0.
> It's the same version as commit
> https://github.com/juga0/torspec/commit/c7cdfd4fcb4b5623e1407e2bec38e9fdf7b70e6b.
Hi,
On 02/05/18 10:31, teor wrote:
> So let's try to keep "relay measurement" and "relay bandwidths" as
> separate concepts.
Aaah, ok. Yes, I much prefer "Relay Bandwidth" as the name for the
section in §2. There are then also lots of references to measurement in
§2.2, that should also be
Hi,
On 02/05/18 09:59, teor wrote:
> Let's use:
> Tor Bandwidth List Format
As we are already using this for the directory lists, I think this makes
sense as a name for the format.
> "Measurements Results" describes how the bandwidths are created by
some generators. But a generator that
Hi All,
Looking at the recent work on the Tor bandwidth measurements document
format, I've noticed there are a few places where language can be
ambiguous [0]. This morning, I noticed more ambiguity in some metrics
tools [1]. We could do with a glossary.
The problem though is not the lack of a
Hi,
> Tor Bandwidth Measurements Document Format
"Measurement" could mean a method for performing a measurement, a single
measurement task, a schedule for a repeating measurement task, a
measurement result or a few other things.
When Large MeAsurement Platforms (LMAP) wrote documents in the
Hi,
On 13/02/18 14:33, Leonid Evdokimov wrote:
> I've recently found out that new Atlas re-design is not that friendly to
> web archive. http://archive.li/ can't properly detect "page loaded"
> event that leads to capturing "loading" page[%]. Moreover,
> https://web.archive.org/ can't capture
Hi,
On 12/02/18 23:55, isis agora lovecruft wrote:
> 1. What passes for "canonicalised" "utf-8" in C will be different to
> what passes for "canonicalised" "utf-8" in Rust. In C, the
> following will not be allowed (whereas they are allowed in Rust):
> - NUL (0x00)
> -
Hi,
On 02/02/18 12:08, Jaskaran Singh wrote:
> Also, the Metrics team has(?) to come up with a proposal on this IIRC.
> Until then it would not be considered a valid project?
Considered a valid project by whom?
Metrics is currently very busy and may not have time to assist with the
project, but
Hi,
On 06/01/18 15:52, Iain Learmonth wrote:
> Ok, I'll see if I can do a quick hack workaround to generate the list
> for Relay Search until the data is available through Tor Metrics.
In fact, my original quick hack workaround still works, as it's only
extracting fingerprints. (
Hi,
On 05/01/18 22:33, teor wrote:
> The fallback 2.0.0 spec hasn't been merged yet, but atagar has reviewed it.
> It's at:
> https://github.com/teor2345/torspec/blob/fallback-format-2-v2/fallback-spec.txt
I've added this link to the Metrics ticket #24434, I started work on
this but ran out of
Hi,
On 24/12/17 20:13, Damian Johnson wrote.
As we are planning to also add a parser to metrics-lib (#24434), would
it be possible to get a full description of the format of the file
possibly in RFC5234 format so that we can check that the generator and
parsers all match up to that
Hi,
On 11/12/17 16:04, Mike Perry wrote:
> https://trac.torproject.org/projects/tor/ticket/2394
>
> I am not sure what repo they are in, though.
>
https://gitweb.torproject.org/metrics-tasks.git/tree/task-2394
Thanks,
Iain.
signature.asc
Description: OpenPGP digital signature
44 matches
Mail list logo
