443 karma · joined April 19, 2008
I work on Jump Desktop. Glad you're using it. If you have any questions / suggestions - please let me know.
For building a REST API
1 - http://gulfnews.com/news/uae/crime/using-vpns-what-uae-resid...
Edit: 24:30 is around the point he mentions it.
Unfortunately it looks like VPC ELBs are still IPv4 only. They have a link in the article from when they introduced IPv6 for non-VPC ELBs back in 2011. Are VPC ELBs being worked on anymore or are we going to have to move to Application Load Balancers for IPv6 support?
For usermode problems WER would do a first level analysis on the client by looking at the crashing thread's exception record (1) or in the case of a user mode hang it would do something much more sophisticated called wait chain traversal (2). It would then generate a signature for the issue and report it to the backend via a single (and cheap) http/https request. The backend would then increment a count for that particular signature and if needed, would ask the client for more information about the issue. Among other things it could ask the client to capture a dump of the crashing process and even a multiprocess dump in the case of hang that involved multiple processes (process A waiting for process B waiting for process C etc). The client would do the necessary collection, prompt the user if necessary (depending on the user's consent settings) and eventually send it off. The 2nd level collection was configurable via a internal web portal - teams could look up their top signatures and request for more information about it. They'd eventually get notified once the extra information was collected - for high frequency issues, the turnaround was very quick.
Kernel mode issues aka bluescreens were treated slightly differently. The client wasn't able to do first-level analysis on kernel mode crashes. Instead it would always send at atleast a minidump of the bluescreen to a backend service where a pool of servers would run the !analyze windbg extension in realtime on the minidump.
(1) https://msdn.microsoft.com/en-us/library/aa260334(v=vs.60).a... (2) https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
Another way we protect hosts is by not allowing random hosts and clients to communicate with each other unless you've given explicit permission to each host/client. This means that Bob can't load up the Jump Desktop client and try to randomly brute force Alice's local account password by trying to connect repeatedly. The cloud server will drop Bob's connection requests to Alice unless Alice has explicitly given Bob permission to connect.
The above applies to our zero setup app, Jump Desktop Connect. Jump Desktop is also a full blown RDP and VNC client (with SSH support) - so you don't really have to use the Jump Desktop Connect app if you don't want to. You can use traditional RDP / VNC-over-SSH to establish secure connections as well.
If you have any questions about security feel free to ask.
Jump Desktop RDP & VNC for iOS: $15 -> $10: https://itunes.apple.com/us/app/jump-desktop-remote-desktop/...
Jump Desktop RDP & VNC for Mac: $30 -> $15: https://itunes.apple.com/us/app/jump-desktop-remote-desktop/...
From the docs it looks like Deis reuqires an advanced Ops person to manage a cluster of Deis machines.