Android-based Interactive Multimedia Presentation Builder and Player – Looking for Investors

Android-based Interactive Multimedia Presentation Builder and Player – Looking for Investors

Learn More…

Downloads to be made available soon… Stay tuned.

 

 

Advertisements

So you want to build a slick Video Chat Service of your own based on Python, RTMP and Flash

Here’s the Research you might want to focus on:

The End of JavaScript !

JavaScript is perceived to be a fairly secure language in that once the code has been placed into the DOM that code cannot be changed by the end-user.

See also: New Hax can attack any Website !

Consider the following graphical representation of a system that could easily be used to cause client-side code to become obsolete:

Figure 1 – Soft Hax

Secure Web Server

Notice how the Web Server remains secure from any kind of hacking attacks. Port 80 is the only port that would need to remain open and the user need only make normal unmodified requests to fetch content from the target web server.

Notice also that those who monitor the web server for any kind of hacking attacks would not see anything aside from normal typical activities such as those that are used by the browser to fetch content using whatever methods are in-use by the content itself.

The Proxy

Notice also how the real magic in this special method of hacking lies in the Proxy layer. The Proxy is the thing that fetches the content while allowing the end-user to choose how the content is to be presented and then modified.

The Proxy passes requests from the client browser to the server while capturing the content so the client browser can be used to determine how to change the content before it gets to the browser.

The Proxy can be used to make the JavaScript look pretty enough for the human using the browser client to make decisions as to what should be changed.

The Proxy can be used to unpack JavaScript, if you know what JavaScript packing is then this will make sense to you.

The Browser Client

The browser client is not your typical FireFox and FireBug combination most web developers are familiar with, it is however a special type of webkit browser.

The end-user would begin by issuing a request that fetches raw unmodified content from the target server. The raw content is unpacked and unminified, as-required, then passed along to the Browser Client. The End-User then gets to see JavaScript that is now more human readable than not and this one feature alone makes this brand of soft hacking valuable and useful. The End-User is then allowed to determine where to make changes in the content; the changes are passed along to the Proxy and the Proxy is then told to fetch the content again but this time the changes are made to the content per the request of the End-User.

Any changes that cause the server to make conclusions other than those it would normally make would be possible.

For Instance

Let’s assume those who crafted their content chose to off-load much processing from the server to the client (this strategy is in common-use today); let’s also assume the security of the server was left in the hands of the client since it was assumed that nobody could change their content once their content was passed along to the browser once the request had been satisfied.

So now here comes an End-User who has the ability to make changes to the content that comes from the server without anyone knowing what is happening other than this one end-user.

What could the End-User do ?

The End-User could make changes that allow the end-user to be logged-in as a User without the need to have a User Account or the End-User could fetch an existing user account for the purpose of making changes.

At the very least an End-User could legally obtain a user account and then make changes to the way the client operates to achieve what could not otherwise be done in a completely legitimate manner.

Confuse, Block and Confound the Browser’s Cache

Confuse the Cache & Block the Cache

Serve your images through a single URI using HTML/JavaScript.

Benefits

Only one image is ever cached – the last image that was served.

Methods

Do this right…

  • Set the response headers correctly to tell the browsers to not cache and not store your image.
  • Request all images through a single URI that does not specify the image file type such as “/get-image/”.
  • Block the typical human user’s ability to view the image via the URI by requiring the referrer to be the domain from which the image was served.
  • Clear the cached URI by sending an empty image as the last image that is served into a hidden image tag.

And whenever someone does manage to click on an image URI sitting in their browser’s cache they will not see the image whenever their browser gets around to showing the image using the browser because the server will not serve the image because the referrer will not be set correctly thus requiring the user to forge some request headers and this will at-least raise the bar a bit higher and keep the typical civilian user from seeing your prized images or other content you don’t wish to share with everybody unless they are Authenticated and logged-in to your SaaS offering.

Images can be served through a single URI by telling the server to serve a series of images as an ordered series of images where each request to the “/get-image/” URI results in the next image in the series being served.  You can write some JavaScript code using jQuery, for instance, to create some HTML content on the fly with the last image going into a non-visual image tag just to clear the cached image (there will be only one).

Response headers will have to be tweaked to ensure the browser will fetch from the server rather than using the cached image but again this is not all that difficult.  Make sure you don’t use some funky trick like appending some random value to the end of the URI because this will not only bust the cache and hit the server, it will also result in every single image being potentially cached even if the Response headers are set to force the browser to not cache and not store each image.

Why bother with any of this anyway ?!?

If your site offers any kind of SaaS or other service your customers are paying for, for instance, then you might very well want to care about what ends-up in the browser’s cache.

The better method

Use Flash or Flex to fetch your images using AMF2 or AMF3 or some other method that forces the bits and bytes of each image to be transmitted in a format other than the native format most browsers know how to cache.

Use a socket client running in the SWF to make a dynamic connection with the server.

The SWF does not even have to be visible unless this is the desired use-case for your Flash talents.

If there is no Flash Player then fail-over to using the techniques listed above that don’t use flash otherwise use Flash and enjoy your ability to show your content to your end-user without allowing them to grab your content from their browser’s cache.

Google App Engine + LAMP (Python/Django/FastCGI) = Rock Solid Always On Service Platform

Front your business with the Google App Engine

What could your business do with an extra 1 million hits per day and 1 GB of Transfer per day ?

This takes the load off your own back-end servers while providing your business with a rock solid always on front door, so to speak.

Your valuable customer data is not even stored in the cloud, in this model, it is however stored on your own LAMP Database Server running MySQL 5.1.

Your customers see your content through the lens of the Google App Engine.

