idea: integrate captcha into some furls

[samuelstoller]

Often when I share data with other people on the internet I do the following:

• Put the data in a directory on my web server.
• Add some .htaccess fu to my webserver to get basic auth protection of the data
• Mail the people a link to the data, I also put on a line following the URL the username and password necessary to access the data.

This way if a search engine grabs the link, the data won't be accessible to the whole internet. (A human needs to read the email message and locate the http auth data necessary to follow the link.)

Furls could emulate this captcha like behavior:

• have an 'incomplete' furl type; missing some critical bytes, but complete enough that the client can figure out whats going on to prompt the user for a key.
• the furl would be completed with a 'key' which a user can pass out-of-link.

[zooko]

Just fixing the wikiformatting thing.

[warner]

hrm. let's clear up some terminology first:

"furls": these are identifiers used by Foolscap to point at instances: code objects with methods on them, meant to be invoked by other code

"uris": identifiers used by Tahoe to point at files or directories: meant to be used by either humans or code

Is this a tahoe issue or a foolscap issue? I'll assume you mean to say that uris could have some only-for-use-by-human properties. Furls are meant for use by programs.

The uri already has security properties built in: possession of the uri is both necessary and sufficient to access the file. If you don't want a search engine to make the file available, don't let a search engine see the uri.

Now, that's a separate question from making for-human-eyes-only URIs. At the moment, since tahoe is not particularly widespread, tahoe URIs *are* for-human-eyes-only, since it would take a human to copy the results out of a web page and paste it into a tahoe client. But even if google got excited about crawling into a tahoe mesh to index the contents of all the tahoe URIs it discovered, it would probably be sufficient to remove the 'URI:' suffixprefix from a published tahoe uri: that would be enough to cause a tahoe client to reject the string as invalid.

Or, you could split the URI in half and send each side to someone via a separate channel.

What is the goal? Is it to hide data from google? Should the URI be sufficient for a human to retrieve the file, but not a computer?

[davidsarah]

I suggest wontfix.

[amontero]

@samuelstoller: check lafs-rpg at ​https://bitbucket.org/nejucomo/lafs-rpg and/or this use case #2144 in case any can help.