Think Like a Martian About Money and Universal Basic Income - <AUTHOR> https://medium.com/basic-income/think-like-a-martian-about-money-and-universal-basic-income-ubi-d543922f06d3 <comment><USER2> > Think about that fact for a moment through Martian eyes. Humans are the only > species on planet Earth who have to pay to live here.

Right, other species are just fighting daily for their territory and their life...

<comment><USER3> Yes, so we should be less like animals. People should be allowed to live without having to "earn a living" \-- the daily struggle for survival would be abolished by UBI.

<comment><USER2> Actually I'm not against UBI, but I don't think that the martians argument about the money system was a good one: the current system is just much civilized than anything that existed before as far as I can tell.

UBI may be part of the next evolutionary step of society, we'll see, but I'm slightly bothered that it relies on the comfort and the wealthiness of the "first world" built to the detriment of the "third world". I personally feel that "people should be allowed to live" would be more convincing to me if it was about worldwide inequality rather than UBI in westerner society.

</comment></comment></comment><comment><USER4> > Thinking as a Martian, if humans were to decide to trust everyone a minimum > amount, such that no human had no trust, but every human had some trust, and > that amount of trust was sufficient for everyone to obtain a minimum amount > of access to the resources necessary for life, then everything would change.

This is looking at human beings from a personal standpoint. You have to look at humans as a group and decide what the Nash equilibrium looks like. If everyone tried to trust a minimum amount, there is a large incentive on single individual to break that trust and gain benefits. You need some kind of system to dis incentivize people from breaking trust. Guess what that's what law and order is. But unfortunately nations haven't been able to agree on common international law because the Nash equilibrium in the group of nations happens to be different.

While I applaud the optimism of the writer, the piece is too rosy and void of facts/theoretical framework for me to appreciate it.

</comment><comment><USER5> Terrible article. The first half is overly long and feels like it's just anti capitalism rather than pro ubi

The rest is just appeals to emotion. The worst offender being here

> We have piles of evidence that a world without UBI is hugely expensive in so > many ways.

With nothing to say that a world with UBI isn't.

<comment><USER6> I relate to this sentiment. This is the best system we got so far, would UBI even work here?

</comment></comment><comment><USER6> This is nihilist lenses not martian eyes (anthropologist).

This way of working stuff is the reason we have some level of human dignity. Before civilization things where far worst.

</comment><comment><USER7> A related notion:

[https://en.wikipedia.org/wiki/Veil_of_ignorance](https://en.wikipedia.org/wiki/Veil_of_ignorance)

</comment><comment><USER8> The problem with universal basic income is that none of the ways to pay for it are palatable. Let's assume for instance that we want a UBI of something like 20% of per capita gdp. Either we (a) cut spending from existing government programs or (b) raise taxes.

It is often suggested that the UBI can replace existing social welfare programs and save money in the long run by cutting out administration costs. First, administration costs are already quite low, social security administration costs in the US for example are usually around 2-3% of total outlays and there is no real reason to believe that similar old age pension programs in other countries are any less efficient. Secondly, existing government programs are usually significantly more generous than a proposed UBI to the recipients of such programs. Cutting existing spending means that the existing users of government welfare will suffer a massive drop in living standards. Leaving outside the moral consequences of imposing austerity on the most vulnerable in society this point is almost never acknowledged by proponents of a UBI.

Raising taxes is the second option but this is even more problematic than diverting existing government spending. Western governments already impose significant taxation on citizens. If you are living in a rich country with tax receipts over 50% of GDP increasing taxes by over 40% basically means restructuring your entire economy. Since income taxes are already quite high you will almost certainly need some mix of increases in payroll and sales taxes to meet the fiscal demands of a UBI. The poor can't reasonably be exempted from this increased taxation as their income will either be hit by increased consumption taxes on almost every good or service they purchase or their after tax income will be hit by the higher payroll taxes. Trying to means test the payroll tax increase won't work as governments will no longer be able to raise enough income to afford a UBI if they try to carve out exemptions for the poor and lower middle class. Assuming you are comfortable with these tradeoffs and the perverse incentives usually created as people try to avoid the large increase in taxes you will be faced the reality that the UBI will not go nearly as far as it would before the additional taxes are imposed. Not only have you given every worker a pay cut you have also increased the price of almost every good they could conceivably purchase with their new income. Finally, such a large increase in taxation will almost certainly impose a dramatic cost in economic activity. Increasing taxation from 50% to 70% of total economic output is far beyond what even the richest countries can support in taxation. No Scandinavian country is even remotely close to this level for example.

The net result is a trilemma in implementing a UBI that cannot be avoided:

a) if you reduce the level of the UBI below what a reasonable person could subsist on you defeat the entire point of having a UBI in the first place b) if you cut existing government spending welfare recipients and existing users of government programs will be massive net losers c) dramatic increases in taxation are beyond what is generally considered possible to put it politely

Silly articles like this on the UBI never bring up _any_ of the public policy issues that must be addressed to implement a UBI and it's pretty clear why. The UBI as I see it proposed incessently is basically the perpetual motion machine of political thought

<comment><USER9> I suggest you look at Andrew Yang's 2020 platform of Freedom Dividend and explanation of how to pay for it.

Yang would offer each person an annual choice between existing benefits or an unconditional transfer payments (UBI). This allows for an easier transition to more UBI while preventing lapses in important benefits for those who need it.

As for the pay-fors: You do NOT need a policy proposal to be revenue neutral (ie 100% paid for by spending reductions and/or tax increases) if it grows the economy or if it saves costs elsewhere in the system. This is true of any policy. We have never paid for our spending during and after WW2, but that doesn't matter because we grew our economy as to make that debt trivial to the size of the economy.

In UBIs case, we have strong evidence from studies that it tends to improve health (especially child health), reduces crime, and increases business creation (a stable albeit small income is a fantastic platform for entrepreneurship), among other benefits. How much does it cost society to fail to eradicate below-poverty incomes? How about failing to end involuntary homelessness? UBI is the cheapest way to get those things.

Back to Andrew Yang's plan: 1) Institute a 10% VAT. 2) Save on reductions in social services (to the degree Freedom Dividend is chosen) 3) Remaining balance paid with deficit spending, growing the economy and reducing upstream costs.

<comment><USER8> Except he doesn't explain how to pay for it as far as I can tell. He has four funding sources that don't come close to adding up to the $3 trillion he would need to fund a UBI. The $800 billion for a vat is incredibly generous but even assuming that he can only come up an additional $500 billion by assuming that everyone will prefer a UBI over other government programs. He also assumes $100-200 billion will be saved by the government due to lower costs of other government programs.

Even assuming everything adds up that still only gets you to $1.5 trillion, you still to come up with another trillion at least! Borrowing the money will result in the US running the largest peacetime budget deficit of any developed country ever. A budget deficit of 15% of GDP would be at least 3 times what the budget deficit was at the height of the Reagan era. It's simply disingenuous to claim that this is par for the course for advanced economies. It isn't.

</comment></comment></comment><comment><USER10> Money was invented as a way of collectively keeping track of who owes what to whom. To abolish it from "the martian perspective" would be to abolish interaction by consent, which has variously been termed slavery and rape throughout the years here on Earth.

<comment><USER3> UBI would not abolish money. It would actually create more money for everyone, and having a guaranteed minimum income would allow people to enter into employment relationships on a purely voluntary basis, because they would have the option to abstain from work.

<comment><USER11> "Create more money"? If you mean printing more money, than we just get inflation, otherwise giving money doesn't create any new value by itself, it's just money changing hands.

<comment><USER3> Yes, UBI would likely contribute to some inflation -- a little bit of inflation is good, necessary, and unavoidable. It would also act as a massive stimulus to the economy, while also empowering economically-disenfranchised people to enter into the market, from which they are barred from participating in without money.

One way to fund a UBI would be through a value-added tax, which would be collected at every stage of production where money is exchanged.

<comment><USER10> Inflation is an unvoted and unregulated tax; being a flat tax it is regressive and it vastly disproportionately (negatively) affects the poor.

It is not good, nor a benefit.

<comment><USER3> Inflation is not a tax: there is no government entity that collects inflation payments.

Not having any money is worse for the poor than having a basic income, even if there is inflation. The market has no direct incentive to serve those without money. The alleviation of widespread human suffering due to poverty and the massive increase in the general utility of the market to humans clearly makes UBI the moral choice.

Inflation does benefit debtors: with money being cheaper, loans are easier to pay off.

<comment><USER10> > _Inflation is not a tax: there is no government entity that collects > inflation payments_

Quite the opposite; when new money enters circulation it is spent (by those doing the printing) at the pre-inflation value of the notes.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> as a wise man once said, a fool believes and acts as what other fools told him too, but a wise man who does not understand that becomes a fool!

</comment><comment><USER13> Anyone who found this line of thinking intriguing, I would like to recommend a book by Ursula Le Guin, The Dispossessed.

It's a story that follows a mathematical genius who lives on a primitive and poor but utopic anarchic planet.

His planet, however, orbits a planet very similar to ours. Due to his discoveries, one of the countries on the earth like planet asks him to continue his work on their planet. During his time there, he explores the danger, sickness and wonders our beliefs and system of capitalism creates.</comment>


String.intern() - <AUTHOR> https://shipilev.net/jvm-anatomy-park/10-string-intern/ <comment><USER2> Every time I see String.intern() my mind leaps to the problem of new Java programmers who are misled into this:

        String a = "hello";
        String b = "world";
        assert a != b;
        b = "hello";
        assert a == b;
        // OH NICE I'LL USE == FOR STRING COMPARISONS NOW