Memcache handles the transfer of your content sitting on your own LAMP server so that your content does not get pulled from your server more than once per version, for instance.  Your Google App Engine App could either pull your content across the wire on-demand as-needed or optimistically via a background Cron job.

Django 1.1.1 running in both your Google App Engine App and your back-end LAMP server means your GAE (Google App Engine) App can cache real data objects from your back-end server using JSON as the transfer medium so that when a GAE Object does not have the data the back-end server is polled for the data using a REST Web Service and the data is pulled across the wire as compressed JSON using ZIP (GAE knows how to handle ZIP files however LZMA or some other form of pure-Python compression technique could also be used to further reduce the data being transferred across the wire from your back-end LAMP server).

A Real World Scenario

Let’s say you are paying something like $150 for a LAMP server that has 10 Mbps of unmetered transfer per month.  This gives you something like 86400 MB per day or 84 GB per day of transfer.

GAE gives you 1 GB transfer per day for FREE per app and you get 10 apps for FREE for an aggregate total of 10 GB transfer per day for FREE.

GAE extends your own LAMP server by giving you 25% more data transfer per day at no cost.

GAE extends your own LAMP server by giving you an always-on (except for maintenance periods) front-door for your single point of failure which is your single LAMP server.  If you cache your content in an intelligent manner your can perform maintenance on your own LAMP server without interrupting your customers other than to disallow logins, for instance, assuming your own LAMP server does nothing more than serve your content and handle your paying customers after they login.

Leverage Flex 4 (aka. Flash Builder 4)

Front your SaaS (Software as a Service) offering with Flex 4 using some Flash tricks that makes it virtually impossible for people to see your valuable SWFs via a SWF Loader Container that keeps your real SWFs away from the browser’s cache which means nobody can reverse-engineer your real SWFs.

Now you have an RIA (Rich Internet App) using some Flash tricks.

Your RIA off-loads processing to the client to the extent possible.

Your RIA App uses JSON and REST Web Services for simplicity and performance.

Your RIA App funnels all requests through the Google App Engine to the extent possible.

Your RIA App maintains the user’s session locally rather than on the server.  This means your paying customers can login using any server or cloud with the actual Authentication being handled by your back-end LAMP server using your own SSL Certs you did not even have to pay for because you created them yourself.  GAE Apps can use HTTPS as of October 2008 as as SWF-based Apps tend to use little bandwidth assuming Flash Builder 4 is being used along with RSLs for the Flex Framework your customers can see that your site is using SSL via HTTPS all the while your Flex 4 App hides the fact that your back-end LAMP server is being contacted using HTTPS either directly from the Flex 4 App or indirectly via your GAE App; you could just as easily use your own form of pure-Python encryption such as some type of SHA using Flex 4 running on the client.  Passwords are typically encoded using SHA making the password stored in your database nice and secure.

Make it Secure

As an option, your RIA Flex 4 App can pass encrypted data from your customers to your back-end server via your Google App Engine App and vice-versa.  The data that changes would invalidate the GAE cache of such data on a per customer basis via memcache.

Make it Intelligent

Leverage the heck out of Google App Engine to the extent possible.

Let your Flex 4 RIA intelligently begin by-passing the Google App Engine whenever it knows your back-end LAMP server is online and you are about exceed your GAE Limits for the day; your back-end LAMP server probably provides more data transfer per day than your GAE (10) Apps can.

Your Flex 4 RIA can intelligently know when your back-end LAMP server may be down for maintenance and when the GAE is down for maintenance; by-pass the GAE when it is down for maintenance and by-pass your LAMP server when it is down for maintenance.

Your Flex 4 RIA can intelligently allow you to expand your back-end LAMP server farm by knowing which servers to hit and when; your GAE Apps can also handle this task.  This allow you to grow your business as your business grows.  Make more money and add another LAMP server in the form of a cheap VPS or a dedicated server – makes no difference how this is done – your front-door keeps on humming along as though it is all one really big expandable elastic cloud because this is what this would easily become at very little cost to you and your businesses bottom line.

Make it Elastic

Go ahead and leverage the Amazon Cloud or the SalesForce cloud using the Google App Engine as the front door.  Off-load processing as-needed to lower the cost of your own data processing without having to buy your own data center.

Make it use Lua

Yes, you can use Lua from the Google App Engine so long as Lua is running on your own back-end server you can use Lua all you want along with Python running in the Google Cloud.

Make it use PHP

Yes, you can use PHP from the Google App Engine so long as PHP is running on your own back-end server you can use Lua all you want along with Python running in the Google Cloud.  You can also run PHP via Java in the Google Cloud but that seems like a longer way to go to get PHP to be more scalable.  Let’s face-it, PHP is far less scalable than Python or Lua for that matter.  Python uses FastCGI but then Python is more multi-threaded than PHP and Python has a threading model that just works better than PHP or Java for that matter.

Grow your Business on Pennies

Let Google pay for all those servers you don’t need or want to buy.  Google has more money than you do anyway, most likely, so why not let Google pay what would be your electric bill.  A single server could easily cost up to $100/’month just for electricity depending on the configuration of the server and where and how it is cooled as well as other factors.  Google tends to use low-cost low-power servers but let’s face it Google has money to pay for such things so let them.

VPS are pretty cheap.

Free Hosts are also well FREE.

Dedicated servers tend to be a bit pricey depending on the data transfer you want to buy.

By leveraging the heck out of Google to the extent possible you could either simply use the Google App Engine entirely for FREE, assuming you have some desire to do this as you are creative enough.  Or let Google front your business for cheap.

You might not need to pay anything more than let’s say $150 to $200 per month for a LAMP server with 6 GB of RAM and something like 150 GB of disk space.  Make efficient use of how you store and transfer your content and you need never worry about what your cost might be for your own high-powered “cloud”.

%d bloggers like this: