Thứ Bảy, 30 tháng 4, 2016

Equity-financed banking

My dream of equity-financed banking may be coming true under our noses. In "the Uberization of banking" Andy Kessler at the WSJ reports on SoFi, a "fintech" company. The article is mostly about the human-interest story of its co-founder Mike Cagney. But the interspersed economics are interesting.

SoFi started by making student loans to Stanford MBAs, after figuring out that the default rate on such loans is basically zero. It
has since expanded to student loans more generally and added mortgages, personal loans and wealth management. Mr. Cagney says SoFi has done 150,000 loans totaling $10 billion and is currently at a $1 billion monthly loan-origination rate. 
Where does the money come from?
SoFi doesn’t take deposits, so it’s FDIC-free. ... Instead, SoFi raises money for its loans, most recently $1 billion from SoftBank and the hedge fund Third Point, in exchange for about a quarter of the company. SoFi uses this expanded balance sheet to make loans and then securitize many of them to sell them off to investors so it can make more loans
Just to bash the point home, consider what this means:
  • A "bank" (in the economic, not legal sense) can finance loans, raising money essentially all from equity and no conventional debt. And it can offer competitive borrowing rates -- the supposedly too-high "cost of equity" is illusory.
     
  • There is no necessary link between the business of taking and servicing deposits and that of making loans. Banks need not (try to) "transform" maturity or risk.
     
  • To the extent that the bank wants to boost up the risk and return of its equity, it can do so by securitizing loans rather than by borrowing. (Securitized loans are not leverage -- there is no promise of your money back when you want it. Investors bear any losses immediately and without recourse.)
     
  • Equity-financed banking can emerge without new regulations, or a big new Policy Initiative.  It's enough to have relief from old regulations ("FDIC-free").
     
  • Since it makes no fixed-value promises, this structure is essentially run free and can't cause or contribute to a financial crisis. 

More. SoFi does not use the standard methods of evaluating credit risk:
Instead of relying on notoriously inaccurate backward-looking FICO scores, SoFi is “forward-looking.” That means asking basic questions—“Do you make more money than you spend?”—and calibrating where applicants went to college, how long they’ve been employed, how stable their income is likely to be over time.
Why can’t banks do this? Because if you use depositor money for loans, as all banks do, you fall under the jurisdiction of the Federal Deposit Insurance Corp. and the Community Reinvestment Act,...
And Basel and the FSOC and the Fed and so forth. FICO score based mechanical lending standards are also demanded by government-backed securitizers Fannie and Freddie.

Yes, bank "safety" regulations demand that banks purposely lend to people that one can pretty clearly see will not pay it back, and demand that they do not lend money to people that one can pretty clearly see will pay it back.

Now, what will the regulatory response be to this sort of innovation? The right answer, of course, should be hosannas: You have introduced run-free banking, that solves all the financial-crisis worries that 90 years of bank regulation could not solve. Let this spread, and the army of bank regulators, lobbyists, lawyers, and associated politicians can all go, well, drive for Uber.

Somehow I doubt that will be the response from foresaid army. And SoFi might well want to invest in its own lawyers, lobbyists and politicians in today's America.
Rather than by the FDIC, SoFi is monitored by the Consumer Financial Protection Bureau. The overbearing regulator that was Elizabeth Warren’s brainchild thus far hasn’t come down on SoFi—the CFPB is perhaps too preoccupied with using “disparate impact” analysis of old-school auto-loan businesses to focus on a relatively exotic, app-based form of banking. But Mr. Cagney should watch his back.
Indeed he should. In today's rather rule-free environment, the CFPB -- or Department of Justice -- might just discover it doesn't like the demographics of Stanford MBAs as target borrowers.
He’d like to get a national lending license, but that would entail federal-oversight entanglements he’d rather avoid.
If he can.

A little puzzle crops up at the end. For now, I gather SoFi does not issue public equity. The plan for expansion is
insurance companies and sovereign-wealth funds might rent him their balance sheets. 
I'm not sure what "rent a balance sheet" means, but it sounds a lot like private equity or long term debt.  It would be even better for stability and low cost to issue public equity, which is liquid -- investors who need money fast can sell. But public equity comes with its own regulatory scrutiny, and perhaps even that is too much for innovation these days.