It works cause source-code literals are intern'ed down into identical objects by the compiler, but that's a special case that won't apply to strings created at runtime.

<comment><USER3> _new Java programmers_

Or perhaps _interns_? ;-P

In fact, I've wondered about the origins of the term "intern" since I first heard of it; the technique was already known to me and likely others as "tokenising" before that, however, since compilers would often have to compare identifiers and doing this to them made it much faster.

<comment><USER4> > In fact, I've wondered about the origins of the term "intern" since I first > heard of it

I always assumed it came from internalize, or something like that.

<comment><USER5> I was curious, but a good amount of Googling didn't turn up any etymology.

I'll take a guess, though, that it's from Common Lisp, because CL's intern function ([http://clhs.lisp.se/Body/f_intern.htm](http://clhs.lisp.se/Body/f_intern.htm)) is clearly part of a suite of names (intern, unintern, :internal, :external) where, in context, "intern" makes complete sense as the name for the function.

<comment><USER6> Usage of "intern" in this sense is much older than Common Lisp. The earliest reference I could find in a few minutes of searching is from 1974, from the MACLISP Reference Manual:

[http://www.softwarepreservation.org/projects/LISP/MIT/Moon-M...](http://www.softwarepreservation.org/projects/LISP/MIT/Moon- MACLISP_Reference_Manual-Apr_08_1974.pdf)

See sections 6.3 and 6.4 and the glossary for definitions and uses of the word.

Unfortunately they don't shed any light on where the term "intern" comes from. Typical usage is that a string is «"interned" or registered in an obarray» but it doesn't explain much more than that. Interning occurs most often at read time, when a string read from the input is turned into an atom, so I'd guess that "intern" is short for "internalize" or similar.

<comment><USER5> Well, I was about to say, the Common Lisp version makes enough sense (and the MacLisp version might be equivalent, for all I know):

In CL, you don't really have a global "symbol table" or "atom table"; instead, interning is about the runtime lexical scopes under which code compilation happens, which consist of stacks of imported namespaces ("packages"), where each namespace exists as a mutable object holding identifier "slots".

(intern foo) is a mutation on the current namespace that creates a local variable "slot" for the identifier foo, shadowing any other foo that might have been in lexical scope from an import. That is, (intern foo) makes foo resolve _internally_ to the current namespace.

(unintern foo) is the complementary mutation; it drops the foo identifier from the current namespace, allowing other symbols (slots in packages) that were previously shadowed by it to re-appear.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is really an unscientific claim but I ran a hand crafted/hacked benchmark just to get a feeling for the numbers. For 5 to 35 character Strings, == is 20 to 40 times faster than String.equals().

Given that s1.equals(s2) if and only if s1.intern() == s2.intern() (assuming you haven't filled the string table), then this looks like an opportunity for a significant optimization.

Before doing this, I had hoped that String.equals might check if both were "interned" and shortcut the character by character comparison if this was the case by just comparing references. But interpreting the results of my rough benchmark would suggest this isn't what is happening which would agree with the source provided for the String.equals method.

Java String comparison is absolutely ubiquitous so I would have expected that an optimization like this might have been considered?

Having said that, the supplied rt.jar source also suggests that the String.hashCode() computation isn't cached/memoized. This strikes me as odd given that Strings are immutatable and Strings are one of the most common key type for Maps.

<comment><USER8> You should compare the cost of one (or two) .intern() plus '==' against a single .equals()

For example, if your code needs 10 .intern() and then performs 100 '==', that is _possibly_ going to be faster than performing the equivalent 100 .equals() (or maybe not)

But if you are comparing a single couple of strings, .equals() is always going to be faster.

Not to mention that if you .intern() random strings, you risk running out of PermGen space. Even in the case of 100 comparisons among 10 strings, you may be better off using a custom HashMap.

You can find all this information in the article.

<comment><USER7> I'm not suggesting that .equals() should be implemented by 2 inter() operations followed by a reference comparison. But that the implementation check whether the pair of Strings happened to be already .intern()ed, and then use the short circuit of a reference comparison.

A programmer could then decide to intern _some_ non-constant Strings in their application if it made sense (i.e. they were frequently used in comparisons or as hash keys).

And I don't think you can't run out of permgen as the String pool is a fixed size - unless I am misreading that section of the article.

However now that I've thought about a bit more, I think the flaw in the idea is unrelated to your points but that currently it's not cheap to determine if a particular String is interned. The StringTable implementation would have to be changed otherwise it would require adding storage overhead to every String which would not be acceptable. This is also probably why .hashCode() doesn't memoize it's results.

</comment></comment></comment><comment><USER9> Total aside from main topic, I love shipilev's posts.

If there are other core JVM developers that have similar blogs, I'd love to hear about them here.

</comment><comment><USER10> We built an inmemory map and we were using String.intern for both keys and values. We could see that we were saving lots of memory but we had the problems described in the article. We then built our own 'String.intern' by using yet another static HashMap. It worked. It was the simplest alternative and it just did the job. Thanks alekskey for the nice article.

</comment><comment><USER11> I'd never seen the @Benchmark annotation before so I looked it up.

The blog author is also one of JMH's authors.

[http://openjdk.java.net/projects/code- tools/jmh/](http://openjdk.java.net/projects/code-tools/jmh/)

</comment><comment><USER12> Have been doing Java for 14 years so far, never ever needed the .intern(). I can imagine it's use-case, but anyway does seem pretty rare case.

<comment><USER13> Deserializing tons of records all having one of a few values for a particular field is an easy and probably fairly common use case.

</comment></comment><comment><USER14> Is "Anatomy Park" a Rick and Morty reference? [http://rickandmorty.wikia.com/wiki/Anatomy_Park_(episode)](http://rickandmorty.wikia.com/wiki/Anatomy_Park_\(episode\))

</comment><comment><USER15> Please consider adding "JVM Anatomy Park" to the title.

</comment><comment><USER16> The code creates unique strings to "interns" which most likely isn't what would happen in a real world application (unless you know... code without thought), you'd inter strings with low variance usually. Not saying that it won't be slower but the memory usage might be lower.

<comment><USER4> Yeah, blindly interning strings isn't a good idea, but it can be useful for certain use cases. For example, keys of maps where you know the keys won't vary much. It can reduce memory usage, and improve lookup performance (since doing a lookup requires a string comparison).

</comment></comment><comment><USER17> This, and the few other articles up, are a great series. Having done Java development now for 30% of my life these are some amazing pointers.

I'd love to buy a hard copy of these if they ever get up to a few dozen articles. Would be good to give to middle-experience devs (like myself) in the future.

<comment><USER18> Some good content along the same vein with 16 years worth of articles: [http://www.javaspecialists.eu/](http://www.javaspecialists.eu/)

</comment></comment><comment><USER19> "The performance is at the mercy of the native HashTable implementation, which may lag behind what is available in high-performance Java world, especially under concurrent access."

What native HashTable is used? Shouldn't the JVM be using an optimized one?

<comment><USER20> I think by "native" they mean "implemented-in-c++-by-the-JVM", which potentially vary; not java.util.HashTable, which should be pretty standard across JVM implementations.

<comment><USER21> Yes, although Hashtable is legacy from JDK 1.0. New code should use HashMap or ConcurrentHashMap.

<comment><USER22> Please be careful with blanket statements like this. HashMap, Hashtable and ConcurrentHashMap behave differently in certain (subtle?) ways. ConcurrentHashMap doesn't like NULL but is thread-safe. Hashtable is synchronized, slow and thread-safe, but doesn't mind NULL. HashMap is not thread safe and doesn't mind NULL.

Edit: pardon the dupes, on unreliable mobile link :-(

<comment><USER23> > Hashtable is synchronized, slow and thread-safe, but doesn't mind NULL.

The issue with Hashtable or rather all legacy collection classes is that the API is rarely useful without additional synchronization. So you might as well use a HashMap wrapped by Collections.synchronizedMap or use a ConcurrentHashMap with a placeholder object instead of null.

</comment></comment></comment></comment></comment><comment><USER24> String.intern() would suck much less if strings had an "IS_INTERNED" flag which would prevent hashtable lookups for already interned strings. Really sad given the insane overhead Java strings have.

<comment><USER25> No, it would suck more, because currently you have an option to avoid string.intern() altogether (and that is what you should do), and pay nothing for that in runtime. Another boolean flag may cost extra 4-8 bytes on the heap for each String object, whether you use String.intern() or not.

</comment></comment><comment><USER26> > in OpenJDK, String.intern() is native, and it actually calls into JVM, to > intern the String in the native JVM String pool.

How much of this also applies when using the standard Oracle JDK?

</comment><comment><USER27> It would be interesting to know where it's used, was it used in the JDK for example?

</comment><comment><USER28> Also see:

XInternAtom (XWindow function)

RegisterClass (Windows)

</comment><comment><USER29> The instrumentation here is impressive. The amount of data inspection done with just a few simple commands is a bit overwhelming. Frankly, I rarely hope to find myself looking at this level of metrics.

There's a lot down there I like to take for granted. But more likely I try to use methods like string.Intern() exactly never.

Use code you know and understand. Frankly, use code you can trust. And wtf would trust a method string.Inter() to do... exactly, what?

If you are writing a function to _do something_ the name of the function must be the thing being done. What the heck is a 'static internalize'? The explicit HashMap was a few lines of code, and it's the most basic and obvious, and surprisingly performant approach. So definitely I agree you must use your own HashMap and not a static internalizer.</comment>


Greasemonkey script to de-scribd HN PDFs - <AUTHOR> http://clayvalet.com/describd.user.js

<comment><USER2> Scribd'ing of the PDFs should be a per-account config option.

I don't mind if it's enabled by default (Scribd being backed by YC and all that), but please allow me to disable this rather annoying feature.

<comment><USER3> PDFs actually load faster than the equivalent Scribd pages on my machine. Not sure why is this.

<comment><USER4> Same here. And the "Streaming document" progress bar is kind of irritating IMHO

</comment></comment></comment><comment><USER5> Guys, I have a better idea. Let's make a patch for the hacker news source to give both options and submit it to PG.

If you know arc (or want to learn) and are interested in doing this, email me at jared@scribd.

</comment><comment><USER6> Not to hijack, but my blacklist script does this too, if you want a blacklist and a searchyc box as well.

<http://userscripts.org/scripts/show/25039>

<comment><AUTHOR> That's cool. If I had known about yours, I probably wouldn't have bothered, though it was kind of fun learning about Greasemonkey.

I made it in response to the comments here. It's kind of sad that for all the hacker/entrepreneurial spirit here, the default reaction is basically "try asking one more time" (there's even a couple of those in the comments on this post!). We had a poll, and people overwhelmingly voted to at least make it optional, so it's not like they don't know what we want.

So I did something about it. I'm tired of reading endless "Something should be done!" comments, when it's completely in our power to do Something. Here's a Something. You made a Something, too, so I respect that.

<comment><USER6> > though it was kind of fun learning about Greasemonkey

Pretty much the only reason I did this too. ;)

</comment></comment></comment><comment><USER7> Scribding PDFs here is the new page framing. Imagine if every link you submitted appears in a frame with some ads at the top? That would be annoying (and so 1996), I don't see the Scribd thing any differently here. I have _no_ problem downloading PDFs.

<comment><USER8> Yea, _pretty_ sure that's what the Adobe Reader plugin is for...

</comment></comment><comment><USER9> Is this your script? <http://userscripts.org/scripts/show/26925>

If it is, in the future, I'd suggest linking us directly to userscripts.org instead of to a .js. I think that you'll find people are perhaps squeamish about links to a .js file.

<comment><USER10> no, the link you posted is my script.

</comment></comment><comment><USER11> Cool, thanks. This works on Opera too! (user javascript)

</comment><comment><USER12> i like it where it shows it as an element in the page. but for large-screen viewing pdf viewer is better. maybe the autoscribding could show a link to the scribd page (eg [http://www.scribd.com/doc/1469514/TOM-JERRY-dibuixos-per- pin...](http://www.scribd.com/doc/1469514/TOM-JERRY-dibuixos-per-pintar)) instead of the full-screen thingie

</comment><comment><USER13> Cool. Now if you could just convert the PDF to HTML, you'd have something there.

<comment><USER14> There's a Firefox extension to view PDFs as HTML.

<comment><USER15> <https://addons.mozilla.org/en-US/firefox/addon/636></comment></comment></comment>


Disruptions Everywhere - Windows 8 Pricing Strategy - <AUTHOR> http://www.virtualpants.com/post/26416606883/disruptions-everywhere

<comment><USER2> The people overseeing Microsoft's business strategy should really take a look at this article. Virtual Pants hit the nail on the head: "Now they're in the business of maintaining other people's cars for peanuts." A company can't feasibly compete with Apple whose revenue is from hardware and Google whose revenue is from advertisements just by reducing their "Cash Cow" to $40.

</comment><comment><AUTHOR> Like Apple, Google is giving away its OS. Instead of profiting using hardware, Google sells ads. So, both Apple and Google are giving away Microsoft's core product and profiting tangentially in other ways.</comment>


You Have – Idea, Logo and Domain. Want to Execute/Monetize? - <AUTHOR> https://www.indiehackers.com/forum/you-have-idea-logo-domain-want-to-execute-monetize-a9f3310a86 <comment><AUTHOR> Here is the direct link: IdeaLogoDomain.com</comment>


Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it - <AUTHOR> https://blog.teller.io/2016/04/26/tauth.html <comment><USER2> 1\. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a similar capability? The blog post mentions "User Tokens" in passing, but doesn't define or describe them.

2\. OAuth 2.0 is published as an RFC from IETF. It may be a bear to read (and yes, it's a framework rather than a protocol!), but the spec is open, easy to find, and carefully edited ([https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749)). Is TAuth meant as a specification, or a one-off API design? If it's a specification, has there been an attempt to write it down as such?

<comment><USER3> I disagree with your first point. The fundamental problem OAuth solves is secure authentication. OAuth 2.0 provides this at a bear minimum as it can be broken in any way SSL/TLS can be broken.

The argument the author is making is that this level of security is not sufficient for a bank. I think I agree with this statement.

For general use, OAuth 2 provides a sufficient level of security since the platforms that use it are usually only as secure as TLS, too.

<comment><USER4> Nope, authorization. Authentication is left as an exercise for the implementer.

Some people use the ability to be authorized to access an account on e.g. Facebook as a stand-in for authentication, but that's a different issue.

<comment><USER5> Is that not a fair thing to do?

Can we not assume someone with access to a Facebook account is authentically the owner of that Facebook account for all of our intents and purposes?

<comment><USER6> As it is right now, yes. But imagine a scenario where Facebook might implement a child account where a parent has access to monitor the usage.

Now there are two people with authorisation to access this Facebook account so the process no longer unique authenticates a single individual.

Of course this is a contrived example and I'm sure there are better examples. But this is why OAuth is authorisation and not authentication and why something like OpenID Connect exists on top of OAuth2.

</comment></comment></comment></comment></comment><comment><USER7> One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions:

1) MyLittleApp wants OAuth access to BankOfMars

2) MyLittleApp bundles BankOfMars SDK into MyLittleApp

3) MyLittleApp requests oauth access via SDK

4) SDK opens WebView for user to log into BankOfMars

5) MyLittleApp has full control over the DOM presented to the user since the WebView is technically its own.

6) MyLittleApp extracts the user's password from the DOM of the WebView

7) MyLittleApp disappears and... profit?

