Lavaboom: Zero-Access Encrypted Email Service Hosted in Germany(techcrunch.com)
techcrunch.com
Lavaboom: Zero-Access Encrypted Email Service Hosted in Germany
http://techcrunch.com/2015/05/15/lavaboom-is-another-zero-access-encrypted-email-service-hosted-in-germany/
45 comments
What exactly does "Zero-Access" mean?
Probably something like this http://zeroknowledgeprivacy.org/
Yeah, a made-up term that was ripped off from http://en.wikipedia.org/wiki/Zero-knowledge_proof because it sounded high-tech, yet has nothing to do with ZKP and merely means "you encrypt everything client-side and we store binary blobs on the server for you".
I see so this works similar to how blockchain.info site works in the browser, with the server used for encrypted backups and to retrieve blockchain data.
Thanks for answering
Thanks for answering
We actually based the Lavaboom Sync functionality on blockchain.info's model - the private keys are encrypted using user's plaintext password, while the client only sends the password's hash to the server during authentication.
As glibgil says, it's called Zero Knowledge and it means we can't access your data because it's encrypted client-side. It was a no-brainer, since we already have your public key.
We make key management easier by offering the option to enable Lavaboom Sync, basically your public and (encrypted) private keys stay on our server and get downloaded on login.
We make key management easier by offering the option to enable Lavaboom Sync, basically your public and (encrypted) private keys stay on our server and get downloaded on login.
What's the point if email's still plaintext in transit?
Here's how Lavaboom works. I hope this will alleviate your worries about emails being sent as plaintext (for PGP users).
1. [email protected] sends an email to [email protected]
Alice already has a keypair (generated automatically at registration), and Bob has one too. Alice adds Bob as a contact (or does nothing and is matched to Bob's key from a public key server), and sends him an email. The email contents + metadata is encrypted before they leave the Lavaboom email client, and are encrypted all the way to Bob. If Bob uses an email client with PGP support, then he can decrypt the email.
2. [email protected] sends and email to [email protected]
Same scenario as above, except that key exchange is done automatically for Lavaboom users (and emails don't leave our servers, making the process even more secure).
3. [email protected] sends and email to [email protected]
Carla doesn't use PGP, so Alice's email needs to be sent as plaintext. However, before storing the email to the database, it is encrypted with Alice's key, and the plaintext version (residing in RAM) is deleted as soon as the mailer reports successful delivery. This way, only Alice has access to her data, and Lavaboom is Zero Knowledge in respect to email contents.
1. [email protected] sends an email to [email protected]
Alice already has a keypair (generated automatically at registration), and Bob has one too. Alice adds Bob as a contact (or does nothing and is matched to Bob's key from a public key server), and sends him an email. The email contents + metadata is encrypted before they leave the Lavaboom email client, and are encrypted all the way to Bob. If Bob uses an email client with PGP support, then he can decrypt the email.
2. [email protected] sends and email to [email protected]
Same scenario as above, except that key exchange is done automatically for Lavaboom users (and emails don't leave our servers, making the process even more secure).
3. [email protected] sends and email to [email protected]
Carla doesn't use PGP, so Alice's email needs to be sent as plaintext. However, before storing the email to the database, it is encrypted with Alice's key, and the plaintext version (residing in RAM) is deleted as soon as the mailer reports successful delivery. This way, only Alice has access to her data, and Lavaboom is Zero Knowledge in respect to email contents.
This is a reasonable approach, but there's a weak link in public key exchange. If Lavaboom (or any other trusted third-party) is facilitating public key exchange, there's nothing preventing them from saying "DE:AD:BE:EF" is Bob's public key when in fact it belongs to Eve the attacker. Not to say that Lavaboom would do this maliciously, but they might be compelled to do so by a state actor or law enforcement.
As a rule of thumb, a messaging system S can only be zero-knowledge if you have exchanged a secret or key with someone else outside of system S. See the HN discussion on iMessage: https://news.ycombinator.com/item?id=7315964
As a rule of thumb, a messaging system S can only be zero-knowledge if you have exchanged a secret or key with someone else outside of system S. See the HN discussion on iMessage: https://news.ycombinator.com/item?id=7315964
We plan to improve it in the nearest future. Yesterday I started work on support for message signing, the server part should be ready next week. Later we'll add support for fetching keys from external exchanges (such as pgp.mit.edu).
> Alice's email needs to be sent as plaintext
Thanks for your explanation! Though in your hypothetical Carla uses Gmail, and Google supports SMTP TLS. So the email would be encrypted in transit to Google's servers.
The problem, which the previous poster may be alluding to, is when a lavaboom user emails a non-PGP user with an account at an email provider that fails to support SMTP TLS. When I wrote about this for CNET two years ago, Hotmail, Yahoo, and AOL did not support it: http://www.cnet.com/news/how-web-mail-providers-leave-door-o...
Now it looks like all three of those companies do, so the question is: Which providers still fail to, two years post-Snowden disclosures?
Thanks for your explanation! Though in your hypothetical Carla uses Gmail, and Google supports SMTP TLS. So the email would be encrypted in transit to Google's servers.
The problem, which the previous poster may be alluding to, is when a lavaboom user emails a non-PGP user with an account at an email provider that fails to support SMTP TLS. When I wrote about this for CNET two years ago, Hotmail, Yahoo, and AOL did not support it: http://www.cnet.com/news/how-web-mail-providers-leave-door-o...
Now it looks like all three of those companies do, so the question is: Which providers still fail to, two years post-Snowden disclosures?
TLS transport is nice to have, but some people can work around it. [0] That's why I only considered PGP, but you're right, SMTP TLS is important. We've also been toying with SMTorP. [1]
0: http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%2...
1: https://github.com/mailpile/Mailpile/wiki/SMTorP
0: http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%2...
1: https://github.com/mailpile/Mailpile/wiki/SMTorP
Just pointing out that 3) isn't really a meaningful guarantee, as you can keep a copy of the session key. I'm not saying that you do, just saying that there's no way to verify either way.
I don't think this detracts from your service in a meaningful way, though.
Do you support clear-signing and/or choosing to send in the clear? (I'm asking mostly out of curiosity, but from a security perspective it can be important in order to be able to send deniably (eg: no, wasn't me that sent that file to a journalist -- look, it's a plain email, anyone could've sent it...)).
I don't think this detracts from your service in a meaningful way, though.
Do you support clear-signing and/or choosing to send in the clear? (I'm asking mostly out of curiosity, but from a security perspective it can be important in order to be able to send deniably (eg: no, wasn't me that sent that file to a journalist -- look, it's a plain email, anyone could've sent it...)).
All encryption is done clientside, all we see are armored PGP messages.
Cleartext signing isn't supported right now, but it's in our issue tracker and I believe that it should be implemented during the next few weeks.
Cleartext signing isn't supported right now, but it's in our issue tracker and I believe that it should be implemented during the next few weeks.
> All encryption is done clientside, all we see are armored PGP messages.
Are you saying 3) above is wrong? Or are you saying that the client, when sending a plain-text message, first encrypts that message, and stores it on your servers, and then sends the email directly? Because that is the only way you can guarantee that you don't have a means to access a copy of the email that is sent un-encrypted.
I understand that when sending encrypted emails (which I gather is your current main focus), the email is encrypted by the client before it is sent on to you.
Another question: how well does this all interop with traditional email+gpg? Would it take a lot of effort to use your service with something like mutt?
Without looking at the client code, I'm guessing client-server is all http(s)? So in order to make a non-browser client one would have to wrap the client-server communication some how (eg: sync mail from server to disk, and set up a binary("sendmail"), or smtp proxy for sending mail)?
Are you saying 3) above is wrong? Or are you saying that the client, when sending a plain-text message, first encrypts that message, and stores it on your servers, and then sends the email directly? Because that is the only way you can guarantee that you don't have a means to access a copy of the email that is sent un-encrypted.
I understand that when sending encrypted emails (which I gather is your current main focus), the email is encrypted by the client before it is sent on to you.
Another question: how well does this all interop with traditional email+gpg? Would it take a lot of effort to use your service with something like mutt?
Without looking at the client code, I'm guessing client-server is all http(s)? So in order to make a non-browser client one would have to wrap the client-server communication some how (eg: sync mail from server to disk, and set up a binary("sendmail"), or smtp proxy for sending mail)?
Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plaintext we see for a short amount of time, but we get rid of it as soon as we send it out to a remote server.
Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing.
Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot.
If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)
Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing.
Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot.
If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)
Thank you for the link -- I suppose it should've been obvious you'll have some use for command line tools internally, if only for automation (but automation is important, how else can my backup cron job let me know it's completed/failed? :-)
Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...).
As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful.
Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it).
That's not to say I'm not interested to see where you end up, and wish you all the best with your project!
Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...).
As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful.
Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it).
That's not to say I'm not interested to see where you end up, and wish you all the best with your project!
On Firefox 37.0.2 I got "Initialization failed" quickly after
the "Authenticating" step.
Also, I guess that wrecked my invitation code …
Waiting for this to mature ;)
Waiting for this to mature ;)
No problem, hit us up on [email protected] for another invite code. That sounds bad, could you please describe your issue on http://web.lava.wtf ? Screenshots and console logs are appreciated!
I can try to incentivise you to submit a bug report by promising an extra invite code once you submit an issue. :) (Just link this comment when you email [email protected])
I can try to incentivise you to submit a bug report by promising an extra invite code once you submit an issue. :) (Just link this comment when you email [email protected])
[deleted]
When I enter my info to reserve a username I never actually get the email with details the page mentions :(. Is this broken right now?
Oops, it seems that someone broke the reservations during a website update - adding that to my TODO list.
Thanks for the reply, that it may take a while to receive the mail is probably useful information to throw on the reservations page until it's fixed if you expect that to take a while. Just a thought.
Why is this any better than protonmail.ch?
1) First of all, Lavaboom is fully opensource - ALL of our sourcecode is published on GitHub, so with enough efford you could download every piece of our setup and run it on your own server.
2) We support true end to end email encryption (it's not perfect, but a lot better than encrypting emails using some password in ProtonMail). Also you can manage all of your keys yourself if you wish, or keep your keychain encrypted on our server, just like in ProtonMail.
3) I'm definetely biased, but our stack is far better - ProtonMail uses PHP, which has a questionable reputation, meanwhile we use a static-typed language in the backend (Go).
4) Lavaboom is designed with hosted installations in mind - as soon as we sort out all the basic functionality of the "public version" (ie. hosted on lavaboom.com), we will start work on a self-hosted version which will make running it locally a lot easier - even on a Raspberry Pi :)
5) You can check all of our claims in the source code - we have nothing to hide!
5) Lavaboom to other providers emails use asymetric encryption. ProtonMail on the other hand... http://security.stackexchange.com/questions/58541/how-are-pr... :)
I might have repeated some points, but generally Lavaboom is a far more advanced product, which is in early stages on development. Right now I wouldn't recommend using Lavaboom for casual emailing, but I think that we will have all of ProtonMail's functionality during next two to three months and by the end of the year we should have a stable product with far more functionality for truly privacy conscious people.
2) We support true end to end email encryption (it's not perfect, but a lot better than encrypting emails using some password in ProtonMail). Also you can manage all of your keys yourself if you wish, or keep your keychain encrypted on our server, just like in ProtonMail.
3) I'm definetely biased, but our stack is far better - ProtonMail uses PHP, which has a questionable reputation, meanwhile we use a static-typed language in the backend (Go).
4) Lavaboom is designed with hosted installations in mind - as soon as we sort out all the basic functionality of the "public version" (ie. hosted on lavaboom.com), we will start work on a self-hosted version which will make running it locally a lot easier - even on a Raspberry Pi :)
5) You can check all of our claims in the source code - we have nothing to hide!
5) Lavaboom to other providers emails use asymetric encryption. ProtonMail on the other hand... http://security.stackexchange.com/questions/58541/how-are-pr... :)
I might have repeated some points, but generally Lavaboom is a far more advanced product, which is in early stages on development. Right now I wouldn't recommend using Lavaboom for casual emailing, but I think that we will have all of ProtonMail's functionality during next two to three months and by the end of the year we should have a stable product with far more functionality for truly privacy conscious people.
ProtonMail also isn't encrypting with a password, it's fully OpenPGP compliant using full length RSA keys. Also, how do we know Lavaboom is going to be around and stable? ProtonMail is financed by the Swiss government and developed at CERN.
Lavaboom dev here, I'm happy to take questions. We're open source, mostly Angular and Go based: https://github.com/lavab
edit: just to point out, we're running a Indiegogo campaign! https://www.indiegogo.com/projects/lavaboom
edit: just to point out, we're running a Indiegogo campaign! https://www.indiegogo.com/projects/lavaboom
"We use JavaScript. All encryption happens on your browser"
How do you prevent the scenario of being forced to provide a poisoned client-side encryption payload, just like e.g. Hushmail was?
How do you prevent the scenario of being forced to provide a poisoned client-side encryption payload, just like e.g. Hushmail was?
1. Our code is public. https://github.com/lavab
2. We'll have Chrome/Firefox extensions for something similar to "signed binaries"
3. We offer the option to run the web client yourself (git clone https://github.com/lavab/web && cd web && npm install && gulp && open "http://localhost:5000")
4. We'll build native desktop and mobile clients.
Hope this answers your question.
2. We'll have Chrome/Firefox extensions for something similar to "signed binaries"
3. We offer the option to run the web client yourself (git clone https://github.com/lavab/web && cd web && npm install && gulp && open "http://localhost:5000")
4. We'll build native desktop and mobile clients.
Hope this answers your question.
Native, or client-hosted javascript sounds workable. Server hosted Javascript cannot be secure even in theory (without a client-side plugin). I gave up on this problem when I shuttered Harpo Mail because of this and I am a US Citizen and realized I can't legally or ethically claim I won't turn you over to the Feds if they hold a gun to my head. It sounds like you are addressing those issues and more, and I wish you success.
Thank you! :) Our servers and us are also based in Germany, which is a plus.
How is it a plus that they're hosted in Germany? The German spy service are on record spying for the NSA, and of course only German citizens are protected by German law, so if anything, for users from the US, being hosted in Germany should be even worse than being hosted in the US (Assuming, the current slow, blow-back against the NSA goes anywhere).
I don't really understand this fascination with hosting things outside of the US "for security" (from apparently, mostly US citizens). Personally I'm in Norway, where the secret police have been spying on "dissidents" (it used to be the "far" left, nominally the neo-nazis/fascists (although they missed the only terror attack, despite having a tip before the fact) -- now it's the "radical" Muslims (you know, a clearly defined threat to national security, aka "brown scary people")).
But regardless of how one feels about using Stasi methods to help perpetuate and sustain illegal wars on the middle east -- one thing should be abundantly clear: Nowhere (AFAIK) does foreign citizens have any rights to not be spied on by local intelligence services. And of course all of NATO is working together on gathering it (along with Sweden, which Norwegian intelligence reportedly work closely with).
All that said, while I think we should all work at taking back our respective governments, and strive for a better (more free) political environment -- I don't think the only measure for an email service should be "am I now safe from state-sponsored actors". In fact, I think that should actually be pretty low on the list.
Use gpg, or give up. More significantly, if you can't do the work for a proper web-of-trust/key distribution and verification, you can't be secure (in the sense indicated above).
I still think services like these are miles better than you-are-the-product, like gmail/outlook.com etc.
Good luck on your service!
I don't really understand this fascination with hosting things outside of the US "for security" (from apparently, mostly US citizens). Personally I'm in Norway, where the secret police have been spying on "dissidents" (it used to be the "far" left, nominally the neo-nazis/fascists (although they missed the only terror attack, despite having a tip before the fact) -- now it's the "radical" Muslims (you know, a clearly defined threat to national security, aka "brown scary people")).
But regardless of how one feels about using Stasi methods to help perpetuate and sustain illegal wars on the middle east -- one thing should be abundantly clear: Nowhere (AFAIK) does foreign citizens have any rights to not be spied on by local intelligence services. And of course all of NATO is working together on gathering it (along with Sweden, which Norwegian intelligence reportedly work closely with).
All that said, while I think we should all work at taking back our respective governments, and strive for a better (more free) political environment -- I don't think the only measure for an email service should be "am I now safe from state-sponsored actors". In fact, I think that should actually be pretty low on the list.
Use gpg, or give up. More significantly, if you can't do the work for a proper web-of-trust/key distribution and verification, you can't be secure (in the sense indicated above).
I still think services like these are miles better than you-are-the-product, like gmail/outlook.com etc.
Good luck on your service!
There's a difference between spying on something and forcing you to do something. I think the idea is there's no "Patriot Act" and National Security Letters in Germany to force providers to introduce backdoors.
The "NSA can spy on you argument" doesn't really apply here. You just try to provide solid security against that. Having poor security in "America" wouldn't save you from NSA anyway.
The "NSA can spy on you argument" doesn't really apply here. You just try to provide solid security against that. Having poor security in "America" wouldn't save you from NSA anyway.
I don't think it's realistic to expect that a provider can't be forced to facilitate secret wire-tapping in any jurisdiction (Nor do I think that is really desirable). Wasn't the (relatively) recent child-porn ring bust an operation involving lots of jurisdictions?
I also don't think Germany will be a safe haven for someone working against the drone program if that involves leaking classified information (otherwise known as espionage, even if it stems from altruistic motives).
I feel people are as much in denial about the likelihood of spying by European governments, as many were about the NSA (and for no better reason -- the NSA was documented to break the law long before Snowden, and so have various European governments).
I don't really see this as much of a win either way. But perhaps it's good marketing copy.
I also don't think Germany will be a safe haven for someone working against the drone program if that involves leaking classified information (otherwise known as espionage, even if it stems from altruistic motives).
I feel people are as much in denial about the likelihood of spying by European governments, as many were about the NSA (and for no better reason -- the NSA was documented to break the law long before Snowden, and so have various European governments).
I don't really see this as much of a win either way. But perhaps it's good marketing copy.
From what I've been told, it's significantly harder to confiscate servers in Germany - but even if that somehow happens, all they would find on our servers is a bunch of encrypted blobs.
As I've recently discovered[1], there appears to be ample room for a good xmpp service as well as for email. Any plans to host a jabber service? If you manage to handle distribution of gpg-keys, that'd be a way to bootstrap distribution/verification of OTR identities as well...
[1] https://news.ycombinator.com/item?id=9546145
[1] https://news.ycombinator.com/item?id=9546145
We plan to build chat into Lavaboom, but we haven't figured out yet what's the best way to do it (and it's a _way_ long ahead, anyway). What you're saying makes a lot of sense and is definitely a possibility.
What is your reaction to security professionals (such as tptacek) objecting to browser encryption? Do you take any specific measures to address the concerns that they have such as browser plugins being able to see decrypted keys, and man-in-the-middle attacks injecting javascript?
We're a small team with limited resources, JS is the easiest medium to get started and ship MVP. Until we have native apps for most popular platforms, you have two options:
(1) run the web client on your own machine, and use Lavaboom this way - if you trust your own computer, of course
(2) install a Chrome/Firefox extension to have some proof that the code is the same as the one at github.com/lavab/web - this is still WIP on our end
Signed native binaries are the best solution IMHO, we're aiming to get there for most major platforms, as I said.
(1) run the web client on your own machine, and use Lavaboom this way - if you trust your own computer, of course
(2) install a Chrome/Firefox extension to have some proof that the code is the same as the one at github.com/lavab/web - this is still WIP on our end
Signed native binaries are the best solution IMHO, we're aiming to get there for most major platforms, as I said.
How does (2) actually work, given that almost any content element loaded onto the page can override what's in the .js file?
> proof that the code is the same as the one at github.com/lavab/web
Theoretically we can prove (via Chrome packaged apps, for example) that the code running on Lavaboom's servers (or locally if you run the web app yourself) is from our public repos. If the code doesn't do magic stuff like dynamically changing itself, and since we use TLS to deliver it, it should be impossible to maliciously alter what's running on the client side, unless we leverage some hypothetical unknown-yet browser-specific vulnerabilities(?).
Also, network activity can be monitored, theoretically the users will be able to detect ~if~ when we start streaming their data to NSA servers. Unless you assume our server is completely compromised and we do the streaming ourselves.
By the way, that's why I designed the system with the premise that we ourselves can't be trusted (e.g. haxorz pwnd us etc.) i.e. asymmetric encryption everywhere. Here's for instance some of my actual data (ignore the pre-refactoring messiness): https://gist.github.com/andreis/70c8f5bb1d811f6ac7db
PS: I'm not saying a web app are ideal for what we do, as I mentioned in another comment we started with it due to sheer pragmatism, and we're planning native apps (or at the very least cordova/electron "native" apps). I would really appreciate your thoughts on the matter.
Theoretically we can prove (via Chrome packaged apps, for example) that the code running on Lavaboom's servers (or locally if you run the web app yourself) is from our public repos. If the code doesn't do magic stuff like dynamically changing itself, and since we use TLS to deliver it, it should be impossible to maliciously alter what's running on the client side, unless we leverage some hypothetical unknown-yet browser-specific vulnerabilities(?).
Also, network activity can be monitored, theoretically the users will be able to detect ~if~ when we start streaming their data to NSA servers. Unless you assume our server is completely compromised and we do the streaming ourselves.
By the way, that's why I designed the system with the premise that we ourselves can't be trusted (e.g. haxorz pwnd us etc.) i.e. asymmetric encryption everywhere. Here's for instance some of my actual data (ignore the pre-refactoring messiness): https://gist.github.com/andreis/70c8f5bb1d811f6ac7db
PS: I'm not saying a web app are ideal for what we do, as I mentioned in another comment we started with it due to sheer pragmatism, and we're planning native apps (or at the very least cordova/electron "native" apps). I would really appreciate your thoughts on the matter.
i tried filing a support ticket about this a couple of days ago and haven't heard back, but i'm unable to get my inbox to decrypt on my second computer. the computer i set the account up on works fine, but it just tells me that it doesn't have a private key when i try to look at my inbox on my laptop. i tried uploading the .json file that i guess is my keypair that downloaded when i set up the account, but it doesn't seem to do anything, just keeps saying no private key. chrome on ubuntu on both devices.
Sorry for no response to the ticket, we found quite a few bugs during integration of our support system and we have a ~200 queued tickets. Please create a new one directly on http://support.lavaboom.com/help_center and I'll take care of your issue.