URL shortening service integrated in Tor2web

[hellais]

Discussing with Dan about tor2web it came up that it could make sense to integrate a URL shortener in tor2web.

To do this though we would have to have some sort of central node that stores the mappings between shortened URL and .onion.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/14807205-url-shortening-service-integrated-in-tor2web?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).

[fpietrosanti]

This topic MAY have many in common with #30 .

Some questions/evaluations:

• Who can create a shortened url? (Anyone or only the .onion site owner?)
• Which time constrain do we want to sustain? (Es: Does a shortened url live for 1 week or 1 year?)
• How a shortened url is created?
• Does the shortened url have to be provided in the secure version of the site (SSL) or can be provided also in clear?

[hellais]

I think that this should just be an URL shortening service a-la bit.ly. So the user of a site when visiting it can create a shortened version of it by clicking on something on the banner or we could already pre-generate a shortened URL for all of them.

We should probably keep this indefinitely as it does not occupy space to keep it.

The URL itself should be randomly generated and I think we should start by having it 5 chars all lowercase with numbers (like goo.gl). If we finish this keyspace then we can go longer.

I think this should be only HTTPS.

[fpietrosanti]

Will the list of all existing url shortened (the database) be:

• public
• privately owned by a single central entity
• only shared among Tor2web operators

?

Because if we look forward in the future with some automatic mechanism to auto-join the t2w network, then such a list would became difficult to be kept "private" .

Instead, if it's public, the whole database can be shared among all Tor2web nodes (and consequently with anyone willing to use it for different purposes).

But making it public, may make the service "not suitable" for every uses, even if it simplify a lot of issues.

What do u think?

[fpietrosanti]

Evaluate integration of Dot Bit NameCoin Service in order to have such facility handled by an external, distributed project:
http://dot-bit.org/Main_Page

[JeremyRand]

Hello, Namecoin developer here. We're definitely interested in supporting .bit to .onion resolution. Does your use case also require the .onion key to sign the .bit domain, or is it sufficient to just have the .bit domain point to the .onion? I'm trying to figure out if .onion signing of .bit is a sufficiently major use case that it's worth the added complexity.

Thanks.

[fpietrosanti]

Hey @JeremyRand well, i think that for the use-case of Tor2web it's different than for a general use-case of a .onion for the Tor Network at large.

Tor2web can accept certain tradeoff between security, resiliency and usability being an overlay network.

So i think that signing a .onion would be enough from a Tor2web perspective to validate that a certain .onion owner would like to register a petname to be available on Tor2web.

What's important from Tor2web perspective is to be able to be fully "stateless", without a local database, being able to query .bit DNS to ask if a certain pet-name is effectively registered or not and bound to that .onion.

From a Tor2web perspect a petname must expire if there's no traffic for a certain amount of time, to prevent massive squotting of "premium" names.

What do you think?

[JeremyRand]

Hello @fpietrosanti ,

So i think that signing a .onion would be enough from a Tor2web perspective to validate that a certain .onion owner would like to register a petname to be available on Tor2web.

Ok, so you don't need the .onion to sign the .bit?

What's important from Tor2web perspective is to be able to be fully "stateless", without a local database, being able to query .bit DNS to ask if a certain pet-name is effectively registered or not and bound to that .onion.

I'm not certain exactly what you mean by "without a local database". The currently available Namecoin client downloads a full copy of the blockchain and then does lookups on the local copy, but the local blockchain is identical to the blockchain held by the rest of the network. If you don't want to store the full blockchain (about 2 GB at the moment), there is work being done on SPV-based lookups, which have negligible storage requirements. Is SPV a better fit for your needs?

From a Tor2web perspect a petname must expire if there's no traffic for a certain amount of time, to prevent massive squotting of "premium" names.

Namecoin names expire after 36 kiloblocks (about 8 months) of inactivity in the blockchain. Registering a new name requires burning some money, and renewing a name requires paying a transaction fee to miners. It's not possible to make names expire based on lookups to the .onion, if that's what you're referring to.

Thoughts?

[fpietrosanti]

Hi @JeremyRand,

regarding the various points:

a) Onion signing
Well, that would be a nice point to have for authentication purposes.
Which piece of software should then be in charge of verifying the authenticity of the name being registered, Namecoin software or Tor2web software?

b) Local database
It's a requirement that a Tor2web operator does not maintain authority on to create/revoke pet names.
Having a few GB disk requirements is not a big issue, as long as it does not become a big 50GB ones in few months, but still something that can run on a mid/low-end VPS.

