Central Perk

marți, 4 noiembrie 2014

Enabling HTTPS Without Sacrificing Your Web Performance

Posted: 03 Nov 2014 04:16 PM PST

Posted by Zoompf

A fast website is a crucial component of a great user experience. So much so that a few years ago Google announced that they were using page load time as a factor in search engine rankings. More recently, Google also announced that they would be favoring websites that use Transport Layer Security (TLS) in its search rankings. TLS encrypts a website's traffic preventing other entities from monitoring its communications. However, adding this protection introduces more complexity to your website and how it communicates with your visitors, potentially slowing things down and negatively affecting the user experience. In this blog post, I will show you how to implement TLS on your website while keeping it fast and responsive.

Conventions and disclaimers

Before we start, a quick note on naming. Beside TLS, you may have also heard the term SSL. SSL was the original encrypted connection protocol created by Netscape in the mid '90s. TLS is the industry standard protocol that grew out of SSL and has continued to evolve and improve while development of SSL has ceased. In the past, SSL and TLS have been largely interchangeable terms. However, the final version of SSL, SSLv3, was recently found to be not secure. All versions of SSL now have known security problems and no one should be using any version of SSL. To avoid confusion, we will not mention SSL again, and will talk exclusively about TLS.

Additionally, while TLS does help protect your websites's visitors from eavesdroppers, it does not magically make your site "secure" from security flaws like cross-site scripting or SQL injection. If you store personal data or conduct commerce through your website, you should explore more rigorous web application security options.

Finally, any type of guide, tutorial, or how-to post on security is highly time sensitive. Attackers are constantly evolving and new attacks are always discovered. Advice about optimizing TLS performance from even 2 years ago, such as using RC4, would today leave your site unsecured. You should always maintain vigilance and make sure you trust your sources.

TLS Areas that need TLC

There are 2 areas of TLS that can harbor performance problems:

Encrypting the data. Data sent back and forth between visiting web browsers and your web server must be encrypted and decrypted. If not configured properly, your page load times can become much slower than unencrypted traffic.
Establishing a secure connection. There are several steps that must occur before a browser establishes a secured connection to your website: identities must be confirmed, algorithms must be selected, and keys must be exchanged. This is known as the TLS Handshake, and it can have a significant impact on your site performance.

We need to give each of these areas some Tender Loving Care (TLC) to optimize for performance. Let's discuss each in detail.

Optimizing Data Encryption

When you use TLS, you are adding another 2 steps to the process of how a browser and web server communicate. The sender has to work to encrypt the data before transmitting it, and the receiver has to decrypt the data before it can process it. Since these operations are occurring on all of your web traffic all of the time, you want this exchange to be as efficient as possible.

There are a large number of ciphers that can be used to perform this encryption/decryption. Some, such as 3DES, were originally designed to be implemented in hardware and can perform slowly when implemented in software on your computer or phone's browser. Others, such as AES, are so popular that CPU makers like Intel have added dedicated instructions to their chips to make them run faster.

A decade ago, TLS data encryption added significant overhead. Today, Moore's law and dedicated support for certain ciphers in CPUs has essentially eliminated this overhead, provided you select the right cipher. The consensus from both security engineers and administrators that run large TLS websites is to use AES, with 128 bit keys. We can see from the chart below that AES running on a CPU that supports built-in AES instructions (denoted by the label AES-NI) is by far the fastest cipher you can use.

chart

Specifying which cipher and options to use can be quite challenging and intimidating. Luckily, Mozilla maintains an excellent page with example cipher configurations to ensure fast and secure connections. These example configurations work with all browsers, and they default to using the faster algorithms like AES. These are constantly updated when new security threats come out, and I highly suggest following their guidance.

As mentioned, to get the most out of AES, your web server will need to use a CPU that supports the dedicated AES instructions known as AES-NI. Most server-grade CPUs made in the last 5 years, such as Intel's Xeon line, support AES-NI. However, older virtualized servers and cloud servers often don't support these instructions. Amazon's M1 class of EC2 instances does not support AES-NI, whereas Amazon's current class of M3 instances do. If you are using a hosted service, check with your hosting provider about what TLS options they support and whether your hosting computer supports AES-NI.

In short, by configuring your web server to use AES ciphers and terminating your TLS connections on a machine with CPU with support for AES-NI instructions, you can effectively mitigate the performance penalty of data encryption.

