BridgeDB issueshttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues2022-03-01T17:35:40Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/29448Provide a dir-spec implementation that serves sanitised descriptors2022-03-01T17:35:40ZirlProvide a dir-spec implementation that serves sanitised descriptorsThe Metrics Team currently performs sanitizing of bridge descriptors before publishing them on CollecTor (and subsequently feeding them into other software).
The published descriptors are detailed in:
https://metrics.torproject.org/col...The Metrics Team currently performs sanitizing of bridge descriptors before publishing them on CollecTor (and subsequently feeding them into other software).
The published descriptors are detailed in:
https://metrics.torproject.org/collector.html#bridge-descriptors
The sanitizing steps are detailed here:
https://metrics.torproject.org/bridge-descriptors.html
The descriptors are transferred to the CollecTor host unsanitized by means of rsyncing a tarball. This violates one of the Tor Metrics principles in that this is a private interface and we are handling sensitive data. While the data is then sanitized and published, it is not possible for others to operate their own CollecTor instance that fetches data directly from the BridgeDB instance. Additionally, this increases code complexity in CollecTor as now we must treat the fetching of relay and bridge descriptors differently.
Ideally the sanitizing steps would be performed by BridgeDB and then we would be able to reuse (at least large chunks of) CollecTor code that currently fetches relay descriptors.
This is a project that would need co-ordination with the Metrics Team on the best way forward.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/25986Add AMP cache fronting option to Moat2022-03-01T17:35:40ZtwimAdd AMP cache fronting option to MoatThis is a followup of https://trac.torproject.org/projects/tor/ticket/25804#comment:25 (summary):
> It turns out that AppEngine is not the only option for domain fronting with Google.
> Google also provides a service called AMP cache f...This is a followup of https://trac.torproject.org/projects/tor/ticket/25804#comment:25 (summary):
> It turns out that AppEngine is not the only option for domain fronting with Google.
> Google also provides a service called AMP cache for AMP pages. What it basically does is proxying random pages on the Internet and making them load faster (e.g. on Google search results). It requires pages to comply with some format though and also strips invisible content, resizes images, etc.
> Despite it is being served via different domain names (one per real domain) it is still hosted at Google infrastructure which can be fronted.
Related tickets: legacy/trac#25807.