Thứ Năm, 28 tháng 4, 2016

Enhancing App Security on Google Play

Posted by Eric Davis, Android Security Team



We’re constantly investing in new tools and services to help developers build secure Android applications. This includes the application sandbox and Security APIs in the platform, Security APIs in Google Play Services, and even open source testing tools. Last year, Google Play also helped developers enhance the security of their applications by looking directly at the code they’ve written and offering suggestions for improvements.



The Google Play App Security Improvement Program is the first of its kind. It has two core components: We provide developers with security tips to help them build more secure apps, and we help developers identify potential security enhancements when uploaded to Google Play. This week, to help educate developers, Kristian Monsen, one of our engineers, gave a presentation about security best practices at the Samsung Developer Conference. And in 2015, we worked with developers to improve the security of over 100,000 apps through the program.



How it works



Before any app is accepted into Google Play, it is scanned for safety and security, including potential security issues. We also continuously re-scan the over one million apps in Google Play for additional threats.



If your app is flagged for a potential security issue, you will be notified immediately to help you quickly address the issue and help keep your users safe. We’ll deliver alerts to you using both email and the Google Play Developer Console, with links to a support page with details about how to improve the app.






Typically, these notifications will include a timeline for delivering the improvement to users as quickly as possible. Applications may be required to make security improvements before any other app updates can be be published.




You can confirm that you’ve fully addressed the issue by uploading the new version of your app to the Google Play Developer Console. Be sure to increment the version number of the fixed app. After a few hours, check the Developer Console for the security alert; if it’s no longer there, you’re all set!



The success of this program rests on our partnership with you—the developers of apps on Google Play—and the security community. We’re all responsible for providing safe, secure apps to our users. For feedback or questions, please reach out to us through the Google Play Developer Help Center. To report potential security issues in apps, please reach out to us at security+asi@android.com.














Thứ Tư, 27 tháng 4, 2016

Developing for Direct Boot

Posted by Wojtek Kaliciński, Developer Advocate



Starting with Android N, a device that has been powered on can boot into a new mode called Direct Boot before the user has a chance to unlock it for the first time. In this mode, the operating system is fully operational, but access to private app data is limited and only apps that have been updated to be Direct Boot aware can run.



Is Direct Boot right for my app?


Not every app should run in Direct Boot mode, so before you start coding check if your app fits these common use cases:



  • Apps that schedule alarms, such as alarm clocks.

  • Apps that provide important and timely notifications, like messaging apps.

  • Apps that provide services to other apps or the system, such as Accessibility Services.



Please note that this is not an exhaustive list and we look forward to seeing what other kinds of apps can benefit from Direct Boot.



Making your app Direct Boot aware


In order to let your app run before the user unlocks the device, you have to explicitly mark components as being Direct Boot aware in the manifest:



 <activity|provider|receiver|service ...  
android:directBootAware=”true”>


You can pick the subset of your app components that need to be Direct Boot aware, but if you are using a custom Application class, it is assumed to be Direct Boot aware if any component inside your app is marked as Direct Boot aware.




For apps that need to run as soon as the system starts in Direct Boot mode, there is a new Intent.ACTION_LOCKED_BOOT_COMPLETED broadcast. All apps will still receive Intent.ACTION_BOOT_COMPLETED after the user unlocks the device.



Using the device protected storage area



To support running apps before the user provides the credentials needed to unlock private app data, all Android N devices now provide two storage locations for data:



  • Credential protected storage, which is the default storage location for all apps, available only after the user has unlocked the device

  • Device protected storage, which is a new storage location that can be accessed at all times when the device is booted, including during Direct Boot



Components of your app that are marked as Direct Boot aware must rely on device protected storage for any data required for their operation during Direct Boot mode. They may still access credential protected storage after the user has unlocked the device.



To access device protected storage you need to create and use a secondary Context object for all file-related APIs:



 Context deviceProtectedContext = context.createDeviceProtectedStorageContext();  