Optimization Checklist

Enable AES as your preferred cipher, following Mozilla's guidelines.
Verify that web server is running on a system with a CPU that supports AES-NI instructions.

Optimizing the TLS Handshake

The TLS handshake is the process that the browser and server follow to decide how to communicate and create the secured connection. Some of the things that happen during the handshake are:

Confirming the identity of the server, and possibly the client
Telling each other what ciphers, signatures, and other options each party supports, and agreeing on which to use
Creating and exchanging keys to be used later during data encryption

The TLS handshake is shown in this rather technical-looking diagram:

handshake

Don't worry. While there are a lot of details in the diagram, the takeaway is that a full TLS handshake involves 2 round trips between the client and the server. Because of the difference between latency and bandwidth, a faster internet connection doesn't make these round trips any faster. This handshake will typically take between 250 milliseconds to half a second, but it can take longer.

At first, a half-second might not sound like a lot of time. The primary performance problem with the TLS handshake is not how long it takes, it is when the handshake happens. Since TLS handshakes are part of creating the secure connection, they have to happen before any data can be exchanged. Look at the waterfall diagram below: (if you need help, check out how to read a webpage waterfall chart.)

The TLS handshake, shown in purple for each step here, is adding 750 ms of delay to the time it takes to get the initial HTML page. In this example, getting the HTML page over TLS takes twice as long as getting the same page over an unencrypted connection! Worse, the browser can't do anything else until it gets this initial HTML page. It cannot be downloading other resources in parallel, like CSS files or images, because it hasn't gotten that initial HTML page telling them about the other resources. This is true with every secured webpage you visit: The browser is blocked from getting that first HTML response. Unfortunately, the TLS handshake increases the amount of time where the browser can't do anything, slowing down your site performance.

Also, remember the TLS handshakes happen at the start of every new HTTP connection. Since browsers download resources in parallel, this means that a visiting browser will create multiple TLS connections and have to wait for multiple handshakes to complete, even with visiting a single page!

Unfortunately, there is not a lot of extra or unnecessary data that we can optimize during the TLS handshake. The primary aspect we can optimize is the "confirming the identity of the server" step. To do this, the browser looks at something called the certificate chain.

The certificate chain

When you visit https://www.example.com, how do you know you are really talking to www.example.com? TLS certificates solve this problem. You receive a certificate telling your browser "yes, this is www.example.com. trust me." But how do you know you can trust the certificate the server sent?

This is where the certificate chain comes in. Your certificate will be digitally signed by some other entity's certificate, which essentially says "example.com is cool, I vouch for it, here is my certificate." This is called an intermediate certificate. Browsers come with a built in a list of a thousand or so certificates that they trust. If the browser happens to trust this intermediate certificate, we are done. However, it's possible the browser doesn't trust your website's certificate, or the intermediate certificate.

What happens then? Simple! The browser will then look to see who signed the intermediate certificate, and who signed that one, and so on... Basically the browser will "walk" up this chain of certificates, seeing who is vouching for who, until it finds a certificate of someone it trusts from that built-in list mentioned above.

The certificate chain looks something like this:

cert-chain-app.zoompf.com

Here we see a certificate for my website app.zoompf.com. My certificate was signed by the certificate by "DigiCert Secure Server CA." The browser does not trust this certificate since it's not in its pre-built list. However, the "DigiCert Secure Server CA" certificate was in turn signed by the "DigiCert Global Root CA" certificate, which is in that list and is thus trusted. So in this case, my certificate chain length is 3.

You can optimize your site performance by making this certificate chain as short as possible, since validating each certificate in the chain takes extra time. Additional certificates also means more data that has to be exchanged while establishing the secured connection. The browser might even need to make additional requests to download other immediate certificates, or to check that each certificate in the chain is still valid and hasn't been revoked.

When shopping for an TLS certificate, ask the vendor:

What certificate will be used to sign your certificate, and how long will the certificate chain be?
Will they include their intermediate certificate bundled with your certificate, so the browser won't have to wait downloading other certificates while walking up the certificate chain?
Do they support OCSP stapling, to reduce the time needed to check for revoked certificates?

I recommend purchasing your certificate from a large, well known vendor. These tend to offer better support and features like OCSP. They are also more likely to have their root certificates trusted by the browser and thus have a shorter certificate chain length. You can learn more about how to test your certificate chain here.

