If you're interested in working with graphics or sounds, I'd recommend checking out openFrameworks, which bills itself as a "creative coding toolkit". https://openframeworks.cc
As a programming instructor the Eve demo video gave me goosebumps. The emphasis on prose+code, world=data, and the discoverability afforded by the inspector are of particular interest to me.
Our current learning stack for folks with zero coding experience is Scratch (https://scratch.mit.edu) to Processing (https://processing.org) to Java.* I'll be watching the Eve project carefully to see how it might fit into our intro to programming path.
*If these intro students continue to our full program they learn C#, SQL, PHP & JS/HTML too.
Your curricular path sounds similar to the one we use at The Coding Space (https://thecodingspace.com). Might I suggest Woof (http://woofjs.com) as alternative JavaScript graphics framework to transition students from Scratch to text based programming?
My understanding is that even with their web login process your password isn't sent to their servers in plaintext. From the comments on their heartbleed blog post: "We only use one-way salted hashes (after going through PBKDF2 rounds) to send to the server for authentication."
So their servers get a hashed version of your password, but not the password itself. Their servers likely also store a hashed version of your password so that they can authenticate you. This style of auth is also used when you use the "show me the password" feature.
This cannot be. Your passwords (the ones you are trying to protect) must be encrypted using your master password. LastPass needs to decrypt them somewhere using your master password. What you are describing is how their browser extension seems to work. However, their website does not require the extension to work. So either they implement security in JavaScript that's running within the page (cannot by definition be done securely), or they store all your passwords in a way that they can decrypt them (invalidates the use case for LastPass).
We implement everything in JavaScript on that page if you're trying to login from the website -- which is as secure as that page load -- LastPass recommends people utilize the extensions to mitigate this risk.
Our choice could be to not allow people to utilize the website but it seems like educating people of the risks and letting them decide is the best policy.
Very happy to get a reply from someone from LastPass!
So then what would prevent someone from using the Heartbleed attack to obtain your private key that use used to secure the HTTPS connection from me to your servers, then inject malicious JavaScript into the page where I enter my password? This is the attack I am worried about outside of Heartbleed as well, since any CA can issue a valid certificate for lastpass.com and I would not know that I am being MITM'ed.
From a strict security point of view, disabling website access seems like the best policy. From a usability standpoint, I understand the tradeoff you made. Perhaps an option at the account level that disabled website access might be a good idea.
Also, how are the share/give functions handled? I know what "share" is not really keeping my password from being seen by the other person (there are a variety of techniques they can use to get at it), but how is the encryption handled on your end?
Lastly, how do I know that the browser extension I download from you is secure? Is there a way for me to verify it somehow?
Having said all that, I absolutely love your product and recommend it to everyone I know. It's a huge net win in terms of security.
I'm not sure that "the universe as Turing machine" is anything more than a theory. The universe can contain Turing machines -- we're both using one right now -- but I don't think we can say for certain that the universe is one.
Also, not everything is computable. Alan Turing proved this in his paper "On Computable Numbers, with an Application to the Entscheidungsproblem." The Halting Problem is a related example of the limits of computation.
A quick look at the MobiRuby example code worries me. It looks like Objective-C, but awkwardly written using Ruby syntax. In other words, it looks more like an Objective-C wrapper, than a Ruby DSL for writing iPhone apps.
However, with plans to port the system to Android, perhaps a unified DSL could be built to target both platforms.
Like some others have said, the Turing Test is more a human mimicry test than a test of intelligence or consciousness. We humans love to anthropomorphize, so tricking us into believing a machine is human shouldn't be how we gauge the effectiveness of our AI.
I ran across these "Fundamental Principles of Cognition" that might do a better job:
For a taste of what is possible with openFramworks, take a peek at this youtube series by Lewis Lepton: https://www.youtube.com/watch?v=dwt2NAd1ZYY&list=PL4neAtv21W...