deviceProtectedContext.openFileInput( ... )


When your app gets updated to a Direct Boot aware version, you might have previously saved Shared Preferences or databases that need to be migrated to device protected storage. You should use Context.moveSharedPreferencesFrom() and Context.moveDatabaseFrom() before accessing them to make sure the app continues to work properly even when data is backed up and restored from older versions or other devices.



Things to watch out for



You should think carefully about what you put in the device protected storage. This should be a minimum set of data that will let your app work during Direct Boot. For example, in a messaging app you could store an access token with a narrow scope that only has access to the number of new messages on your server. All sensitive, private information, like the full message history and a read/write access token, should still be saved in credential protected storage.



Another thing to remember is that during Direct Boot apps can only access other Direct Boot aware apps and components. If your app depends on external Services and Activities, make sure you gracefully handle the situation when they’re not available. Intent filters will by default match only components available in the current user state (locked / unlocked). There are two new flags for explicitly telling the Package Manager which components to enumerate: PackageManager.MATCH_DIRECT_BOOT_AWARE and PackageManager.MATCH_DIRECT_BOOT_UNAWARE.



What’s next?


Until devices with Android N that support Direct Boot out of the box are released, you can test your apps using Android N Developer Preview builds. On Nexus 5X and Nexus 6P, you can wipe all user data and enable full Direct Boot mode by using Settings > Developer options > Convert to file encryption. Alternatively, you can reboot into bootloader and issue the appropriate fastboot command:



 $ adb reboot-bootloader  
$ fastboot --wipe-and-use-fbe


Warning: Both methods will perform a factory reset and delete all user data on your device.



Alternatively, you can use an emulated Direct Boot mode. To enable it, set a lock pattern on the device, choose "No thanks" if prompted for a secure start-up screen when setting a lock pattern, and then use the following adb shell commands to enable and disable emulation:



 $ adb shell sm set-emulate-fbe true  
$ adb shell sm set-emulate-fbe false


Please note that using these commands will cause your device to reboot. You should only be using emulated Direct Boot mode on test devices, as it may cause data loss.



#BuildBetterApps



Follow the Android Development Patterns Collection for more!

































Thứ Ba, 26 tháng 4, 2016

Android Studio 2.1 supports Android N Developer Preview

Posted by Jamal Eason, Product Manager, Android



With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.



Android Studio 2.1 includes the following new features:



  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.

  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.




Deeper Dive into the New Features



N Developer Preview



On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.



Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.





N Developer Preview on the new Android Emulator



Instant Run & General Build Performance Improvements



Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.



In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.



We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.



We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.



What's Next



Update



If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.



Test and Validate Apps with N Developer Preview



After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.




We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

























Macro Musing Podcast

I did a podcast with David Beckworth, in his "macro musings" series, on the Fiscal Theory of the Price Level, blogging, and a few other things.



(you should see the link above, if not click here to return to the original).

You can also get the podcast at Sound Cloud, along with all the other ones he has done so far, or on itunes here.  For more information, see David's post on the podcast.

Thứ Hai, 25 tháng 4, 2016

Building TV Channels

Posted by Josh Gordon, Developer Advocate



Channel surfing is a popular way of watching TV. You pick up the remote, lean back, and flip through channels to see what’s on. On Android TV, app developers can create their own channel-like experiences using the TV Input Framework.




To the user, the channels you create look and feel just like regular TV channel. But behind the scenes, they stream video over the internet. For example, you can create a channel from a video playlist.



Watch this DevByte for an overview of how to build to a channel, and see the sample app and developer training for more info. The sample shows how to work with a variety of media formats, including HLS, MPEG-Dash, and HTTP Progressive.







If you already have an app that streams video, consider also making your content available as a channel. It’s a great opportunity to increase engagement. We’re excited to see what you develop, and look forward to seeing your content on the big screen!

Protecting against unintentional regressions to cleartext traffic in your Android apps

Posted by Alex Klyubin, Android Security team



When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.



Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.



Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.



New protection mechanisms



For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.