Optimization checklist

Minimize the length of your certificate chain.
Verify that any immediate certificates are bundled with your certificate.
Get a certificate that supports OCSP, if possible.

Avoiding full TLS handshakes

At its heart, the TLS handshake is about the client and the server verifying each other, agreeing on a common set of ciphers and security options, and then continuing the conversation using those options. It seems silly that a client and a server that have recently communicated before need to go through this full process over and over again. Imagine this scenario: You are visiting a blog like this one over TLS. Multiple TLS connections with multiple handshakes were made to download all the content. In a few minutes, you click a link to read a different page on this site, which causes your browser to do multiple TLS handshakes all over again.

This is where TLS session resumption comes in. Basically, TLS session resumption allows a client to say, "Hey server, we communicated a little while ago and did so using the following TLS options... Is it OK to start talking again using those same options?" This is a huge improvement on performance. A full TLS handshake requires 2 round trips to create the secure connection. TLS session resumptions allows us to do it with 1 round trip.

The great thing about session resumption is that it is basically a free short-cut. When the client asks the server, "can we use these previously agreed upon settings?", it does so as part of the first round trip in setting up a full TLS handshake. If the server agrees, great, the short cut is followed and no further handshaking is necessary. If, for whatever reason, the server doesn't agree to the session resumption request, the TLS handshake continues as normal and completes in 2 round trips. There's no reason not to use session resumption.

There are 2 different mechanisms to implement TLS resumption. The first is Session Identifiers and the second is Session Tickets. They both do the same thing. The difference between them is primarily which side has to keep track of the previously agreed upon options. All web browsers support both, but some web servers, like Microsoft's IIS, only support session identifiers. Session identifiers are a slightly older mechanism, and can potentially expose your site to Denial of Service attacks. Enabling either session identifiers or sessions tickets is done via your web server configuration, and is quite easy. Consult with your administrator about getting these options enabled.

Optimization checklist

Enable TLS resumption on your web servers.
If possible, avoid using session identifiers to reduce your exposure to Denial of Service attacks.

Other TLS Options

There are several other TLS options and nuances we are glossing over: What asymmetric algorithm should you use? What key exchange protocol should you use? What key size should you use for your symmetric cipher? Should you be using perfect forward secrecy? These are important decisions from a security perspective, and everyone's needs are different. From a performance perspective, these are largely moot. It is best to leave these choices to whomever manages your server, or to follow advice from Mozilla on the page linked above.

Minimizing TLS handshakes altogether

As we have seen, the TLS handshakes, while necessary, can have an impact on your performance:

They can delay the download of critical responses like the initial HTML page.
They can happen multiple times on a single page.
There isn't much we can do to optimize them.

While session resumption can cut the delay of a TLS handshake in half, it is still best to avoid TLS handshakes altogether. You can do this by minimizing how many HTTP connections a browser makes when visiting your website. Luckily, many traditional front-end performance optimizations that you should be doing anyway can help. This makes front-end performance optimizations even more important on sites secured with TLS. Let's focus on 4 optimizations that are particularly relevant for sites using TLS.

1. Persistent connections

Persistent connections allow HTTP to make multiple requests over a single HTTP connection. Persistent connections allow the browser to load the page faster because it can make requests more quickly. But it can also cut down on the number of TLS handshakes. Consider this waterfall, which we looked at before:

See how virtually every HTTP request has a purple section? This purple section is the TLS handshake. Why does it keep happening? Because the web server is explicitly closing the HTTP connection, and thus the underlying TLS connection, with every response. We can see this with the Connection: close response header, as shown below:

ssl-connection-close

This is terrible for performance in general, but especially bad for a site using TLS. Your website should be using persistent connections.

2. Domain sharding

Domain sharding is a technique to trick a visiting browser into downloading resources from your website more quickly. It works by having a single web server with different hostnames. For example, your site might be named example.com, but configured to resolve the names static1.example.com and static2.example.com to the same server. Since browsers allow only a limited number of HTTP connections to a single hostname at the same time, using multiple hostnames trick the browser into downloading more content in parallel.

