Tracker Respone with Private Flag

[Klaus_1250]

There has been a lot of discussion here regarding DHT and Private Trackers. I was wondering if µTorrent supports, besides the private flag, also the private flag the tracker can send?

See: http://wiki.bitcomet.com/help/SecureTorrent and http://wiki.bitcomet.com/help/Tracker_HTTP_Protocol

[Firon]

yes, though as wiggo said below, it's a dirty, unreliable fix at best.

[wiggo]

Klaus:

The private flag should NEVER be located in the tracker announce since it's a very unreliable/quick&dirty/bad feature.

Instead, the private flag should ALWAYS be located in the .torrent file for private trackers.

So I guess that future releases of uTorrent will not support the announce based private flag feature. uTorrent will encourage private trackers to put the private flag in the .torrent file instead since that's the correct and reliable way to make the .torrent private.

[ColdArmor]

nonono @ private flagged trackers..

[Klaus_1250]

I see that support has been removed from µTorrent 1.2.1. Isn't that going to p#ss off a lot of private tracker site admins?

I know it is not the correct way to make torrents private, but what about private trackers that have a huge backlog of torrents? They would need to rebuild all the .torrent files and users whould need to redownload the .torrent.

Last, doesn't this create a difference in how BitComet and µTorrent treat (private) torrents and trackers?

[Firon]

Well, only BitComet supported it, so not really.

It's so insecure and unreliable that it's useless, so it's not gonna be supported by µTorrent, period.

[ColdArmor]

I think ludde even changed it in 1.2.1 to ignore that flag when it is sent.

[1c3d0g]

Yup. The private flag should be set in the torrent creation process. It's good to see that µTorrent does not encourage bad habits, unlike some other program... :mad:

[BlackLion]

LOLOL @ 1c3d0g

[Kludge]

Good to see standards, and not

encourage bad habits, unlike some other program...

Great work... Just hope other clients eventually follow suit, and alleviate the workload from site admins

[Klaus_1250]

This isn't going to alleviate the workload from site admins. I think BitComet introduced this to alleviate the workload of siteadmins. I agree that the private tracker response is not really a good thing though.

[chaosblade]

And since when are we supposed to make the site admins life easier ?

He should actually research on a good method for this private tracker before going ahead and implementing stuff.

[Firon]

There's php scripts for a tracker to remake all their .torrents, if they cared enough to. It'd take a bit of work, but it'd be reliable, and it'd get them exactly what they wanted.

[ColdArmor]

I know atleast 3 private site that use that method.

[1c3d0g]

Then those trackers need to be informed on how to implement the private flag properly.

[nightshifted]

There's php scripts for a tracker to remake all their .torrents, if they cared enough to. It'd take a bit of work, but it'd be reliable, and it'd get them exactly what they wanted.

The tracker where I'm a moderator has added the private=1 key to all .torrent files posted since May 13 (it's members only and you need your personalized version to seed with, so you have to download the .torrent file back anyway when you start a seed), but the administrator didn't want to disrupt older torrents with the change to the info_hash (the key would be meaningless if it were outside the info dict and didn't change the info_hash, right?). From what I'm learning now, it may be worth altering those older torrents, of which quite a few are still running. But that's up to him.

[Firon]

The private flag is useless outside of the info dict. The point of putting it in the infodict is that it's difficult to remove without changing the infohash.

Well, changing them would be nice, but I saw a few trackers that simply banned DHT-enabled clients from old torrents... But I don't recommend this solution, it's a better idea to remake the torrents.

I don't know if this is possible, but you could try make the tracker give a different announce response error ("Please re-download this torrent" or something) for infohashes matching the old torrents that you changed. That, or just make it display that for any infohash that doesn't exist on the tracker...

[nightshifted]

It's impossible to remove it from inside the info dict without changing the info_hash!

That last idea is a thought ... caching the info_hashes of existing DHT-vulnerable torrents on the tracker to say to download the new version instead of just that there's no such torrent there.

Thank you again, Firon, for all your help this evening.

[ColdArmor]

There's php scripts for a tracker to remake all their .torrents' date=' if they cared enough to. It'd take a bit of work, but it'd be reliable, and it'd get them exactly what they wanted.[/quote']

The tracker where I'm a moderator has added the private=1 key to all .torrent files posted since May 13 (it's members only and you need your personalized version to seed with, so you have to download the .torrent file back anyway when you start a seed), but the administrator didn't want to disrupt older torrents with the change to the info_hash (the key would be meaningless if it were outside the info dict and didn't change the info_hash, right?). From what I'm learning now, it may be worth altering those older torrents, of which quite a few are still running. But that's up to him.

We need more trackers like this

[Firon]

I'm glad to have helped out.

[splintax]

We need more trackers like this

Agreed. Too many of these private trackers are just banning stuff because of what they heard on the internet from someone else without looking into the problem properly, and blaming everything on the BT client.