Block cleartext traffic in production



To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.



You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.



Please note that WebView does not yet honor this feature.



And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.



Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.



Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.



Detect cleartext traffic during development



To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.



Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.



Declare finer-grained cleartext policy in Network Security Config



Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.



Next steps



It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!



As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com.
HTTPS, Android-Security




























Blinder on Trade

Alan Blinder has an excellent op-ed in the WSJ on trade. It's hard to excerpt as every bit is good.
1. Most job losses are not due to international trade. Every month roughly five million new jobs are created in the U.S. and almost that many are destroyed, leaving a small net increment. International trade accounts for only a minor share of that staggering job churn. ...

2. Trade is more about efficiency—and hence wages—than about the number of jobs. You probably don’t sew your own clothes or grow your own food. Instead, you buy these things from others, using the wages you earn doing something you do better.  ...
3. Bilateral trade imbalances are inevitable and mostly uninteresting. Each month I run a trade deficit with Public Service Electric & Gas. They sell me gas and electricity; I sell them nothing....

4. Running an overall trade deficit does not make us “losers.”...

5. Trade agreements barely affect a nation’s trade balance. ..a nation’s overall trade balance is determined by its domestic decisions, not by trade deals... America’s chronic trade deficits stem from the dollar’s international role and from Americans’ decisions not to save much, not from trade deals. Trade deficits are not a major cause of either job losses or job gains. ...trade makes American workers more productive and, presumably, better paid.
One could say much more. Trade is not a "competition," for example. But,  having done this sort of thing, I'm sure lots of other good bits are on the cutting room floor.

Alan is more sympathetic to government "help" to trade losers, which I agree sounds nice if it were run by the benevolent and omniscient transfer payment planner, but I think works out poorly in practice when we look at the success or failure of actual trade adjustment programs. But that is a small nitpick.

Alan closes by wishing that Bernie Sanders and Donald Trump understood these simple facts a bit better. I think his list of politicians needing enlightenment could be a little longer. But he's courageous enough for speaking the kind of heretical truth that will come back to haunt him should he ever want a government job.

An Outsourcing Playbook for Android development

Posted by Rupert Whitehead, Developer Relations



We recently updated The Secrets to App Success on Google Play with tools and tips to help app and game developers grow successful businesses on Google Play. However, many great apps are created by agencies and freelancers on behalf of companies. Today, we’re releasing a new playbook to help companies of any size who are considering outsourcing their Android app development.



How do you choose an agency? What are the pitfalls you should avoid? What can you do to make your app successful? These are some of the questions tackled by the new Outsourcing Playbook that you can read on Google Play.














Let us know your feedback



Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve our developer resources and support. Let us know what you think.

Thứ Bảy, 23 tháng 4, 2016

Lessons Learned I

I spent last week traveling and giving talks. I always learn a lot from this. One insight I got:  Real interest rates are really important in making sense of fiscal policy and inflation.

