Cryp.sr - the next step
corte.si
corte.si
Lots of possibilities. You could add a popup that comes in when user presses ':' to allow macros.
I'd prefer it if you went with 'a' being to edit the current line, and puts the cursor at the end; 'i' to edit line with cursor at beginning, and to use 'o' for add-new-line-after-current line; 'O' to add the line before.
If you could turn this into a powerful text editor that would be really neat.
Another thing that might be useful is an authentication mechanism that tries to proof against the most obvious internet-cafe afflications (keyboard grabbers, that sort of thing).
In which case "host proof" is really only a marketing term. This has been discussed a couple of times here in the past week or so (mostly by tpatcek) and, really, there is no way to effectively secure data just with Javascript.
These sorts of apps have some use - so long as users understand the flaws involved and trust the server owner (and their browser).
http://corte.si/posts/security/hostproof.html
I should note that Clipperz has now addressed all the points I raised in my post.
The "host-proof" idea has been around for a while, but is really just in its infancy. There's a lot of work to be done, but the idea is both important and promising.
The verification is all very well and good; but you have to either verify the code each time (a pain) or trust the server between the times you do review the code.
For most people reviewing the code is impractical.
We discussed all this before in great detail; I'll try to dig out the threads. But from a security perspective this sort of stuff has a use, but not for things you really must keep secure.
As a start: because the code of the app is sent "over the wire" with some regularity it is trivial to intercept and modify it.
The techniques are still clunky - but that's because it's very early days, and we're still developing the tools and techniques to make things seamless. The basic idea, however, is entirely sound, and increasingly important.
I'll admit up-front that I have only a cursory knowledge of security topics, but it was my understanding that SSL prevents the traffic from being read, but not from being modified. Am I incorrect in this belief?
Unless you breach it somehow, you can only do denial-of-service, not a true man-in-the-middle.
You modify the packets of an SSL session and your data is discarded.
I took a quick look at your code for this. I think you'd be more honest to say that the security of your plugin rests on the inability for an attacker to evade your regex. In particular, the functions apphash_hostile_check() and apphash_split() could leave a route for attackers to smuggle in hostile data without changing the hash.
This comment is troubling: // Do we need to check all frames // What happens if tab loads in background? Do we need to run this when tabs switch?
Also, using a hash instead of an HMAC leaves you open to length extension attacks.
More importantly: why leave a potential door open by taking on the hard MitM problem of parsing and hashing JS from your browser plugin in a way that is unambiguous with how the browser will render it? Instead, ship the encryption code in the plugin itself. Now a user who has downloaded a correct plugin one time has assurance that it won't be swapped out from under themselves for a trojan.
However, I'm guessing that would violate your actual business model which divides users' trust into two categories: unaware and unwarranted. The unaware will happily trust your claims of "host-proof security" and not use the plugin. The more technically informed will have unwarranted trust that the browser plugin is difficult to evade.
I expect that the latter problem is the "software obfuscation problem" combined with the "vantage point problem". That's not something you want to make your lynchpin of assurance.
I hope this convinces you to drop the misnomer of "host-proof security".
Send me a note once you hit a million downloads of the plugin. Perhaps you'll be more willing to listen then.
Start with content-controlled code, which you somehow have to memorize and reverify before you run.
Now load that code through the HTML DOM, which allows Javascript to be run based on tags and attributes littered throughout markup.
Now consider that you're working in a language that allows virtually any operation to be transparently overridden.
"Clunky" and "very early days" are not words that harmonize well with "basic idea is entirely sound". The basic idea simply isn't sound.
I really, really like engineers trying as hard as they can at hard problems. Give them a dose of the dangers involved, absolutely-- but why discourage someone with "scrap it" language who is absolutely trying to give it their best possible shot? I want MUCH more of that, rather than discouraging one project because some host, somewhere MIGHT misuse this to commit fraud. There's real value to the world if companies/governments/sites work really hard on this problem. Even if they don't get it 100% right, we can all benefit just from the philosophy of this approach even if the technology has corner cases.
Not a perfect analogy or a refutation below, but I want to remind readers that there are millions of real world problems that are hard and hairy, yet can still be sound:
# There is no less hospitable environment to man than outer space.
# Start with the vacuum, for which you need an airtight container, large enough to contain men and equipment with no possible way for air to escape into space and leave you dead.
# Now launch that container into space, accelerating all the way up to escape velocity, which puts incredible pressures on the craft through the entire trip, risking integrity the whole way.
# Now consider that you're working with some of the most explosive/flammable substances just to get your container into the air.
# "Clunky" and "very early days" are not words that harmonize with with "basic idea is entirely sound". The basic idea simply isn't sound.
Actually, I think all the interface features I suggest would just be in OmniOutliner (http://www.omnigroup.com/products/omnioutliner/) – just try out OmniOutliner if you can and note the interface. The most relevant keyboard shortcuts: Command-Shift-{ and } for creating a new parent-sibling or child, Esc for toggling between selecting the list item and editing it, left and right for collapsing and expanding items. There might be features in its menus and inspectors that would be useful, too.
Also, a toggle-able help toolbar might be nice. It would display the key bindings in the ? help box along with their descriptions, and they would be clickable links. This would make it easier for new users to learn the key bindings.
I was unable to bring up the help modal box when pressing '?'. The only way to get to it was to use my mouse to press the question mark link at the top right.
This seems an odd place for this sort of feedback, but I saw no other avenue.
I just noticed that cryp.sr had made it to HN - I'll check here for bug reports, or you can just email me at aldo@corte.si.
Firefox 3.6.3 on Mac OSX 10.5.8
All the other keybindings worked fine.
edit Ah, I see you've written a bit on it yourself (http://corte.si/posts/security/hostproof.html). Time to go exploring!
As far as the actual app goes, I have only one real gripe. Being used to Vim, I expect i to add before and a to add after (with I adding at the beginning, and A at the end). Not having i/I do anything confused me for a moment.
anyways, it's super cool to see this expand into a really useful webapp. keep going!