absherwin

WHEN I was a King and a Mason - a Master proven and skilled

I cleared me ground for a Palace such as a King should build.

I decreed and dug down to my levels. Presently under the silt

I came on the wreck of a Palace such as a King had built.

There was no worth in the fashion - there was no wit in the plan -

Hither and thither, aimless, the ruined footings ran -

Masonry, brute, mishandled, but carven on every stone:

"After me cometh a Builder. Tell him I too have known.

Swift to my use in the trenches, where my well-planned ground-works grew,

I tumbled his quoins and his ashlars, and cut and reset them anew.

Lime I milled of his marbles; burned it slacked it, and spread;

Taking and leaving at pleasure the gifts of the humble dead.

Yet I despised not nor gloried; yet, as we wrenched them apart,

I read in the razed foundations the heart of that builder’s heart.

As he had written and pleaded, so did I understand

The form of the dream he had followed in the face of the thing he had planned.

When I was a King and a Mason, in the open noon of my pride,

They sent me a Word from the Darkness. They whispered and called me aside.

They said - "The end is forbidden." They said - "Thy use is fulfilled.

"Thy Palace shall stand as that other’s - the spoil of a King who shall build."

I called my men from my trenches, my quarries my wharves and my sheers.

All I had wrought I abandoned to the faith of the faithless years.

Only I cut on the timber - only I carved on the stone:

"After me cometh a Builder. Tell him, I too have known."

For the curious: Downloading all the repos and extracting email addresses takes 1-2 days and costs <$50 on AWS.

Edit: Apparently, this doesn't re-write the actual repo so anyone seriously interested in e-mail addresses will be unaffected. It was already easier to get e-mails via cloning rather than through scraping or the API.

Real-estate appraisals are imperfect but getting within 20% most of the time is quite achievable. The main problem is for unusual or expensive properties which could be handled similarly to hard-to-value assets.

Your statement doesn't follow unless defining that subset is easy. What should be included or excluded? As we're discussing corporations, we have ample evidence of the ability to game. You could suggest closing loopholes but most of the loopholes also have legitimate uses.

You write that "capital assets are valued at sale for income purposes" is a solution to the difficulty in measuring their value. Why is this the case? Remember that the origin of this discussion is whether it's better to tax corporate income or the wealth of those who own the vast majority of that income. Are you asserting that valuing a person's equity holdings is difficult?

It's also worth noting that short-term investors are a greater threat to long-term focused decisions than pay incentives. Most CEO's aren't actually foolish enough to risk destroying their company for more money in the near-term. They like their jobs so what does terrify them is an investor demanding more leverage or adopting a riskier strategy on pain of advocating removal or a hostile takeover. When Chuck Prince said he couldn't sit down until the music stopped, he wasn't worried about a smaller bonus but about posting lower profits that would have led to calls for his removal. "There was a merchant in Baghdad..."

Wealth is the value of everything you have less what you owe. Every item can be valued by seeing what people would pay for it, which is usually just its current market price. How do you determine income objectively? You could merely take wealth at two points in time but our society has declined to define it that way because much of the money coming in might go to some sort of expense which ought to be excluded, which is neither objective or simple, and because some changes (such as fluctuations in asset prices) are assumed to be transitory and therefore impractical to tax. The latter is actually the source of most of the perfectly legal tax evasion in this country: Hold stocks, generate value, pay nothing until you sell which needn't be ever.

There will be some complicated edge cases but there will be relatively few and the ability to game them is less because wealth is a simpler concept than income.

As for the economic payers. Consider what happens if we eliminate corporate taxes: The company has more money. It can use that money in three general ways: Lower prices, raise pay or return it to shareholders. In a company with little competition, the optimal calculation is fairly simple. Does the additional return enable new entrants at current prices? Do we have employees who could leave and create competition and to what extent does the additional cash-flow make it more likely? In a competitive environment, the right answer is based on the sensitivity of profit to talent, the sensitivity of talent to pay increases, and the sensitivity of consumers to price decreases.

Given this different factors, what's the empirical answer? It varies based on circumstance and no one can say definitively. Here's an example of one attempt to answer based on variation in European tax rates that suggests that 49% of the taxes are paid by workers: http://www.econstor.eu/bitstream/10419/51691/1/66322666X.pdf. You can find many more papers with different points of view through your favorite search engine.

This may yield higher returns to investors than they could otherwise receive but, if so, it's only because they underestimate you. If the return on funds invested with you is expected to be higher, the ETF's price will increase until the perceived risk-adjusted return is equal to that in the market. What causes the types of entities who receive above average returns through nontraditional vehicles to achieve them is some combination of the the higher cost of raising that money, more limited availability and social convention.

Beware. The liquidity of these markets is vastly lower than that of equities. Also remember Keynes: "The market can remain irrational longer than you can stay solvent" or in this case longer than the contract durations offered.

Regarding Moxie, I noted in the original post and immediately after his first post that he'd need to provide a valid SSL certificate. He asserted one wasn't necessary and I assumed perhaps he had some other trick to make it appear as though he had one so I invited him to email me details. His attack didn't do that and it turned out he had interpreted the requirement for a valid SSL certificate to mean that he couldn't present one the browser would flag as invalid. I'm sorry if you or he feel that I wasted his time.

The SSL connectivity for the server did work. The only way to defend against the attack Moxie posted would be to modify my browser. The exploit Moxie used depends on the fact that if one doesn't type https:// the browser will request http. You could argue my error was abbreviating in the posting but that wouldn't change how users type it. The best defense against this is HSTS which comes in two flavors: The standard version is applied after first visting the site. Would you have said that invalidated the attack? The attack would work just as well on a browser with cleared cache or running in incognito mode.