The problem with domain sharding is that the browser doesn't know that example.com, static1.example.com, and static2.example.com are all the same server. It will make new HTTP connections to each hostname, and have to do a full TLS handshake each time. In our example, we are potentially doing 3 times the number of TLS handshakes because of our sharded hostnames. Additionally, session resumption information for connections on one hostname cannot be used by connections to another hostname, even though under the covers all these names refer to the same server.

The net result is that increased number of TLS handshakes caused by domain sharding may offset any advantage gained from downloading more content in parallel. In fact, sharding a TLS-protected website might actually make it slower. This is especially true if you follow the next two pieces of advice, which will reduce the number of items that need to be requested at all.

3. Combining CSS and JavaScript files

Combining multiple CSS or JavaScript files into one or two primary files is a huge front-end performance optimization. Browsers can download one 100 KB file faster than 10 10-KB files. The advantage for TLS sites is that if you are making fewer requests, you are less likely to need additional HTTP connections that will require a resumed or full TLS handshake.

4. Caching resources

The fastest request is one the browser doesn't have to make. Caching might be the best front-end performance optimization you can make. If I just visited your site, and I'm looking at a second page, there is no reason to download your logo a second time. If you don't use caching, the browser must check with your website if it is OK to use logo image it has previously downloaded. This is called a conditional request, and it's bad for performance. Because of the difference between bandwidth and latency, even if you don't actually download anything from the server, simple sending a request to ask if it is OK to use a logo takes almost as long as just downloading the logo again.

Conditional requests are bad for TLS. You are forcing the browser to create more HTTP connections, and thus perform more TLS handshakes, just to check if the content is still valid. Caching your static resources like images, CSS and JavaScript will have a big benefit and can prevent these additional connections.

Optimization checklist

Enable persistent connections. Ensure your application or CMS is not prematurely closing HTTP connections.
Use tools like WebPageTest to see if domain sharding will actually improve performance for your TLS enabled website.
Combine multiple JavaScrpt and CSS files into bundles where appropriate.
Cache your static resources for 5 minutes, even if you don't have a file versioning system in place.
If you have the infrastructure and processes in place, use far-future caching with a file versioning system that changes the URLs of your resources when they change.
Test your site to ensure you are properly implementing front-end performance optimizations.

Summary

Google is now favoring websites that are secured using TLS in search engine rankings. TLS can have an impact on performance and this article has shown you the steps you can take to minimize the impact.

The data encryption overhead for secure connections is largely a problem of the past, thanks to faster CPUs with built-in support for AES cipher operations. The TLS handshake can be optimized by keeping your certificate chain short by purchasing your certificate from a large, well known vendor whose signing certificates on the trusted list instead of web browser. You can speed up subsequent TLS handshakes by enabling session resumption on your server. You can avoid many TLS handshakes all together by implementing common front-end performance optimizations like persistent connections and caching, and avoiding tricks like domain sharding. You can also use Zoompf's free performance report to ensure your website is using AES and is properly implementing the suggested front-end performance optimizations.

In our next blog post we will discuss with intersection of security and performance that Google is creating with its new SPDY protocol.

If you'd like to stay on top of your website performance, consider joining the free Zoompf Alerts beta to automatically scan your website every day for the common causes of slow website performance.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

Seth's Blog : Despite, in spite of, because... three ways to manage creativity

Despite, in spite of, because... three ways to manage creativity

The people you hire will do creative work despite your management style, sometimes.

Or they might do it in spite of your approach, rarely.

But the most likely way to get the work you seek is to earn it, to have people bring their best ideas forward because of the leadership and guts you bring to the table.

You can't demand creativity, not for long. You can earn it though.

• Email to a friend •

Please help us make Pinterest better!

We want to make sure you get the most out of Pinterest, and we'd love your…

Hi there,

We want to make sure you get the most out of Pinterest, and we'd love your feedback.

Please take a few minutes to complete this survey:

Begin survey

Thanks!
The Pinterest Team

luni, 3 noiembrie 2014

Mish's Global Economic Trend Analysis

Sisyphean Fed Struggle to Create Inflation; Faber on Gross' Deflation Theory, Japan's Bond Ponzi Scheme, and Gold
166 Local Tax Increase Proposals on California Ballots; Not For the Kids
Cameron's Lies Reach "Point of No Return" Warning From Merkel; Chameleon Politics

Sisyphean Fed Struggle to Create Inflation; Faber on Gross' Deflation Theory, Japan's Bond Ponzi Scheme, and Gold