<comment><USER8> The flow we (Mondo) are considering for this:

1\. MyLittleApp opens web view to log into Mondo

2\. User enters something to identify themselves into the web view (eg. email address, phone number)

3\. We dispatch a notification to the user's registered device (ie. the Mondo app where the user is logged in – this may be the same device or a different device)

4\. User opens the Mondo app and accepts/rejects the authorisation request

5\. User returns to MyLittleApp, OAuth flow completes

In this flow, the user is not exposing their login credentials to the app… at worst, the app could extract their email/phone number. It also introduces another factor into the auth flow: the user's registered device.

<comment><USER9> What's to stop the app (or anyone in the context of a rooted device) replacing the legit Mondo auth page with a shim? Nothing.

<comment><USER10> What does replacing the auth page gain the attacker? At worst the user enters their email address into a phishing page. The important thing is that there isn't a password :)

<comment><USER11> > _What does replacing the auth page gain the attacker?_

If the spoof app has a "Connect with Twitter* (and you don't have the Twitter app installed), and then a webview is opened, the spoof app can replace Twitter's login page with their own, and capture the username and password.

<comment><USER8> In the proposed implementation above, the _only_ piece of information that a user enters inside the web view is a username. The user must then use the native Mondo app on a previously-authenticated device to complete the OAuth flow. The Mondo app could also require biometric (ie. Touch ID) authentication.

While a malicious application can inject JavaScript to intercept the username, this alone is useless to an attacker.

<comment><USER12> Well, the malicious application can inject a password-field, and an unsuspecting user might not realize that (s)he is giving an app/attacker the password, and not the correct third party.

User education only goes so far, this type of attack can also make a web view that traditionally asks for a TOTP one-time password code susceptible to leaking a users password, _even if the normal login flow doesn 't ask for that password_.

[ed: note that it's pretty trivial to eg: set up hidden cameras in voting booths, if you want to spy on a few people, or perhaps have people film themselves in a voting booth - the point is rather that if most people make an effort to follow the common rules wrt. voting booths, the system is reasonably secure. And it's not trivial to make similar claims about a (presumably) centralized on-line system.]

<comment><USER8> On Mondo, there simply are no passwords at all. Instead, when the user wishes to log into our first-party apps, we send a login link to their registered email.

We'll almost certainly add additional required factors to this process (eg. biometrics), as we see the user logging into the Mondo app on a new device as one of the most critical from a security perspective.

<comment><USER12> I hope that's not biometrics in a potentially attacker-controlled web-view (if such a thing is possible) - biometrics are difficult to revoke...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/Z protocols, the author of this post does not truly understand OAuth 2, nor have they looked in any appropriate depth into supplements like OIDC or alternatives.

For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few implementation details (such as how to obtain user info, how to validate an Access Token), which the author seems to just assume are part of the spec, as he does with bearer token. Other parts, like the client/user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec.

> Shared secrets mean no non-repudiation.

Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder.

> Most importantly using JWT tokens make it basically impossible for you to > experiment with an API using cURL.

 _sigh_. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only.

> OAuth 2.0 is simply a security car crash from a bank's perspective. They > have no way to prove that an API transaction is bona fide, exposing them to > unlimited liability.

