information in urls

[mathias baert]

Hi

I was looking at the urls for feeds and items in feeds

http://127.0.0.1:9862/key/TmCAKJ3kdBxi4OMXBryJakLif2jtYfnnrN50rUt_vWQ/1/1/0/3/data.feed

Is it intentional that this part "1/1/0/3" is visible?

feed-id, feed-version, item-id, depth

This is item/feed meta data,

for which we do not have access control.

The person who can see this url

can conclude 

that you have a large/small amount of feeds,

that you have bumped/not bumped the version before,

that you have a large/small amount of items in your mine,

that one item/feed was created after another item/feed,

that items are not appearing in a feed,

...

Is that a problem?

I can imagine situations in which I would prefer not to divulge this information.

example:

I have taken pictures at an event,

I import them in my mine, tagging them all with "bigparty2010"

and tag some of them with "toodrunktoshare"

with some close friends people at the party I share all tagged with "bigparty2010"

with most others I share "bigparty2010 !toodrunktoshare"

that last group now knows that there are items missing from my stream and can speculate.

Even better, they can estimate at which time the pictures where taken,

count how many ids are missing and so they can ask me

"hey what happened between 23h and 24h? there are 20 pictures missing from your feed."

Greetings

Mathias

[Alec Muffett]

> The generated feeds are RSS,
> I thought you were using ATOM,
> when did that change?

About 2 weeks ago; it's going to be switchable between "rss201" and "atom" since there is nothing in the Mine! protocol now which requires ATOM over RSS, and there is no reason to *prefer* ATOM over RSS.

The default will now be "rss201" because my testing experience has been that Enclosure-Handling in RSS is much better dealt-with across Feed Readers with RSS than it is with ATOM; simply: there are a bunch of Feed Consuming Tools which don't know what to do with ATOM enclosures.

The code to swap between the two is a trivial change:

http://code.google.com/p/pymine/source/browse/trunk/api/feedgen.py#82

See lines 83 and 91 :-)

> I was looking at the urls for feeds and items in feeds
> http://127.0.0.1:9862/key/TmCAKJ3kdBxi4OMXBryJakLif2jtYfnnrN50rUt_vWQ/1/1/0/3/data.feed
>
> Is it intentional that this part "1/1/0/3" is visible?

For the moment, yes; this was all part of the core-refactoring, the old Minekey structure got tossed away and replaced with this.

> The person who can see this url can conclude

> ...

> that items are not appearing in a feed,

You're absolutely right.

> Is that a problem?
> I can imagine situations in which I would prefer not to divulge this information.

It's an issue, but I wouldn't call it a problem because the new setup is designed to be forward compatible so that I can reinstate secrecy later, once I have worked out how best to do it.

The problem with the old mechanism was that it tried to combine both integrity and secrecy in a single process, which is a bad way to go about it (ref: Bart and Darren helping me analogise minekeys to IPsec) - the better way is to have the content integrity check on the *outside* of the secrecy wrapper - you might say "have the wax seals on the *outermost* envelope" - and then have the secrecy mechanism on the inside.

Also: the primary reason that I have removed the "secrecy" component temporarily is because crypto-secrecy requires an non-stdlib library for Python, which complicates OSX deployment; the "integrity" component (HMAC) however *is* part of the stdlib.

Once the Mine is more established amongst developers, and once I've had a thought about how not to mess it up again, then the secrecy can go back and be made default, and keys can be upgraded automatically - this is the joy of keys being "opaque" URLs. I intend to pre-populate a couple of extra crypto-keys into the databases, just to enable this all to happen transparently. :-)

-a

--
alec.m...@gmail.com
http://www.crypticide.com/dropsafe/