• Registered: 2008-01-06
  • Posts: 28

Topic: The Flash Sandbox.

I've read most of the posts about the Flash sandbox and think I understand most of it.  And I can see why it is necessary.

As I understand it, a request from a widget running on my Chumby has the domain *.chumby.com.  So if I want to access something from a different server, then at server needs to have a crossdomain.xml file which allows access from *.chumby.com.  Which also means that any widget from any Chumby can access stuff.

I can see where Chumby is concerned about this, because they don't have 'control' over bandwidth, responsiveness, etc.  So and unsuspecting user might have poor response, bad service, and it's not Chumby's fault.

From the perspective of a guy who has stuff on his server he would like to get at, I'm not too enthused about opening my server up to everybody.

I know that I can put some code into a specific application so only serve content based on some 'secret' code, but that's tough to do for packages, and it still doesn't prevent somebody from just trying different URLs to see what they get.

So, for the Chumby folks..  Is there some way you could set things up so that at least Private Widgets get a security domain of something like 'widget-id'.chumby.com?

That way, sites that want to allow any widgets access will still work with the *.chumby.com, but if I only want to serve to my chumby, or a few, I could create a more limited crossmain.xml file.

  • jvc
  • Busy Chum
  • Offline
  • Registered: 2007-11-10
  • Posts: 158

Re: The Flash Sandbox.

FYI, The crossdomain file can be placed (and not required to be called "crossdomain.xml") as long as the widget is aware of it's location

For instance I create WidgetABC and make it private. Inside WidgetABC's code is 

System.security.loadPolicyFile("http://yourserver.com/supersecretplace/bobGroceryList.xml");

where bobGroceryList.xml is actually a crossdomain.xml file

This is one way of limiting access instead of just placing a crossdomain.xml at the root of your server where Flash will look for it by default.

From what I understand if you wanted to get even tricker with it you could pass the Chumby ID as a variable to a script which then could return a valid crossdomain.xml file if the ID is correct

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: The Flash Sandbox.

The implementation of the security sandbox is built into the Flash Player source from Adobe - we don't really have anything to do with it.

To do what you're asking, we'd have to play some rather tricky DNS games - not sure we even have that option with our hosting service.

To expand on jvc's response, you could use a unique chumby id as part of the path to the crossdomain file (requires the beta Control Panel, which passes an MD5 hash of the chumby GUID to the widget):

System.security.loadPolicyFile("http://yourserver.com/"+_root._chumby_chumby_id+".xml");

This would effectively give you a whitelist.

For older Control Panels, you could use the username (available in "_root._chumby_user_name").

Duane's Website

  • Registered: 2008-01-06
  • Posts: 28

Re: The Flash Sandbox.

jvc... thanks a bunch for that information.   It sounds like that should accomplish what I need.  "Technically" it's security by obscurity.. but I'm not planning on using it for a shopping cart or to hand out SSN's.. ~:-)

Thanks also to Duane...  I'm pretty sure I know where to get the ID, so that shouldn't be a problem.  The DNS probably wouldn't be the hard part.  You'd "just" need to add some code at activation time to create the entry.  The Apache config would probably be the harder part.

Nick

  • Registered: 2007-12-17
  • Posts: 7

Re: The Flash Sandbox.

I have a related question regarding the Flash Sandbox and its security policy. I implemented a HTTP listener as a .net application to receive and respond to Chumby requests.  I am not sure how the security policy will work. Do I need to use a crossdomain.xml file and if so, where do I put it?

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: The Flash Sandbox.

The best source of information for this is the Adobe site. See this page for links to the various articles on the topic.

In general, in order to fetch XML and movies from one domain with a Flash movie that is hosted on another domain requires "permission", which is granted by the "crossdomain.xml" file.  This is the opposite of the "robots.txt" file used by search engines, which is used to *deny* permission.

If you're providing the HTTP service, you should be able add a response for a fetch for the crossdomain file.

Duane's Website

  • Registered: 2008-01-06
  • Posts: 28

Re: The Flash Sandbox.

Using the System.security.loadPolicyFile works, and it does allow me to put the crossdomain.xml file with the application that uses it.  So I'm at least not exposing my whole system to every chumby.

One thing that finally dawned on me is that the URL that you specify in loadPolicyFile doesn't have to BE and XML file.  It just needs to RETURN an XML file.  To the web server that gets the load request, it's just a "standard" HTTP request.

The URL could just as easily point to a PHP script that looks at the name of the file being requested and/or where the request came from and do some lookups in a database or file to determine if it should grant access.  If it doesn't want to grant access, it just needs to reply with a "not found"...

So, while it still wouldn't be enough for banking... it would still provide a whole lot of flexibility and still stay within the 'sandbox' model.

  • From: Sydney, Australia
  • Registered: 2009-08-19
  • Posts: 17

Re: The Flash Sandbox.

Duane wrote:

To expand on jvc's response, you could use a unique chumby id as part of the path to the crossdomain file (requires the beta Control Panel, which passes an MD5 hash of the chumby GUID to the widget):

System.security.loadPolicyFile("http://yourserver.com/"+_root._chumby_chumby_id+".xml");

I have been hoping to implement a model somewhat similar to the above. I've realised that the "_root._chumby_chumby_id" variable in Flash returns a GUID which is DIFFERENT to the one returned by the "guidgen.sh" script!!

- Are these values meant to be different?
- Is there a way of accessing the value of "_root._chumby_chumby_id" from a flash movie running directly (not as a widget) on the Chumby?
- Is there a way of accessing the value returned by "guidgen.sh" from within a flash movie and/or a widget?

Any help appreciated.

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: The Flash Sandbox.

Yes, they are meant to be different, but unique.

We don't publish the device's actual ID to the widget for security reasons (one could attempt to spoof the device).

The current mechanism to create the widget's device GUID is by computing an MD5 of the actual device GUID and reformatting as a GUID.  However, that's not guaranteed across all future products, that may use an entirely different mechanism (but still unique).

Duane's Website

  • From: Sydney, Australia
  • Registered: 2009-08-19
  • Posts: 17

Re: The Flash Sandbox.

Duane wrote:

We don't publish the device's actual ID to the widget for security reasons (one could attempt to spoof the device).

What unique Chumby Id can I access from within Flash to build an authentication mechanism around it on my website? I am running my application in stand-alone mode (non-widget). It seems that the"_root._chumby_chumby_id" value is only available when the application is used as a widget, and the GUID itself cannot be accessed within Flash!

  • From: Tulsa, OK
  • Registered: 2008-08-04
  • Posts: 657

Re: The Flash Sandbox.

techgermz wrote:
Duane wrote:

We don't publish the device's actual ID to the widget for security reasons (one could attempt to spoof the device).

What unique Chumby Id can I access from within Flash to build an authentication mechanism around it on my website? I am running my application in stand-alone mode (non-widget). It seems that the"_root._chumby_chumby_id" value is only available when the application is used as a widget, and the GUID itself cannot be accessed within Flash!

If you're building a widget that will be public, I would recommend the _chumby_user_id for a particular user (in which case *any* chumby this person owns can access that particular data) or _chumby_chumby_id to keep data for a particular chumby.

As far as what IDs to pull running as a local widget, I'm afraid I don't know enough to comment.

Cheers.

Get -> Chumbyland | Joice | Word Up | Newsdom

cbreeze's Website

  • From: Sydney, Australia
  • Registered: 2009-08-19
  • Posts: 17

Re: The Flash Sandbox.

Thanks for your response cbreeze.

The app that I am working on will be limited to a private set of users within our organization, and will be run as a dedicated app (not through the widget framework). To build an authentication structure for only allowing a specific subset of chumbys to access a somewhat sensitive RSS feed, I need to be able to identify each chumby uniquely.

In my attempts so far, it seems that neither '_chumby_chumby_id' nor '_chumby_user_id' are available when the app is run in stand-alone (non-widget) mode. Thus my question, how can I uniquely id a Chumby while in this mode?

The closest lead I have so far is using the 'guidgen.sh' through the 'exec' protocol as mentioned in this post here. I'm just doing some research on exec, as I haven't used it before.

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: The Flash Sandbox.

For a completely standalone movie, here's what you can do, since such movies have privileged access to the device (or you can turn on full privileges for widgets, as documented in another thread):

Use the class documented here - notice there's a function called "_backtick" - this is similar to Perl's backtick operator in that it executes a shell command and returns the result.

It should *only* be used to run very fast (ie immediate return) commands, since it's blocking, and will cause Actionscript timeouts if it takes any significant amount of time.

In your case, you can use it to execute "guidgen.sh" to get the device GUID.

For things that take longer, you'd more likely use the "exec://" protocol in conjunction with an XML object - this is done asynchronously, but it's necessary that the other process exit at some point, at which time the onData/onLoad handlers for the XML object are called.

For attaching to processes that are running externally but do not quit or require interactivity with the player, you should use the pipes support.

Hope this helps!

Duane's Website