Impressive idea and implementation. I love that you're going for vi keybindings.
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).
Unless I have read this wrong cryp.sr uses Javascript to encrypt/decrypt data right?
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).
This is not correct, on a few fronts. It _is_ possible to secure data with just Javascript (with care), and "host proof" describes a design philosophy that has real meaning - Google the term, and look at excellent commercial projects like Clipperz (who use "zero knowledge" as a synonym for "host proof"). You can also read this post I wrote when I took my first skeptical look at the idea. It discusses how and why the host-proof idea could work, and finds some flaws in Clipperz and PassPack, the two most prominent "host-proof" commercial apps:
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.
Yes I understand your point; but it still comes down to trusting to server (which is fine, but it is something "host proof" doesn't really encourage IMO).
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.
Again, you should read more on this issue before you criticize the idea in absolute terms. Yes, verification is necessary, which is why I wrote a browser addon that can do hash-based verification of the application every time the page is loaded (described here: http://corte.si/posts/security/crypsr.html, with links to the github project), and which is why cryp.sr has application hashes published with every modification. Yes if you send your traffic unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and any other good host-proof app, uses SSL, which is designed to counter exactly that type of threat.
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 respect your opinion as much as anyone here. Still, I wish there was anything I could say to get a little of the negative tone off of your security advice sometimes. (You're much better than bad ivory tower security experts I've worked with over the past fifteen years, though.)
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.
I'm as wary of Javascript as anyone - in fact, your first sentence is practically a verbatim quote from my first post on the host-proof idea. However, I don't think that there needs to be a superstitious dread about this - it just means we have to think harder, work more carefully, and perhaps encourage some changes by browser creators in the longer term.
Browser changes can make things more convenient, but we have all the tools to create secure though somewhat cumbersome host-proof applications today. Yes, the Javascript environment sucks, but it's what we have - dismissing the possibility that we can do secure crypto with strictly controlled input, where all components are verified, is not reasonable and not backed up by evidence.
I think you should say "unproven" instead of "clunky". I don't know any paper that has been published on how to unambiguously verify JS content from a browser plugin.
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".
I welcome peer review, which is why I publish all this stuff, and why I repeatedly ask people to verify my code. If you've actually found a way to circumvent the apphash verification routine, I would be delighted to hear about it and would lovingly craft a fix immediately.
Why should anyone help you hop onto the endless cycle of "while (1) { find browser plugin evasion tactic; patch }" when it can be avoided entirely by taking a different approach? Especially when your claims of "host-proof security" don't mandate use of said plugin?
Send me a note once you hit a million downloads of the plugin. Perhaps you'll be more willing to listen then.
So... I'll take it that means you haven't discovered a way to circumvent the verification, and you're just being shrill for effect. Send me a note once you have - I'm always happy to receive constructive criticism.
Yes if you send your traffic unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and any other good host-proof app, uses SSL, which is designed to counter exactly that type of threat.
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?
To my (limited) knowlegde: you can modify the packets, but since they're encrypted, you shouldn't be able to change the transmitted data to your liking.
Unless you breach it somehow, you can only do denial-of-service, not a true man-in-the-middle.
No, all encryption modes in SSL also use some kind of integrity protection (MAC, usually). So SSL gets you privacy in that the message you send is encrypted and authentication in that only the endpoint could have transmitted that exact message.
You modify the packets of an SSL session and your data is discarded.
The idea is cool, and I like your additional list features. But the interface needs more alternate, intuitive ways of navigation compared to the vim keybindings (I don't use a terminal text editor). You can already click on an item to select it, but it would be nice if you could drag and drop the items, both up and down and left and right.
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.
This is really cool. I've thought about how a host-proof app might be built, but not very seriously. I actually have a pretty simple project coming up that'd benefit from it, too. Maybe this'll motivate me to experiment. Any resources/reading you'd suggest, or have you mostly been figuring this out on your own?
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.
Nice. I love the vim keybindings and markdown support.
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.
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).