Tube ripping software, will help or hurt Tube Sites ?
 

I was approached today by a eastern europian based developer with a pretty nice riping software for RedTube. All it does it connect to RedTube and downloads all the new videos. He wanted to know if I am willing to market this.

I have looked at other Flash Video download softwares but this is far more automated then any thing else. Just set it up and it keeps downloading.

Will a software like this going to help more people to get free content or will the usage of software like is going to burn so much bandwidth Tube sites will find its not worth running a business ?

wont it cost you the same amount of bandwidth? That software gonna do nothing. Move on. :2 cents:

It sounds like a great way to fuck tube sites.

if its released public is will just help people get content for free.
Should keep it private and a few people chip in a get a nice server and just leave it constantly downloading for a few weeks to eat up the servers bandwidth

well ........eastern europe developer as in probably russian or ex-russian republic, they are smart without a doubt.
so how you wanna market this, will it be using RedTube bandwidth?
it looks like to me (personally) as a good idea, but heh

Eventually, they'll (have to) institute a max amount of bandwith use by IP. Most hosts have a single gateway, even if they have multiple IP aliases. Whoever uses such a product will eventually get noticed, banned, and have to start somewhere else (on a new gateway IP/block/etc.)

So, no, it won't change much. It'll cost them a bit of traffic, but as the tube sites get to such a point of saturation that they're all stealing from eachother, it's going to just become a set of not-necessarily-connect CJTs.

What format does it download the files in? Flash or raw video?
WG

...I think. I haven't actually tested that.

Its a client software that sites on your PC and does the download. The files are saved as FLV and it comes with a built in FLV player.

For tube sites to ban they need to block complete IP blocks, but still it can be spoofed.

Most colo providers will sell you BW at very low price if you are only doing pull (downloads)

How the fuck its a good idea mates? If you owned a tube site, wont you boot that ass-hat IP off the earth after downloading some hundred gigs? Even if no, how some tera bytes are going to hurt them if they are serving dozens already? .. come'on.

you can't be serious.

There have been progs like that around since pics first appeared on the net.....

They will be dealt with in the same way.

Grouchy, being a server admin you tell these guys how a tube site owner can prevent such dirty little tricks. :thumbsup

Couldn't the FLV files be coded to embed ads into them easily? Via pre-roll or post-roll?
WG

A bit of .htaccess magic and you could embed ads in just the ripped ones....

I'm bored. I'll bite. There are tons of ways.

The easiest would be to just require registration; then, they've got direct user tracking; embed it into the rendered page data; then just check the access logs and use some heuristics for account auth.

There's HTTP_REFERER (sic) for FLV/FLA; easy to fake, though.

You could easily use a hash in the embed code for the player which obfuscates the path to the file, that's pretty trivial.

Another way would be to rebuild the system to put the file out of the access of the web root directory, and have a call to a ticket/auth system place a single symlink to the stream which expires upon load right once the stream starts 'streaming', so it doesn't work right when the file gets loaded. As the file handler 'stays' until the stream is done, that single request will work, but concurrent requests will fail unless done very, very, very, very quickly, again, supposing you can figure out how the auth system hashes.

There's plenty of ways to (over) engineer a system, but the easiest is still just blocking the thieves' IP address and analyzing the headers to see what sort of browser/etc it mimics to download the content.

It'd be easier to have them prebuilt with ads/non-ads, and just serve the file from different directories. Recreating a flv on the fly is pretty CPU intensive.

Yes, and no. See above.