The security doesn't, but availability might: the relay is very easy to DoS (not even DDoS!). This is the one thing that I think Thomas has jumped the gun on with his recommendation: the current protocol and infrastructure won't survive a DoS attack, which is tragically likely if magic-wormhole's popularity increases. Brian Warner is aware of this and has written about it.
I noticed the same issue as Joey Hess, except a couple of years later; then when I was giving a magic-wormhole demo, some of the audience members accidentally broke some of my live transfers in various ways.
(Otherwise, I feel just as gleeful as Thomas does. It's an awesome tool and fun to use!)
Thank you for writing this book! I recently used this book to brush up on crypto fundamentals for some interviews and found it really valuable. I was even able to implement a padding oracle attack after only knowing it in theory for a very long time. I was also wondering if you had any plans to complete. Right now, there are 36 TODO's in the book. Not all of them need further explanation and can be left as an exercise but some of them might be useful to dig into. Regardless, it is still awesome!
It's not entirely unreasonable. We use software because it's useful. If you make it so secure that it is no longer useful, what have you got left?
In the case of Firefox extensions, I'm aware of the risks of the old model, but the fact is that the only observable difference it has made to me so far is that when I accidentally hit back on a page with an unsubmitted form the other day I lost about 20 minutes' worth of work, because the extension I used to use that would have saved everything automatically no longer works. This is not progress.
Lazarus: Form Recovery hasn't been maintained in years. But I don't think there's anything about it that can't be done with web extensions. There's already one that has the base functionality: https://addons.mozilla.org/en-US/firefox/addon/textarea-cach...
With the appropriate extension this can be made seemless. Hit a hotkey get an emacs buffer with the current contents of input box. Write some stuff and save and quit. Input box now contains contents of emacs buffer. Annoyingly this requires a service that sits in the background in chrome because security wont let chrome launch such a process. In chrome you can use text-aid-too. Pentadactyl/vimperator can do it with firefox and others.
My earlier mistake was clicking to focus on my Firefox window but not quite on the form text area I was aiming for, and then trying to delete the last word I had typed. Your tip would have saved me on that occasion.
The idea that the XUL extension model is necessary for a browser to be useful is obviously false. The majority of Web users use browsers that do not have a XUL extension model.
(And, of course, I don't believe your desired functionality is incompatible with Web Extensions anyhow.)
That was the practical result of the change we're talking about for this user, regardless of any theoretical benefits elsewhere or any theoretical ability to provide equivalent functionality within the new architecture.
Other people are welcome to use other browsers, but I was using Firefox, and a big reason I was still using Firefox despite various other changes I didn't particularly want was the range of useful extensions I could choose from.
I guess you would lose some of your remaining market share to chrome and wonder how much smaller your revenue is going to be when the yahoo deal expires?
> I guess you would lose some of your remaining market share to chrome
So, you're saying that:
- some people kept using Firefox because it had more powerful extensions than Google Chrome.
- these people are upset because mozilla is breaking the old extensions in favor of a less powerful alternative (still better than Chrome's, that the main point of the OP)
- then people are going to move to Google Chrome which still is the worst browser for extensions
Who reasons this way ? There are legitimate reasons for being upset (my favorite addon disapeared and that makes me sad / I need to rewrite all my addons, depending if you're a user or an addon dev), but I don't think anyone will shoot himself in the foot and use a worse (addon-wise at least) alternative just because mozilla's people are mean !
The idea is for extensions to have the flexibility they have had. I don't think anyone would object to WebExtensions if it didn't cripple or make existing extensions impossible to exist in the future.
Also, this interest is not about the majority of the users. This is about the users who know about Firefox extensions and use a bunch of them everyday! I know my life has certainly become more productive and less stressful with several extensions than without. In my experience, Firefox extensions have also historically been of better quality and reliability compared to Chrome extensions. For now, I have just two examples for my case - switching proxy servers and saving/restoring browser sessions. I use Firefox extensions that work beautifully, and just as one would expect (they're Foxy Proxy and Session Manager), but similar extensions in Chrome don't work and I always end up fighting more with the browser and the extensions to have a better experience. To this day, I can't trust Chrome to restore a crashed session on the first (re)launch. So I use Chrome more as a one-off browser once in a while and try to avoid having long running sessions (my browser sessions on Firefox can span several days, weeks or sometimes even months).
My opinion is that technically savvy people must use their knowledge and influence to guide others to use things that make life easier and better. I have been following this myself by encouraging people to use Firefox and by showing them some great extensions to have.
The majority of Web users use browsers that do not have a XUL extension model
And the majority of these users may have no idea what an extension is either. That doesn't mean all browsers should be dumbed down to cater to the lowest-common-denominator who will manage to infect themselves regardless of how featureless and "secure" browsers become.
> The idea that the XUL extension model is necessary for a browser to be useful is obviously false. The majority of Web users use browsers that do not have a XUL extension model.
I explicitly preferred Firefox over every other browser I ever tried because its extensions were more powerful and more abundant, and it appears likely that this was due to XUL providing deep access to extensions. You can't just say that others didn't have a feature if that feature was a key differentiator!
I'd like better permissions, but not at the cost of a more flexible, customisable browser than chrome. There should be reasons to use firefox above and beyond muscle memory.
This would help all the individuals who have inadvertently installed malware addons which do not have pwned systems as soon as there are any, if there are ever any.
Count the instances of "arbitrary code execution" for chrome vs adobe. Its a huge improvement! Granted its not just the pdf reader in the case of adobe.
One of the constraints I am working with is that a human is not necessarily in the loop all the time. What is the best way then bootstrap the encryption process?
You basically don't. You're adding a lot of complexity chasing after a very marginal (say, 5%†) fraction of the security application-layer crypto gets you.
You can get that fraction closer to 50% without a human in the loop by segregating your crypto code from the application in a virtual HSM, using something like a TLS client certificate to authenticate your application to the HSM, have humans in the loop for restarts/bringups of the HSM itself, and doing pretty aggressive monitoring on the request patterns between the app and the HSM.
The threat model here is that someone owns up your app server --- if that wasn't in your model, you wouldn't need application layer crypto. The idea is that owning up the app server will get an attacker enough access to make requests to the HSM, but not control of the HSM itself. If the HSM can detect abnormal volume of requests, you can use it as a circuit breaker to prevent bulk exfiltration of your secure data. You also get accountability, so that when your server is compromised you might know exactly what records were accessed.
Typically, the app server itself will handle all of the database operations, and the virtual HSM just provides a "seal" and "unseal" operation --- convert plaintext to ciphertext, convert ciphertext to plaintext.
† The 5% you're getting in the dumb online crypto scenario is that if you store the root crypto secrets in a file, an attacker can't necessarily recover it from an SQL injection attack --- but in reality the percentage is probably lower, since most of the time SQLI will equate to RCE.
Thanks for the response. Although not ideal, I am stuck with using crypto at the DB level. Based on what you said; running something like vault (running as a separate user from the DB) and accessing it using the HTTP API + TLS client cert seems like the way to go.
Along similar lines, I wonder if this fuzzer can be used to bruteforce passwords for applications. Would it do any better than standard "try all the combinations" method?
