The executing process belongs to you - you should allow it no secrets in its basic running.
First thing in any lang: learn the tools available for debugging and quickly opening library code to trace execution. Set breakpoints; dive into stack traces.
In addition to giving security professionals tools to see how vulnerable their infrastructure is to real-world attacks, releasing exploits like this actually creates significant pressure for vendors to patch vulnerable software.
Take the recent Java 1.7 vuln (3 weeks or so ago). Oracle released a patch 4 days after that exploit was rolled into Metasploit. I'm sure they'll tell you that's a coincidence, but it's still nice to see happen completely out-of-band from their normal patch process. Word around the campfire is that Oracle knew of that vuln for months w/out a patch. Then along comes big bad Metasploit and you've got a patch for everyone on Java 1.7. I call that a win.
Yeah fair point that this exploit gives privs @ the level of the browser's current user. In that parenthetical, I was basically trying to explain what "session" means in Metasploit parlance in general.
He's running a web server process w/ Metasploit, configured to serve/run the exploit module. Then he issues a GET request to the server w/ the affected browser and gets a session in Metasploit (framework). The screenshots are basically proof showing that the session (connection to compromised machine w/ high-level/root access) has been created.