Posted: 03 Nov 2014 05:20 PM PST

Sisyphean Fed Struggle

Earlier today in The Trouble with Porosity and Prosperity Bill Gross mentioned the possibility of deflation in the US and spoke of the Fed's Sisyphean struggle to create inflation.

Before the advent of central banks in the early 20th century, prices were just as likely to go up as down. The world of the 1930s and the more recent lost decades of Japan give testament. Prices change – and while they usually go up these days, sometimes they do not. We are at such a moment of uncertainty.

That one or the other should be favored, is a fascinating debate. Currently, almost all central bankers have a targeted level of inflation that approaches 2%. Some even argue for higher levels now that deflationary demons approach in peripheral Euroland. They argue that the 2% level is sort of like a firebreak. Once inflation approaches zero, goes their theory, the deflationary firestorm is difficult to stop. With interest rates at zero and quantitative easing approaching potential political maximums, there is little water left to pour on the flames. Best then to keep inflation at a reasonable 2% so that the zero hour never comes. They have a point, but then how to explain to the average 30-year-old citizen that if so, his/her retirement dollar will only be worth half as much come 65, and if inflation averages 3%, it will only be worth a third. Actually, a 30-year-old citizen of the 1970s (yours truly), has experienced a 75% depreciation of his purchasing power.

Jim Grant, one of the most gifted financial historians of our day, has long argued that economies did just fine during bouts of deflation in the 18th and 19th centuries – in fact, in many cases, they did better. America in the 1880s was a period of good deflation with output rising by 2% to 3% from 1873 to 1893.

But Grant must know, I suspect, that our modern finance based economy is not your 19th century Oldsmobile, if there had been one. Stopping the printing press sounds like a great solution to the depreciation of our purchasing power but today's printing is simply something that the global finance based economy cannot live without.

Why not? Simple math, I suppose. Our 2014 U.S. Oldsmobile requires 4% nominal growth just to keep it running, and Euroland economies need at least 3%. Having created outstanding official and shadow banking credit of nearly $100 trillion with an average imbedded interest rate of 4% to 5%, the Fed presses must crank out new credit (nominal growth) of approximately the same 4% to 5% just to pay the interest rate tab. That of course wasn't the case in Grant's 19th century version – there was very little debt to service. But now at 500% to 600% of GDP (shadow debt included), it's a Sisyphean struggle just to stay above water. Inflation, in other words – or in simple math – is required to pay for prior inflation. Deflation is no longer acceptable.

Such is the dilemma facing central bankers (and supposedly fiscal authorities) in 2014 and beyond: How to create inflation. They've made a damn fine attempt at it – have they not? Four trillion dollars in the U.S., two trillion U.S. dollar equivalents in Japan, and a trillion U.S. dollars coming from the ECB's Draghi in the eurozone. Not working like it used to, the trillions seem to seep through the sandy loam of investment and innovation straight into the cement mixer of the marketplace. Prices go up, but not the right prices. Alibaba's stock goes from $68 on opening day to $92 in the first minute, but wages simply sit there for years on end. One economy (the financial one) thrives while the other economy (the real one) withers.

The real economy needs money printing, yes, but money spending more so, and that must come from the fiscal side – from the dreaded government side – where deficits are anathema and balanced budgets are increasingly in vogue. Until then, Grant's deflation remains a growing possibility – not the kind that creates prosperity but the kind that's the trouble for prosperity.

Faber on Gross' Deflation Theory and Japan's Bond Ponzi Scheme

In a Bloomberg TV interview, Trish Regan asked Marc Faber about Gross' deflation theory. Faber also discussed Japan's latest QE endeavor.

Faber stated: Japan is Engaged in a Ponzi Scheme. Click on link to watch video.

Transcript

TRISH REGAN: Hello, Marc. Always good to see you. What do you think here about what Bill Gross is saying? Do you think in fact deflation is a real possibility.

MARC FABER: Well, I think the concept of inflation and deflation is frequently misunderstood because in some sectors of the economy you can have inflation and in some sectors deflation. But if the investment implication of Bill Gross is that – and he's a friend of mine. I have high regard for him. If the implication is that one should be long US treasuries, to some extent I agree. The return on 10-year notes will be miserable, 2.35 percent for the next 10 years if you hold them to maturity in each of the next 10 years.