If it's possible to make a query to a remote system as alternative to local database it would be lovely, but not strictly required.

c) Lookup
How Tor2web Python/Twisted software would then make the lookup?
Are there a local REST server or a DNS Resolver to query in localhost?

d) Expiry
The expiry issue maybe tricky, do you think that would be possible somehow to be able to have the amount of kiloblocks before expiry/renewal happens to be "configurable" ?

e) Hostname or URL
In the context of use of a DNS the resolution should be to have a .onion to be associated to a whatever.bit hostname.
But in order to do also a URL Shortening service we would need to be able to register also URLs like http://blahblah.onion/something?abc=123 .
How do you see the complexity/feasibility of storing also URLs, other than hostname?

f) Revocation
Are then owner of a .bit being able to revoke it trough some kind of documented procedure?

[JeremyRand]

Hi @fpietrosanti,

These are good questions.

a) Onion signing
Well, that would be a nice point to have for authentication purposes.
Which piece of software should then be in charge of verifying the authenticity of the name being registered, Namecoin software or Tor2web software?

Namecoin can verify that the owner of the .bit name intended it to point to the configured .onion name. If we also want to verify that the owner of the configured .onion name intended that .bit name to point to it, then it should be possible by adding some more info to the blockchain, there's just a question of what practical goal that would achieve. Basically, my question is, is there a likely circumstance where a user knows a .onion name, needs to know what .bit name is endorsed by that .onion name, and cannot or does not wish to find that information by visiting the .onion website and looking for a link to the associated .bit name on the .onion web page? If that circumstance is likely to occur, can you explain some details about that use case? If it's a significant use case, then I would have no objection to supporting it by requiring the .onion key to sign the .bit name (although I can't speak for the other Namecoin devs); I just don't know of any significant such use cases at the moment.

b) Local database
It's a requirement that a Tor2web operator does not maintain authority on to create/revoke pet names.
Having a few GB disk requirements is not a big issue, as long as it does not become a big 50GB ones in few months, but still something that can run on a mid/low-end VPS.

If it's possible to make a query to a remote system as alternative to local database it would be lovely, but not strictly required.

While I can't make absolute guarantees about blockchain size, I strongly doubt that Namecoin's local storage requirements would go anywhere even close to 50 GB before SPV-based lookups are implemented.

c) Lookup
How Tor2web Python/Twisted software would then make the lookup?
Are there a local REST server or a DNS Resolver to query in localhost?

We provide a local REST interface now, and we might be able to provide a local DNS interface as well. Some of that code is in the middle of a refactor at the moment, though.

d) Expiry
The expiry issue maybe tricky, do you think that would be possible somehow to be able to have the amount of kiloblocks before expiry/renewal happens to be "configurable" ?

I'm not sure. What kind of configurability are you looking for? We are considering a proposal to make the renewal period about 13-14 months based on block timestamps rather than block height, so that the renewal period is more predictable and closer to the length of ICANN-issued domains.

e) Hostname or URL
In the context of use of a DNS the resolution should be to have a .onion to be associated to a whatever.bit hostname.
But in order to do also a URL Shortening service we would need to be able to register also URLs like http://blahblah.onion/something?abc=123 .
How do you see the complexity/feasibility of storing also URLs, other than hostname?

Can this use case be met by a deterministic transformation of .bit hostname to URL? Seems like you could just take the 2nd-level domain label and use it as the value of a URL parameter.

f) Revocation
Are then owner of a .bit being able to revoke it trough some kind of documented procedure?

Revocation is being discussed, and there are some experimental specs/implementations, but nothing finalized yet. Does your use case consist of the scenario that the Namecoin private key for a .bit name has been stolen? Or are you concerned about something else?

[JeremyRand]

Hi @fpietrosanti, just wanted to make sure this is still on your radar. :)

[fpietrosanti]

@JeremyRand I'm on the radar but overbusy, apologize. Will you come to the CCC Hacker Camp 2015 in the upcoming August? We may have a group brainstorming on the topic!

[JeremyRand]

Hi @fpietrosanti,

I'm unable to attend CCCamp this year (I'm in the U.S. and can't afford a flight), but I think at least one other Namecoin dev might be there; I'll check on that. It's likely that I could join a brainstorming session by video chat, if that's doable for you guys.

[JeremyRand]

Hi @fpietrosanti,

Sincere apologies that we weren't able to meet up with you at CCCamp. Is there any public info of what was discussed at the brainstorming session?