Harald Uhlig got me thinking again about fiscal policy and inflation, in his skeptical comments on the fiscal theory discussion, available here. At left, two of his graphs, asking pointedly one of the standard questions about the fiscal theory: Ok, then, what about Japan? (And Europe and the US, too, in similar situations. If you don't see the graphs or equations, come to the original.) This question came up several times and I had the benefit of several creative seminar participants views.

The fiscal theory says
 \[ \frac{B_{t-1}}{P_t} = E_t \sum_{j=0}^{\infty} \frac{1}{R_{t,t+j}} s_{t+j} \]
 where \(B\) is nominal debt, \(P\) is the price level, \(R_{t,t+j}\) is the discount rate or real return on government bonds between \( t\) and \(t+j\) and \(s\) are real primary (excluding interest payments) government surpluses. Nominal debt \(B_{t-1}\) is exploding. Surpluses \(s_{t+j}\) are nonexistent -- all our governments are running eternal deficits, and forecasts for long-term fiscal policy are equally dire, with aging populations, slow growth, and exploding social welfare promises. So, asks Harald, where is the huge inflation?

I've sputtered on this one before. Of course the equation holds in any model; it's an identity with \(R\) equal to the real return on government debt; fiscal theory is about the mechanism rather than the equation itself. Sure, markets seem to have faith that rather than a grand global sovereign default via inflation, bondholders seem to have faith that eventually governments will wake up and do the right thing about primary surpluses \(s\). And so forth. But that's not very convincing.

This all leaves out the remaining letter: \(R\). We live in a time of extraordinarily low real interest rates. Lower real rates raise the real value surpluses s. So in the fiscal theory, other things the same, lower real rates are a deflationary force.

The effect is quite powerful. For a simple back of the envelope approach, we can apply the Gordon growth formula to steady states. Surpluses \(s\) grow at the rate \(g\) of the overall economy. So, in steady state terms,
 \[ \frac{B_{t-1}}{P_t s_t} = E_t \sum_{j=0}^{\infty} \frac{(1+g)^j}{(1+r)^j} \approx \frac{1}{ r - g} \]
\[ \frac{P_t s_t}{B_{t-1}}  \approx  r - g \; \; (1) \]
(and exact in continuous time). The left hand side is the steady state ratio of surpluses to debt. The right hand side is the difference between the real interest rate and the long-run growth rate.

So, with (say) a 2% growth rate g, and a 4% long-run interest rate r, surpluses need to be 2% of the real value of debt. But suppose interest rates decline to 3%. This change cuts in half the needed long-run surpluses! Or, holding surpluses constant, if long-run interest rates fall to 3%, the price level falls by half.

You can see the punchline coming. Long term real interest rates are really low right now. If anything, we're flirting with \(r \lt g\), the magic point at which governments can borrow all they want and never repay the debt.

With this insight, Harald should have been asking of the fiscal theory, where is the huge deflation? And the answer is, well, we're sort of there. The puzzle of the moment is declining inflation and even slight deflation despite all our central bankers' best efforts.

Pursuing this idea, there is a larger novel story here about growth, interest rates, and inflation.

Obviously, there is an opposite prediction for what happens when real interest rates rise. Higher real rates, unless accompanied by higher surpluses, will drive inflation upwards.

In conventional terms, looking at flows rather than present values, suppose a government that is $20 Trillion in debt faces interest rates that rise from 2% to 5%. Well, then it has to increase surpluses by $600 billion per year; and if it cannot do so inflation will result.

A similar story makes sense for the cyclical falls in inflation. What happened to our equation in 2008?  Surpluses fell -- deficits exploded -- and future surpluses fell even more. Debt rose sharply. Why did we see deflation? Well, real interest rates on government debt fell to unprecedentedly low levels. This really isn't even economics, it's just accounting. The equation holds, ex-post, as an identity!

To think a bit more about real rates, growth, and inflation, remember the standard relation that the real interest rate equals the subjective discount rate (how much people prefer current to future consumption) plus a constant times the per capita growth rate
\[ r = \delta + \gamma (g-n) \]
The constant \(\gamma\) is usually thought to be a bit above one.

With \(\gamma=1\) (log utility), then we have \(r-g = \delta-n\). The magic land of unbounded government debt can occur because government surpluses can grow at the population growth rate, while interest rates are determined by the individual growth rate. But population growth is tapering off, and must eventually cease, and bondholders prefer their money now. With \(\gamma \gt 1 \) ,
\[ r-g = \delta - n + (\gamma-1)(g-n) \; \; (2)\]
The new term is the per capita growth rate, which is positive, further distancing us from the land of magic.

More to the point, though, we now have before us the central determinant of long run real interest rates. Real interest rates are higher when economic growth is higher. And \(r-g\) rises when economic growth \(g\) rises.

So, going back to my equation (1), we actually had a puzzle before us. Higher real interest rates would mean lower values of the debt, and would thus be inflationary if not accompanied by austerity to pay more to bondholders. But higher real interest rates must come with higher economic growth, and higher economic growth would raise surpluses, helping the situation out. Which force wins? Well, equation (2) answers that question: With \(\gamma \gt 1\), the usual case (a 1% rise in consumption growth comes with a more than 1% rise in real interest rates), higher growth g comes with higher still interest rates r, and thus remains an inflationary force, again holding surpluses constant.

All in all then, we have the hint of a fiscal theory Phillips curve: Inflation should be procyclical. In good times, interest rates rise and the real value of government debt falls, producing more inflation. In bad times, interest rates fall and the real value of government debt rises, producing less inflation.

Central banks have been absent in all this. The natural next question is, does this provide another reinforcing channel by which central banks might raise inflation if they raise interest rates? I don't think so, but one needs more equations to really answer the question.

What matters here are very long-term real interest rates, the kind that discount expectations of surpluses -- yes, we need some surpluses! -- 20 to 30 years from now to establish bondholder's willingness to hold debt today.

In no model I have played with can central banks affect real interest rates for that long. I think a quick look out the window convinces us that central banks cannot substantially raise interest rates in a slump, with supply of global savings so strong compared to demand for global investment. Long-term interest rates really must come from supply and demand, not monetary machination. Higher real interest rates require higher marginal products of capital, and thus higher economic growth, not louder promises, more speeches, or more energetic attempts to avoid the logic of a liquidity trap.


Thứ Năm, 21 tháng 4, 2016

The Google Play Awards coming to Google I/O

Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play



Google Play has seen tremendous growth over the past year, reaching more than 1 billion Android users across 190 countries. As a way to recognize our incredible developer community and highlight some of the best apps and games, we’re kicking off our first-ever Google Play Awards.





The program will showcase five nominees across 10 award categories and feature them in a dedicated collection on Google Play. Nominees were selected by a panel of experts on the Google Play team based on criteria emphasizing app quality, innovation, and having a launch or major update in the last 12 months. The winners of each category will be announced at Google I/O in May.



The full list of categories and nominees are below:



Standout Startup


Apps from new developers that offer a unique experience while achieving strong install growth. And the nominees are...

























Dubsmash
Hopper
Musical.ly
Robinhood
Vrse


Standout Indie


Games from indie developers that focus on artistic design, high quality and innovative gameplay. And the nominees are...

























Alphabear
Alto’s Adventure
Fast like a Fox
Neko Atsume: Kitty Collector
Prune



Best Families App


Apps or games with family friendly design that encourage creativity and exploration. And the nominees are...

























Card Wars - Adventure Time
LEGO Jurassic World™
My Very Hungry Caterpillar
Thinkrolls 2
Toca Nature


Best Use of Material Design


First-class implementation of material design concepts that deliver an immersive and innovative user experience. And the nominees are...
























Bring!
Robinhood
The Fabulous
Todoist
Vevo



Best Use of Google Play Game Services


High quality games with several strong GPGS feature implementations. And the nominees are...


























Sea Battle 2
Table Tennis Touch
Tapventures
TowerMadness 2
Zombie Highway 2



Early Adopter


Early adopter of a nascent technology or platform, providing a delightful user experience. And the nominees are...


























Glide
Mechanic Escape

Minecraft: Story Mode
World Around Me

Zumper



Go Global


Apps or games with great localization and culturalization, or subject matter appeal, across multiple regions. And the nominees are...


























Dragon Ball Z Dokkan Battle
Freeletics Bodyweight

Memrise
Musixmatch
Pokémon Shuffle Mobile



Most Innovative


Apps or games offering a highly engaging novelty experience or unique benefit. And the nominees are...


























Fast like a Fox
NYT VR

SmartNews
The Fabulous
This War of Mine



Best App


A true representation of beautiful design, intuitive UX and high user appeal, quality and rating. And the nominees are...



























BuzzFeed News
Colorfy

Houzz
TuneIn Radio
Yummly


Best Game


Games with strong mechanics, informative tutorial, broad appeal and tasteful design. And the nominees are...

























Alphabear
Clash of Kings

Clash Royale
MARVEL Future Fight
Star Wars™: Galaxy of Heroes



Join us live at the ceremony on May 19th at 7:00 pm PDT on stage 7 at Google I/O or via the live stream. You can also track the conversation on Twitter and G+ using the hashtags #io16.