Hi gang:

Here's the problem.

I have a client who has Flash Videos and wishes to rent these Videos
out for a certain time period. (No, it's not porn -- shame on you).

I have written the code and have NO problems with registering the
user, having the user pay, and managing user's time to allow viewing
the video. That's all been solved.

However, once the user is provided with a url where the Flash Video
resides, then the user can view the video remotely by just creating a
page that references that url -- that's easy to do.

Now, how can I stop that from happening?

I have some ideas, but would like to hear what greater minds have to say. :-)

Thanks in advance for all replies.

tedd


--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

On Fri, 2008-01-04 at 12:58 -0500, tedd wrote:
> Hi gang:
>
> Here's the problem.
>
> I have a client who has Flash Videos and wishes to rent these Videos
> out for a certain time period. (No, it's not porn -- shame on you).

Bah!

> I have written the code and have NO problems with registering the
> user, having the user pay, and managing user's time to allow viewing
> the video. That's all been solved.
>
> However, once the user is provided with a url where the Flash Video
> resides, then the user can view the video remotely by just creating a
> page that references that url -- that's easy to do.
>
> Now, how can I stop that from happening?

Use a URL that maps to a PHP script. Have the PHP script check that they
are logged in. If not, redirect to login. If they are logged in, then
flush the flash object to their browser with appropriate headers.

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........

At 1:09 PM -0500 1/4/08, Robert Cummings wrote:
>On Fri, 2008-01-04 at 12:58 -0500, tedd wrote:
>> Hi gang:
>>
>> Here's the problem.
>>
>> I have a client who has Flash Videos and wishes to rent these Videos
>> out for a certain time period. (No, it's not porn -- shame on you).
>
>Bah!
>
>> I have written the code and have NO problems with registering the
>> user, having the user pay, and managing user's time to allow viewing
>> the video. That's all been solved.
>>
>> However, once the user is provided with a url where the Flash Video
>> resides, then the user can view the video remotely by just creating a
>> page that references that url -- that's easy to do.
>>
>> Now, how can I stop that from happening?
>
>Use a URL that maps to a PHP script. Have the PHP script check that they
>are logged in. If not, redirect to login. If they are logged in, then
>flush the flash object to their browser with appropriate headers.

Rob:

I have all of that logic in place now.

My question was specifically how to stop a remote viewer from viewing
the video once the url is known.

I think Daniel answered it by disabling hot-linking. I just need to test it.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

On Fri, 2008-01-04 at 13:29 -0500, tedd wrote:
> At 1:09 PM -0500 1/4/08, Robert Cummings wrote:
> >On Fri, 2008-01-04 at 12:58 -0500, tedd wrote:
> >> Hi gang:
> >>
> >> Here's the problem.
> >>
> >> I have a client who has Flash Videos and wishes to rent these Videos
> >> out for a certain time period. (No, it's not porn -- shame on you).
> >
> >Bah!
> >
> >> I have written the code and have NO problems with registering the
> >> user, having the user pay, and managing user's time to allow viewing
> >> the video. That's all been solved.
> >>
> >> However, once the user is provided with a url where the Flash Video
> >> resides, then the user can view the video remotely by just creating a
> >> page that references that url -- that's easy to do.
> >>
> >> Now, how can I stop that from happening?
> >
> >Use a URL that maps to a PHP script. Have the PHP script check that they
> >are logged in. If not, redirect to login. If they are logged in, then
> >flush the flash object to their browser with appropriate headers.
>
> Rob:
>
> I have all of that logic in place now.

Then what is the problem? or do you mean you don't ant the same user to
view the item while logged in at some point in the future? If so then
use a GET parameter (MD5 or SHA1 should suffice) that maps to a DB entry
that indicates expiration time.

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........

"tedd" <tedd.sperling@gmail.com> wrote in message
news:p06240808c3a420b207cf@[192.168.1.102]...
> Hi gang:
>
> Here's the problem.
>
> I have a client who has Flash Videos and wishes to rent these Videos out
> for a certain time period. (No, it's not porn -- shame on you).
>
> I have written the code and have NO problems with registering the user,
> having the user pay, and managing user's time to allow viewing the video.
> That's all been solved.
>
> However, once the user is provided with a url where the Flash Video
> resides, then the user can view the video remotely by just creating a page
> that references that url -- that's easy to do.
>
> Now, how can I stop that from happening?
>
> I have some ideas, but would like to hear what greater minds have to say.
> :-)
>
> Thanks in advance for all replies.
>
> tedd
>

Tedd, I think your biggest problem is going to be that most browsers cache
the things they run across, this would include embedded flash videos,
although it may take a little work
(http://www.walkernews.net/2007/06/03...-cache-folder/)
the users could grab the file form their cache. Second even if you use PHP
to map to a file eg. somephpfile.PHP?file=dl29coj2jodod which would respond
by serving a specific file, all you have to do is use Firefox's HTTP Live
Headers extension which will see the response come back with the actual
filename since you have to connect to it eventually.

You can fix the caching problem by following one of these suggestions
http://kb.adobe.com/selfservice/view...nalId=tn_14743
And as far as the evading the live headers finding the actual file name and
just directly downloading it I'm not really sure how you would stop that.
You could have a PHP file open the .swf and read all of it's contents then
write out the headers and all the data, that way the user would really only
be talking to the PHP file.

Oh, and there's one more big problem. What's to stop people from just
taking the url (mapped or not) once logged in and just going to that
directly and doing a save as?

Really there's a ton of interesting ways a user could grab the flash movies,
but maybe rather than just having a .flv player and .flv files which can be
stolen off your site you might want to build authentication into the flash
movie itself. You could do something like serve the customer a unique
every time they request to watch a movie, then serve them the movie
and have it check for the .

Although even with all that in place you can still just get a flash
decompiler and decompile the protected .swf player/video and grab the .flv
content out of it.

Jesh, this is really a lot harder than I thought. Oh well, guess there's
never absolute security.

- Dan

At 1:54 PM -0500 1/4/08, Robert Cummings wrote:
>On Fri, 2008-01-04 at 13:29 -0500, tedd wrote:
>
> > Rob:
>>
>> I have all of that logic in place now.
>
>Then what is the problem? or do you mean you don't ant the same user to
>view the item while logged in at some point in the future? If so then
>use a GET parameter (MD5 or SHA1 should suffice) that maps to a DB entry
>that indicates expiration time.
>
>Cheers,
>Rob.


Rob:

I'm sorry, I must not explaining it well.

I have all the code in place to manage viewers.

What I'm asking is how to stop someone who isn't authorized to view a
video after they know the url.

For example, let's say a person pays and has access to the video for
some period of time.

Later his time runs out and if he returns to the site and tries to
see the video again, he can't because he has to pay again. No
problem, I have all that worked out.

However, let's say the user pays, views the video, makes a note of
the url, and his time runs out. What's to stop him from viewing the
video again by just entering the url?

That's what I'm asking -- I think Daniel's suggestion to prohibit
hot-linking may work. I just need to test. Also, Daniel has provided
me with some other code that is going to take me a while to test.

Thanks for your time.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

On Fri, 2008-01-04 at 14:43 -0500, tedd wrote:
> At 1:54 PM -0500 1/4/08, Robert Cummings wrote:
> >On Fri, 2008-01-04 at 13:29 -0500, tedd wrote:
> >
> > > Rob:
> >>
> >> I have all of that logic in place now.
> >
> >Then what is the problem? or do you mean you don't ant the same user to
> >view the item while logged in at some point in the future? If so then
> >use a GET parameter (MD5 or SHA1 should suffice) that maps to a DB entry
> >that indicates expiration time.
> >
> >Cheers,
> >Rob.
>
>
> Rob:
>
> I'm sorry, I must not explaining it well.
>
> I have all the code in place to manage viewers.
>
> What I'm asking is how to stop someone who isn't authorized to view a
> video after they know the url.
>
> For example, let's say a person pays and has access to the video for
> some period of time.
>
> Later his time runs out and if he returns to the site and tries to
> see the video again, he can't because he has to pay again. No
> problem, I have all that worked out.
>
> However, let's say the user pays, views the video, makes a note of
> the url, and his time runs out. What's to stop him from viewing the
> video again by just entering the url?

It's simple, the URL should NOT directly point to the flash. It should
point to a PHP wrapper script. The wrapper script then allows you to do
any kind of checking necessary to restrict viewing of the video. This
can include:

- checking that the user is logged in
- checking that the user paid during current session
- checking that the user has email address robert@interjinn.com
- etc

If the check allows viewing of the flash, then read the content of the
flash object in PHP and flush to browser along with appropriate flash
content headers.

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........

On Jan 4, 2008 3:12 PM, Robert Cummings <robert@interjinn.com> wrote:
> It's simple, the URL should NOT directly point to the flash. It should
> point to a PHP wrapper script. The wrapper script then allows you to do
> any kind of checking necessary to restrict viewing of the video. This
> can include:
[snip]
> - checking that the user has email address robert@interjinn.com

Remember, Rob, he said it's not porn. So it doesn't have to be
your address that's allowed in at any given time. ;-P

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

On Fri, 2008-01-04 at 15:27 -0500, Daniel Brown wrote:
> On Jan 4, 2008 3:12 PM, Robert Cummings <robert@interjinn.com> wrote:
> > It's simple, the URL should NOT directly point to the flash. It should
> > point to a PHP wrapper script. The wrapper script then allows you to do
> > any kind of checking necessary to restrict viewing of the video. This
> > can include:
> [snip]
> > - checking that the user has email address robert@interjinn.com
>
> Remember, Rob, he said it's not porn. So it doesn't have to be
> your address that's allowed in at any given time. ;-P

I was hoping he was lying 8)

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........

On Fri, 4 Jan 2008 13:29:04 -0500, tedd wrote:
> .... I have all of that logic in place now.
>
> My question was specifically how to stop a remote viewer from viewing
> the video once the url is known.

You can't. Just last night I viewd a video (flv) out of a video hosting
site with Opera and with its cache set Very High -- just for this
exercise. While the video was displaying in the Opera window, I fired up
a linux konsole and navigated down into the .opera/ directory to the
cache sub-directory. Seeing the most recent entries and picking off the
largest of them, I rightly guessed that was the video and I copied it --
with rename -- to another directory.

Rule 1 on the web:
If you send it to them to see, read, or hear, they have it.


OBTW, if you're curious:
The 'loaded' URL is:
http://dailymotion.alice.it/video/x3...pe-triode_tech

The simpler, flv-only URL is:
http://www.dailymotion.com/swf/x3wrzo

A pretty kewl video for some of us......


Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts: <http://jonz.net/ng.htm>

Hi gang:

Here's my logic, so what's wrong with it?

My sole concern here is to protect a Video from being stolen and/or
being viewed remotely while allowing "approved" users to view it.

It is a fact that anything you present to a user is theirs. There's
no stopping them from downloading a Video if they have permission to
do so. In fact, that's exactly what they do when they view a Video --
they can't view it in their browser unless their browser has it.

Now, I have investigated several ways to protect videos and prevent
caching. Some methods are very complex -- but complexity does not
always guarantee security. Complexity is more likely to present
problems in its application. Sometimes the simplest method is best.

The simplest protection method I can think of can be done by using
Flash Video Actionscript in concert with php/mysql.

It's a simple matter to have the Video run the following prior to displaying:

theXML.load(http://example.com/security.php)

That's similar to a javascript onload function.

Upon loading the Video, the Video will run the script "security.php"
which in-turn will check to see if an approved user is attempting to
view the Video. This done by simply checking a user-id session
variable in the script that delivers the Video.

If that session variable (user-id ) is empty, then the security.php
returns nothing.

If that session session is not empty, then the script will check the
user-id against the database to see if the user has permission to
view the Video. If the user does not have permission, then the
security.php script returns nothing.

If everything checks, then the security.php script will return a key
and the Video will check that key against an internal key -- if a
match is made, then the video plays.

Now, please note that this will also prohibit the user, even after
paying for the Video, from downloading the Video for future plays
because the Video will always check for a key.

Even if the user downloads the Video and takes the Video to a remote
player, the Video will still try to run the security script seeking a
key. If the security script is not there, then it fails. Even if the
user figures out that the Video requires a key, the still user has no
way to determine what that internal key is.

So, I think this will work. What say all of you? Where have I screwed up?

And, please no one liners that solve the entire mess and make me look
like a fool.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

On Jan 4, 2008 9:16 PM, tedd <tedd.sperling@gmail.com> wrote:
> Hi gang:
>
> Here's my logic, so what's wrong with it?
>
> My sole concern here is to protect a Video from being stolen and/or
> being viewed remotely while allowing "approved" users to view it.
>
> It is a fact that anything you present to a user is theirs. There's
> no stopping them from downloading a Video if they have permission to
> do so. In fact, that's exactly what they do when they view a Video --
> they can't view it in their browser unless their browser has it.
>
> Now, I have investigated several ways to protect videos and prevent
> caching. Some methods are very complex -- but complexity does not
> always guarantee security. Complexity is more likely to present
> problems in its application. Sometimes the simplest method is best.
>
> The simplest protection method I can think of can be done by using
> Flash Video Actionscript in concert with php/mysql.
>
> It's a simple matter to have the Video run the following prior to displaying:
>
> theXML.load(http://example.com/security.php)
>
> That's similar to a javascript onload function.
>
> Upon loading the Video, the Video will run the script "security.php"
> which in-turn will check to see if an approved user is attempting to
> view the Video. This done by simply checking a user-id session
> variable in the script that delivers the Video.
>
> If that session variable (user-id ) is empty, then the security.php
> returns nothing.
>
> If that session session is not empty, then the script will check the
> user-id against the database to see if the user has permission to
> view the Video. If the user does not have permission, then the
> security.php script returns nothing.
>
> If everything checks, then the security.php script will return a key
> and the Video will check that key against an internal key -- if a
> match is made, then the video plays.
>
> Now, please note that this will also prohibit the user, even after
> paying for the Video, from downloading the Video for future plays
> because the Video will always check for a key.
>
> Even if the user downloads the Video and takes the Video to a remote
> player, the Video will still try to run the security script seeking a
> key. If the security script is not there, then it fails. Even if the
> user figures out that the Video requires a key, the still user has no
> way to determine what that internal key is.
>
> So, I think this will work. What say all of you? Where have I screwed up?
>
> And, please no one liners that solve the entire mess and make me look
> like a fool.
>
> Cheers,
>
> tedd
>

I'm not sure if you mean FLV's or SWF's.

If you mean FLV's loaded from SWF's, the browser can cache the FLV,
and the user can later retrieve it.

If you mean SWF's, there are "extractors" out there.

In other words, it's not really possible to completely secure these
videos, but this is a fairly good solution, as I see it.

--
-Casey

Tedd,

As Casey noted, there's no totally secure methodolgy, but your's is close
enough - everything is wrapped in the Flash movie, so even if the movie is
sent on to someone else, that someone has to be approved.

We've been doing something similar for several years now, validating against
a database and when validation succeeds, issuing a key stored in the
database and as a Flash (ach, can't remember the name, but Flash's
equivalent of a .)

As for people wanting "total security" - unplug everything and go split
wood. Most security breaches are internal, and usually all that's necessary
is to keep honest people from straying down the wrong path.

Cheers - Miles

On Jan 5, 2008 1:16 AM, tedd <tedd.sperling@gmail.com> wrote:

> Hi gang:
>
> Here's my logic, so what's wrong with it?
>
> My sole concern here is to protect a Video from being stolen and/or
> being viewed remotely while allowing "approved" users to view it.
>
> It is a fact that anything you present to a user is theirs. There's
> no stopping them from downloading a Video if they have permission to
> do so. In fact, that's exactly what they do when they view a Video --
> they can't view it in their browser unless their browser has it.
>
> Now, I have investigated several ways to protect videos and prevent
> caching. Some methods are very complex -- but complexity does not
> always guarantee security. Complexity is more likely to present
> problems in its application. Sometimes the simplest method is best.
>
> The simplest protection method I can think of can be done by using
> Flash Video Actionscript in concert with php/mysql.
>
> It's a simple matter to have the Video run the following prior to
> displaying:
>
> theXML.load(http://example.com/security.php)
>
> That's similar to a javascript onload function.
>
> Upon loading the Video, the Video will run the script "security.php"
> which in-turn will check to see if an approved user is attempting to
> view the Video. This done by simply checking a user-id session
> variable in the script that delivers the Video.
>
> If that session variable (user-id ) is empty, then the security.php
> returns nothing.
>
> If that session session is not empty, then the script will check the
> user-id against the database to see if the user has permission to
> view the Video. If the user does not have permission, then the
> security.php script returns nothing.
>
> If everything checks, then the security.php script will return a key
> and the Video will check that key against an internal key -- if a
> match is made, then the video plays.
>
> Now, please note that this will also prohibit the user, even after
> paying for the Video, from downloading the Video for future plays
> because the Video will always check for a key.
>
> Even if the user downloads the Video and takes the Video to a remote
> player, the Video will still try to run the security script seeking a
> key. If the security script is not there, then it fails. Even if the
> user figures out that the Video requires a key, the still user has no
> way to determine what that internal key is.
>
> So, I think this will work. What say all of you? Where have I screwed up?
>
> And, please no one liners that solve the entire mess and make me look
> like a fool.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>