The only real defense which, to my knowledge, only exists in Chrome is the HSTS preload. I suppose I could have noted that I'd modify my browser to have it on the HSTS but that doesn't effect real world security either.

That said, I am extremely curious how you would defend against SSL stripping in the wild. This seems like a potentially devastating attack. None of the banks that I checked are on the preload and many don't seem to use HSTS at all. What defenses would you have considered sufficient so as not to consider this trivially exploitable by an SSL redirect vulnerability that effects almost the entire web?

Your argument above effectively reduces to: The web is insecure so you always lose and putting in a disclaimer to ban such attacks is weaselly. The SSL vulnerability is a huge problem but that doesn't mean understanding the security of the rest of the system is worthless.

I never said I'd check the fingerprint of the certificate against my memory. Moxie used that retort against me after his attack produced a session that was obviously not over https. I explicitly denied that that was one of my criteria. That said, at least in chrome, appspot.com is pinned.

The irony is that this does show that SJCL provides a modest security increase over plaintext in the case of broken SSL. It requires a per-site attack to be constructed ahead of time vs. simply reviewing the plaintext for all sites after the fact and picking what's valuable.

Your key argument seems to be that naive developers might use JS crypto because of this. If they use it naively, I'm sorry for that. I'm also sorry if they exclude it naively because of other rhetoric. I hoped that this would generate more nuanced discussion that would cause them to be more aware of the risks if they chose to use it. Obviously that wasn't the case and nothing was learned about the various angles from this app could be exploited aside from the trivial one.

I truly appreciate your laying out your reasons above. I understand I struck a negative chord but am glad that we've been able to move into discussing the specific technical issues.

You chose to reassert that you believe your accusation is true without responding to the specific points raised and turn the focus of the discussion to the subsidiary point.

I failed at my second goal and while I've succeeded in the third it was in different way than anticipated.

I also to reiterate that this isn't some backhanded attempt at a product launch. I would have hoped that my statements, using an appspot domain, no design and limited functionality would have made that clear.

Moxie did provide a more detailed attack description. I had to correct an iptables command and modify sslstrip to alter the JS but otherwise his instructions were complete and correct. Per the original instructions, he should have had to configure the proxy but that's purely a function of who does that labor so I happily did the small amount of extra work.

Once I completed the attack, I learned as I suspected from reading about sslstrip, the SSL certificate was removed. I thanked Moxie for his efforts and praised his work but informed him that it didn't meet the initial requirements. He argued that it works in the wild and that I could acquire appspot.cc and a certificate for that. I replied that if he wanted to conduct a convincing enough demo that I would be fooled into clicking, I'd consider that sufficiently close to being valid. Alternatively, he could produce an SSL certificat e that the browser would accept as valid for that domain. I agreed that a user in the wild might not be as cautious but that in agreeing to route my traffic through a malicious proxy, I recognized I was giving an attacker a significant advantage and that's why I made a valid SSL certificate a requirement in the initial post.

He replied back that any LAN can be malicious so he disagrees with my assessment and that he didn't trust I wouldn't throw up more unreasonable objections and that I should pay.

I replied outlining exactly how I would evaluate any alterations to the MITM he's proposing. It was at this time he posted to twitter. I heard about that and emailed him and he denied he was accusing of of dishonesty but only noting that I had declined to pay the reward tptacek thought he was owed. I remained concerned that it wouldn't be taken that way and unfortunately tptacek has proven my fears correct.

In any event, I asked him if he believed his approach genuinely met the valid certificate requirement at this point because I wanted to assess whether he was he felt my rules were unfair or that I wasn't abiding by them. He declined to reply to that question.

Moxie suggested that I acquire a certificate for a similar domain to meet that requirement but that doesn't meet either the normal definition of valid (If a show requires a valid ticket to be shown at the entrance, will one from last night do?). He did claim that producing a forged certificate is possible and I have no reason to doubt him. However, he noted that he nor anyone else would produce one for a reward of this amount.

We were still corresponding when he made the tweet in question. I ultimately asked him if he believed that a certificate to another domain was a valid certificate and his reply didn't address that point but discussed instead why he and tptacek are frustrated by these kind of contests.

I'm sorry I seem to have offended you.

While there's much talk of disruption in startups, their goal isn't to destroy, it's to build something better and the destruction results therefrom. Considered that way, the institutionalization of startups doesn't contradict their mission any more than writing in a higher level language makes one less of a programmer.

I agree with most of the details; most people's incentives aren't pure. While that may not be ideal, yet far it has accelerated innovation.

Your point about weak passwords holds in both ordinary clients and in the browser. It's just a matter of degree. There are plenty of sufficiently strong passwords that are memorable. Since the degree of weakness tolerable is logarithmically proportional to the hashing time and JS is usually within an order of magnitude of native code, the additional entropy required is small given equivalent hashing time.

Ironically, this is an advantage of having a second layer of cryptography in the browser. It forces an attacker to do significantly more work to acquire the data passively or requires an active attack.

2. It doesn't exist. The code was written in the same form it was uploaded.

If the maintainer of JS code make a mistake and fixes it in future versions, there's no need to worry about it anymore either. However, every time I upgrade I'm just as much at risk from someone attacking either my connection or having attacked the server. So to believe it's more secure, you have to believe those things are easier to do in the context of a web application.

Those are creative solutions to your contest. I should have been cleverer.

2. The code I wrote isn't obfuscated. The code at the top is just SJCL and angular.js which are https://github.com/bitwiseshiftleft/sjcl and https://github.com/angular/angular.js