Too much noise out of nothing...or: "protect our streams!"

I've seen this in the IM spam in live musicians group, and Vint also pointed me to this entry, where the author in total panic suggests that the world is collapsing.

Uh-oh. The visitor can view the parcel media URL without a problem. Now, let me tell you - it is a bad idea anyway to base your security on the fact that your stream URL is "not visible".

First, we go over the reasons why the world is indeed not collapsing - we'll consider three of the possibilities to get the URL of the sound stream (one of them is absolutely impossible to circumvent without the drastic change of the client architecture). Then, I will present a couple of solutions to the panicking folks for their consideration.

So....

How to find out the URL for the parcel sound stream

In these examples, I've used the stream URL of Digitally Imported - the radio that is frequently heard in SL. So here goes the credit to them - take a look, and maybe get the membership with them for listening outside the SL.

Terminal output in the linux client

Start secondlife. Start music. Look at the terminal. Done.

This scenario can be "fixed" by having LLs remove the printing of the URL. But please, do not submit a jira on this, please. It is ridiculous. Why ? keep reading.

Debug console in any client (linux, windows, mac)

Basically the same thing as above, but requires turning on the debug console. Here we go.



Again, this is "fixable" by removing the printing of the URL by LLs. However, consider that these are useful for debugging. Those of you who would rush to file a jira right now, will be the first to shout be worried when the streams do not work at all, no ? So, keep reading.

Capturing the requests for the stream itself

This one is a bit more involved and multistep.

1. Go to wireshark website and download the Wireshark - a tool for capturing and analysing the network traffic.


2. Install wireshark on your secondlife PC, start secondlife, start the stream


3. (optional) Launch command prompt ("cmd" on windows), and issue command "netstat" - one of the connections will tell you the streaming server address. Now we need to know the URL


4. Stop the stream, launch wireshark for capturing TCP traffic ("tcp" in the filter)


5. Start the stream, once you hear the music stop the stream and stop capturing via wireshark


6. Find the addresses that do not belong to LLs machines - or the address you found previously from "netstat" if you did that step.Select one packet out of that conversation, right-click, and select "Follow TCP Stream". You will see the output similar to the one below, where first goes the request to the server, and then the reply. The interesting parts are: "GET /stream/1024 HTTP/1.1 ; Host: 64.236.98.50".
   

This gives us the stream URL of http://64.236.98.50/stream/1024.





This "problem" is not fixable. In principle. Unless LLs will start using skype or some other encrypted way to transfer the sound. Which, my friends, will drastically limit your ability to select the streams, and I would not wonder if this would become a "paid service" then, with LLs being the streamhosters themselves. So - Do not rush to submit jira.

This is why I think that while MISC-378 is a bug, it is at most a minor bug, in my opinion.

Now, we go to the second part of the post...

The solutions for the panicking masses

To find the solution it is always best to first define the problem. And the problem is not others being able to view the URL. The problem, as I see it from the words of those who are worried, is that they would like limit the listener audience only to those who are present on the parcel, as much as possible.

The first "weak" solution was presented in the bug report - simply check the user-agent of the client that requests the stream. While it is also by far not fool-proof, it would limit the impact.

The second solution is something I've just come up with. You would want to turn on the stream *only* when there is someone on your parcel. Assuming that your streamhoster does allow some kind of control over scripts via HTTP(S), this is quite trivial to script with the LSL - ask your nearest friendly scripter on how to do it.

All in all, I think that for legitimate music this should not be a problem at all - but I can imagine those streaming the kazaa-ed mp3's to be worried.

Oh, by the way, and before anyone labels me a code junkie who does not get anything in the fine arts, I do write the music myself and from time to time perform in SL, so... :-)