Tahoe URIs and gateway URLs are too long and ugly #882

New Issue

tahoe-lafs · 2010-01-07T05:44:10Z

davidsarah commented

2010-01-07 05:44:10 +00:00

Add all your complaints about the length, ugliness, spamminess, and other usability niggles of Tahoe URLs here :-)

tahoe-lafs added the

labels 2010-01-07 05:44:10 +00:00

tahoe-lafs added this to the undecided milestone 2010-01-07 05:44:10 +00:00

davidsarah commented

2010-01-07 06:10:47 +00:00

#217 and its comments describe proposals, discussed further in NewMutableEncodingDesign, for changing the mutable file protocol. This seems to have become associated with the proposal to use ECDSA, but only some of these suggested protocols actually depend on the shorter public keys enabled by ECDSA. (There are other performance reasons to use ECDSA anyway.)

So, here are the comments from there that relate specifically to URL or cap length, starting with /tahoe-lafs/trac-2024-07-25/issues/5279#comment:-1 by Zooko:

... Therefore, these caps [by NewMutableEncodingDesign]enabled when embedded into tahoe hyperlinks can look like this:

http://localhost:8123/MW_upyf5nwrpccqw4f53hiidug96h

http://localhost:8123/MR_o859qp5btcftknqdppt66y1rxy

David-Sarah: this length is incorrect. The cryptovalue part appears to be base32, i.e. 130 bits. NewMutableEncodingDesign can't achieve that; the cryptovalue would have to be twice as long as this.

http://localhost:8123/MV_7j97kjz7zm3mdwsbr8n35oafpr4gjsn9665marzgunpf43nnzz8y

(That's with 128 bits for the storage index in the verify-cap -- I don't imagine verify-caps are important to pass around among users the way read-only caps and read-write caps are.)

This is very satisfying! We get the " http://localhost:8123" trick, the "MW_"/"MR_" tags, the human-friendly base-32 encoding, and we still have URLs that are small enough to be not quite so "intimidating" to users who are considering sharing them with text tools.

Note that since the crypto-values are 128-bits long, and 26 chars of base-32 encoding holds 130 bits, we have two extra bits to play with. It wouldn't hurt to redundantly encode the type tags, in case users lose or mangle the "MW_"/"MR_" tags. (For example when I double-click on the cap in XEmacs it selects only the base-32 portion -- it treats the underscore as a word separator.)

#217 and its comments describe proposals, discussed further in [NewMutableEncodingDesign](wiki/NewMutableEncodingDesign), for changing the mutable file protocol. This seems to have become associated with the proposal to use ECDSA, but only some of these suggested protocols actually depend on the shorter public keys enabled by ECDSA. (There are other performance reasons to use ECDSA anyway.) So, here are the comments from there that relate specifically to URL or cap length, starting with [/tahoe-lafs/trac-2024-07-25/issues/5279](/tahoe-lafs/trac-2024-07-25/issues/5279)#[comment:-1](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment--1) by Zooko: > ... Therefore, these caps [by [NewMutableEncodingDesign](wiki/NewMutableEncodingDesign)]enabled when embedded into tahoe hyperlinks can look like this: > <http://localhost:8123/MW_upyf5nwrpccqw4f53hiidug96h> > <http://localhost:8123/MR_o859qp5btcftknqdppt66y1rxy> David-Sarah: this length is incorrect. The cryptovalue part appears to be base32, i.e. 130 bits. [NewMutableEncodingDesign](wiki/NewMutableEncodingDesign) can't achieve that; the cryptovalue would have to be twice as long as this. > <http://localhost:8123/MV_7j97kjz7zm3mdwsbr8n35oafpr4gjsn9665marzgunpf43nnzz8y> > (That's with 128 bits for the storage index in the verify-cap -- I don't imagine verify-caps are important to pass around among users the way read-only caps and read-write caps are.) > This is very satisfying! We get the " <http://localhost:8123>" trick, the "MW_"/"MR_" tags, the human-friendly base-32 encoding, and we still have URLs that are small enough to be not quite so "intimidating" to users who are considering sharing them with text tools. > Note that since the crypto-values are 128-bits long, and 26 chars of base-32 encoding holds 130 bits, we have two extra bits to play with. It wouldn't hurt to redundantly encode the type tags, in case users lose or mangle the "MW_"/"MR_" tags. (For example when I double-click on the cap in XEmacs it selects only the base-32 portion -- it treats the underscore as a word separator.)

davidsarah commented

2010-01-07 06:20:04 +00:00

Note that in the last comment, Zooko was actually talking about a different proposal, so he wasn't actually incorrect (although that length of read cap is indeed unachievable).

/tahoe-lafs/trac-2024-07-25/issues/5279#comment:-1 by Brian:

There are a small number of caps that are meant to be shared by humans over text links (IM, email, etc). These are the ones that we want to keep small. Since we only really need maybe 3 or 4 of these, we assign each of these a single-letter prefix, like:

"D": read-write directory
"d": read-only directory
"F": immutable file (still longer than we want)

Zooko replied in /tahoe-lafs/trac-2024-07-25/issues/5279#comment:-1

I thought Ping had suggested that capital letter meant "write authority", so it would be:

D: read-write directory
d: read-only directory
f: immutable file
Also potentially:

F: read-write mutable file
?

Leaving open how to spell "read-only mutable file"...

This single-letter prefix seems like a good idea to me.