TL;DR: This article, led by comments like this ("unlimited", really?), strikes me as pure marketing (aimed at a naive audience) for a "spec" that probably would not exist had proper due diligence into alternatives, or perhaps some public discussion, occurred. At the very least, inconsistencies (a few of which I've mentioned above) could have been avoided.

[1] [https://tools.ietf.org/html/rfc6750](https://tools.ietf.org/html/rfc6750) [2] [https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749) [3] [https://tools.ietf.org/html/rfc6749#section-2.3.2](https://tools.ietf.org/html/rfc6749#section-2.3.2)

<comment><USER9> Author here:

> For one, bearer token [1] is only one type of "Access Token" described by > the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few > implementation details (such as how to obtain user info, how to validate an > Access Token), which the author seems to just assume are part of the spec, > as he does with bearer token. Other parts, like the client/user distinction, > and the recommendation for separate validation of clients, the author > ignores completely, generating his own (ironically mostly OAuth2-compliant > [3]) spec.

Last time I checked other access token types were still drafts and bearer tokens were the only stable kind.

> Again, not true. Diffie-Hellman provides a great way to come to a shared > secret that you can be cryptographically sure (the adversary's advantage is > negligible) is shared between you and a single verifiable keyholder.

I as a bank cannot attribute liability for an erroneous transaction to a developer if with both share the secret with which a signature is computed. If I as a bank am compromised and want to cover my arse by moving the blame to a poor external developer I can do that with a shared secret by forging signatures after the fact. This is precisely why I don't want shared secrets.

Even if your point is valid re DH, why push that up to the application level and reinvent the wheel when you can get the same benefits, less intrusively by using a battle tested protocol circa 20 years old?

> sigh. If only there was a way to write one orthogonal program that can speak > HTTP, and in a single cli command send that program's output to another > program that can understand the output. Maybe we could call it a pipe. And > use this symbol: |. If only.

This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl?

Finally, despite everything you say no OAuth 2.0 based protocol can guarantee privacy. People like that privacy when it comes to their finances I find.

Sorry for any typos, I'm on the move. Thanks for your comments :)

<comment><USER13> My DH comment was a bit aside the point I probably should have made. (Also, apologies for my sarcasm re: bash pipes -- that was unnecessary and probably unproductive).

> Public key cryptography can be used with JWT tokens but they don't solve the > problem of how the client will generate key pairs, demonstrate proof of > possession of the private key, and enrol the public key with the API.

JWT is not in any way attempting to solve the problem of client identity and authentication. Rather, the question of federated user identity and how to validate that the identity assertion came from a trusted source (where the PKI and assertion signing comes in).

Furthermore it is signed _with, among other assertions, the audience assertion_ so that you can cryptographically verify that a token was given with the authorization of a user by a trusted service (your JWT provider, via whatever authN methods it allows) and to a given client. This should give a substantial enough audit trail to enable reasonable proof that an end-user authorized a client (which itself had to authenticate to the provider) to perform an API transaction if it can be proven that the signature was validated and that the token issuer was clear about exactly what the user was giving the client authorization to do.

OAuth2, OIDC, and all modern standards I'm aware of _also_ require client validation of some form. From the OAuth2 spec:

        Confidential clients are typically issued (or establish) a set of
        client credentials used for authenticating with the authorization
        server (e.g., password, public/private key pair).

This implementation _is_ unspecified in OAuth2 but could (and in your case probably should) certainly include digitally signing each API request (much like twitter and amazon require) with a private key and validating the signature against the client's registered public keys as well as the constraints (especially audience, scope, and expiration) given via the token.

If your goal is to provide a non-repudiable audit trail of user identity and authorization and client identity and agency (authorized by the user to perform X) then OIDC, JWT, and client AuthN via request signing with registered keys should be more than sufficient to avoid liability in the case of rogue clients or shady users. As always, the audit trail is the most important piece, along with sound crypto and standard practices that have been audited by appropriate experts, so that your audit evidence cannot be reasonably called into question.

<comment><USER14> I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done? You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you identify the client but not sure you can ever identify app developer with it (if needed for audit purposes). Or am I missing something, maybe?

<comment><USER15> I had the same questions, and it's very hard to find the answer - took me a very long time to piece this together but this is how Google does it:

1) You create a "normal" client in Google Developer console (i.e. a web client) 2) You create a native/Android client _in the same project_. This client is shared across all phones. 3) You add a scope of audience:server:client_id:$NORMAL_CLIENT_ID to auth requests from the mobile. 4) You get back token minted for the web client, from the native client!

This is how it works:

