Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #31066

Closed (moved)
Open
Opened Jul 02, 2019 by Alex Catarineu@acat

Consider protection against requests going through catch-all circuit

While taking a look at upstreaming #26353 (moved) to Firefox I was thinking whether it would make sense to have some mitigations to reduce potential anonymity loss if there are requests unintentionally going through the catch-all circuit. We currently isolate requests by originAttributes.firstPartyDomain. If originAttributes.firstPartyDomain is empty, then the request goes to the catch-all circuit (socks username --unknown--).

I would suggest changing this and proxying with socks username --unknown--|||firstPartyDomain(request) instead, where firstPartyDomain is calculated as if the request host was the origin. I think this can only improve user anonymity wrt current behaviour, at the cost of potentially worse network performance (more circuits). But I think there should not be many cases were firstPartyDomain is empty, and also not so many --unknown-- + domain combinations to make this a performance issue. I think it should be seen just as a mitigation for the potential cases in Tor Browser that might not obey first party isolation.

Not sure if this has already been discussed in the past, but I thought it might be interesting to consider.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#31066