However, if you compare that to French government bonds yielding today 1.21 percent, I think that's quite a good deal, or Japanese bonds, a country that is engaged in a Ponzi scheme, bankrupt, they have government bond yields yielding 0.43 percent.

Well I think they're engaged in a Ponzi scheme in the sense that all the government bonds that the Treasury issues are being bought by the Bank of Japan.

REGAN: So Japan's engaged in a Ponzi scheme. What about the US? We've done our share of money printing. We've had record low interest rates for six years.

FABER: I think the good news is – for Japan is that most countries are engaged in a Ponzi scheme and it will not end well. But as Carlo Ponzi proved, it can take a long time until the whole system collapses.

Faber on Gold

Here are a few excerpts courtesy of Bloomberg that did not appear in the above video.

REGAN: I know you have been bullish in gold for – well, pretty much forever, Marc. But now we're in a situation where gold is at a four-year low. Goldman now predicting 10, 15 down [percent]. Soc Gen saying $1,000. Where do you see gold finishing the year?

FABER: I would say Goldman Sachs is very good at predicting lower prices when they want to buy something. I would say, yes, we are down from $1,900 to $1,160 or something like this, and it's been a miserable performance since 2011. However, from the 1990 lows we're still up more than four times. So I just looked at performance tables over 10 years and 15 years. Gold hasn't done that badly, has done actually better than stocks.

Now I personally, I think that we may still go lower. It's possible. I'm not a prophet, but I'm telling you I want to own some gold because I don't trust the financial system anymore. I think the whole thing is going to collapse one day and then I'll be happy to have some assets. But of course the custody is important. I wouldn't hold my gold at the Federal Reserve because they will lend it out. I wouldn't hold my gold in the US at all.

REGAN: Okay. So you want gold even at these levels. Where do you see – you still see it going lower however as we close out the year?

FABER: I don't know whether it will go lower, but I think by the time I die, it will be meaningfully higher. I'm now 68 and I don't think it will be 100 [I will die at 100]. I'm not that optimistic.

Mish Comments on Gross' Deflation Theory

