240: TZ Discussion – Hope in a Quantum Encryption Box

Justin and Jason discuss the details of selling Pluggio, what Justin considers to be the ideal attributes of a SaaS business and his idea for a collaborative web app for doing mockups, the hypocritical startup advise of Ben Horowitz and Dustin Moskowitz, the surprising wealth of A-list celebrities and Internet entrepreneurs, the Xerox compression bug and the Laravel “returning” bug, Nassim Taleb’s Skin in the Game paper, analog mockups, developing an Android app in Titanium, why Apple’s board is concerned about the current rate of innovation, the nonsensical empirical risk assessment of the U.S. government, the cynical political theatre of shutting down U.S. embassies based on non-specific terrorist threat, how Snowden was offered one year’s asylum in Russia as well as a job by social networking giant VKontakte, why Lavabit and Silent Circle both shut down their encrypted email services, how the TSA is rapidly expanding beyond the confines of the airport and the increasing militarization of local police, the lurching surveillance / police state and the possibility of a quantum internet.

Udi Mosayev says:

Posted August 14, 2013 at 5:58 AM

Hey, Udi is here with a defense statement 🙂

Regarding the Laravel bug:
It’s still hard to understand that these kind of bugs exists (as well the copy bug).
Justin uncovered it after version 3 was so popular and version 4 is already released and used by many.
How no one else could find this bug before? I’m sure not only Digedu has users that insert ‘returning’.. probably many developers just couldn’t figure it out in case they had a problem like we did.

After I was able to replicate it (I didn’t understand at first it was only for INSERTs).. I was seriously shocked. Then Justin sent us the copy bug, which as you described has so many serious implications.. that’s just shuttered my world. Think how many other problems like that might exist..

The Fine:
If I had a a product generating few thousands a month I would agree to Justin’s “offer”, but only after we do things that will make me feel comfortable doing so: automated testing post-deployment, a proper defined workflow.. to avoid common human errors as much as possible.
The only thing that’s wrong with my suggestions is because master never tested before deployment to live?
What I suggest: merging features/fixes into staging branch, test it on staging, then merging it to master. When master is never touched directly = so no conflicts between staging and master. What problems ‘master’ might have? the same exact code was already tested.
You think a strange merge bug might occur? if its something like the Laravel bug then I guess it should happen and the world should know about these problems 🙂

No offense taken btw 🙂 I have a lot to learn and I listen to other opinions, but usually when I feel strongly about something (even when I’m wrong) it takes a while to convince me otherwise. So Justin, don’t give up in case I give you a hard time about a subject 🙂

Duncan from Vetter says:

Posted August 15, 2013 at 4:08 AM

This show should be called ‘The one with the swearing”.

🙂

Jason says:

Posted August 15, 2013 at 10:48 AM

@Duncan from Vetter – Yeah, I figured f*ck it! 😉

Stanislaw Pitucha says:

Posted August 16, 2013 at 6:09 AM

I guess the process that Udi proposed is usable, but I wouldn’t ever leave it to the developers. If I understand what was proposed correctly, then it works quite well, provided: this is automated by something like Jenkins or another CI system, no one apart from this system has write rights to the production branch, everything can be automatically tested so that the process always tests locally before actually merging.

That’s the way gerrit+jenkins integration works really and it’s used by many big projects out there. I wouldn’t trust developers to follow the process if it’s not enforced though 🙂

Sandy says:

Posted August 16, 2013 at 4:09 PM

I’m no expert either, but isn’t that what the Tor software does?

http://en.wikipedia.org/wiki/Tor_(anonymity_network)
https://www.torproject.org/

Posted August 16, 2013 at 6:55 PM

@Sandy – Yeah, that’s true, but there are all of these other reasons to believe that Tor and classic encryption may not be as effective as originally thought (see links below). A quantum internet would just be the ideal (at least as far as I understand it).

* Encryption is less secure than we thought
(For 65 years, most information-theoretic analyses of cryptographic systems have made a mathematical assumption that turns out to be wrong.)
http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-0814.html

* Math Advances Raise the Prospect of an Internet Security Crisis
(Academic advances suggest that the encryption systems that secure online communications could be undermined in just a few years.)
http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/

* Has Tor been bugged by the NSA?
(Last week I recommended people use Tor to anonymize their Web surfing. Some people think that’s a dangerous idea.)
http://www.itworld.com/it-management/364242/has-tor-been-compromised-nsa

* Feds Are Suspects in New Malware That Attacks Tor Anonymity
http://www.wired.com/threatlevel/2013/08/freedom-hosting/