Link to home
Start Free TrialLog in
Avatar of RadioGeorge
RadioGeorgeFlag for United States of America

asked on

Protecting (Hiding? Redirecting?) HTML code

Condensed but most simple example:

On my website, there's a page with a customized flash player that plays songs from a list of 50 or so mp3 files.

Let's say the address of the page with the player is www.playmusic.com/tt2,

and the page of mp3 files is located at www.playmusic.com/variety/tt2.

Visitors to the site simply go to www.playmusic.com/tt2 and listen. It's come to my attention that not-so-honest types are figuring out that  the index--and songs/links which can be downloaded are available at www.playmusic.com/variety/tt2.

For the record, I pay all required music licensing fees, ASCAP, BMI, SESAC and Sound Exchange.

I want to stop the vandals from accessing, displaying, and promoting the song links on the page that contains them.

The online searching that I've done so far seems to say:

1) that protecting or hiding the HTML code can't be completely done
2) can be done to some extent with no search engines being able to track the site (not something I can live with)
3) redirecting may work in this case

It's a little beyond me, and that's why you're reading this.

Experts, are there any ways to do what I need to do?
Avatar of Scott Fell
Scott Fell
Flag of United States of America image

There is no way to protect yourself 100%.  There are tools out there where you can redirect the sound that is supposed to go to the speakers to instead be recorded to your hard drive.

Otherwise, you can use your web server to prevent certain files or directories from being directly targeted.  Something on the line of http://www.dotnetcurry.com/ShowArticle.aspx?ID=270
Avatar of RadioGeorge

ASKER

Scott, I appreciate your responding to my question, but the page you directed me to is so technically complex, I  have no idea of what the author is even talking about, so there's no value there for me at all.

Any other ideas or suggestions that a totally no-tech type can understand?
The article described how to block certain file types from playing directly.  In that case it is  using iis, but in Linux you would use htaccess.

Regardless this still does not prevent a user from diverting the sound from the speakers to a recording.  If somebody wants to grab it, one way or another they can.
Sorry, but this solution simply does not come close to adequately answering my question. However, it appears EE is set up to require awarding points rather than just yanking the question, which doesn't make sense, but I'm not in charge.
>I want to stop the vandals from accessing, displaying, and promoting the song links on the page that contains them.

I doubt anybody is vandalizing your site or you would be asking a different question.  Somebody stealing your bandwidth is a different story.   I have given you some technical and general options on how to prevent that and you mentioned it is over your head.   You have the option of either asking for more details on what you don't understand or hire a professional to do this for you.

The information I provided you is valid.

1) There is not a 100% way for somebody to "steal" your music.  If you can stream it, people can record it.   This was backed up by your own research as posted in your question.

2) One option I gave you is to use your web server (iis web.config or linux .htaccess) to prevent other sites from accessing specific files.

This is by no means an easy, cut and dry answer.   A 3rd option is to use a streaming service you would have to pay that can "vault" your media and allow access only via your webserver.  This is probably not something you can do on your own unless you want to do some coding.  

>appears EE is set up to require awarding points rather than just yanking the question
You could delete the question, but that would discount the information you have been provided.  The proper thing to do at this point could be to ask for more clarification if you still do not understand.
Scott,

I'm sorry that you take offense at my comments but I stand by them.

The matter of people recording music, audio, whatever from the speakers was simply never an issue.

What part of "over my head" don't you understand? When the jargon you pointed me to is 100% tech talk, it's pretty much like being spoken to in a foreign language. (I have experienced this same thing before on EE; I can only conclude it's an engineer thing.)

You say: "One option I gave you is to use your web server (iis web.config or linux .htaccess) to prevent other sites from accessing specific files." Scott, this is TECH TALK! I have absolutely no clue what this says or means.

I realize the answer is not cut and dry, but I do expect a general overview statement about the answer to be extremely simple.

I awarded you the points because you DID make an effort to help. Let's leave it at that.
ASKER CERTIFIED SOLUTION
Avatar of Scott Fell
Scott Fell
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Scott,

Thank you for the followup comment, which I was indeed able to follow.

Your solution in the "playmusic.com" example may be the only thing that will work and I certainly understand it and know how to implement it.

For the record, I don't use any video, so that's not a consideration

I see how the streaming and "vault" solutions would work, but because of the structure of the site we're talking about, they are simply not applicable. Also, with listeners in over 4,000 cities in more than 140 countries/nations, I imagine the vault concept would tend to get very pricey very fast.

My operation is best described as "file on demand," specifically designed to (1) avoid 24/7 streaming costs, (2) comply with music licensing requirements (I pay ASCAP, BMI, SESAC, and Sound Exchange), and (3) track each and every song (used custom-built software) that is heard to keep required records that get sent quarterly to the music publishers.

Guess we had to volley for awhile to get a possible solution--and again, thanks for the time you've put into this.
Scott's followup to earlier posts provided a simple (possible) solution that is easy to understand and implement.  Sometimes, that's just the way things work out.

His persistence and willingness to respond so that I could understand what he was saying show a lot of class, and I appreciate that very much.