Gross and Faber are primarily talking about prices (price inflation and deflation, not monetary inflation and deflation. However, Gross mixes the two when he discusses printing presses and credit math.

Nonetheless, Gross' context is clear. I run into this myself and dislike having to write "price", "monetary", or "credit" in front of every inflation or deflation reference when context should make it clear.

Good Deflation vs. Bad Deflation

Bill Gross says "Deflation is no longer acceptable."

I suggest, ordinary consumer price deflation will not hurt banks one bit. The problem for the Fed is not price deflation, but asset-price deflation.

Gross should be able to figure this out. Interestingly, Gross even spoke of "good deflation with output rising by 2% to 3% from 1873 to 1893."

The truth of the matter is falling consumer prices never have and never will hurt banks.

The alleged "bad deflation" which Gross did not mention is in regards to falling asset prices. If banks extend loans on houses or other investment property, and the loans go sour, banks become capital impaired, unable or unwilling to lend.

The irony is the Fed (central banks in general), cause asset price inflation (followed by deflationary asset price busts), when they attempt to create 2% inflation willy-nilly as if consumer price deflation is bad.

"Bad Deflation" Doesn't Really Exist

Actually, there is no such thing as "bad deflation". All deflation is inherently good. Deflation is the natural state of affairs as a result of rising productivity and technological advancements.

Falling prices means more affordability for more people.

Deflation only seems bad when banks make poor lending decisions on risky assets, then become capital impaired when the loans go bad. Why does that happen? Easy ... The Fed has created a moral hazard. Banks believe the central bank will always bail them out if they get in trouble.

And so far they have. So banks keep making risky loans, and investors keep plowing into riskier and riskier assets.

Bubbles of Increasing Amplitude

Via the moral hazard of bailouts, the Fed sponsors bubbles and crashes of increasing amplitude over time.

But the biggest bubble of all is belief central banks will always be able to handle these busts.

Gross needs to replace "simple math" with "exponential math" coupled with the fact central banks can (for a while) target prices in general, but they cannot target wages or the prices they want.

Back to the Drawing Board

The Fed expanded money supply by $4 trillion dollars and the CPI is up less than 2%!

What's the Fed going to do for an encore when the global economy slumps, US jobs with it, and prices of goods services, and assets sink?

Expand money supply by $8 trillion? $16 trillion? $32 trillion? Buy equities? Buy more than 100% of debt issuance like Japan?

How nuts does it get?

Gross concludes with "The real economy needs money printing". I suggest Gross go back to the drawing board and come up with a different answer.

Suggested Reading for Bill Gross

Mike "Mish" Shedlock
http://globaleconomicanalysis.blogspot.com

166 Local Tax Increase Proposals on California Ballots; Not For the Kids

Posted: 03 Nov 2014 11:17 AM PST

There are 166 tax increase proposals on the ballot in California. 118 of them are bond proposals. It matters little what the proposals are for.

Forget about any claim, "it's for the kids". Politicians have a way of doing whatever they want with the money once the tax hikes pass.

Ed Ring writing for Union Watch notes new tax revenue is in too many cases, suspiciously equal to the amount that pension contributions need to be raised in the next few years.

But wait, doesn't money have to be spent on what the bond proposal says it's for? If you think so, please consider this guest post by Ed Ring.

Note: everything that follows until the last line is from Ring.

California's $12.3 Billion in Proposed School Bonds: Borrowing vs. Reform

"As the result of California Courts refusing to uphold the language of the High Speed Rail bonds, the opponents of any bond proposal, at either the state or local level, need only point to High-Speed Rail to remind voters that promises in a voter approved bond proposal are meaningless and unenforceable."

Jon Coupal, October 26, 2014, HJTA California Commentary

If that isn't plain enough – here's a restatement: California's politicians can ask voters to approve bonds, announcing the funds will be used for a specific purpose, then they can turn around and do anything they want with the money. And while there's been a lot of coverage and debate over big statewide bond votes, the real money is in the countless local bond issues that collectively now encumber California's taxpayers with well over $250 billion in debt.

Over the past few weeks we've tried to point out that local tax increases – 166 of them on the November 4th ballot at last count, tend to be calibrated to raise an amount of new tax revenue that, in too many cases, are suspiciously equal to the amount that pension contributions are going to be raised over the next few years. For three detailed examples of how local tax increases will roughly equal the impending increases to required pension contributions, read about Stanton, Palo Alto, and Watsonville's local tax proposals. It is impossible to analyze them all.

As taxes increase, money remains fungible. More money, more options. They can say it's for anything they want. And apparently, bonds are no better.

At last count, there are 118 local bond measures on the November ballot. And not including three school districts in Fresno County for which the researchers at CalTax are "awaiting more information," these bonds, collectively, propose $12.4 billion in new debt for California taxpayers. All but six of these bond proposals (representing $112 million) are for schools. Refer to the list from CalTax to read a summary of what each of these bonds are for – "school improvements," "replace leaky roofs," "repair restrooms," "repair gas/sewer lines," "upgrade wiring," "renovate classrooms," "make repairs."

To be fair, there are plenty of examples of new capital investment, "construct a new high school," for example, but they represent a small fraction of the stated intents. On November 4th, Californians are being asked to borrow another $12.3 billion to shore up their public school system. They are being asked to pile another $12.3 billion onto over $250 billion of existing local government debt, along with additional hundreds of billions in unfunded retirement obligations for state and local government workers. They are being asked to borrow another $12.3 billion in order to do deferred maintenance.
We are borrowing money to fix leaky roofs and repair restrooms and sewers.

This is a scandal, because for the past 2-3 decades, California's educational system has been run for the benefit of unionized educators and unionized construction contractors who work in league with financial firms whose sales tactics and terms of lending would make sharks on Wall Street blush. These special interests have wasted taxpayers money and wasted the educations of millions of children. Their solution? Ask for more money.

Nobody should suggest that California's public schools don't require investment and upgrades. But before borrowing more money on the shoulders of taxpayers, why aren't alternatives considered? Why aren't educators clamoring for reforms that would cut back on the ratio of administrators to teachers? Why aren't they admitting that project labor agreements raise the cost to taxpayers for all capital investments and upgrades, and doing something about it?

If their primary motivation is the interests of students, why aren't they supporting the Vergara ruling that, if enforced, will improve the quality of teachers in the classroom at no additional cost? Why aren't they embracing charter schools, institutions whose survival is tied to their ability to produce superior educational outcomes for far less money?

Why don't they question more of these "upgrade" projects? Is it absolutely necessary to carpet every field in artificial turf, a solution that is not only expensive but causes far more injuries to student athletes? Is it necessary to spend tens of millions per school on solar power systems? Does every high school really need a new theater, or science lab? Or do they just need fewer administrators, and better teachers?

And to acknowledge the biggest, sickest elephant in the room – that massive, teetering colossus called CalSTRS, should teachers, who only spend 180 days per year actually teaching, really be entitled to pensions that equal 75% of their final salary after only 30 years, in exchange for salary withholding that barely exceeds what private employees pay into Social Security?

Thanks to unreformed pensions, how many billions in school maintenance money ended up getting invested by CalSTRS in Mumbai, Shanghai, Jakarta, or other business-friendly regions?

How much money would be saved if all these tough reforms were enacted? More importantly, how much would we improve the ability of our public schools to educate the next generation of Californians? Would we still have to borrow another $12.3 billion?

Here's an excerpt from an online post promoting one of California's local school bond measures: "It will help student academic performance, along with ensuring our property values. If you believe that strong schools and strong communities go hand in hand, please vote…"

Unfortunately, such promises are meaningless and unenforceable. The debt is forever.

Ed Ring is the executive director of the California Policy Center.

End Guest Post

I will have some comments on the Illinois Gubernatorial election later this week. Real Clear Politics has Governor Pat Quinn in a slight lead over Republican challenger Bruce Rauner.

Mike "Mish" Shedlock
http://globaleconomicanalysis.blogspot.com

Cameron's Lies Reach "Point of No Return" Warning From Merkel; Chameleon Politics

Posted: 03 Nov 2014 10:12 AM PST

Hot Water Over Lies

UK Prime Minister David Cameron is in increasingly hot water on a number of fronts as his lies become more and more transparent.

Cameron has pledged to hold an up-down referendum on UK exit from the EU but only on the condition he wins the next election and even then, only on his promise that he can get an overhaul of EU rules for benefit of the UK.

Promise or a lie? I suggest the latter.

"Point of No Return" Warning From Merkel

And without using the word lie, German Chancellor Angela Merkel warned UK could leave EU if David Cameron insists on migrant quotas.

Germany would be prepared to accept that Britain will have to leave the European Union if David Cameron insists on restricting the number of immigrants from the bloc who can live and work in the UK.

Mr Cameron's bid to curb levels of migration from the EU is taking Britain to a "point of no return", according to Der Spiegel.

Mr Cameron has said that he will reform Britain's relationship with the EU before holding an in-out referendum in 2017.

The Prime Minister used his speech last month to the Tory Party conference to pledge to put reform of the freedom of movement principle would be "at the very heart of my renegotiation strategy for Europe".

However, Angela Merkel, the German chancellor, has said that she would not support any plans to change the freedom of movement rules that allow an unlimited number of EU migrants to live and work in the UK.

At a recent summit in Brussels, Mrs Merkel is reported to have told Mr Cameron that Germany would not accept any of his demands of freedom of movement and told him: "That's it."

What's Next for Cameron?

Inquiring minds may be asking "What's Cameron's Next Move?"

The answer is the same as always: Lie.

Cameron the Chameleon

Right, wrong, or indifferent, Cameron will give into Merkel without admitting it. No lie is too great if he thinks it will help keep him in office.

Cameron is a chameleon who wants to appease UKIP, appease the greens, appease Labour, appease the Liberal Democrats, appease the Tories, appease Scotland, appease your aunt Martha and my uncle Ben.

If he had an ounce of integrity he would hold that up-down vote now. But he won't.

Instead, look for creative excuses, more wishy-washy statements, and above all, more lies disguised as promises.

Mike "Mish" Shedlock
http://globaleconomicanalysis.blogspot.com

Damn Cool Pics

A Wedding Photo Shoot Becomes a True Test of Love
PC Lounge
Halloween Mugshots
12 Selfies That You Cant Take Back [Infographic]

A Wedding Photo Shoot Becomes a True Test of Love

Posted: 03 Nov 2014 03:51 PM PST

A Chinese girl arrived for her pre-wedding photo shoot looking years older as a result of carefully applied makeup. The girl used the look as a way of testing her fiancé and asked him he would still love her in 70 years from now. The groom was angry when his bride-to-be refused to remove her makeup and the couple ended up in an argument on the street where the bride collapsed in tears.