[https://developers.google.com/identity/protocols/CrossClient...](https://developers.google.com/identity/protocols/CrossClientAuth#androidIdTokens)

The reason it is safe is because you can only do the cross client stuff from a mobile client, which disallows any redirect urls except for localhost and a couple of other special URIS (see [https://developers.google.com/identity/protocols/OAuth2Insta...](https://developers.google.com/identity/protocols/OAuth2InstalledApp#formingtheurl))

It's ok that the secret is not really secret because it's not possible to use it to making a Phishing site since the redirect URL is localhost.

I guess that doesn't answer your "how does it identity the app developer" but it does tell you how these things are deployed at least, and the important fact that there's just one client (not one for every device)

<comment><USER14> I understand that. Problem is that I can "steal" other dev's app client_id and use in my app. So it seems impossible to use such client_id for auditing/evidence. With a web client I cannot do that since I don't own the domain, so I can be proven to be a party in some transaction

<comment><USER16> They should allow for push notifications. That'd be more secure

At the end of the day though, everyone has to sign their apps with certs that are pretty well validated. So, it really cuts down on funny business like you mention.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Some features that I think a system like this should have:

1\. The client (or the device holding the authentication token, or the app, etc) should be able to maintain (on its own storage!) an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations), and the server should store audit log hashes _and verify that they were only ever appended to_. And the server should send a non-repudiable confirmation of this back to the client.

Why? If someone compromises the bank or the bank-issued credentials (it seems quite likely that, in at least one implementation, the bank will know the client private keys), the client should be able to give strong evidence that they did _not_ initiate a given transaction by showing (a) their audit log that does not contain that transaction and (b) the server's signature on that audit log.

2\. Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves. Did I read it wrong?

3\. An obvious place where an HSM fits in.

How does TAuth stack up here?

Also, there's a very strange statement on the website:

> to unimpeachably attribute a request to a given developer. In cryptography > this is known as non-repudiation.

Is that actually correct as written or did you mean "to a given user"?

<comment><USER18> > an audit log of all transactions it has authorized, that log should be > cryptographically verifiable to be append-only (think blockchain but without > all the Bitcoin connotations)

A blockchain related technology is overkill, you just need forward integrity: [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.111...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.111.6973&rep=rep1&type=pdf)

<comment><USER19> "The URL does not match any resource in our repository."

</comment></comment></comment><comment><USER10> As much as I love Stevie, teller.io and this demo: Why not both?

OAuth 2 is not "bad" in general, you just need to consider the implications of using it. If you have an API that allows clients to move customers' money or take out loans, you should take additional steps to defend against MITM attacks. For example using client side certificates :)

That said, TAuth looks really good and tidy. Of course the developer may still lose the private key, so in the end you'll always need to additionally monitor API requests for suspicious behaviour.

<comment><USER9> Hey Jonas! TAuth is simpler than OAuth 2.0 and doesn't suffer the same security issues. So… why use OAuth?

<comment><USER10> The devil you know I suppose ;)

IIRC we didn't go too far down the client cert route because we're behind CloudFlare and we like it that way. Something to revisit in the future.

</comment></comment></comment><comment><USER20> The main complaint about OAuth 2.0 seems to be that bearer tokens are a bad idea. Well, you can implement OAuth 2.0 to use any kind of token you want, with any property you want. People do bearer tokens because it is easy, not because it is required.

The secondary complaint seems to be that OAuth 2.0 is a mess. That one I heartily agree with! A few years ago I wound up having to figure out OAuth 2.0 and wrote [http://search.cpan.org/~tilly/LWP-Authen- OAuth2-0.07/lib/LWP...](http://search.cpan.org/~tilly/LWP-Authen- OAuth2-0.07/lib/LWP/Authen/OAuth2/Overview.pod) as the explanation that I wish I had to start. In the process I figured out why most of the complexity exists, and whose interests the specification serves.

The key point is this: _OAuth 2 makes it easy for large service providers to write many APIs that users can securely authorize third party consumers to use on their behalf. Everything good (and bad!) about the specification comes from this fact._

In other words, it serves the need of service providers like Google and Facebook. API consumers use it because we want to access those APIs. And not because it is a good protocol for us. (It most emphatically is a mess for us!)

</comment><comment><USER21> > One of the biggest problems with OAuth 2.0 is that it delegates all security > concerns to TLS but only the client authenticates the server (via it's SSL > certificate), the server does not authenticate the client. This means the > server has no way of knowing who is actually sending the request.

That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server.

[https://tools.ietf.org/html/rfc6749#section-4.1.3](https://tools.ietf.org/html/rfc6749#section-4.1.3)

> If the client type is confidential or the client was issued client > credentials (or assigned other authentication requirements), the client MUST > authenticate with the authorization server as described in Section 3.2.1.

Now, this doesn't work for "public" clients like a pure-javascript webapp, but that's a separate question.

Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.

<comment><USER9> > That's not just plain not true. In the OAuth2 authorization_code grant, a > "confidential" client is REQUIRED to send a client_id and client_secret to > authenticate itself to the server.

All secrets go over the wire, which is protected with TLS. Ultimately the security is delegated to TLS. You're simply wrong here.

> Count me as pretty dubious of letting some unknown group try to re-implement > bank authentication without fully understanding the specification they're > trying to fix.

Your misunderstanding is also indicative that OAuth 2.0 is too complicated.

<comment><USER21> You're correct that OAuth2 ultimately delegates all security to TLS--if that concerns you, you're better off using OAuth1a that has its own signing/verification protocol.

The statement in the OP that:

> the server does not authenticate the client. This means the server has no > way of knowing who is actually sending the request.

is incorrect as written. [In the case of a confidential client] The server _does_ authenticate the client, and it _does_ know who is making the request.

If you're going to claim that TLS-protected authentication somehow counts as "does not authenticate the client" then I guess you'll agree that Gmail "does not authenticate" my IMAP client when it makes a TLS-secured connection and sends my 'app password' over the wire.

</comment></comment></comment><comment><USER22> Their description of the MITM attack is entirely dependent upon how the authorization server validates redirects in the implicit and authorization code grant flows. This is tied to how client registration is performed. So, if you want to ensure that the authorization code or access token is only delivered to a redirect URI that is trusted, that should be part of the policy enforced in your infrastructure... More specifically, you can require domain verification and validation as part of the client registration process, and I would expect that at a minimum when dealing with delegated access to financials.

Another alternative to this would be to perform an OOB flow, wherein the redirect URI is actually hosted on the authorization sever itself and the client can scrape the access token from the Location header.

<comment><USER9> These are two separate things: MITM and open redirect. A MITM attack is not on the the auth code, but on the bearer token.

<comment><USER22> By design, OAuth2 doesn't allow for open redirects: this is just part of how clients are registered. What I'm getting at is not strongly validating the registered redirects on a sensitive client, which can lead to leakage of the access token in the implicit flow and the authorization code grant flow. Once you perform that intercept, the token may be presented by a malicious third party until it expires or is revoked.

</comment></comment></comment><comment><USER23> This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a MITM attack.

Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?

<comment><USER24> You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert.

They want _cryptographic proof of client identity_. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary.

This is different from 2fa because 2fa is authentication of identity that only happens once and _does not provide cryptographic proof of identity_. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted.

tl;dr

2fa:

      Client request 1: "Gimme $5."
      Bank reply 1:     "Who are you?"
      <man-in-the-middle starts listening>
      Client request 2: "StrawberryNewtonManicDresser"
      Bank reply 2:     "Okay, you can now use session ID 1234 to request more money."

      MITM request 1:   "Gimme $100000."
      Bank reply 1:     "Who are you?"
      MITM request 2:   "Session id 1234."
      Bank reply 2:     "Okay, here's your money."

client certs:

      Client request 1: "Gimme $5."
      Bank reply 1:     "Who are you?"
      <man-in-the-middle starts listening>
      Client request 2: <'Gimme my money.' ^ PRIVATE_KEY>
      Bank reply 2:     <verifies CR2 against stored client cert>
      Bank reply 2:     "Okay, you can now use session ID 1234, starting at iteration 2, to request more money."

      MITM request 1:   "Gimme $100000."
      Bank reply 1:     "Who are you?"
      MITM request 2:   "Session id 1234, iteration 2."
      Bank reply 2:     <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key>
      Bank reply 2:     "You're a faker, get lost."

....at least, I think that's how it works, iirc. The messages are re-signed so a stolen session token doesn't allow replay by an intermediary (the same sort of protection modern TLS has, but for the server's protection, not the client's)

It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into _active valid sessions started by the user_ , so verifying the user's identity is completely pointless in this case.

<comment><USER25> That seems right to me. It's the same approach as SSH key-based auth in a nutshell

</comment></comment></comment><comment><USER26> I visited the homepage ([https://www.teller.io/](https://www.teller.io/)) and got a warning about the SSL cert being invalid. Kind of ironic. :)

<comment><USER27> > I visited the homepage ([https://www.teller.io/](https://www.teller.io/)) > and got a warning about the SSL cert being invalid. Kind of ironic. :)

The correct URL is [https://teller.io](https://teller.io) and then you wont get an SSL cert warning. Not everyone uses "www". Nowhere on teller.io do you see a link to www. You put garbage in and got garbage out.

<comment><USER28> many if not most people input the www subdomain by rote. unless teller does not care about that category of people, it should probably fix the issue

<comment><USER29> Of course they should. Redirect traffic from www.teller.io to teller.io

<comment><USER30> Or, correctly teller.io to www.teller.io. Previous discussion [https://news.ycombinator.com/item?id=11004396](https://news.ycombinator.com/item?id=11004396)

</comment></comment></comment></comment></comment><comment><USER31> This is unlikely to work - developers in general can't cope with managing SSL certificates. They won't know what to do with them or handle them securely.

You need full integrity verification, with a secure store and whitebox crypto keys to make such a scheme secure.

<comment><USER32> I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.

<comment><USER31> Even dev's can't cope. Most apps leak credentials severely. You need integratity verification, obfuscation and whitebox crypto to do this sort of thing securely.

All of that is available in the banking world and is often deployed by people like Irdeto (who I work for) and Arxan etc.

<comment><USER32> Is that why irdeto.com does not use SSL on their site? Because you're not willing to manage SSL certificates?

<comment><USER33> Wow it doesn't even redirect 443 it just hangs...

</comment></comment></comment></comment></comment><comment><USER34> Problem one exists because, apparently, MITM is a problem with TLS because it's possible for bogus certificates to get through? Well... I guess. But then that's a TLS problem. And your entire banking website is served through TLS. So, if it really is an issue, then solving it just for auth is like putting an Abus padlock on a screen door.

Problem two bemoans the bearer token in Oauth 2. Yes, it's not as secure as OAuth 1, but it's also far simpler. But you don't have to use bearer tokens; you are free to use MAC tokens instead. Why reinvent the wheel?

</comment><comment><USER35> I think my biggest bug here is that as far as I understand this flow, it essentially says that a given certificate that is generated and signed by a third party (Teller in this case) would be expected to bundle this private certificate with the application. Isn't it possible to extract the certificate from the app bundle after the fact? Or am I missing something here...

</comment><comment><USER36> The premise for adding client certificates is a MITM made possible because careless app developers will disable server certificate validation.

So, how exactly does adding a client certificate solve that problem? If server certificate validation is disabled on the client, the MITM can still accept the client certificate and substitute their own.

The difference is that in this case the attacker will gain access to the API but the client will not, unless they are being actively MITM. If the client tries to access the API outside the MITM their client cert will be rejected as invalid.

<comment><USER9> Actually no. The certificate must be signed by Teller (or it's rejected) and associated with the same application as the auth token.

<comment><USER36> Right, so what stops an attacker from getting a client certificate signed by Teller?

I guess I missed something about how the client certificate is being provisioned. I see the video showing a client certificate being downloaded onto a desktop, but that's obviously not the intended UX for actual end- users...?

<comment><USER36> So I realize now at this stage you are focused on server-to-server only, in which case there's no issue with trying to deploy individual client certs to end-user devices.

Pulling a certificate via the browser is not great assuming we want a highly controlled chain of custody over the private key bytes and that these certs will expire and need to be regularly rotated. But it's not much work to build some command line tool to send a CSR off for signing, that seems reasonable for server-to-server authentication.

I wonder if you'll run into issues with various languages' HTTPS libraries not properly supporting client certificates.

It's nice to think this could all just work with the lower layer taking care of everything, but I also wonder with the shitshow that is TLS if you can even be sure the client cert validation code can really be trusted as much as an application-layer check.

</comment></comment></comment></comment><comment><USER37> Client certs are still a bit of a pain. There is already an IETF spec in the works, called Token Binding, on how to bind tokens to key pairs that clients maintain, and create on demand.

[https://github.com/TokenBinding/Internet- Drafts](https://github.com/TokenBinding/Internet-Drafts)

[http://www.browserauth.net/home](http://www.browserauth.net/home)

It's already implemented in Chrome.

</comment><comment><USER38> I thought client certificates were being phased out, didn't Chrome just remove the <keygen> html tag?

<comment><USER9> A PKCS#10 request is built using PKI.js, all crypto is done by native WebCrypto APIs.

</comment></comment><comment><USER39> > The EU is forcing all European banks to expose account APIs

I'm so jealous!

</comment><comment><USER40> Actually oAuth 1.0 is less secure than oAuth 2.0 because it engages in security theater. It doesn't even require https and as a result any man in the middle can eavesdrop on the requests. And if the token is leaked, it's game over.

<comment><USER41> oAuth 1.0 supports both PLAINTEXT and HMAC-based signature schemes. I assume the article is assuming HMAC-based signatures (the PLAINTEXT option seems to be less well-known). With an HMAC-based signature, the token will not be leaked.

But you're correct that eavesdropping is possible.

<comment><USER40> Right, the HMAC based approach is what is recommended over the bearer token approach. But you still leak everything else in the request.

Actually, the same logic should be done for cookies. You COULD replace cookies (which are bearer tokens) with signing every request to the server, but then you're just avoiding the REAL solution: https!

Actually the biggest security theater I have seen on the web is httponly cookies to "mitigate XSS". As if the main thing an attacker will do once they inject JS is to send your cookies somewhere. They can just execute anything in the context of your session while they still have it! So by being security theater, httponly cookies are worse than useless. The right way is to prevent XSS by escaping everything properly.

</comment></comment></comment><comment><USER42> So, it seems like the main concern here is that a client will not validate the SSL certificate, so the SSL layer is now manually added into javascript code using the WebCrypto API to prevent this? I see not validating SSL certificates being a potential problem with something like a REST API, but is it common to disable SSL verification at the browser level where you would need to use javascript to do this?

</comment><comment><USER43> One of the things about OAuth is that the user needs to check the website url where he is giving his credentials. Amusingly, many mobile apps seems to forget this important bit. The redirect me to a web ui _inside_ the app itself and expect me to enter my password inside the app. I guess they thought this was a better user experience than handing over control to the browser :/

</comment><comment><USER41> Two things: 1\. Why not just add client-side certificates to an OAuth-based API? 2\. Client certificates do not prevent an attacker from pretending to the be server.

Let's say your API server followed the standard OAuth 2.0 protocol except required client-side certificates? Would that be as secure as TAuth?

If so, then the OAuth 2.0 option has the advantage of being well-supported by existing libraries and well-understood from a security perspective. It's less likely that a previously-unknown issue with OAuth 2.0 will crop up and force everyone to scramble for a fix.

And while client certificates prevent an attacker from forging client requests (i.e. tricking the API server) an attacker can still trick the client. An attacker capable of MITM'ing server-cert-only HTTPS can also trick TAuth clients into sending it's banking API requests the attacker's servers. It can respond to those requests with whatever it wants.

To summon the activation energy to adopt (or switch to) a new, less-popular protocol, I'd expect more security benefits.

</comment><comment><USER44> > _Most importantly using JWT tokens make it basically impossible for you to > experiment with an API using cURL. A major impediment to developer > experience._

Why can't a developer do exactly what you did in your second video, which is to save the JWT to a variable, and then use it in the request?

Heck, you could create a quick wrapper "jwt_curl"/"jwt_http" or something that automatically pulled in that variable…

There's two big things about this scheme that leave me confused: how do you know what the correct certificate for the client is? Do you just send it over HTTPS? But then, one of your opening premises is that we don't get TLS verification correct and are open to MitM, so this seems to contradict that, or are we hoping that "that one request won't be MitM'd", like in HSTS? (which seems fine)

</comment><comment><USER45> How does this compare with SimpleFIN: [https://bridge.simplefin.org/info/developer](https://bridge.simplefin.org/info/developer)

SimpleFIN seems simple and still secure. But maybe I'm missing something?

</comment><comment><USER46> It's still a bit unclear to me how a client generates his certificates and somehow links it to his bank account. The demo shows a web-UI generating it, but would a mobile user have to visit the website to fetch a certificate?

</comment><comment><USER47> By logging into a 3rd-party site using Google+, for instance, you remain logged-in to Google when you go to _any_ other web site.

And the authenticator clearly does not require this global behavior: if you immediately log out from a Google page, you remain "logged in" at the 3rd- party site that you started from. So why doesn't it log you out globally? Probably to convenience Google, at the expense of security when you auto- identify yourself to who knows how many other web sites before you realize what happened.

Logging into one page with one set of permissions should mean "LOG INTO THIS PAGE", not "REVEAL MY SECRETS TO THE INTERNET".

</comment><comment><USER12> Let me see if I understand this correctly:

1) Problem: app authors disable TLS (server) cert validation.

2) Solution: give each app author the responsibility of managing and distributing a client side certificate.

Sounds like now you have two problems? In particular, you now have to make sure that every lost/compromised certificate is added to your growing CRL? And you need app developers that demonstrably do not even have the vaguest idea how public key cryptography can be used for authentication to take responsibility for doing this? And there's still no guarantee that they won't disable certificate verification?

Did I miss anything?

</comment><comment><USER40> At Qbix we developed a much more secure way than oAuth to _instantly_ personalize a person's session -- and even connect the user to all their friends -- while maintaining privacy of the user and preventing tracking across domains by everyone except those they choose to tell "I am X on Y network" ... it also restores the social graph automatically on every network and tells you when your friends joined one of your networks.

</comment><comment><USER48> >The EU is forcing all European banks to expose account APIs with PSD II by end of 2017.

Any reference for this? The text of PSD II is here — [http://eur- lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:320...](http://eur- lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366) — but it's too long and it isn't clear to me whether it is actually ratified.

</comment><comment><USER49> What bothers me about OAuth is the way you're on one website and are then asked with a pop-up to enter your Gmail or Facebook etc. password as a normal part of the flow. Users aren't savvy enough to check the URL or understand what's going on here so getting them used to this flow is asking for phishing by the look of it. Something that forced two factor authentication would be good.

</comment><comment><USER50> It's pretty strange to see a new authentication protocol (they describe it as authorization protocol, but they do authentication as well), just as W3C's WebID-TLS is being finalised. Oh, did I mention it uses client X.509 certificates as well? And how does the author imagine that banks would rely on his new protocol to ensure non-repudiation?

</comment><comment><USER51> > The most realistic threat is the client developer not properly verifying the > server certificate, i.e. was it ultimately signed by a trusted certificate > authority?

From an attackers point of view, this sounds like a very tiny ray of hope. It sounds like a cool feature/vulnerability that will probably be going away soon because it is so easy to fix.

<comment><USER52> The problem with the, "was it signed by a trusted authority?" concept is that you generally can't automated the 3rd party since they're not under your control. Also, they typically charge every time you request a new certificate (even if client-only).

The solution to that is to run your own CA but then it won't be 3rd party anymore. It's sort of the catch-22 with SSL/TLS: Either you use a 3rd party _or_ you get to automate things. There doesn't appear to be any middle ground.

Why is there no middle ground? Because if the 3rd party CA is doing their job they're investigating _every single request for a new certificate_. That means you can't just get a new client-side certificate on demand, instantaneously whenever the need arises.

<comment><USER51> "client developer not properly verifying the server certificate" makes it sound possible, but I think I understand the problem now maybe.

The 3rd party CA may have issued a cert to malicious party that issued another cert to their man in the middle.

You can't be sure unless you are your own CA, but then you aren't a 3rd party anymore.

</comment></comment></comment><comment><USER53> I didn't see anything about renegotiation. If clients present their certificates during first handshake, it will lead to security concerns. Attackers could observe client's certificates (extract meta-data, de-ano clients ...). If renegotiation is used it will drastically reduce "Bonus DDOS mitigation"

</comment><comment><USER54> tl;dr: it forces client to have a certificate so that the server can verify.

This is kind of a pet peeve. Anyone who ignores or wants to disable server certificate verification has to understand the risk.

</comment><comment><USER55> How is this better than Hawk and Oz by OAuth's creator, Eran Hammer? TAuth seems to solve fewer problems, as it cannot be used by public clients.

</comment><comment><USER32> It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure.

I wonder if this is a custom built solution or if Teller.io is using something like HashiCorps Vault to do the whole SSL cert dance.

Either way, this looks promising.

<comment><USER56> > It's kinda crazy that it has taken so long for someone to actually take an > initiative and attempt to make the authentication more secure.

Not when you consider we've all been subjected to decades of "don't write your own security!!!"

<comment><USER9> Author here. This is not a new invention. This is standard TLS, and some newer things like WebCrypto brought together.

</comment></comment></comment><comment><USER57> Has this been tested against a broad user base? It seems rather involved.

</comment><comment><USER58> Relying on SMS for bank security has always seemed crazy to me. It's not secure. Didn't Telegram creator just got hacked by the Russian mobile provider that sent an SMS to itself?

<comment><USER59> A lot of banks do use proper hardware tokens (TOTP and similar) for all transactions though.

I am under the impression that we are now in a phase where security needs to be stepped up, but in the mean time tokens send via SMS are considered 'good enough'. There are lots of initiatives for the next step, each providing proper two-factor authentication, but a lot of services are waiting it out because the hardware tokens or smartcards you need for each user cost money, and if you adopt one of the current solutions such as TOTP tokens, users would need such a device for each service they use (again, for banks this is already accepted; at least in the Netherlands).

Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you.

Also, relying on SMS means all these services have a single unique number to identify you with across services. I dislike the privacy implications this entails, and prefer to keep (some of) my on-line identities neatly quarantined the rest. FIDO U2F addresses this problem; even if you use the same hardware key for every service you use, they cannot be linked.

<comment><USER60> > Ideally, a standard such as FIDO U2F gains ground, so users can safely and > conveniently reuse a single hardware token for any service supporting that > standard. Who knows, perhaps having your 'internet key' on you can become as > commonly accepted as having your house keys on you.

Unfortunately, most FIDO U2F services allow SMS as a fallback authentication method, including Google and Github. At least Github has some strong warnings about it.

<comment><USER59> That is to be expected at this time though, and for a service like Github letting the user choose their level of authentication strength is fine — you are mostly responsible for what data you store there yourself. In the mean time it will help the adoption of this standard to at least have the option available.

If a service is actually guarding private data by definition (like a bank or an insurance agency) than phasing out SMS in favour of FIDO U2F or another true hardware factor is a much more likely scenario.

</comment></comment></comment></comment><comment><USER61> Must be British... "authorisation" ?

<comment><USER62> It uses a UK phone number and supports an EU banking initiative, so I would guess so. Why is that relevant?

<comment><USER63> authorisation is spelled authorization, atleast in the US

<comment><USER64> It's spelled authorisation everywhere else.

</comment></comment></comment></comment><comment><USER65> [https://xkcd.com/927/](https://xkcd.com/927/)

<comment><USER66> Can someone just blacklist every post that is nothing but a link to this comic.

<comment><USER65> Can someone just blacklist every post that is nothing but a new standard trying to add to the list of crappy pre-existing standards?

Also, you forgot the question mark on the end of your sentence there. Unless you meant a sarcasm mark or an interrobang and the comment parser stripped it?</comment></comment></comment>


Ham vs. Ham as Radio Amateurs Are in Conflict with ARRL - <AUTHOR> https://perens.com/static/ARRL/TransparencyOctober2018.html <comment><USER2> I just submitted my vote for N2RJ. ARRL leadership has seemed out of touch for quite some time. They seem more interested in selling wildly over priced books than advancing the interests of the Ham community. Amateur radio may seem like a quaint hobby for old timers but there are a number of newer hybrid operating modes that play nicely with the digital world. Ham's need a strong advocacy voice so that relevant policy decisions don't overlook the needs of amateur operators. Amateur radio is a great way to learn physics and electronics. I was a liberal arts major and now have my Extra class license. What I learned getting there is so much more valuable than the rag chews and 73s. Keep Ham strong!

<comment><USER3> I got back into the hobby after letting my license expire years ago. SDR and GNU radio are what pulled me back in. I feel like it's a renaissance for amateur radio.

<comment><USER4> I sorely missed the experimental side of the hobby (and the Shack's easy parts access)- always a big kick - after that dropped away.

What's the best place online to plug into what's going on in SDR?

<comment><USER5> As mentioned the RTL-SDR group on Reddit is good. You can also play without any hardware (and with better antennas) using online SDRs: [http://rx.linkfanel.net/](http://rx.linkfanel.net/)

<comment><USER6> Also [http://websdr.org/](http://websdr.org/)

</comment></comment></comment></comment></comment><comment><AUTHOR> Note that the author of this piece, Bruce Perens, is the founder of the open source initiative with Eric Raymond.

Sadly none of this stuff with the ARRL is new. One ham activity is contests where hams compete to talk to as many people as they can in a weekend or over multiple weekends. There are clubs consisting of multiple members who compete for the prize of top club. In the early seventies they changed the rules so that you could be a member if you lived within 175 miles of the clubs location.

I helped formed a Midwest club, the Mad River Radio Club that was based in Ohio but had members in four states. We entered and won the competition. Then after the event was finished the ARRL rewrote the rules posthumously and all of a sudden we'd been disqualified.

<comment><USER7> I let my ARRL membership drop last year. QEX was worth it, but they refuse to provide access to back issues, so I said to hell with it.

<comment><USER8> If someone has copies of back issues, I'd be interesting in coordinating getting them into the Internet Archive.

<comment><USER9> That would be a worthwhile activity :) If successful, post URL on HN.

<comment><USER10> "2168731C3901ED9F01218D2FFB531EE31524EC15"

(direct URL could break HN rules)

<comment><USER9> QEX 1981-2016 (1.85GB) - thanks for the magnet :) ... torr download via VPN = 7kB/s (2 days); via Furk = 35 kB/s. The Furks have it.

</comment></comment></comment></comment></comment></comment><comment><USER11> Somewhat off topic, but I was a Ham radio operator in my pre-teen years and had a technician license (this was decades ago when there was the Novice class and you had to pass a Morse code test). I remember the used radio well that I bought when I was around 12 I think (it had vacuum tubes!)

Being out of amateur radio for so long:

1\. I honestly don't even remember what my call sign was. Does anyone know if there is some way I can look that up? This was literally decades ago.

2\. This may come across as a dumb question, but what is Ham radio primarily _used_ for today? I mean, when I was a kid I remember being thrilled being able to talk to (or at least listen in on) conversations from around the globe. This was all in pre-internet days, nevermind pre-chatroom and social network days. What is ham radio's "niche" now that the internet has taken over the world?

3\. Does anyone use Morse code anymore?

4\. What are the new "hybrid operating modes" that exist?

Thanks!

<comment><USER12> 1\. yes. it might be in the fcc database still. search at the fcc web site. also, qrz.com might have old database info from old callbooks.

2\. many things. i like radiosport competitions. there are many sub-hobbies. experimenting with high coding-gain codes is also interesting.

3\. yes. i use it for radiosport. go listen at the low end of 40m right now for the California QSO Party. many dits. (asking if morse code is still used by anybody is like asking if people still use sailboats. yes, but not for commercial purposes. )

</comment></comment><comment><USER13> Both my husband and I let our ARRL memberships lapse. We had some connections that could've helped the HOA issue but were given a stern no thanks by the legislative team. Communications with them always went south and they just didn't seem to want to think outside the box, or accept any help. Not even to hear us out. An organization that won't give its members the time of day and listen to new ideas is stale, and should be upended..

</comment><comment><USER14> I think it's important to support the ARRL. The publications, event- management, and advocacy are extremely valuable to amateur radio.

But a vote for new leadership is one way of supporting the ARRL, and a far better decision than simply cancelling one's membership.

I know most of the signatories of the letter and they are all bright and thoughtful people. It's also cool to have Perens involved, since he's a celebrity outside amateur radio. I believe he has a quad antenna visible on his rooftop in the Berkeley hills.

</comment><comment><USER15> My needs are simple. Keep the frequency allocations for my transmission, and help stop my neighborhood from filling with devices that emit stray RF and block my reception. My two issues are, almost certainly, the primary issues for many other people.

Perens has [http://perens.com/static/ARRL/TransparencyOctober2018.html](http://perens.com/static/ARRL/TransparencyOctober2018.html) about new people for five director slots. Going through them, I first see that the Valerie Hotzfeld website is "very worried" about 160,000 members versus 170,000. Seems like a minor concern to me.

The Ria Jairam website says she'll oppose any proposal to the FCC unless there's open debate by membership. I believe that the correct ARRL position, when the FCC may be considering a change relevant to my two issues, is sometimes COMPLETELY OBVIOUS and what we actually need is the fastest possible action by ARRL.

The Fred Hopengarten website mentions "A low cost basic membership: one idea - no QSL bureau (inbound or outbound)." But inbound QSLs (see the [https://www.arrl.org/incoming-qsl-service](https://www.arrl.org/incoming-qsl- service) page) don't require membership at all! I'm not sure why a prospective member would pay a "low cost" to reduce their current service level.

The Michael Ritz website talks about "addition of Kosovo, Z6, to the DXCC Approved Country list." Hello? I'm a maker, not an international diplomat.

The George Hippisley website has a tantalizing mention of "Frequency Spectrum" at [http://www.w2ru.net/whatFrequencySpectrum.html](http://www.w2ru.net/whatFrequencySpectrum.html) \- but it's BLANK!

Five candidates' websites, and I can't find any discussion of what I need from ARRL. And yet, my incumbent director, who apparently has no website at all, has a mailed statement to our entire division saying he'll emphasize my two issues.

</comment><comment><USER16> Generally there is no problem with a board of directors making their in meeting discussions private just as long as they clearly communicate the results of those discussion to the membership. The problem here seems to be a section (8) in the new code of conduct which compels a director to politically support board decisions outside of meetings. Section 8 is now proceeded by the following message on the web site: "NOTE: ALL OF SECTION 8 HAS BEEN SUSPENDED BY ACTION OF THE BOARD OF DIRECTORS PENDING FURTHER STUDY AND REVIEW." That seems problematic as it does not refer to a particular motion at a particular board meeting. It is thus not clear that the section has actually been suspended.

This whole thing strikes me as sloppy politics that eventually led to pointless infighting...

</comment><comment><USER17> I didn't sign up when I got my ticket because of issues like this or related to this. It's really a pity. The hobby has some interesting directions it could grow currently.

The other side of the hobby I dislike is the proliferation of proprietary protocols, but that's another topic altogether.

</comment><comment><USER18> :( as a ham this makes me sad.... My callsign is W9BJH..... I wish we could resolve things IRL faster but drama creates unhappiness....

<comment><USER9> The wisdom of posting call letters online is questionable given it allows ready access to personal information

</comment></comment><comment><USER19> Is it too late, for a new member (as of today), to vote? Where and how?

<comment><USER20> Based on [http://www.w2ru.net/](http://www.w2ru.net/), it sounds like you needed to have been a member as of Sept. 10th to be able to vote.

</comment></comment><comment><USER21> TLDR?

<comment><USER22> The society which represents U.S. amateur radio operators voted to have their board be much less transparent and members were not told about this. There is now a campaign to elect board members who are running on a transparency platform.

</comment></comment><comment><USER23> Something strange about those names. Can't put my finger on it...</comment>


Bitcoin: Soft block size limit reached - <AUTHOR> https://bitcointalk.org/index.php?topic=149668.0 <comment><USER2> I am not a developer for bitcoin, but I have been following along in #bitcoin- dev and reading some of the forum threads. (most interesting conversation by far is on freenode)

In pools/miners that are not blocking satoshi dice 70-95% of every block is filled with SD transactions. Further, SD has upped their fees to get higher priority.

Interestingly, the sentiment of the devs and the sentiment of the users is _vastly_ different. It seems that the users are overwhelmingly pro SD, anti filtering out SD transactions, and think this is just a nice test for bitcoin and this type of transaction volume is inevitable anyway. (plus, they are of the libertarian leaning in general).

Sentiment amongst the devs varies, but it does seem they all agree that SD is abusing the blockchain. There is no reason SD can't remain provably fair and have the same flow without spamming the blockchain; and, since they are reusing addresses and acting in a such a way that their transactions _can_ be trivailly tracked, there is no reason (in some of the devs' minds) to not treat them as spam and filter out their transactions.

For their own part, the owners of SD have reportedly taken a "fix your shit" attitude when asked to change their methods.

In any case, it has spurred a lot of discussion on "how" to raise the soft limit; which is completely arbitrary, and many pools have already raised it regardless. The real news is that the `hard` limit, which _will_ create a fork is not even an order of magnitude away. No one wants to keep making hard forks, so there is a lot of debate on how to best determine future block limit size on a system wide scale.

For my own part, it is hard not to see SD as spamming/abusing the blockchain. If I ran a mining pool or a hasher (I don't) I would block SD as Luke-jr does by not including addresses into blocks that start with `1dice`. It's note worthy that it would be essentially impossible (rather than trivial) to censor SD transactions if they followed best practices.

It is also worth noting that there are whispers of SD transaction volume being something of a conspiracy. I have not done any analysis on this; but what I have heard is that the vast majority of SD transactions appear to be bots, playing losing bets 24 hours a day. SD has issued stock, which is publicly traded.

<comment><USER3> How can you have a viable worldwide currency subject to "spamming the blockchain"? The nice thing about gold and USD is they have no viable DOS attack vectors.

What implications does this have on the future of bitcoin? Is it even possible to have a reliable currency if anyone can create a crippling load on the system?

<comment><USER2> Well you determine what counts as spam and just don't propagate it. Fees are a part of the process of keeping spam out of the blockchain. Some people also count sending 'bitdust' as spam.. seemingly defined as anything less than 10k satoshis (or 1/10,000th of a bitcoin--obviously that definition would have to change over time if bitcoin continued to appreciate).

The real answer to your question though is 'off chain transactions' will likely become the way a lot of debts are settled. It's trivially easy to double spend coins that have been not confirmed into any blocks, so it's inevitable that this type of fraud will become more prevalent. As such, it makes things like 'buying coffee' with bitcoin really annoying, if I am going to have to wait 2-15 minutes for my transaction to get confirmed into a block it isn't really going to work. So B&M retailers will be forced to make their customers wait for transactions to confirm, or risk getting scammed (which breaks the whole "point" of bitcoin having lower fees than CCs).

Enter off-chain transactions. Retailers could either let you hold a balance there, or, more likely.. someone will pop up with a competitive off-chain transaction scheme; perhaps Ripple, perhaps something more like bitinstant; where balances are demoninated in bitcoin and retrievable in bitcoin, but day- to-day small transactions actually happen in a 'centralized' database and are only written to the blockchain upon cashing out. (note this is exactly what is happening with mtgox, where tons of coins exchange hands just within their system that don't get written to the blockchain until you cash out your coins).

</comment></comment></comment><comment><USER4> Reading the thread, the most interesting thing seems to be that this is a problem partly caused by the website satoshidice.com, and several people are adding special filtering to ignore any transactions performed by this website.

This immediately raises a large number of very interesting questions. I was under the impression that the whole point of bitcoin was that it allowed anonymous transfer of funds with no central authority. If some group of large miner groups have the power to a) identify satoshidice, and then b) ignore it's transactions, then what is the point of bitcoin?

<comment> Tuna-Fish So long as there's someone who mines coins and who accepts satoshidice transactions, they will eventually be completed. Being discriminated against slows your transactions down, it does not prevent them.

The way the system is designed to deal with discriminating miners is to _allow_ all discrimination (a miner can choose which txns to include based on any criteria he/she wishes), but diluting their choices by having enough miners.

SatoshiDice is actually very useful for the network, because it allows us to test how it functions in a saturated environment long enough in advance that we can make changes if they are needed.

<comment><USER5> Yet this action does seem like collusion which was the oringal point. I didn't know transactions could be excluded as well. Who's to say that in the future miners could collude against certain merchants?

<comment><USER6> Oh they could if they wanted, and if they knew what the addresses in use by the merchant were. This could be made difficult by the merchant continually generating new addresses. The merchant could also add a little sweetener (transaction fee), and it feels pretty likely that a proportion of the wider BTC community would overcome their (presumably) ethical concerns and process the transactions anyway.

But yes, in principle, colluding miners could make life difficult for merchants they dislike. This is one reason why a large and divers base of miners is important to the BTC system.

</comment></comment></comment></comment><comment><USER7> The main complaint with Satoshi Dice is that most of their transactions are not actually transferring any value (actually, they are transferring a tiny bit of value if I understand correctly; I've never used SD). They're using the Bitcoin system as a secure message system to notify everyone who lost a bet (i.e., most betters). It seems to me that Satoshi Dice could very easily create their own block chain to do this and just use it as poker chips, which would take all the load of the Bitcoin system. Once you are "in" the virtual currency system, it's quite easy to exchange currencies. The hard part is getting your dollars in.

But Bitcoin would have run up against the block size limit at some point anyway; the vast quantity of Satoshi Dice transactions have only accelerated the confrontation of this dilemma. I actually appreciate the fact that Satoshi Dice is effectively stress testing the system. Bitcoin block size is a serious impediment to scaling up.

I wonder if Bitcoin core dev (and Google employee) Mike Hearn has consulted with Jeffrey Dean and Sanjay Ghemawat about this issue. I know that Bitcoin recently switched from Berkeley DB to leveldb for most of the client's bookkeeping, which would have been a good opportunity for Mike to approach them about this dilemma. However, I know that all the core Bitcoin devs are already very capable, so I'm not sure if a technological solution to this issue even exists. The answer may be more political (i.e., convincing all the miners to go along with an idea).

<idlespeculation>On a related note, I wonder what the level of adoption of Bitcoin is among Google employees. As mentioned above, Mike Hearn is a Google employee and a long-term Bitcoin core dev. I would speculate that the level of adoption is relatively high, which makes me also speculate about when Google might start accepting Bitcoin. Anyone care to comment?</idlespeculation>

<comment><USER8> I doubt Google as an organisation would accept Bitcoin unless the adoption was overwhelming. Google Wallet is yet another data mining tool for them, and they won't give that up easily.

Single reason I don't have a Nexus 4 is that I have to use Google Wallet and I won't give Google my real name to link it to my account no matter how hard they try.

<comment><USER7> Unfortunately, I think you're correct here. I guess I'm hoping a cabal of Bitcoin insiders will somehow convince the powers-that-be to start using btc, but your interpretation is much more likely.

</comment></comment></comment><comment><USER9> I'm not following this. Can someone dumb it down a bit?

<comment><USER10> There are too many bitcoin transactions, so the blocks are too big. The miners have to be run with different settings to account for that.

I don't know what bitcoin proponents think will happen in the bitcoin future when everyone will be payibg with it; the size of the block will quickly get to megabytes.

Yeah, bitcoin doesn't scale well.

<comment><USER11> >bitcoin doesn't scale well

Meanwhile, average and available bandwidth and disk space goes up.

By the time the block chain breaks into the terabytes range, storage and network technology will have advanced to the point where it's not a problem anymore.

<comment><USER9> Does every new user have to download the entire blockchain? That's a point I'm not really clear on.

<comment><USER12> If you are hosting your own wallet and not using an online solution yes.

<comment><USER13> Do you know of an online wallet that seems to be reputable? I'm looking at Coinbase at the moment.

<comment><USER12> Blockchain.info is quite popular. That's really all I know.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Upon further reading, it sounds almost like a supply and demand issue that needs to be solved with an increase in transaction fees, no?

<comment><USER8> Yes, one of the options is to let the market take care of it.

But then you cannot advertise Bitcoin transactions as free any more, as free TXs will likely be lost at a non-negligible rate in the future.

Blocking Satoshidice is a temporary fix to give time to the developer community to come up with a better plan. So is increasing the soft limit (we are currently at 1/4 of the hard limit, doubling the soft limit will put as at 50% of it, and it will double the blockchain bloating rate).

<comment><USER14> I think it's fair that "free TXs will likely be lost". That's really just the market at work - If Satoshidice would pay proper fees, I bet those miners would be very happy to lift their block. In a sense making it "worth their effort".

Any P2P network dies when leeching of resources completely outweighs sharing of resources. I think Bitcoin with its transaction fees has a very clever mechanism to prevent that from happening.

<comment><USER15> Satoshi dice transactions pay relatively high fees and is probably the only reason transactions have any fees at all. Miners already limit the number of free transactions that are processed some (BTC guild) don't even process free transactions. The problem is luke-jr's pool explicitly blocks transactions including satoshi dice addresses. For whatever reason possibly to artificially lower transaction fees to increase adoption. If the miners acted economically this wouldn't be a problem.

<comment><USER14> Ah, interesting!

I would still be curious whether it's just a matter of price, though. Surely at _some_ point the miners couldn't resist processing the transactions?

</comment></comment></comment></comment></comment><comment><USER16> Bitcoin lead dev addresses the issue- <https://bitcoinfoundation.org/blog/?p=135>

</comment><comment><USER9> Another curiosity I had. Has anyone considered storing files in the block chain?

Obviously it wouldn't be practical but it might help with censored files.

<comment><USER17> You can store ASCII in the blockchain. Has been done before: <http://news.ycombinator.com/item?id=2830084>.

</comment></comment><comment><USER3> One can only imagine what ordinary folks who thought they'd be on the bleeding edge in accepting bitcoin think of all this.

All this talk of spamming block chains, miners, soft-hard limits - word that mean nothing to your average cowboy - can't be good for bitcoin's near future.

</comment><comment><USER9> So could a miner mine more coins by settings their max block size lower?? Or am I misunderstanding completely?

<comment> Tuna-Fish No. Nearly all (99.9999% or thereabouts) of the work you need to do to mine bitcoins is independent of the size of the block you mine. You want to run large blocks to collect as much transaction fees as you want to.

</comment></comment><comment><USER9> In the case of a hard fork does an end user have to do anything to move their coins or is it transparent?</comment>