4 ms·

The issue I've always had with onion addresses is that you can't remember them, which means you need to keep a list of bookmarks saved locally somewhere, which–

by pault 9y ago

The issue I've always had with onion addresses is that you can't remember them, which means you need to keep a list of bookmarks saved locally somewhere, which–if you're using tor to avoid prosecution–is pretty incriminating. What's the solution?

na85 9y ago
Keep one bookmark to a community directory? The plausible deniability is that you just visit for the catpicures1685isbis.onion, and not for cocainehookerz3288uiop.onion
- wybiral 9y ago
  But now you have to trust that community directory not to give you the wrong onions...
  - PhearTheCeal 9y ago
    Which is why information like that should be stored in the blockchain where it can't be modified.
    - zaroth 9y ago
      I assume this is already done, and if not why not? The practical implementation would be the bookmarking service would authenticate their links against this blockchain, and the user would either have an agent on their system to validate the claims, or another 3rd party who they trusted to validate the claims?
    - airwavves 9y ago
      This is a remarkably good idea. You can store an onion hash in a blockchain transaction and then use the signature of the key which sent that transaction to verify it.
      - StavrosK 9y ago
        Or just use IPFS.
    - wybiral 9y ago
      That does seem more secure compared to the way people often talk about onion link lists and search engines. But the blockchain can still be flooded with fraudulent onions and at some point you're still putting all of your trust into a form of authority.
  - Ajedi32 9y ago
    Unless the bookmark entries in your directory are encrypted with a passphrase only you know. So... it sounds like what you're looking for is a password manager.
    - pault 9y ago
      Doesn't protect from rubber hose side channel attacks.
      - Ajedi32 9y ago
        Yeah, ideally you'd want plausible deniability. In theory, you could achieve this by only storing the password DB in a cloud service you access through the Tor browser, but then you run into two other problems. First, how do you remember the address of the service you're using to store your password DB? If you store that address on your device, you've lost your plausible deniability. I guess you'd have to use a well-known clearnet site you access through Tor (Dropbox, Google Drive, etc). That leaves another problem though. If you have a password manager installed on your PC, that implies the existence of a password database, which might also cause you to lose your plausible deniability. Maybe if there was a profiles/password manager feature built into the Tor browser that lets you decrypt and load a profile from a service provider, then destroys all local evidence of that profile when you close the browser? Seems like a feature that could be useful in all browsers actually. A cross-browser password manager and bookmarks sync feature? That'd be really convenient.
        asn_tor 9y ago
        Indeed, an encrypted bookmark manager in Tor browser would be cool. Also see this blog post: https://blog.torproject.org/cooking-onions-names-your-onions https://blog.torproject.org/cooking-onions-names-your-onions
        infogulch 9y ago
        IPFS over Tor?
nikcub 9y ago
There is a pluggable name resolution proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt https://gitweb.torproject.org/torspec.git/tree/proposals/279... You'd be able to run namecoin and other systems edit: to add, I haven't yet completely bought into the new onion services. I like a lot of the security improvements, but it is really going to depend on how name resolution works and how authenticating endpoints will work for users. Running a pluggable name resolution system means we can try out different solutions and see which takes off organically and practically.
- asn_tor 9y ago
  Yes indeed the naming issue is important and needs to be addressed. We are currently pretty busy with stuff so we haven't even started implementing the aforementioned proposal (or considered whether it's a good idea). BTW check out this link for some survey results that point out that onion length might not matter so much since the legacy onions were already unrememberable: https://lists.torproject.org/pipermail/tor-dev/2017-September/012464.html https://lists.torproject.org/pipermail/tor-dev/2017-Septembe... Cheers and thanks for keeping the discussion fruitful :)
deleted 9y ago
[deleted]

by pault 9y ago

na85 9y ago

Keep one bookmark to a community directory? The plausible deniability is that you just visit for the catpicures1685isbis.onion, and not for cocainehookerz3288uiop.onion

wybiral 9y ago
But now you have to trust that community directory not to give you the wrong onions...
- PhearTheCeal 9y ago
  Which is why information like that should be stored in the blockchain where it can't be modified.
  - zaroth 9y ago
    I assume this is already done, and if not why not? The practical implementation would be the bookmarking service would authenticate their links against this blockchain, and the user would either have an agent on their system to validate the claims, or another 3rd party who they trusted to validate the claims?
  - airwavves 9y ago
    This is a remarkably good idea. You can store an onion hash in a blockchain transaction and then use the signature of the key which sent that transaction to verify it.
    - StavrosK 9y ago
      Or just use IPFS.
  - wybiral 9y ago
    That does seem more secure compared to the way people often talk about onion link lists and search engines. But the blockchain can still be flooded with fraudulent onions and at some point you're still putting all of your trust into a form of authority.
- Ajedi32 9y ago
  Unless the bookmark entries in your directory are encrypted with a passphrase only you know. So... it sounds like what you're looking for is a password manager.
  - pault 9y ago
    Doesn't protect from rubber hose side channel attacks.
    - Ajedi32 9y ago
      Yeah, ideally you'd want plausible deniability. In theory, you could achieve this by only storing the password DB in a cloud service you access through the Tor browser, but then you run into two other problems. First, how do you remember the address of the service you're using to store your password DB? If you store that address on your device, you've lost your plausible deniability. I guess you'd have to use a well-known clearnet site you access through Tor (Dropbox, Google Drive, etc). That leaves another problem though. If you have a password manager installed on your PC, that implies the existence of a password database, which might also cause you to lose your plausible deniability. Maybe if there was a profiles/password manager feature built into the Tor browser that lets you decrypt and load a profile from a service provider, then destroys all local evidence of that profile when you close the browser? Seems like a feature that could be useful in all browsers actually. A cross-browser password manager and bookmarks sync feature? That'd be really convenient.
      - asn_tor 9y ago
        Indeed, an encrypted bookmark manager in Tor browser would be cool. Also see this blog post: https://blog.torproject.org/cooking-onions-names-your-onions https://blog.torproject.org/cooking-onions-names-your-onions
      - infogulch 9y ago
        IPFS over Tor?

nikcub 9y ago

There is a pluggable name resolution proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt https://gitweb.torproject.org/torspec.git/tree/proposals/279... You'd be able to run namecoin and other systems edit: to add, I haven't yet completely bought into the new onion services. I like a lot of the security improvements, but it is really going to depend on how name resolution works and how authenticating endpoints will work for users. Running a pluggable name resolution system means we can try out different solutions and see which takes off organically and practically.

asn_tor 9y ago
Yes indeed the naming issue is important and needs to be addressed. We are currently pretty busy with stuff so we haven't even started implementing the aforementioned proposal (or considered whether it's a good idea). BTW check out this link for some survey results that point out that onion length might not matter so much since the legacy onions were already unrememberable: https://lists.torproject.org/pipermail/tor-dev/2017-September/012464.html https://lists.torproject.org/pipermail/tor-dev/2017-Septembe... Cheers and thanks for keeping the discussion fruitful :)

deleted 9y ago

[deleted]