Note that in the last comment, Zooko was actually talking about a different proposal, so he wasn't actually incorrect (although that length of read cap is indeed unachievable). [/tahoe-lafs/trac-2024-07-25/issues/5279](/tahoe-lafs/trac-2024-07-25/issues/5279)#[comment:-1](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment--1) by Brian: > There are a small number of caps that are meant to be shared by humans over text links (IM, email, etc). These are the ones that we want to keep small. Since we only really need maybe 3 or 4 of these, we assign each of these a single-letter prefix, like: > "D": read-write directory > "d": read-only directory > "F": immutable file (still longer than we want) Zooko replied in [/tahoe-lafs/trac-2024-07-25/issues/5279](/tahoe-lafs/trac-2024-07-25/issues/5279)#[comment:-1](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment--1) > I thought Ping had suggested that capital letter meant "write authority", so it would be: > D: read-write directory > d: read-only directory > f: immutable file > Also potentially: > F: read-write mutable file > ? > Leaving open how to spell "read-only mutable file"... This single-letter prefix seems like a good idea to me.

davidsarah commented

2010-01-07 06:31:33 +00:00

Zooko:

I've been blogging with tiddly-wiki-on-top-of-tahoe. here's my blog. Almost everytime I give someone the URL to my blog, they say something about awful the URL is. :-(

I'm getting sick of hearing about it.

<zooko> Please read my blog: 
        http://tahoebs1.allmydata.com:8123/uri/URI:DIR2-RO:hgvn7nhforxhfxbx3nbej53qoi:yhbnnuxl4o2hr4sxuocoi735t6lcosdin72axkrcboulfslwbfwq/wiki.html 
                                                                        [13:12] 
<wiqd> er, no ?                                                         [13:17] 
<zooko> Okay. 
<PenguinOfDoom> zooko: That URL is utterly terrifying                   [13:30] 
<PenguinOfDoom> zooko: is it a thing that you made up with tahoe?       [13:31] 
<zooko> PoD: I know.  -(                                                [13:32] 
<zooko> http://allmydata.org/trac/tahoe/ticket/217 # DSA-based mutable files 
        -- small URLs, fast file creation                               [13:33] 
<arkanes_> that's "small" is it?                                        [13:34]

...

Here's today's mockery of my blog's URL, from Wes Felter:

zooko wrote:

Hi WMF! I read your blog today. Here is my new one:
http://tahoebs1.allmydata.com:8123/uri/URI:DIR2RO:hgvn7nhforxhfxbx3nbej53qoi:yhbnnuxl4o2hr4sxuocoi735t6lcosdin72axkrcboulfslwbfwq/wiki.html

Dude, that URL is crazy; the price of being a cypherpunk I guess.

Zooko: > I've been blogging with tiddly-wiki-on-top-of-tahoe. here's my blog. Almost everytime I give someone the URL to my blog, they say something about awful the URL is. :-( > I'm getting sick of hearing about it. ``` <zooko> Please read my blog: http://tahoebs1.allmydata.com:8123/uri/URI:DIR2-RO:hgvn7nhforxhfxbx3nbej53qoi:yhbnnuxl4o2hr4sxuocoi735t6lcosdin72axkrcboulfslwbfwq/wiki.html [13:12] <wiqd> er, no ? [13:17] <zooko> Okay. <PenguinOfDoom> zooko: That URL is utterly terrifying [13:30] <PenguinOfDoom> zooko: is it a thing that you made up with tahoe? [13:31] <zooko> PoD: I know. -( [13:32] <zooko> http://allmydata.org/trac/tahoe/ticket/217 # DSA-based mutable files -- small URLs, fast file creation [13:33] <arkanes_> that's "small" is it? [13:34] ``` ... > Here's today's mockery of my blog's URL, from Wes Felter: >> zooko wrote: >>> Hi WMF! I read your blog today. Here is my new one: >>> <http://tahoebs1.allmydata.com:8123/uri/URI:DIR2RO:hgvn7nhforxhfxbx3nbej53qoi:yhbnnuxl4o2hr4sxuocoi735t6lcosdin72axkrcboulfslwbfwq/wiki.html> >> Dude, that URL is crazy; the price of being a cypherpunk I guess.

davidsarah commented

2010-01-07 06:37:51 +00:00

No description provided.

Zooko again: > Here's the latest in my collection of mockery and suspicion for having such a long, ugly URL: ``` <zooko> Here's my blog which mentions it: <zooko> http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/w\ iki.html <TigZ> erm <Defiant-> longest url award <TigZ> is it just me or is that URL a little odd <CVirus> LOL [13:30] <TigZ> smells a bit spammy <cjb> zooko: yeah, what's up with that? :) ``` > Add to the collection of mockery, contempt and suspicion: ``` <zooko> On a nearly completely unrelated topic, please check out my awesome blog and the great flamewar that I've spawned on the Open Source Initiative's mailing list <zooko> http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html <mwhudson> zooko: that's one mighty url ``` > ``` <zooko> Here's my blog: http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html <glyph> whee ridiculous URLs <glyph> zooko: is that number swiss? : <glyph> :) ``` > ``` <zooko> I blogged: http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html <edcba> your url is really shitty ``` > ``` Oh, cool, and you have a blog but that's the whackiest blog URL I've ever seen -- I guess it's temporary. ``` > rootard is one of the creators of the Nexenta distribution: ``` <zooko> Laptop Versus Axe: http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html <zooko> Yes, just a Python userland application, packaged up in the distributions. Exactly. <rootard> you really need tinyurl for these things :) <zooko> Duly noted. ```

davidsarah commented

2010-01-07 06:43:04 +00:00

Dig those horizontal scrollbars. Sorry.

Zooko:

I do still have a concern that 256-bit read-caps (e.g. http://127.0.0.1:8234/c/r_FRPG24yB7Amho6NoWaaJlBrU7lON7AyiChWRcaQZ1pH or http://127.0.0.1:8234/c/D_FRPG24yB7Amho6NoWaaJlBrU7lON7AyiChWRcaQZ1pH/path/to/sub/file.txt) might be long enough to exclude Tahoe from some interesting uses where 125-bit read-caps (e.g. http://127.0.0.1:8234/c/r_FMK3eUypHbj6uLocF0496 or http://127.0.0.1:8234/c/D_FMK3eUypHbj6uLocF0496/path/to/sub/file.txt would fit.
...
This guy I don't previously know named Dhananjay Nene, dnene on twitter, wrote: "@zooko have you ever documented what the long URL on your klog is for ? Spooks me every time .. and I always wonder.".

I added a note to the NewCapDesign web page specifying short-and-sweet as a separate desideratum from cut-and-pastable.

swillden:

The entropy required for high security precludes truly "short and sweet" URLs as long as the key is embedded in the URL.

I think this is a strong argument for variable-security aliases, and perhaps even user-selectable aliases.

zooko:

Argh! I just encountered a new example of how the current Tahoe-LAFS caps are too long to be acceptable to most users.

I had commented on the blog of (good security researcher) Nate Lawson -- http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/ -- and included a link to my klog, namely this link:

http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html

He edited my comment and replaced that link with this:

http://allmydata.org/pipermail/tahoe-dev/2010-January/003476.html

Thus changing my comment from linking to my blog to linking to my mailing list message, which is not what I had intended.

I assume that Nate Lawson did this because the URL to my blog is too long and ugly.

So this makes me feel renewed motivation to invent new Tahoe-LAFS caps which are substantially shorter than the current ones.

Dig those horizontal scrollbars. Sorry. Zooko: > I do still have a concern that 256-bit read-caps (e.g. <http://127.0.0.1:8234/c/r_FRPG24yB7Amho6NoWaaJlBrU7lON7AyiChWRcaQZ1pH> or <http://127.0.0.1:8234/c/D_FRPG24yB7Amho6NoWaaJlBrU7lON7AyiChWRcaQZ1pH/path/to/sub/file.txt>) might be long enough to exclude Tahoe from some interesting uses where 125-bit read-caps (e.g. <http://127.0.0.1:8234/c/r_FMK3eUypHbj6uLocF0496> or <http://127.0.0.1:8234/c/D_FMK3eUypHbj6uLocF0496/path/to/sub/file.txt> would fit. ... > This guy I don't previously know named Dhananjay Nene, dnene on twitter, wrote: "@zooko have you ever documented what the long URL on your klog is for ? Spooks me every time .. and I always wonder.". > I added a note to the [NewCapDesign](wiki/NewCapDesign) web page specifying short-and-sweet as a separate desideratum from cut-and-pastable. swillden: > The entropy required for high security precludes truly "short and sweet" URLs as long as the key is embedded in the URL. > I think this is a strong argument for variable-security aliases, and perhaps even user-selectable aliases. zooko: > Argh! I just encountered a new example of how the current Tahoe-LAFS caps are too long to be acceptable to most users. > I had commented on the blog of (good security researcher) Nate Lawson -- <http://rdist.root.org/2009/12/30/side-channel-attacks-on-cryptographic-software/> -- and included a link to my klog, namely this link: > <http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html> > He edited my comment and replaced that link with this: > <http://allmydata.org/pipermail/tahoe-dev/2010-January/003476.html> > Thus changing my comment from linking to my blog to linking to my mailing list message, which is not what I had intended. > I assume that Nate Lawson did this because the URL to my blog is too long and ugly. > So this makes me feel renewed motivation to invent new Tahoe-LAFS caps which are substantially shorter than the current ones.

davidsarah commented

2010-01-07 07:07:13 +00:00

Replying to davidsarah:

(although [128-bit mutable]a read cap is indeed unachievable).

Here's why: preimage attacks against a hash function can be performed simultaneously against multiple targets. That is, for N target files, the work factor of a brute force attack against a K-bit hash that succeeds with probability p is p/N * 2^K^.

In the case of encryption, we can use a longer key for the actual cipher than for the secret value in the read cap. Provided that the cipher key is long enough and is derived using a salt that is unique for each file, this prevents multiple-target attacks. But for a hash we can't do that, because the attacker would be in control of the salt.

Therefore, if the work factor needed for attacks against confidentiality is p * 2^K^ (which we assume to be sufficient even for low p), then to get at least the same work factor for attacks against integrity, we need at least K + log2(N) bits, where N is the number of targets available to an attacker.

In my opinion, we should assume N to be at least 2^50^. In that case, for an optimal protocol that obtains integrity from every bit of the cryptovalue, the minimum cryptovalue length of a read cap would be 178 bits for a 2^128^ security level.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment-74317): > (although [128-bit mutable]a read cap is indeed unachievable). Here's why: preimage attacks against a hash function can be performed simultaneously against multiple targets. That is, for N target files, the work factor of a brute force attack against a K-bit hash that succeeds with probability p is p/N * 2^K^. In the case of encryption, we can use a longer key for the actual cipher than for the secret value in the read cap. Provided that the cipher key is long enough and is derived using a salt that is unique for each file, this prevents multiple-target attacks. But for a hash we can't do that, because the attacker would be in control of the salt. Therefore, if the work factor needed for attacks against confidentiality is p * 2^K^ (which we assume to be sufficient even for low p), then to get at least the same work factor for attacks against integrity, we need at least K + log2(N) bits, where N is the number of targets available to an attacker. In my opinion, we should assume N to be at least 2^50^. In that case, for an optimal protocol that obtains integrity from every bit of the cryptovalue, the minimum cryptovalue length of a read cap would be 178 bits for a 2^128^ security level.

davidsarah commented

2010-01-07 07:12:12 +00:00

zooko:

Nate Lawson pointed out on his blog that my comments kept hitting his spam filter due to the long URL.

Hmm. Are we sure that it is actually the length that is triggering the spam filter?

In any case, given the argument in the previous comment, it is quite possible that the minimum feasible read cap length would be still be long enough (or whatever) to trigger the filter. If that were the case, there would be no point in worrying about something we can't fix.

zooko: > Nate Lawson pointed out on his blog that my comments kept hitting his spam filter due to the long URL. Hmm. Are we sure that it is actually the *length* that is triggering the spam filter? In any case, given the argument in the previous comment, it is quite possible that the minimum feasible read cap length would be still be long enough (or whatever) to trigger the filter. If that were the case, there would be no point in worrying about something we can't fix.

davidsarah commented

2010-01-07 07:17:10 +00:00

Brian:

Zooko: interesting! A spam filter that keys off the length of URL! I wonder if the assumption is that it takes a human being to come up with short names, and that robots are only capable of coming up with long random ones? That seems to be the thinking behind some other comments you've transcribed, from humans saying they distrust the tahoe URLs because they "smell spammy".

Zooko:

By the way, the reason I keep posting on this ticket about people who complain about Tahoe-LAFS URLs, bots that ban Tahoe-LAFS URLs, etc. etc. is to show that the issue with long URLs is not just my personal preference. There seems to be plenty of evidence that long URLs are unacceptable to a significant, perhaps overwhelming, fraction of users. One of the data points that isn't already recorded on this ticket is that as soon as allmydata.com had paid Brian and me to invent Tahoe-LAFS, they then immediately paid someone else to invent a tiny-url-central-database to hide Tahoe-LAFS URLS.

If anyone has any evidence that users are okay using Tahoe-LAFS-sized URLs, please post it to this ticket! As far as I know, I'm the only human in the universe who doesn't mind using Tahoe-LAFS URLs on the Web. (Note: I don't mean putting Tahoe-LAFS caps in your aliases files or whatever, I mean on the Web. Sharing the URLs with other people, posting them on blogs, etc. etc.) Of course, I am not a representative data point for this issue since I am not only a hacker but also a Tahoe-LAFS hacker. If you are a hacker and you don't mind using Tahoe-LAFS URLs, I would like to know it, but I would be even more interested if your mom is okay using Tahoe-LAFS URLs. But I'll take whatever data points I can get, because I think making a major technical decision about something like URL size without considering real world observations of user preferences is a sin (akin to optimizing without measuring). :-)

David-Sarah:

I am a hacker and I do mind using Tahoe URLs, primarily because they wrap. That usually requires manual fiddling to get a web browser to accept a Tahoe gateway URL that is embedded in email, rather than a single click. If they were less than 75 characters, it'd be fine.

[that's all the comments from #217.]OK,

Brian: > Zooko: interesting! A spam filter that keys off the length of URL! I wonder if the assumption is that it takes a human being to come up with short names, and that robots are only capable of coming up with long random ones? That seems to be the thinking behind some other comments you've transcribed, from humans saying they distrust the tahoe URLs because they "smell spammy". Zooko: > By the way, the reason I keep posting on this ticket about people who complain about Tahoe-LAFS URLs, bots that ban Tahoe-LAFS URLs, etc. etc. is to show that the issue with long URLs is not just my personal preference. There seems to be plenty of evidence that long URLs are unacceptable to a significant, perhaps overwhelming, fraction of users. One of the data points that isn't already recorded on this ticket is that as soon as allmydata.com had paid Brian and me to invent Tahoe-LAFS, they then immediately paid someone else to invent a tiny-url-central-database to hide Tahoe-LAFS URLS. > If anyone has any evidence that users are okay using Tahoe-LAFS-sized URLs, please post it to this ticket! As far as I know, I'm the only human in the universe who doesn't mind using Tahoe-LAFS URLs on the Web. (Note: I don't mean putting Tahoe-LAFS caps in your aliases files or whatever, I mean on the Web. Sharing the URLs with other people, posting them on blogs, etc. etc.) Of course, I am not a representative data point for this issue since I am not only a hacker but also a Tahoe-LAFS hacker. If you are a hacker and you don't mind using Tahoe-LAFS URLs, I would like to know it, but I would be even more interested if your mom is okay using Tahoe-LAFS URLs. But I'll take whatever data points I can get, because I think making a major technical decision about something like URL size without considering real world observations of user preferences is a sin (akin to optimizing without measuring). :-) David-Sarah: > I am a hacker and I do mind using Tahoe URLs, primarily because they wrap. That usually requires manual fiddling to get a web browser to accept a Tahoe gateway URL that is embedded in email, rather than a single click. If they were less than 75 characters, it'd be fine. [that's all the comments from #217.]OK,

davidsarah commented

2010-01-07 07:22:40 +00:00

From NewCapDesign:

Make them shorter, prettier, and easier to use

Short and not so ugly. This is important to enable cut-and-paste (see below), but also just because people are suspicious and averse to long and ugly URLs. See #882 for notes in which dozens of people have spontaneously complained about the current URLs. By contrast, tiny URLs such as tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users have no problem with those -- see Twitter.

I (warner) am curious about where the suspicion comes from. Do long URLs make people think they're being attacked, some sort of browser buffer overrun thing? Or that they're being phished, with a URL that a human would evaluate differently than their browser? I agree that people (including me) don't like long URLs, but I've never pushed anyone to explain the "suspicion" aspect. One comment in #217 says "smells a bit spammy", and a later one says "Spooks me every time".

It's likely because it's difficult for a human to verify there isn't hidden information in there, or a hidden URL, that they're sending out or visiting that they therefore can't anticipate or intelligently control. When people see a long hex string, perhaps it represents information that the person crafting it wants to hide from the person using it. I totally understand the skepticism; however, in this case there's nothing to be done, I think. -midnightmagic

Enable convenient cut-and-paste. If caps are too long they'll wrap in email. If they contain lots of word-breaking characters then you have to drag after you've double clicked (this is probably ok). If the word-broken sections are small and at the beginning or end then you have to be very precise about that drag. The best design would be a single short non-word-breaking string. The next best will be to have a large non-word-breaking string at the start and end, with smaller segments (if necessary) in the middle. Note that tahoe: is an easy target, but x-tahoe: is not (you'd have to double-click on the "x").

Usable in a browser. Specifically, it should be easy to actually use a filecap that you get in email or IM, and many email/IM clients will look for http URLs and make them clickable. If tahoe filecaps start with http:, then they'll be made clickable. This is at odds with the IANA-friendly tahoe: prefix. Clients may make tahoe: URIs clickable too (I've seen them make other letters-then-colon strings clickable, even when the letters are not "http"), so perhaps a reasonable solution is to provide an OS-level URI handler for the tahoe: scheme, which could embed the filecap in an http URL and submit it to a webbrowser (i.e. when you click on tahoe:foo, a helper program is launched with tahoe:foo, and that in turn launches your web browser with <http://localhost:8123/foo>). (#52)

From [NewCapDesign](wiki/NewCapDesign): > Make them shorter, prettier, and easier to use > Short and not so ugly. This is important to enable cut-and-paste (see below), but also just because people are suspicious and averse to long and ugly URLs. See #882 for notes in which dozens of people have spontaneously complained about the current URLs. By contrast, tiny URLs such as tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users have no problem with those -- see Twitter. >> I (warner) am curious about where the suspicion comes from. Do long URLs make people think they're being attacked, some sort of browser buffer overrun thing? Or that they're being phished, with a URL that a human would evaluate differently than their browser? I agree that people (including me) don't like long URLs, but I've never pushed anyone to explain the "suspicion" aspect. One comment in #217 says "smells a bit spammy", and a later one says "Spooks me every time". >>> It's likely because it's difficult for a human to verify there isn't hidden information in there, or a hidden URL, that they're sending out or visiting that they therefore can't anticipate or intelligently control. When people see a long hex string, perhaps it represents information that the person crafting it wants to hide from the person using it. I totally understand the skepticism; however, in this case there's nothing to be done, I think. -midnightmagic > Enable convenient cut-and-paste. If caps are too long they'll wrap in email. If they contain lots of word-breaking characters then you have to drag after you've double clicked (this is probably ok). If the word-broken sections are small and at the beginning or end then you have to be very precise about that drag. The best design would be a single short non-word-breaking string. The next best will be to have a large non-word-breaking string at the start and end, with smaller segments (if necessary) in the middle. Note that `tahoe:` is an easy target, but `x-tahoe:` is not (you'd have to double-click on the "x"). > Usable in a browser. Specifically, it should be easy to actually use a filecap that you get in email or IM, and many email/IM clients will look for http URLs and make them clickable. If tahoe filecaps start with `http:`, then they'll be made clickable. This is at odds with the IANA-friendly `tahoe:` prefix. Clients may make `tahoe:` URIs clickable too (I've seen them make other letters-then-colon strings clickable, even when the letters are not "http"), so perhaps a reasonable solution is to provide an OS-level URI handler for the `tahoe:` scheme, which could embed the filecap in an http URL and submit it to a webbrowser (i.e. when you click on `tahoe:foo`, a helper program is launched with `tahoe:foo`, and that in turn launches your web browser with `<http://localhost:8123/foo>`). (#52)

davidsarah commented

2010-01-07 08:43:24 +00:00

In reply to Zooko on tahoe-dev:

> By the way, here is another link to my blog: http:// 
> testgrid.allmydata.org:3567/uri/URI:DIR2- 
> RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdyko 
> zia5544jqa/wiki.html

observe that clicking won't work because only "http://" is
highlighted
move mouse approximately to start of link
carefully position mouse pointer to the left of the 'h',
on the right-hand half of the preceding space
visually check that mouse pointer is a text selection cursor
and not a hand cursor
click and drag to highlight all four lines of the wrapped URL
press Ctrl-C
move mouse to web browser window and click
press Ctrl-T (new tab)
press Ctrl-V
visually check that URL didn't get mangled. Since it isn't
fully visible in the address bar, this check requires:
click, pause, click-drag to end, scan for mangling,
click, pause, click-drag to front, scan for mangling,
click to unselect.
(Maybe this is more clicks than necessary, but it's what I
actually did. The pauses are a habit to avoid Windows'
horrible double-click behaviour in text fields.)
URL was not mangled. Press Enter.

Phew. That should have been:

observe that full URL is highlighted
move mouse pointer to URL and click.

In reply to Zooko on tahoe-dev: ``` > By the way, here is another link to my blog: http:// > testgrid.allmydata.org:3567/uri/URI:DIR2- > RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdyko > zia5544jqa/wiki.html ``` - observe that clicking won't work because only "http://" is highlighted - move mouse approximately to start of link - carefully position mouse pointer to the left of the 'h', on the right-hand half of the preceding space - visually check that mouse pointer is a text selection cursor and not a hand cursor - click and drag to highlight all four lines of the wrapped URL - press Ctrl-C - move mouse to web browser window and click - press Ctrl-T (new tab) - press Ctrl-V - visually check that URL didn't get mangled. Since it isn't fully visible in the address bar, this check requires: click, pause, click-drag to end, scan for mangling, click, pause, click-drag to front, scan for mangling, click to unselect. (Maybe this is more clicks than necessary, but it's what I actually did. The pauses are a habit to avoid Windows' horrible double-click behaviour in text fields.) - URL was not mangled. Press Enter. Phew. That should have been: - observe that full URL is highlighted - move mouse pointer to URL and click.

davidsarah commented

2010-01-09 05:12:59 +00:00

Replying to [davidsarah]comment:6:

Replying to davidsarah:

(although [128-bit mutable]a read cap is indeed unachievable).

Here's why: preimage attacks against a hash function can be performed simultaneously against multiple targets. That is, for N target files, the work factor of a brute force attack against a K-bit hash that succeeds with probability p is p/N * 2^K^.
...
Therefore, if the work factor needed for attacks against confidentiality is p * 2^K^ (which we assume to be sufficient even for low p), then to get at least the same work factor for attacks against integrity, we need at least K + log2(N) bits, where N is the number of targets available to an attacker.

Clarification: this depends on the fact that we would only truncate the final hash for each file, not the intermediate hashes used in Merkle trees or the hash of the UEB. Section 6 of this paper explains that for a Merkle-Damgård hash (such as SHA-256), there is a second-preimage attack with work factor p/B * 2^L^ where B is the total number of blocks (of 64 bytes in the case of SHA-256) that have been hashed, and L is the hash output length in bits. However since the intermediate chaining values are not truncated, this could only be applied with L = 256, and so it shouldn't be a threat as long as SHA-256 is secure.

Replying to [davidsarah]comment:6: > Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment-74317): > > (although [128-bit mutable]a read cap is indeed unachievable). > > Here's why: preimage attacks against a hash function can be performed simultaneously against multiple targets. That is, for N target files, the work factor of a brute force attack against a K-bit hash that succeeds with probability p is p/N * 2^K^. ... > Therefore, if the work factor needed for attacks against confidentiality is p * 2^K^ (which we assume to be sufficient even for low p), then to get at least the same work factor for attacks against integrity, we need at least K + log2(N) bits, where N is the number of targets available to an attacker. Clarification: this depends on the fact that we would only truncate the final hash for each file, not the intermediate hashes used in Merkle trees or the hash of the UEB. Section 6 of [this paper](http://www.di.ens.fr/~zimmer/pub/eurocrypt08.pdf) explains that for a Merkle-Damgård hash (such as SHA-256), there is a second-preimage attack with work factor p/B * 2^L^ where B is the *total* number of *blocks* (of 64 bytes in the case of SHA-256) that have been hashed, and L is the hash output length in bits. However since the intermediate chaining values are not truncated, this could only be applied with L = 256, and so it shouldn't be a threat as long as SHA-256 is secure.

zooko commented

2010-02-05 18:50:46 +00:00

<zooko> I thought you meant <http://allmydata.org/trac/tahoe-lafs> or my blog:
	<http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html>
<Jonathan_L> oh, nice URL! Really user friendly!
<Jonathan_L> :P

``` <zooko> I thought you meant <http://allmydata.org/trac/tahoe-lafs> or my blog: <http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html> <Jonathan_L> oh, nice URL! Really user friendly! <Jonathan_L> :P ```

zooko modified the milestone from undecided to 2.0.0

2010-02-23 03:10:33 +00:00

zooko commented

2010-03-04 07:21:16 +00:00

"You've gotta get a tiny URL." --Jacob Appelbaum

jsgf commented

2010-03-04 21:32:14 +00:00

Attachment wiki.html.png (901 bytes) added

Raw CAP as a QR code

**Attachment** wiki.html.png (901 bytes) added Raw CAP as a QR code

wiki.html.png

901 B

jsgf commented

2010-03-04 21:33:14 +00:00

Attachment wiki.html-url.png (1135 bytes) added

CAP with full URL

**Attachment** wiki.html-url.png (1135 bytes) added CAP with full URL

wiki.html-url.png

1.1 KiB

jsgf commented

2010-03-04 21:37:59 +00:00

I've been looking at encoding caps in QR codes as a way to publish them, get them into phones and other devices, etc. You can see from the attached images the codes are large. They could probably be further reduced, but these were generated with "small" size at http://qrcode.kaywa.com/. I don't know how well they'd reproduce if printed.

The URL is also too large to fit into a single SMS (at 141 characters).

I've been looking at encoding caps in QR codes as a way to publish them, get them into phones and other devices, etc. You can see from the attached images the codes are large. They could probably be further reduced, but these were generated with "small" size at <http://qrcode.kaywa.com/>. I don't know how well they'd reproduce if printed. The URL is also too large to fit into a single SMS (at 141 characters).

davidsarah commented

2010-03-05 02:33:04 +00:00

Sizes of QR codes for various raw bit lengths:

Sizes of QR codes for various raw bit lengths: * [up to 142 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A1234567890123456789012345678901234567890123) * [143 to 209 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A123456789012345678901234567890123456789012345678901234567890123) * [210 to 275 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A12345678901234567890123456789012345678901234567890123456789012345678901234567890123) * [276 to 345 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234)

davidsarah commented

2010-03-05 03:14:03 +00:00

Replying to davidsarah:

Sizes of QR codes for various raw bit lengths:

up to 142 bits

143 to 209 bits

210 to 275 bits

276 to 345 bits

Hmm, these sizes seem larger than they should be. For example, the last link above has 1177 data pixels (37*37 - 192 for the corner registration marks). That's a lot of redundancy to encode 345 bits. I generated the URLs and bit lengths by using the "telephone number" encoding at qrcode.kaywa.com, finding the largest number of digits that could be encoded at each size, and converting to a bit length. Maybe that method is incorrect, I'll check.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment-74331): > Sizes of QR codes for various raw bit lengths: > * [up to 142 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A1234567890123456789012345678901234567890123) > * [143 to 209 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A123456789012345678901234567890123456789012345678901234567890123) > * [210 to 275 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A12345678901234567890123456789012345678901234567890123456789012345678901234567890123) > * [276 to 345 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234) Hmm, these sizes seem larger than they should be. For example, the last link above has 1177 data pixels (37*37 - 192 for the corner registration marks). That's a lot of redundancy to encode 345 bits. I generated the URLs and bit lengths by using the "telephone number" encoding at qrcode.kaywa.com, finding the largest number of digits that could be encoded at each size, and converting to a bit length. Maybe that method is incorrect, I'll check.

davidsarah commented

2010-03-05 03:56:46 +00:00

Replying to [davidsarah]comment:17:

Replying to davidsarah:

Sizes of QR codes for various raw bit lengths:

up to 142 bits

143 to 209 bits

210 to 275 bits

276 to 345 bits

Hmm, these sizes seem larger than they should be. For example, the last link above has 1177 data pixels (37*37 - 192 for the corner registration marks). That's a lot of redundancy to encode 345 bits.

Actually that was the next to last link, so it was encoding 275 bits.

The second link is the same size as the example on Wikipedia, so in that case I know that the number of additional fixed bits is 126, leaving 33*33 - 192 - 126 = 771 data pixels to encode 209 bits. I suspect that the problem is that it's actually encoding each digit with 8 bits (which for this example would be 504 bits in 771 data pixels).

Replying to [davidsarah]comment:17: > Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/882#issuecomment-74331): > > Sizes of QR codes for various raw bit lengths: > > * [up to 142 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A1234567890123456789012345678901234567890123) > > * [143 to 209 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A123456789012345678901234567890123456789012345678901234567890123) > > * [210 to 275 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A12345678901234567890123456789012345678901234567890123456789012345678901234567890123) > > * [276 to 345 bits](http://qrcode.kaywa.com/img.php?s=5&d=TEL%3A12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234) > > Hmm, these sizes seem larger than they should be. For example, the last link above has 1177 data pixels (37*37 - 192 for the corner registration marks). That's a lot of redundancy to encode 345 bits. Actually that was the next to last link, so it was encoding 275 bits. The second link is the same size as the example on [Wikipedia](http://en.wikipedia.org/wiki/QR_Code), so in that case I know that the number of additional fixed bits is 126, leaving 33*33 - 192 - 126 = 771 data pixels to encode 209 bits. I suspect that the problem is that it's actually encoding each digit with 8 bits (which for this example would be 504 bits in 771 data pixels).

davidsarah commented

2010-03-05 04:20:13 +00:00

Ah, I should have been using the URL option. For some reason that produces smaller QR codes than the phone option even when both are restricted to decimal digits.

Ah, I should have been using the URL option. For some reason that produces smaller QR codes than the phone option even when both are restricted to decimal digits. * [90 to 159 bits](http://qrcode.kaywa.com/img.php?s=5&d=123456789012345678901234567890123456789012345678) * [160 to 255 bits](http://qrcode.kaywa.com/img.php?s=5&d=12345678901234567890123456789012345678901234567890123456789012345678901234567) * [256 to 372 bits](http://qrcode.kaywa.com/img.php?s=5&d=1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012)

zooko commented

2010-03-20 17:38:18 +00:00

<zooko> Whoo! Hack Fest!
<ChosenOne> huh? :D
<zooko>
	<http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html>
<ChosenOne> oh man, these URLs suck in gnome-terminal :D	
<zooko> [ChosenOne](wiki/ChosenOne): what sucks about those URLs in gnome-terminal?
<ChosenOne> it's not really a tahoe-lafs problem... url-highlighting
	    (i.e. being able to click them) stops at a colon. so it's the same
	    for wikipedia etc. (and a filed bug for gnome-terminal)
<idnar> yeah, that's really annoying
<ChosenOne> *thinks* maybe i'll write an irssi-plugin to replace colons
	    automagically to %3A in URLs :p

``` <zooko> Whoo! Hack Fest! <ChosenOne> huh? :D <zooko> <http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html> <ChosenOne> oh man, these URLs suck in gnome-terminal :D <zooko> [ChosenOne](wiki/ChosenOne): what sucks about those URLs in gnome-terminal? <ChosenOne> it's not really a tahoe-lafs problem... url-highlighting (i.e. being able to click them) stops at a colon. so it's the same for wikipedia etc. (and a filed bug for gnome-terminal) <idnar> yeah, that's really annoying <ChosenOne> *thinks* maybe i'll write an irssi-plugin to replace colons automagically to %3A in URLs :p ```

zooko commented

2010-08-03 14:38:35 +00:00

Some old notes about this are on ticket #102. Please read them!

zooko commented

2010-08-24 20:27:47 +00:00

Tantek collected some examples of tiny urls being used in the wild in print:

http://tantek.pbworks.com/ShortURLPrintExample

Tantek collected some examples of tiny urls being used in the wild in print: <http://tantek.pbworks.com/ShortURLPrintExample>

zooko commented

2010-11-30 02:03:23 +00:00

I have previously noticed when I post comments on people's blogs and give a tahoe-lafs url such as http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html as my "home page URL" that my comment gets automatically canned for being spam.

Just now I received this comment on twitter:

@zooko you must trigger some URI overflow into Google Reader's back end, it's impossible to subscribe to your blog's feed!
(http://twitter.com/seb_martini/status/9347963721617408)

Followed by:

@zooko never mind, seems to work when shortened http://bit.ly/dURKfO ;)

Where http://bit.ly/dURKfO is a tinyurl that currently elicits http://pubgrid.tahoe-lafs.org/uri/URI%3ADIR2-RO%3Aixqhc4kdbjxc7o65xjnveoewym%3A5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.xml .

So apparently (I haven't confirmed this) the current tahoe-lafs URLs are incompatible with Google Reader.

I have previously noticed when I post comments on people's blogs and give a tahoe-lafs url such as <http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html> as my "home page URL" that my comment gets automatically canned for being spam. Just now I received this comment on twitter: @zooko you must trigger some URI overflow into Google Reader's back end, it's impossible to subscribe to your blog's feed! (<http://twitter.com/seb_martini/status/9347963721617408>) Followed by: @zooko never mind, seems to work when shortened <http://bit.ly/dURKfO> ;) Where <http://bit.ly/dURKfO> is a tinyurl that currently elicits <http://pubgrid.tahoe-lafs.org/uri/URI%3ADIR2-RO%3Aixqhc4kdbjxc7o65xjnveoewym%3A5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.xml> . So apparently (I haven't confirmed this) the current tahoe-lafs URLs are incompatible with Google Reader.

zooko commented

2010-12-08 05:01:52 +00:00

(http://twitter.com/naesten/status/12352362991583232)

@zooko: wow this is a long URL you've got here <http://is.gd/dUlo9> -- its almost as long as a freenet URI!

(http://twitter.com/naesten/status/12352362991583232) @zooko: wow this is a long URL you've got here <<http://is.gd/dUlo9>> -- its almost as long as a freenet URI!

zooko commented

2011-01-14 17:28:35 +00:00

<zooko> Oh by the way here is what I think of FIPS 180
<zooko>
	<http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html>#FIPS%20and%20Common%20Criteria%3A%20don%27t%20rely%20on%20them%20FIPS%20and%20Common%20Criteria%3A%20don%27t%20rely%20on%20them%2C%20part%202
<exarkun> you need better blog urls :(				        [09:54]
...
<zooko> What's wrong with my blog urls!
<exarkun> a lot							        [09:56]
<exarkun> and that's coming from someone who doesn't expect much from urls
<zooko> Just the length?
<zooko> Length isn't everything you know.
<exarkun> the length and the myriad of unusual contents
<zooko> Mind if I quote you on that?
<exarkun> : _and_ % _and_ [ _and_ ] _and_ #			        [09:57]
<exarkun> I... guess not?

``` <zooko> Oh by the way here is what I think of FIPS 180 <zooko> <http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html>#FIPS%20and%20Common%20Criteria%3A%20don%27t%20rely%20on%20them%20FIPS%20and%20Common%20Criteria%3A%20don%27t%20rely%20on%20them%2C%20part%202 <exarkun> you need better blog urls :( [09:54] ... <zooko> What's wrong with my blog urls! <exarkun> a lot [09:56] <exarkun> and that's coming from someone who doesn't expect much from urls <zooko> Just the length? <zooko> Length isn't everything you know. <exarkun> the length and the myriad of unusual contents <zooko> Mind if I quote you on that? <exarkun> : _and_ % _and_ [ _and_ ] _and_ # [09:57] <exarkun> I... guess not? ```

davidsarah commented

2011-01-14 19:25:10 +00:00

the length and the myriad of unusual contents

: and % and [ and ] and #

Of those characters, the base URL (http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html) only has ':', and the rest come from a fragment.

> <exarkun> the length and the myriad of unusual contents > <exarkun> : _and_ % _and_ [ _and_ ] _and_ # Of those characters, the base URL (<http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html>) only has ':', and the rest come from a fragment.

zooko commented

2011-03-18 17:24:53 +00:00

<zooko>
	<http://alpha.zooko.com:3458/uri/URI%3ADIR2-RO%3Avnovnwpkecmncyjachu6d46nbe%3A3fz3pn6sx7ckidfzk4sn5gyfbhhglcbs7djgmiexk7klnrtlujya/diet_research/Latest/Kalaany-2009-Tumours_with_PI3K_activation_are_resistant_to_dietary_restriction.pdf>
<zooko> According to Richard Feinman (in that video), this paper suggests that
	maybe in the future drugs could be developed to mess with this
	pathway, but it doesn't mention that carbohydrate restriction ought to
	have the same effect.					        [11:12]
<zooko> (Which is typical. I have a nice rant about it on my blog. The
	possibility of a trillion dollar patent may have something to do with
	the emphasis on looking for drugs, but it is mostly probably just
	ignorance about carbohydrate restriction
	diet. <http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html>#longevity%20and%20dementia%2C%20drugs%20and%20diet
	)							        [11:13]
<itamar> zooko: your blog implementation is cool and everything, but it needs
	 better URLs						        [11:17]
<zooko> itamar: what's wrong with them?
<itamar> it looks like your cat walked over the keyboard	        [11:23]
<zooko> Mind if I quote you on that?
<itamar> not at all

``` <zooko> <http://alpha.zooko.com:3458/uri/URI%3ADIR2-RO%3Avnovnwpkecmncyjachu6d46nbe%3A3fz3pn6sx7ckidfzk4sn5gyfbhhglcbs7djgmiexk7klnrtlujya/diet_research/Latest/Kalaany-2009-Tumours_with_PI3K_activation_are_resistant_to_dietary_restriction.pdf> <zooko> According to Richard Feinman (in that video), this paper suggests that maybe in the future drugs could be developed to mess with this pathway, but it doesn't mention that carbohydrate restriction ought to have the same effect. [11:12] <zooko> (Which is typical. I have a nice rant about it on my blog. The possibility of a trillion dollar patent may have something to do with the emphasis on looking for drugs, but it is mostly probably just ignorance about carbohydrate restriction diet. <http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html>#longevity%20and%20dementia%2C%20drugs%20and%20diet ) [11:13] <itamar> zooko: your blog implementation is cool and everything, but it needs better URLs [11:17] <zooko> itamar: what's wrong with them? <itamar> it looks like your cat walked over the keyboard [11:23] <zooko> Mind if I quote you on that? <itamar> not at all ```

zooko added

major

and removed

critical

labels 2012-03-29 16:09:40 +00:00

davidsarah commented

2012-05-14 00:40:39 +00:00

On 13/05/12 08:55, Michael Rogers wrote on tahoe-dev: