Similar, but arguably less complicated. Just a link, and executes a browser in 
a remote session, you do what you do, and then close the session and the 
session expires.  I'm not wedded to the idea. But I'm trying to figure out a 
way to use all this excess datacenter capacity.

Alex Eckelberry 
www.eckelberry.com
727-644-8830

Sent from my iPhone 
There will be typos 

> On Jun 10, 2014, at 10:55 AM, "Rod Trent" <[email protected]> wrote:
> 
> Sounds a bit like Spoon…
>  
> http://spoon.net/
>  
> From: [email protected] [mailto:[email protected]] 
> On Behalf Of Alex Eckelberry
> Sent: Tuesday, June 10, 2014 10:46 AM
> To: [email protected]
> Subject: [NTSysADM] a "secure browser"
>  
> To the list,
>  
> I've been noodling an idea for a while and I was curious what your thoughts 
> might be on this.  Feel free to shoot holes, I’m still working it out.
>  
> At one of the companies I'm involved with, Runaware, we have massive excess 
> datacenter capacity, with large Citrix farms hosting software demos (our 
> primary business).
>  
> Recently, a large corporate client came to us and asked us to create a 
> special Citrix instance for them, allowing their people to safely surf the 
> web, do web conferences, etc. through our datacenters.  We installed a web 
> filter for them, set them up and they are happy.  This is all done through 
> HTML 5, so it's seamless.  It’s basically a sandboxed session – once the 
> session is over, it’s over.
>  
> Which brings me to my idea -- a "secure browser".  This is a shortcut to a 
> browser that would launch in our Citrix datacenter, running everything 
> safely, outside of the firewall.  An admin would deploy this secure browser 
> link onto user desktops.  Users would be instructed to use the secure browser 
> for external surfing.  
>  
> It doesn't require the Citrix plug-in, since we use HTML 5.  So to the user, 
> it's seamless, not requiring any downloads, etc.  (we could use RDP but it's 
> just not fast enough for graphics and other complex apps).
>  
> Thoughts?
>  
> Alex Eckelberry
>  
>  
>  

Reply via email to