There seems to be a pattern emerging in all of these 'disruptive' business models, whether it be Bitcoin (banking), AirBnb (hotels), or Uber (cabs). We look around and see these industries burdened by regulation, which tends to create entrenched players and which seem to us to be inefficient. So we create similar peer-to-peer equivalents, only to start rediscovering the reasons for all those regulations in the first place. I would argue that one reason mature industries seem inefficient to us is that it's been so long since we've encountered the problems the regulatory 'inefficiencies' were meant to address, that we've forgotten why our ancestors put them in place. Peer-to-peer is not a new idea, it's how things worked back before we started using government to solve the problems inherent in the peer-to-peer model.
That is an absolutely terrible lesson to draw from this episode.
First and most importantly, Airbnb and Uber are not disrupting industries burdened primarily by consumer safety regulations; they are disrupting industries burdened primarily by barriers to entrance that are designed to direct economic rents to politically favored actors. Huge difference.
There is no plausible 'consumer protection' story for preventing licensed livery cab drivers from picking up curb hails, whether on the iphone or otherwise. The law is there to protect the incomes of people who buy cab licences.
There is no plausible 'consumer protection' story that would explain why building codes for permanent residence are not good enough for temporary residence as well. The law is there to protect hotel operators from vacation rental competition.
So let's not compare Bitcoin with Uber and Airbnb, because they are completely different animals.
Bank security regulations, OTOH, ARE designed to protect consumers, although I'd argue that they're mostly unnecessary in practice. Legitimate banks don't get hacked because there are billions of dollars at stake for the banking institution, and their business literally depends on their ability to secure payments. The incentives are there with or without bank regulations.
Bitcoin sites, on the other hand, regularly get hacked because they are fly-by-night operations written by idiots who are probably also trying to steal from you. It's the fake-money equivalent of using www.send-monie-through-me.co.in and then being surprised when you get ripped off.
Bottom line: there is nothing wrong with regulation designed to protect consumers from actual threats. There is everything wrong with regulation designed to protect business from competition. The latter is what needs to be 'disrupted'.
Claiming hotel regulation has no benefit to consumers is simply not true. Consider the perspective of a resident of San Francisco (like me). SF has a very limited amount of housing. We can debate all day about ways to fix that and impediments to building more (and more affordable) housing, but the simple facts right now are that there are a LOT more people who want to live in SF than there are housing units.
Additionally, there are a lot of tourists that visit SF. Those two demands for places to sleep, from tourists and residents, are at odds. The price you can charge for a hotel room in SF is substantially greater than what you can charge on a nightly basis in stable rent.
So what we're seeing happen in SF is people who have rental units that would normally be on the rental market are now pulling those off the rental market and putting them on the AirBnB market, which serves tourists instead of residents. Because frankly, why wouldn't you? If you can rent your place for $200/night to tourists you can make a hell of a lot more money than you can renting to someone for a year.
The hotel regulations aren't only to help hotel consumers, they're to help the renters too. Now, you could argue the natural market economics should just play out and the city should allow as many hotels to exist as the market will support. But that's not a city I want to live in. I value prioritizing housing for residents instead of tourists.
The problem you described has a very simple solution. Grant more permits to increase the number of brand new housing units added to the market each year. The rate at which SF adds housing units given demand is absurd. In fact, you'd probably have many more small business opportunities in SF if the city were willing to add residential units faster.
Which is why the financial district was wiped off the map during the 1989 earthquake, whereas lower units such as those in the marina survived without problems?
The Marina was wiped off the map in the 89 earthquake. It's built entirely on landfill and suffers from terrible liquefaction. The buildings there suffered bad structural damage and many people who lived in the Marina at the time moved elsewhere because of all the damage, making room for all the yuppies that took over that neighborhood.
So long as the foundation is bedrock, there is nothing preventing the building of highrises in San Francisco. We have the technology.
There is actually tons of demand in silicon valley but development there is mostly illegal. Mountain View recently rejected Google's request for mixed use zoning in the Googleplex which IMO is just gratuitous nimbyism (it's not even in anyone's back yard!). This is probably related to so many silicon valley types living in SF instead of anywhere near their work.
Thank god they aren't building more housing in SF - a temporary fix (b/c eventually you'll run out of housing again) to a non-problem. The NewYorkification of San Francisco would ruin the city.
You are literally arguing for the destruction of the planet when you argue against density. More people living in a smaller space is much more efficient, and therefore less polluting energy.
San Francisco might be "ruined" by your definition, but how is it any of your right to tell people what they can and can not build on their land?
> You are literally arguing for the destruction of the planet when you argue against density.
Sure cramming people in like sardines makes it easier to make things efficient - but it's very realistic to make less dense populations efficient/sustainable too. Urban developement isn't some kind of ecological optimization problem. There are factors you are completely dismissing, like overall happiness, contribution to the community and the nation as a whole, cultural value generated etc.
> but how is it any of your right to tell people what they can and can not build on their land?
Are you serious? There is the whole idea of community and sustainability. If a community deems a certain construction project detrimental to the overall health and wellbeing of its members then they can stop projects. If I don't want to live next to a highrise and the accompanying noise, traffic, pollution, I have a say in what my neighbor can build.
I'm not personally telling people what to do (because I have no authority). I'm engaging in a public debate over the SF community's values and priorities.
"There are factors you are completely dismissing, like overall happiness, contribution to the community and the nation as a whole, cultural value generated etc."
Which is not created by suburban sprawl, either. You seem to (without support) indicate that this is not possible with denser communities.
You may value that prioritization, but that isn't strange as you are a renter and so prefer things aligned as close as possible to your personal benefit.
That is simple egoism, don't coat it in nice language.
Um, in exactly the same way that tourists prefering their interests to be prioritized is also 'egoism', right? Or property owners preferring their incomes to be maximized, just like renters preferring their rents to be minimized. So?
I'm not a "market fundamentalist" by a long shot, but markets generally do a pretty good job of balancing various interests like this. They're a lot better in a case like this than the government attempting to decide how many units must be available for which uses.
Well, in the long term turning the housing into hotels screws everyone because the people who work at and maintain the hotels need somewhere to live too, as do the employees of businesses that bring tourists into the city...
There is no plausible 'consumer protection' story that would explain why building codes for permanent residence are not good enough for temporary residence as well. The law is there to protect hotel operators from vacation rental competition.
This is not a very thoughtful comment. There are obvious reasons why properties zones for permanent residence aren't appropriate for transient residence; the latter type of occupancy is accompanied by crime and abuse.
You seem to be falling into the trap of considering "consumer protection" only from the perspective of the tenant.
Is there any evidence that apartments rented out with AirBnB are more prone to crime and abuse of non-tenants than apartments not rented out with AirBnB?
You're effectively asking whether apartments rented to unchecked strangers for days at a time are more prone to abuse than apartments rented months or years at a time.
There is a reason hotels require "special use" zoning exceptions in cities, and it's not because Mariott and Hyatt have captured the city council; it's often the residents who create uproars when those exceptions are granted.
This is seen in Berlin, where some houses have several ferienwohnung. People come and go and are usually very loud while staying. People who really live in those buildings complain a lot and for a reason.
I'm not sure if we're talking about the same thing, we might be, we might not be.
You are talking about renting apartments to unchecked strangers for days and I am talking about people renting out their apartment on AirBnB. There's some relationship between the two sets but I don't think they're equivalent.
Regardless, is there evidence for the claim that crime and abuse of non-tenants is higher for either the set you're talking about or the set I'm talking about than in the general population?
I haven't looked, but my intuition is that the differences are so pronounced that finding data should not be difficult. I would not want my neighbors regularly renting their apartment while they are out of town. There is already a substantial enough difference in decorum and responsibility between owners and renters that condo associations as well as the mortgage industry (as well as FHA) establish maximum renter to owner ratios.
I live in a high rise that also contains a hotel, but with different lobbies and elevators, and that doesn't bother me. I think this is because a hotel has a management staff that maintains common area decorum and holds occupants responsible for their actions during their stay. An apartment rented on airbnb has no similar oversight or responsibility for common facilities.
Yes. There is enough evidence of this that NYC created an entirely new beauracracy just to handle these issues. Numerous papers have published articles describing fraudulent or deceptive AirBnB listings, the guests' lack of resource, AirBnB's lack of assistance.
I'm asking about evidence for the higher rates of crime and abuse to non-tenants that tptacek claimed, not about deceptive listings on AirBnB or damage to tenants.
The rationale behind this is that with permanent residence there is the expectation of a careful examination of the dwelling, and that's relatively cheap because you only have to do it once every couple decades, whenever you buy a house, and hey, people should be able to make their house however they like. With temporary residence, the cost of doing that would be prohibitive, because visitors visit new temporary residences for short durations, and an individual visitor has a low probability of being hurt. Having a shoddy structure is the exact sort of thing where making decisions for immediate profit that have a low probability of high damages in the future that regulations make sense for.
I agree with the general sentiment, I think many of these regulations exist as protection for existing industry, but isn't the risk of a hotel burning down much greater than a home burning down? The potential loss of life in a single incident is far higher.
I imagine the rules about what safety equipment a small ocean-going yacht and an ocean liner must have are pretty different too, for similar reasons.
I think it's important to use language that's fair and reasonable when arguing your point.
When you say "There is no plausible 'consumer protection' story for preventing licensed (sic) livery cab drivers from picking up curb hails" (I think you meant unlicensed) it's easy to dispute that point.
Here is the first hit on Google for "cab rider ripoff": http://www.nypost.com/p/news/local/taxis_taking_wBtAr13EzaKS... - "At least a dozen hacks have been caught hitting unsuspecting passengers with pricey tolls for bridges and tunnels that the cab never actually crossed".
And the result: "We are confirming these data, and if appropriate, will likewise seek to revoke their licenses," Yassky said. "We will continue to comb the GPS data for any similar incidences."
That type of legal solution is not possible if taxi drivers are unlicensed.
And the well-publicized instances of Airbnb problems (e.g. prostitution) are already demonstrating that at least some of the regulations are in fact necessary.
Finally, the point about consumer bank regulation is, if your bank account does get ripped off, you're insured to $250K by the FDIC, which BitCoin doesn't have. Though perhaps that is a market opportunity for an aspiring YC company?
In any event, you're overstating the case to make your point -- keep the language reasonable if you expect to make your point.
"There is no plausible 'consumer protection' story that would explain why building codes for permanent residence are not good enough for temporary residence as well. The law is there to protect hotel operators from vacation rental competition."
As an apartment owner in a multi-unit apartment building, I don't want the neighboring apartments being used as short-term rental properties - and the building regulations forbid it. It's absolutely a quality-of-living and consumer-protection issue protecting property owners from the risks associated with transients.
Why do you need to government to require that? How about you only rent from land lords that disallow tenants from renting out their apartment. Maybe some people don't mind this and would like to have that as an option.
I don't rent - I own my apartment. I've invested in a property and a neighborhood zoned for a specific purpose. Cities are generally configured with zoning laws designed to preserve a certain standard of living for the larger community that extends beyond just a single apartment or building. It helps to preserve the intended use of those properties for people that choose to buy in those neighborhoods.
For instance it gives property owners in a residential neighborhood an assurance that a neighboring building can't decide to convert their rooftop to a nightclub potentially disturbing the neighboring buildings with noise, foot-traffic, car traffic, drunks, trash, fights, etc. If you gave individual landlords the right to make these decisions without wider oversight, you'd run into a lot more issues like these. Sure - today they can petition to override existing zoning regulations and that sometimes happens, but residential issues are larger than just an individual apartment or building.
I always wonder why people with this attitude live in cities. If you want peace and quiet, shouldn't you go get a few acres in the country? Living in the city means you're living right next to a bunch of other people. Living in the city and having the expectation of peace and tranquility and total control over your home just seems like expectations out of whack.
Maybe it's just that I get peeved when people get all "landed gentry" and start thinking that somehow because they are privileged to have been able to buy a piece of property that they have a moral right to control the lives of their neighbors.
That said, I support regulations "within reason" and I suppose it all comes down to a quantitative difference in where we draw that line.
Because that's not always an available option in the housing market. There are some cities (for example, present day San Francisco) where city wide apartment vacancy is so low that tenants basically have to take what they can get. Tenants are at a serious disadvantage to the whim landlords in this kind of market. Thus laws exist that restrict what landlords are allowed to provide, which serves to protect the tenants.
You can make an argument about not restricting the free market, but shelter is such a basic human need that I think it merits a healthy amount of regulation.
And the inadequate amount of housing availability is because of government regulation as well. If they would allow more building this would be less of an issue.
> There is no plausible 'consumer protection' story that would explain why building codes for permanent residence are not good enough for temporary residence as well. The law is there to protect hotel operators from vacation rental competition.
I think Uber and Airbnb stand on different ground here. The building codes issue is a red herring; Airbnb faces more severe problems. I can think of plenty of "traveler protection", "hotel protection", "tenant protection" and "landlord protection" stories. Real stories detailing Airbnb's failure to answer these issues are already circulating the internet:
Thank you. As an Uber user in DC, I have yet to encounter, or hear of any news event in which Uber put people in a dangerous or even inconvenient situation. It's infuriating to see people compare Uber to a poorly secured Bitcoin site, as if the regulations in banking are somehow equivalent to those with taxi cabs.
Uber only uses licensed sedan drivers. They are already subject to safety regulation, but unlike taxi cabs they are also checked by reviews from passengers. The most frightening experience I ever had in a vehicle was in a taxi cab taking me from the airport in San Antonio to my hotel. He was exceeding 90 mph, and driving recklessly, ignoring the turn signals of other drivers on the interstate. Where was your touted regulation then?
...I have yet to encounter, or hear of any news event in which Uber put people in a dangerous or even inconvenient situation.
Not surprising, considering that Uber currently carries a tiny fraction of the traffic that the cab companies do. As the company scales, it's not hard to imagine that they will need to bear more responsibility for background checks on their drivers, and assume liability for damages those drivers may cause. Full-time drivers will begin battling one another for preferred territory, and Uber will have to mediate the conflicts. In short, Uber will start looking more and more like a traditional cab business, and less and less like a peer-to-peer matchmaking service.
It's not always about the direct users. Having Airbnb people show up next door and have a 3 day party impacts people. Or from a health and safety standpoint, bedbugs easily spread though apartment buildings.
They've been getting hacked as long as there have been banks, it's just that they used to have to physically break in, rob the tellers at gunpoint, or commit fraud by assuming someone's identity (say, by forging their signature). Either way, there is a regulatory framework in place that ensures that the depositors are made whole in the event of a such a 'hack'.
"I was told confidentially by an IT Security specialist from a major bank that the public would be shocked if they knew the amounts that are stolen daily from online financial institutions via ACH and wire fraud. Typically, breaches and total numbers are not revealed because they don’t want to advertise a weakness and they certainly don’t want to alarm customers. Some of the more vicious attacks are State sponsored. I believe him. That’s what bitcoin is up against as it progresses into the mainstream. The leading security experts are in that world, already protecting against the barbarians at the gate. They are not in the bitcoin world."
Bank accounts require identification and bank transactions have paper trails. Additionally international transactions have a lot of delays built in. Robbing a bank is probably safer then hacking one.
You don't hear of any high-profile bank disclosures, which I imagine is probably because they have security teams that keep up with everything religiously. Most old brick banks have internal systems architected in ways that a younger intruder in the Anonymous mold wouldn't know anything about, as well; you're starting to get into big iron Cobol land.
That said, I don't think it's an impossible task (is anything?), and I'm sure some day there will be a large disclosure through some means, internally-assisted or otherwise.
Nothing is impossible, but remotely hacking a bank is pretty damn close. A number of years ago, a friend worked for a large multi-national bank. He once described to me some of the key components of the security system. While the details are hazy (such as I understood them at the time), I do remember that one of the key points was that one of the "very important" servers that handled transactions between outside entities (i.e. other banks) and internal systems was double-firewalled. That is, you couldn't initiate connections from the internet or the intranet. The server would only make connections to hosts of its own choosing, on its own schedule.
Modifying or updating anything on the server required physical access.
There was actually a high-profile incident not too long ago with one of the big banks' online banking system. Users could view other people's account information just by incrementing an integer in the URL as I recall. It's not necessarily so much that banks are secure, but hacking them is much riskier than hacking Bitcoin sites, especially for white-hats.
re: "Legitimate banks don't get hacked because there are billions of dollars at stake for the banking institution. "Legitimate" financial institutions do get hacked, and to suggest otherwise is crazy talk. Look here where a financial institution has an exploited flaw ongoing since at least 2008. http://www.batstrading.com/alerts/ ( http://cdn.batstrading.com/resources/system_self_help/BATS_N... )
> There is no plausible 'consumer protection' story that would explain why building codes for permanent residence are not good enough for temporary residence as well.
Your home is your home, so if you die in a fire it's your look out.
But a hotel, or a temporary residence, is not your home, and if you pay money to someone to provide a service they should meet minimum standards for safety.
This is a good thing. It allows small businesses to compete but without using "safety" as an area which can be cut.
I disagree 100% with your non-Bitcoin factual assertions because they are demonstrably false but I do not have the time to address them point-by-point.
But I will address this one major factual error: Legitimate banks don't get hacked because there are billions of dollars at stake for the banking institution, and their business literally depends on their ability to secure payments.
Banks are not in the business of securing payments; that is what payment processors like Mastercard and Visa do. Banks are in the business of investing money which has been deposited with them. As a result of (state and federal) legislation, banks are liable for making depositors whole in the event of theft, so they are motivated to invest significant sums in security.
Except that regulating things is not the same as holding a monopoly on regulations. If government is so completely confident that its currency is much more superior and stable, well, allow the competition! Make it legal to receive whatever I want to receive as a payment. Let businesses regulate the currency market and determine what currency is reliable. Oh wait, except that then government cannot tax you, of course.
Also, this incident has nothing to do with regulating bitcoins. It has to do with Rails and this particular exchange site, whose reputation is now damaged and who's going to lose business. Note how free market works great in this case: the organization costs people their lost money and will most likely go out of business. Unlike big banks.
This has everything to do with regulating bit coins and the exchanges. No bank in the US would ever dare run a stock rails site, I would bet they would be rightfully sued. On top of that, funds in a bank are insured to a point so if someone at a bank messes up, the innocent people who lost their money won't lose everything they own. The free market is cruel and so are it's proponents, we've advanced past this "fuck you I've got mine" mentality as a species. If bit coin was regulated like a bank, this wouldn't be a problem. Since anti-regulation people fail to grasp this point, let me add that I do not support every bit of regulation ever passed. There is good regulation and bad regulation. Only intellectually childish people view it as ALL good or ALL bad.
> No bank in the US would ever dare run a stock rails site, I would bet they would be rightfully sued.
Why so? Even banking websites build on frameworks and if you'd have chosen Spring for example, there was a Remote Code Execution vulnerability in 2010. And even if you roll your own framework, you're just as likely to introduce a critical flaw. The Dutch governmental DigiD service runs rails [1]. The critical difference between the BC service and a bank or the government is that a responsible party would have secured their app immediately. The DigiD service was taken down pretty quickly and stayed down until patched. There were multiple workarounds that did not involve major patches and even if you didn't know which of your apps was vulnerable, you could filter the payload at your load-balancers if you had some [2].
[1] http://lwn.net/Articles/532224/
[2] An xml tag with the type "yaml" was required to trigger this. It's a pretty specific payload that is very unlikely to be used in a regular request.
My point is not that all regulation is bad. People decide if a regulation is bad or good. One may think a guns regulation is a good thing, the other may decide that a drugs regulation is a good thing. You can't reach objectivity in most cases. And then regulations have side effects: we always have to look not at just the intentions of those regulations, but also at the incentives they create (and that we cannot always foresee, example: minimum wage law).
Make it legal to receive whatever I want to receive as a payment.
This is already. You can legally trade things for other things. There is no law saying that you have to use Euro (or your local government issued money)( for everything.
The only think you have to use it for, is taxes or paying fines.
"Along with the power to coin money, Congress has the concurrent power to restrain the circulation of money which is not issued under its own authority in order to protect and preserve the constitutional currency for the benefit of all citizens of the nation."
Note how free market works great in this case: the organization costs people their lost money and will most likely go out of business. Unlike big banks.
That sounds horrible. If a bank gets hacked and "loses" my money, they owe me that money. Federal and state law requires them to put that money back into my bank account, at the bank's expense. (Note, this is not the same as FDIC insurance, which applies in the event of a bank failure.) The free market still applies: on top of getting their money back, customers can take their money to more secure banks.
Make it legal to receive whatever I want to receive as a payment. Let businesses regulate the currency market and determine what currency is reliable. Oh wait, except that then government cannot tax you, of course.
You can receive whatever you want to receive as payment; this has been a basic principle of English-based law for hundreds of years. The currency requirement is merely that any debt obligation must be satisfiable through the use of currency equivalent to the value of the debt. Also note that the government reserves the right to tax you regardless of the currency you use. This has been basic law in some form or the other for hundreds of years, and is explicitly stated in I.R.C. section 61.
> The free market still applies: on top of getting their money back, customers can take their money to more secure banks.
Unless the bank goes bankrupt. Basically, if the bank plays fast and loose with customers' money the customers shoulder the risks whilst the bank owners get the rewards - and there's no way customers can tell whether this is happening, since they neither have access to the bank's internal records and systems nor the skills and resources to make sense of them.
Actually, the only reason the baks have to return the money in the first place is because of Government intervention, and even that's not enough. Unfortunately, thanks to binding arbitration the US has a free market of sorts in dispute resolution, and the banks and financial providers have so much more market power than consumers that they can effectively pressure arbitrators into siding with them. If they don't, the bank won't do business with them and they can't find work, whereas most consumers only need to use arbitration a few times in their lifetime at most.
FDIC insurance applies if the bank goes bankrupt (and has since the 1930s), ergo, I would still get my money back. It is not a matter of arbitration; banks have gone bust frequently enough that there is a settled procedure for issuing insurance proceeds to depositors of a failed bank.
Banks pay for FDIC insurance coverage as part of their capital requirements for being a bank.
>Basically, if the bank plays fast and loose with customers' money the customers shoulder the risks whilst the bank owners get the rewards - and there's no way customers can tell whether this is happening
Tip: This is happening. This is how banks have and will always make money.
It is the role of governments to regulate to what extent the bank can use your money and for what purposes in order to minimize customer risk.
This argument seems to beg the question (in the actual meaning of that phrase), at least w.r.t Uber and AirBNB. All the problems they've had have come from the regulatory authorities, except for those one or two bad incidents on AirBNB which are pretty much unavoidable in a business like that. So is the argument that regulation is good because it's hard to cope with the regulators?
I just don't buy into the abrogation of common sense argument for regulation. If you let random people stay at your apartment, there's a chance they'll destroy it. If you're really worried about that then buy renter's insurance or don't sublet your place! If you give your bitcoins to some random website, there's a chance it'll get hacked! It's not like those people didn't have option of putting their money someplace more secure, like a bank.
I think regulation in general is really important for making our society a decent place to live, but when it makes reasonable activities effectively illegal that is generally a sign that it has passed that point and started making things worse.
All the problems they've had have come from the regulatory authorities...
I'm not sure about Uber, but this is most definitely not true of AirBnb, which has come under fire from many neighborhood associations. It's not just your quality of life that gets reduced when you rent your house to bad apples, it's your neighbors' as well.
I guess I can take other people's word on this argument, I live in New York (where AirBNB is illegal) and there's plenty of odd loud people running around my building any given day. Inside a building is different but I have no problem with individual building leases banning AirBNB (I'm sure some would and some wouldn't).
All the problems they've had have come from the regulatory authorities, except for those one or two bad incidents on AirBNB which are pretty much unavoidable in a business like that.
Atlantic, Wired, the NY Times, Chicago Tribune, and the L.A. Times have variously run horror stories for renters who made the mistake of using AirBNB to book rooms (see, e.g., Toshi hotels and their variants). The whole point of hotel regulations is to protect the guests, not the hotelier.
This is the freedom from risk argument for regulation? There are plenty of horrible legal hotels in the world. I personally think cheap hotels are an important part of the ecosystem.
> The whole point of hotel regulations is to protect the guests, not the hotelier.
Brilliant point. It's a case of experimenting with the balance of freedom vs regulation.
Perhaps it's not vital that a hotel(or taxi) is licensed today, because we can easily see its realtime feedback from previous users. But then again, perhaps those users don't notice that there is no emergency lighting and the fire alarm is disabled, or that the driver has multiple convictions for dishonesty.
It's great to see that this post has triggered so much discussion. Let me add that I'm not saying the status quo shouldn't be challenged, or that there aren't efficiencies to be had, only that if a business model looks too good to be true ("hey, I can rent a whole house for the cost of a hotel room and have 10 people stay for the price of 1!"), it probably is. Neighbors (who also qualify as consumers, I believe) are raising serious objections to AirBnb. At least one Bitcoin exchange has qualified itself as a bank---presumably raising its costs and requiring it to charge more fees than its competitors in return for the security it offers. Meet the new boss, same as the old boss.
A decent observation, but it's also true that sometimes complexity becomes an end in itself. It cyclically begets more complexity until it collapses and a new, simpler form emerges.
This Tetris-like complexity-collapse model is very common in biological evolution.
When it works well, the new simpler system will still solve the problems that the old complex system solved. It will just solve them more elegantly.
Paypal encountered many of the problems that central regulators were set up to solve. Their solution to fraud protection was better than anything else out there, and has been widely copied in the industry. Do they have false positives? Yes, but international person-to-person (vs. company-to-company) money transfers have never been easier. Newer startups will make it easier still.
Regulators and incumbents need competition. No new product is ever better than an existing product in ALL respects, only in some features. Hitting the features that existing regulations are meant to ensure might not be #1 on the feature roadmap, but it's on there.
The problem is when features that are less important to customers are prioritized by regulation (and therefore by guns) over features that are incredibly important to customers. Clearly, the existing taxi regulations did not incentivize rather important features like "convenient for taxi customers" but instead were about edge cases that are important, but only at scale.
I agree that companies need to take a look at how their industry is regulated and what purpose those regulations serve. But the fact that companies can come into these types of industries, openly skirt the regulations, and still be massively successful shows that the existing laws aren't meeting the needs of the people who use these services.
And how exactly has government solved "the problems inherent in the peer-to-peer model"? I'm not sure what problems you're talking about in the first place.
I'm not sure what problems you're talking about in the first place.
That's the point. :-) A number of them have been enumerated above: protecting banking customers from loss in the event of theft; regulating the location and safety of hotels; providing some means of recourse against a dishonest cabbie.
They are inherent in peer-to-peer because peer-to-peer transactions are based on trust, and trust ultimately has to be based on accountability. If I'm in a small town, I can trust a local resident because I know their history and where they live. If they injure or steal from me in some way, I have some recourse, if nothing else with the social shame that can be brought to bear in a small society. But in a large-scale business, in a society of strangers, that accountability has to be enforced by some kind of regulatory body. And that kind of regulation implies at least some kind of comparatively centralized authority, which is at odds with a true peer-to-peer ideal.
No, I'm saying someone will have to be the regulatory body for AirBnb, because their business is infringing on other people's rights, for example neighboring homeowners who are disturbed or damaged by AirBnb renters, or customers who are exposed to dangerous conditions on an AirBnb property.
Are you saying that AirBnb, for example, can't be the regulatory body for its customers? Or is there a reason why it's necessary for the government to step in?
Much of the regulation was created for good reason but it is hard to argue that there aren't a lot of regulation that is merely special interest to prevent competition or grant special favor.
Rather than more regulation, perhaps more transparency is a better solution. 3rd party certification would do a much better job at security than a government regulation. And have much less abuse and overhead.
Imagine that a thief breaks and enters into a warehouse which is holding physical gold for its customers, and the thief steals all their gold. The warehouse and/or its customers will suffer losses, but every single ounce of the gold stolen by the thief will continue to be as valuable as any other ounce of gold. In other words, gold will continue to be the same exact commodity.
Essentially the same thing has happened here, but in the digital realm. A thief (or thieves) broke into the backend systems of an exchange which was holding bitcoins for its customers, and the thief stole all their bitcoins. The exchange and/or its customers have suffered losses, but every single bitcoin stolen by the thief will continue to be as valuable as any other bitcoin. In other words, Bitcoin will continue to be the same exact commodity -- its integrity has NOT been compromised.
The moral of this story: if you own bitcoins, make sure they are stored in a truly secure system. Many Bitcoin exchanges claim to be -- but really aren't -- truly secure!
Shesh. A Bitcoin has no inherent value. If such incidents become common enough, nobody will be willing to buy bitcoins for dollars or accept bitcoins as payments for goods,which means that the thieves will sit on a bunch of useless bits.
Chinese people can pay their taxes in yuan. When there was a gold standard you could pay your taxes in gold, but now there isn't, which is why gold is just a commodity, not a currency.
Gold is inherently useful as a tangible object with exploitable physical properties. Gold, for example, has good conductivity and is used to plate electrical connections. Gold is also useful for its rust-resistance.
Thus, on this basis, like all useable physical goods, gold has some inherent value as a commodity.
None of these points have anything to do with an intrinsic value for bitcoin; all of them presuppose that bitcoin is intrinsically valuable.
Bitcoin can be worthless and yet hard to counterfeit; I can sign a random number right now and it's worth nothing. I can Tweet that number or create a permanent record in any number of other ways.
Your second point is the same as your first; it again presumes that there is some value to bitcoin.
I can store a lot of things without meaningful cost. That doesn't make them valuable. My application server with seven gigs of dev logs isn't a treasure trove either, despite the ease with which I managed the data relative to bars of gold.
Bitcoins are easier to transfer than gold coins. That is true. But spent facial tissue is also easier to transfer than gold.
You can form contracts with all manner of instruments, from cows to gravel to pork bellies. Every commodities trader in Chicago has a story about a friend of a friend who ended up with a garage full of pork when they failed to sell a futures contract in time.
> Gold is inherently useful as a tangible object with exploitable physical properties. Gold, for example, has good conductivity and is used to plate electrical connections. Gold is also useful for its rust-resistance.
Do you really mean to say gold's rust-resistant properties are to blame for it's exceedingly high price on the market?
Fact: In 2013, Bitcoin is the world's easiest way to send a standardized indicator of wealth from one person to another. Forget anonymity, forget open source, forget deflation, forget amateurs building Ruby on Rails websites poorly!
Bitcoin's #1 benefit is the ousting of intermediaries. Because Bitcoin transactions can occur directly between two people without any third party involvement, the platform upon which people trade Bitcoin for goods and services becomes irrelevant. With Bitcoin, the platform only matters to the extent it aids in the market discovery process.
I for one see inherent value in a currency I have control over 24/7, that I can literally park in my brain never to touch the public Internet, carry with me everywhere I go, send to anyone, anywhere at any time, instantly and without an intermediary. If you see no value in that, honestly, what is there to say. Good luck with your financial goals in 2013.
A USD has no inherent value since it is also a FIAT currency. At least BitCoin's algorithm is locked into a growth curve that eventually stops. The US can continue to print money. THe way I see it, BTC is going to increase in value.
> The moral of this story: if you own bitcoins, make sure they are stored in a truly secure system. Many Bitcoin exchanges claim to be -- but really aren't -- truly secure!
Then how do you know what storage locations are truly secure? If you have to be a computer security expert to safely use bitcoins, then that will surely decrease the demand for the currency and therefore reduce its value.
Looks like this is one of those stories that belongs in an "always-true" newspaper, along with "tensions in the middle east escalating" and "congressman apologizes for affair".
I can't get to the article at the moment, but I'd love to know why they failed to update their app especially since it handles financial transactions. I had several apps to update and the process took very little time and effort.
It's not excusable really, but I'm not too surprised.
It was only a day or so from when a patch was available to when a public exploit was everywhere. Maybe they were on vacation, maybe the site was built by contractors who have since moved on, maybe they don't read hackernews or other programming news sources. I expect to see similar stories in the coming weeks.
This vulnerability went from disclosure to exploit extremely quickly. The CVE was published on the 8th. I can't speak for them, but in the process of trying to update, we ran in to some issues with therubyracer (a core component of the Rails asset pipeline) and libv8 (the library that therubyracer uses to embed the V8 engine). It was extraordinarily bad timing, and it slowed down our update process by almost a day while waiting on a new version of therubyracer and libv8 to hit.
Having said all that, if our upgrade holdup had taken any longer than it did, we would have implemented one of the mitigation strategies.
You cannot leave your site open to a pre-auth remote code execution vulnerability while you wait for fixes to the asset pipeline or to any other component of Rails.
I don't know that that's what you're saying you did but we need to be glacier-blue-ice-clear about this. Nobody gets to wait on bugs like this. You patch or workaround immediately or, most probably, you shut your app down.
It slowed down the update (to 3.2.11), but it didn't prevent us from removing the XML parser from DEFAULT_PARSERS immediately. I'm not defending anyone here. I'm simply pointing out that the scenario wasn't exactly status quo. This has all moved very quickly.
EDIT: I guess that qualifies as a mitigation strategy, but when I said that, I was talking more along the lines of the patches, or like another person I know, even more dramatic steps like forking Rails. There are regressions in the 3.2.x updates since 3.2.9 that affect some sites.
Bottom line is that there was a lot of bad timing here that sucked up a lot of time in securing a Rails site.
Also, lest anyone think that they have time, there appear to be scanners up using the Metasploit code. This request came from an IP address on Road Runner's netblock from Ohio. The request hit a server that we don't publish, and the IP doesn't match any other requests in our logs. The greatest likelihood is that it is a computer locked up in a botnet.
You also cannot publish little known pre-auth remote code execution vulnerabilities for your web-framework without first publishing a mitigation patch that doesn't paint a BIG FAT RED ARROW onto the attack vector.
You also cannot leave 6 years of vulnerable Rails-versions up on rubygems.org without even backporting your patch (yes, they're still up there now).
It makes no sense to blame the users of a web-framework, most of which are not security experts, for not responding instantly with the perfectly correct procedure to an event of this magnitude.
Put the blame where it belongs, on the idiots who "handled" the issue by releasing a "recipe to exploit"-Advisory. The same idiots who ramble about "not breaking old apps" when asked why the vulnerable gems are still up on rubygems.org and continue to be quietly installed by any Gemfile referencing them...
I sympathise with you but (a) none of this matters in context; you still have to fix immediately or pull the plug and (b) you are deluding yourself if you think a flaw that 5 teams found independently the day the last SQLI advisory was released wasn't going to be in Metasploit within 7 days. This bug was too damn blatant.
I don't know why people weren't taking a hard look at the params processing code path in Rails for 6 years, but they clearly weren't. The SQLI bug from last week pointed people at that code, it got its first real shake, and that's all there is to say about it.
As a fan of responsible disclosure, the sad state of the universe is that telling people "upgrade to X now" on an open-source project makes it very easy for anyone to diff to find out what the fix is, which makes it very easy for people to figure out how to exploit it.
A bit more creativity should be allowed when handling a vulnerability of this magnitude.
For example, publish a patch that escapes all input in curious ways, presumably to prevent SQL injection. Pad it, obfuscate the actual fix with code-noise, make it annoying to read. Then release it as some handwavy, semi-plausible "follow-up" to the previous SQL-injection, urging everyone to upgrade in small caps.
Yes, a handful of blackhats will see through the bluff. However, it will likely be the exact same blackhats that already had discovered the issue after the initial SQL injection advisory.
This would have given the Rails-community a head-start, rather than unleashing every script-kiddy on the planet at once.
I was actually pretty upset because I thought that might have been what the Rails team was trying to do --- to come up with an occlusive patch, like you're advocating. Because that plan was. not. going. to. work. When multiple teams flag the same RCE on the same day, the only reasonable conclusion to come to is that the cat is out of the bag.
What needed to happen is what happened: a patch and a series of workarounds were produced as soon as possible.
Nobody got to choreograph this one. The control you think the Rails team had over this, they did not have.
This is terrible. The OpenBSD/SSH team tried this once, with the channel bug. They released the privsep version of ssh which didn't fix but mitigated the bug, and told everybody there was a critical bug and you really, really wanted to upgrade. What happened next? Everybody from Alan Cox on down started complaining about how they weren't going to dance to somebody else's tune and they were going to wait to see the real fix, thank you very much.
I actually remember this incident (albeit blurredly, hell, was that really 10 years ago...).
I dug up a few snippets[1] and I think the main sources of the animosities back then were certain regressions caused by privsep (not a hassle-free change) and a bit of ego-clashing (Alan Cox, Theo).
Your summary of the events may be about right, but is "not wanting to dance to someone else's tune" really a good argument against an attempt at responsible disclosure?
No. I was advocating to release a patch that fixes the issue in an obfuscated, non-obvious way. And labeling it as a boring-yet-important follow-up to the previous SQL-injection vulnerability, rather than yelling "LOOK, REMOTE CODE INJECTION HERE -->.<-- !!" on all available news-channels.
Would you invest time in a framework where the developers knowingly lie about security vulnerabilities and provide fixes that are intentionally complicated?
That seems like something that would ruin any future credibility of the project. No further security vulnerabilities could be trusted as being accurate (and any further patches would just be begging for additional scrutiny).
If a Linux distro released a kernel patch for a super-critical security vulnerability that lied about its nature, AND downplayed its importance, users would go apeshit (justifiably).
You're still making no sense. Various large projects, including the kernel, have seen silent security patches (yes, even by Linus himself).
Also there is no "downplaying" in declaring any kind of problem as a remote SQL injection vulnerability. That is still obviously urgent enough for everyone to patch immediately. Yet it doesn't attract blackhats in the same way as blarting "remote code injection".
Mis-labeling a Remote Code Execution vulnerability as SQL-I is absolutely downplaying the severity. SQL-I is a bad finding, RCE is tantamount to the worst thing you could possibly find in an application.
There were people on this very site who were commenting about whether they should concern themselves with this patch (initially because people erroneously attributed the vuln to SQL-I, and then later because they "weren't using XML anyway")
Those kinds of things happen when you don't clearly describe what a vulnerability is, and when you try to mask how big of a deal something is.
This was a huge vulnerability. It was critically important that everyone running a Rails app fix it immediately. Shouting that from the rooftops was absolutely the right approach. Cloak and Dagger bullshit to try and hide that is unequivocally a bad idea.
Well, the votes are strongly in your favor, but I remain unconvinced - accepting that I'm in the minority here.
For me this very article (bitcoin exchange being hacked) demonstrates that despite the harsh wording, the advisory didn't reach everyone in time. Not even those who should really care (like bitcoin exchanges).
I still think the explicit disclosure did more harm than good, by drawing maximum attention from the blackhat-community without really improving the reach amongst the oblivious. I still think a "staged" disclosure might have worked better, even at the risk of the timeline being short-circuited by a malicious party spilling the beans early.
However, there's little point bemoaning this particular baby or bathwater much more now.
I'm more interested in the steps that the Rails-team will be taking to lessen the blow by future security incidents. As I've said in another thread I'd be in favor of an optional (opt-in) kill-switch, to be triggered only in drastic cases like this one. Perhaps that is a point where we can agree again - otherwise we'll have to part in disagreement. :)
I don't understand how the Rails team could plausibly have slowed down the disclosure. The exploit wasn't proprietary information, and it was easy to find.
I don't want to drag this out further (all said and voted I think), so I'll only briefly refer to my idea of an "obscured" patch. Not pretty by any metric and definitely not a template for future incidents. But I still think it could have stretched the timespan a bit between the discovery by security-researchers/rails-hackers - and that afternoon when our Rails-intern (beginner ruby frontend coder) proudly showed us how he reproduced it in his rails console...
How much time do you think that would have bought? At least a few minutes, but definitely not days. And at what cost would it be?
I'm all in favor of giving people more time to upgrade, but this issue was very unusual. Multiple groups were all finding it at the same time and who knows when the first "full disclosure is always the right answer" group would have started singing? Like it or not, full-disclosure people exist in the world, and responsible-disclosure people need to be aware of their existence.
If just one person/group had found this, RoR could have done a better "get ready to upgrade next Tuesday at 6am" followed by a "here is the patch, details to follow tomorrow" on Tuesday at 6am.
I was actually pretty pissed that it wasn't explicitly labeled as a "remote code execution" vulnerability in the CVE post title. This is open source, you don't get to hide. The code is there. Trying to be clever about releasing a patch isn't going to help, because every patch gets looked at by a large community of security people. Some of those people are the good guys, but some are the bad guys.
Nothing about this situation was good, but hiding it would have only made it worse. When you're serving shit sandwiches for lunch, it's best to let everyone know that's what's on the menu. End of story.
Perhaps this may sound harsh, but if you handle large amounts of money and are informed that your software stack allows arbitrary code execution then:
You pull off the plug ASAP.
Better have customers unable to use the service for one day than have the customers lose their money while you stumble trying to figure out how to patch it. This is elementary for any mission critical system. Just imagine your neighborhood nuclear plant delaying the insertion of the control rods during a meltdown because it has to wait for some shinier parts to arrive.
therubyracer thing was annoying, but there's no reason it had to delay your upgrades -- you could simply lock to the same version of therubyracer you were using previously without problems, it was just as compatible with the new version of rails.
The fact remains though, that this exploit was _so_ severe, that, depending on how attractive a target you were and how disastrous it would be for you to be compromised (financial services? High on both scales) -- it would have been a better choice to _take your app down_ until you can fix it, rather than leave it up with the vulnerability. The vulnerability was "an attacker can run whatever code they want on your server, and they can discover that you are vulnerable by cheap automated port scan." It's as bad as it gets.
I'm not saying that you shouldn't mitigate this vulnerability immediately (which is not the same as upgrading to 3.2.11). People are asking why/how this kind of thing happens, and I'm pointing out that there are a lot of opportunities to make the wrong decision in this situation.
I think an even better question is why they didn't have multiple layers of security that would have prevented a bug in a public facing server from compromising financial data.
When systems are designed with security in mind, rather than simply throwing together a web/sql application, people put a lot of time and effort into constructing barriers to protect the integrity of their data.
Take for instance the CACert certificate authority. They designed their system in a way where the master key that signs certificates is stored in a computer that isn't connected to any network. The actual servers then talk to this computer over the serial port using a carefully crafted API when they actually want a certificate signed. This means signing certificates is slow and the key is inaccessible. So if all their servers got remotely compromised, a hacker would never be able to get the key and at best would probably be able to sign a short list of certificates before being detected.
Other people have suggested that this black box should store public/private key pairs generated from the user's password for each user on the exchange. So when a user signs up for an account on the exchange, Javascript code generates a private key from the user's password, client side. The corresponding public key is sent and stored in the offline transaction signing box. Whenever the user wants to initiate a withdrawal, the transaction signing box creates a random number that needs to the signed with the private key that corresponds to the public key it has on store. This way an attacker need to compromise a server and install an eaves dropping application that replaces new users' (or existing users changing their password) real public keys with its own. Just breaking into the server wouldn't do the attacker any good at first.
Bitcoin supports "cold storage" which is effectively a wallet that can receive funds, but is offline so you cannot transfer funds out of it. That is, the private key is stored offline.
There is really no excuse for exchanges not using cold storage.
I think this will require too much manual intervention to be viable. Customers not being able to withdraw their funds because they've been sent to the cold wallet makes them unhappy with the service.
You could handle withdrawals out of a float fund, without actually reconciling against the user funds until an offline process completes. This way, at most, your float is at risk, and it's your money, not the customer's.
This is a remote code exploit. For the web interface to do its job, it needs to be able to manipulate the wallet. They can stare at the code that does that, write their own, and do whatever they want.
Why does a web interface need to directly manipulate the wallet? It needs to store the transactions somewhere where the machine that executes them (using the wallet) can find them.
You need the seperation and you need to closely monitor and control the transactions requested from the web interface to detect any fraud or misuse.
Doesn't matter whether you do it directly or indirectly. There is some way of automatically manipulating money, and it will discover what it is.
I can dream up architectures which limit manipulations, require the user to constantly type in passwords, etc. A company not security conscious enough to update is unlikely to have done that. But suppose they did, what happens? EVEN THEN you can turn the website into the digital equivalent of an ATM skimmer, and steal money. That is, of course, assuming that I have not managed to turn shell access into some more direct compromise of your whole network.
Here is the moral. If you're directly handling money or a money equivalent on your website, and someone has shell access, they will be able to steal from you.
That's why you put velocity controls in place, so that if things go south you can limit losses. Coupled with alerting/reporting on transaction volumes and you should be able to get ahead of someone that bypassed your front end before they make off with all of your cash.
That said, if the backend is also vulnerable to the same or another exploit, that's not going to buy you much.
A secure bitcoin service provider should never manipulate the wallet directly, or in realtime. Transactions should be handled transparently, logged, and then actuall excuted on the offline wallet later after fraud and loss mitigation routines have been applied.
After the Rails exploit was announced I was jokingly mentioning to a friend that this will hit a few Bitcoin exchanges. Seems there are still exchange operators that haven't learned anything about the previous exploits.
Any exchange operator that didn't stop whatever they were doing, be it eating a sandwich or having a baby, and run to patch their servers has failed their user base completely.
An exchange operator that operates both the exchange its self and its web-facing front end from the same server(s). You really have to wonder what they were thinking?
While a front end compromise is always going to be bad, splitting the two gives you more options and more ability to spot when the front end is acting unusually.
If it's that easy to steal, you're probably doing it wrong. The front-end server should never have direct access to the bitcoin RPC server, since the front-end is likely to be vulnerable. Instead, it should contact a robust back end server, which then talks to the RPC.
Banks don't keep all of their assets in cash in the safe. In its very simplest form, a bank takes money from depositors and pays a small "savings" rate. It then lends this money to borrowers at a higher rate. Every dollar in the safe is a dollar that isn't out earning interest, so the bank wants to only keep enough on hand to cover what customers will need for withdrawals.
I met an ex bank robber once. He and his "gang" attempted to rob a branch that was near a factory. The factory employed a number of immigrants who were fond of cashing their entire paycheques on pay day, so it would bring in a lot of extra cash every pay day. They timed their robbery for when the payroll money was present.
Unfortunately for them, the scheme had been rumbled, so the payroll delivery was fake and the police were waiting in plain clothes for them. He was shot in the neck but survived and learned to play bridge in prison, and in the fullness of time was released, where I met him and heard his story.
Any ways... It seems quite possible to me that a bank could be robbed but remain solvent.
Robert Heinlein makes good meat out of this misunderstanding of banking in his book 'Time Enough for Love'.
The nearly immortal protagonist often ends up being the banker in a small frontier towns. He routinely has to deal with mobs of people who attempt to "nationalize the bank" and are dumbfounded to discover that the bank does have all of the money in a safe.
Most Bitcoin exchanges - apparently including this one - only store a small portion of their funds in the wallet on their live server for exactly the same reason. They claim they can cover the loss.
Banks are typically capitalized by a variety of assets, of which cash is typically a small amount.
In addition, the bank typically has its cash holdings distributed at a number of different branches.
Your account at the bank is technically it's liability. Essentially, you've loaned your money to the bank with an option to redeem it at any point in time (demand-deposit account, or checking account) or up to some period of time after asking for it (time-deposit account, or savings account).
So, let's say a bank's branch is robbed of $10,000. What happens? The banks shareholder lose $10,000.
Let's say all the cash and physical assets at a branch is robbed. The bank will typically cover those assets with assets from other branches. The bank's shareholders swallow the losses. Sometimes the bank will sell additional shares, or some of its remaining real assets to help provide it with more liquidity so it can continue to cover funds requests by account holders.
Let's say a bank has all its assets in cash in a single branch location and that location is robbed, meaning the bank now has no assets left. That bank is now bankrupt. It goes to bankruptcy court and you are a creditor. Once the banks remaining assets are sold, you may get a few pennies.
This is a major failing of the existing bitcoin repositories. They aren't banks and so aren't regulated as such. They're just storage lockers where you hide your cash under a mattress. In the event of a theft or fraud... oh well! It'd be interesting to see someone get a bank charter and backup those bitcoin deposits with real capital.
It should be obvious that the above is a gross simplification on my part and the FDIC and modern banking arrangements make things much more complicated when it comes to bank failures. That said, the simplification gets to the original question of what happens without modern banking arrangements.
>Let's say a bank has all its assets in cash in a single branch location and that location is robbed, meaning the bank now has no assets left. //
Governments can and do offer an insurance system whereby they will ensure that customers receive a substantial part of their monies back - this aids against bank runs (where customers panic and all try to withdraw their money as cash and so cause the bank to implode).
And aside from movies, the meth-heads can only carry and drive off with so much money. A few thousand here and there. It's a very inefficient time to be a bankrobber.
"Using confidential data on the value of every bank heist in the U.K. from 2005 to 2008, the trio came up with an economic model of bank robbery.
They found that the average revenue from a British bank robbery in 2005-2008 was only $31,600, although excluding the one-third of robberies that came up dry boosts the average to $46,600. But those proceeds have to be divided among the gang, and while extra gang members raise the average take, the haul per person decreases.
The average take per person per successful job was $19,792, equivalent to less than six months’ average wage in the UK, although being armed increased revenues substantially. While that may not sound too bad, multiple jobs greatly increase the risk of arrest and incarceration, as 20% of heists ended that way.
Data from the FBI paint a similar picture. In 2011, there were 5,086 bank robberies in the U.S., generating $38,343,501.96 in revenues for the perpetrators, or an average of $7,539 per heist. Excluding the robberies where nothing was taken increases the average only to $8,457. Not only is the return low, the risk is high: out of 13 people killed during bank robberies in 2011, 10 were robbers."
Yeah, most banks just intentionally try not to publicise the fact they've been robbed from what I've heard - it's bad for business and tends to encourage future robbers.
I wasn't expecting this, but it feels good to know:
"Number of incidents in which deaths occurred: 3"
all 3 were the perpetrators rather than employees / customers. On the other hand 2 hostages being the employee's family members is disappointing. It's really sad that people really do involve the families of targets just for a bank robbery.
If only there were some way to learn from history - then it wouldn't take newly launched services decades to meet basic modern security standards.
Seriously, I don't see any comparison between this and a bank robbery. It's not like banks in 1933 were only just figuring out that they should lock the door where they stored the money, or that they should repair any holes in the wall, or even that paper walls, though they are quick to build, have a very bad record on security.
In the US, at least, people still got famous for being bank robbers back then. The FDIC, which provides limited insurance for bank deposits, started their insurance on January 1, 1934. So, sophistication aside, it's an interesting question what happened to depositors after a bank robbery.
My question was, specifically: It's 1903, you deposit your life savings into your local bank, and a week alter it gets robbed. Do you get any of that money back? Or are you now broke?
A deposit is an IOU from the bank to you; If the bank fails as a result of the robbery, you are SOL. However, if the bank remains solvent, it absorbs the loss.
In most cases, even a large robbery wouldn't ruin a bank: They could borrow against or sell their mortgages to another bank for cash to pay depositors.
This is different than a safety deposit box: The fine print is that you are responsible for its contents and if the bank is robbed, they will not replace the contents or reimburse you.
So, if you put your life savings into gold and put the gold in a safety deposit box, you lose. If you put your life savings in a deposit account, you will be reimbursed unless the bank fails outright.
(Prior to the creation of the FDIC in the US or deposit insurance in Canada).
How would the bank know whose money got stolen? It's basically a bad question. If the bank fails because of the robbery, then you lose all your money in 1903 (or at least most of it). Otherwise, things just keep on trucking as normal.
The majority of legitimate people running Bitcoin related services are of a very fringe type. It will probably remain this way for a while. This is because there is so much risk involved. Not just risk of currency or business failure, but risk of harsh legal action. The subsection of the population this selects for ends up being... let's say... not so reliable.
Then worse, you have tons of internet criminals coming up with clever strategies to part people with their Bitcoin. Will these guys reimburse their users or end up giving an excuse and disappearing into the ether? Only time will tell.
That said, Bitcoin itself remains strong and probably one of technologies with the biggest potential in quite a long time. These issues will continue to occur and spawn drama for the foreseeable future. At some point the good Bitcoin news will drown out the bad Bitcoin business news. But that's not going to happen anytime soon. So let's get used to it.
Even given I must admit that this was a spectacularly stupid hole[1], I don't think your point is valid. It's not like other frameworks in other languages don't have similar issues [2]. Rails is for what it does well engineered, well tested and using it for what it's intended is usually a solid choice. Rails enables and pushes testing on all levels, thus improving quality of all rails apps that follow the lead. You can argue that rails is not a good fit for a lot of use cases, but that's a completely different argument - and one I usually agree with - but all in all rails and its ecosystem pushes exactly the values that you say are missing.
[1] Auto-Unmarshalling yaml in xml, seriously? Who wants yaml in xml?
[2] I'm sorry to single out spring here, but this is a nice example since it's the same kind of attack: Instatiation of an arbitrary class, in this case by modifying the class loader and loading the class from a remote server: http://support.springsource.com/security/cve-2010-1622
Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype.
However, my original generalizes the problem as a human issue which is where the real problem is:
Did they do a risk analysis on rails - no
Did they verify their architecture - no
Did they perform input/type checking - no (sorry but statically typed languages win here)
Did they act responsibly - no
Would you trust them with your cash? Probably not then.
This is the opposite of banks who have multiple layers of security to prevent all the associated risks of the business.
Would a bank run their OLTP on rails? Hell no, because they did the risk analysis above, which is my point.
I agree on your analysis of the BC exchanges behavior. They neither did a proper risk analysis nor did they build a systen designed to safely handle the wallet nor did they respond in a timely and responsible manner. I just fail to see how that's rails fault.
Would a bank run their OLTP on rails? I don't know. I'd rather say that rails is a bad fit for that kind of problem, but that's not the goal. Rails is built for web-applications of a pretty specific type, quick build and release cycles while still keeping a solid focus on code quality [1]. So your problem is that folks see an opportunity to make money, take the first tool that seems to fit and build stuff that doesn't hold water. But that's language agnostic. You certainly realize that 10 years ago java was the "poorly specified rickety language in a community of hype".
Perhaps they should have done this up front, you know as part of the engineering, hence my point. Stopping and thinking for a bit usually covers these problems. I've read a huge chunk of the rails framework source code and it certainly used to be a pretty amateur piece of kit.
The argument is definitely not preposterous. Are you saying guarding against bad inputs and enforcing type is bad? A language which uses no type inference has less assumptions therefore is likely to be less error prone. I've proven this hundreds of times over the last 30 years of writing code in things from communications electronics to financial quotation platforms.
>Perhaps they should have done this up front, you know as part of the engineering, hence my point.
And you know what, I have a feeling they did have multiple people looking over the code, and it's been vigorously refactored over the years. Rails 3 is a somewhat different beast from Rails 2.
Careful auditing reduces bugs but does not eliminate them. Crowing about "proper engineering" is very nice but is somewhat farcical given the state of the art in the industry.
>Are you saying guarding against bad inputs and enforcing type is bad?
No. Of course you guard against bad inputs.
But that's wholly separate from enforcing the type of the objects. And it's not like people are eval()ing stuff willy-nilly.
"Actually, this bug was discovered precisely because people began to perform a more in depth analysis."
From Wikipedia: Ruby on Rails - Initial release July 2004
Eight-and-a-half years later, in depth analysis has come about to find this? (The exploit is present through 3.2, meaning it's been around all that time).
As a Rails developer myself, it is really embarrassing to admit that all Rails apps in the last few years have been completely and totally vulnerable. The good point that it was discovered by security researchers without a known exploit is good, but we don't know if it was previously exploited without anyone's knowledge. Maybe there were smart pen testers who were routinely getting in to Rails apps without anyone's knowledge for years.
I completely agree: It's a stupid bug that lingered long in the codebase, probably because it was hidden in an obscure feature that nobody knew about or used. It's embarrassing, but I bet that pretty much every larger framework out there had a remote code execution bug[1]. Still, it's wrong to point at it and say "that's an engineering or QA bug that's symptomatic for the rails bunch." I'm not a rails friend, but the response showed that the rails developers take security and QA serious. Patches and workarounds were released not only for the supported versions, but also for older, long-dead releases.
I bet that pretty much every larger framework out there had a remote code execution bug[1].
I would gladly take the other side of that bet.
A decade ago I was working on a site using Perl/Mason/Apache. When we were bought by eBay, we were put through a thorough pen test. The ONLY security hole they identified as needing fixing was a redirect that could redirect to any URL anywhere. (The people testing us were shocked - they had never before seen that few problems.)
To the best of my knowledge, no holes have been discovered in that architecture in the following decade either. (Looking through Apache vulnerabilities, there have been a couple of remote code exploits. But not on all platforms, and we turned off every feature we didn't need.)
If you take the attitude up front that you won't have magic, this kind of bug doesn't tend to slip in. If you take the attitude that there will be a lot of magic, then this kind of bug does slip in.
You admit that the framework you used had a couple of exploits and you were not affected because you turned of all features that you didn't need. The current rails vulnerability does not affect you if you turned off all features you didn't need. Same argument. So we have a hole in Mason, I already cited one in Spring, someone else cited one in .NET http://news.ycombinator.com/item?id=5043839.
I don't think "Rails generation" means only Rails. I think the idea is that we're so dependent on frameworks these days, there are massive pieces of our application that we have no clue how they work, and worse, we trust the framework authors implicitly. More and more we're seeing the downfalls of this. As Rails is essentially the best known and most deployed, hence the name.
Think about it: for most apps, probably 95% of your code is a framework that you didn't write. When this is criticized, the response is typically "open source unicorns! speak no more!" Moreover, there seems to be a different level of forgiveness just because it's open source. If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow.
I love frameworks, and I think an average team would on the whole write less secure code than an open source framework would. If we want maximum transparency into our code, we'd go back to CGI written in C, but our productivity would tank, and looking back, the boom of recent years never would have happened.
However, we need a different attitude. Let's be honest: the arguments about open source are mostly a lie. Yeah, I went there. No, I'm not advocating closed source. Too many hang their hat on the ideals of open source. We're not talking ideals. We're talking rubber meets the road, cash leaves the bank reality. "Anyone can view the source - many eyeballs makes it more secure." The truth is, there aren't that many eyeballs. How many download, or (for the real technology ninjas) git clone, and trust what they're working with (whether app or framework) by a faith that rivals any religious organization?
As an industry, we need to read more code. We need to push back against the Barnes and Noble developer, the one who paid $29 for a book and now calls themselves a developer because they finished it front to back. Not everyone needs to be a senior engineer, but we have too many with that title after 3 years of building framework apps who couldn't code their way out of a CS101 class if they had Donald Knuth and Dennis Ritchie as their personal tutors.
This is pure supposition, but I think if at least 10% of those who used Rails read Rails, it'd be far more secure.
You want to export your common web app code to a framework for all the same reasons you don't want to write your own crypto libraries - the more people look at it the safer it is.
Far more damage has been done to the web from people not using a good ORM or a toolkit that escapes your view layer against XSS, or forgot to add request forgery protection.
I'd encourage you to read those vulnerabilities, not just Google to disprove me. I'm speaking specifically on the ability for someone to remotely execute code on a ASP.NET WebForms application, and that was just a random example. What you linked to was comparable to saying Groovy is insecure because of the most recent vulnerability found in Java browser plugins. (http://www.itpro.co.uk/645031/new-java-7-bug-prompts-calls-f...)
I never claimed we shouldn't leverage well-written projects. I do challenge the idea that there's many eyeballs: most download and have faith. There's a bunch of eyeballs, yes, but not nearly as many as we tell ourselves.
You're totally right about frameworks resulting in better, more secure apps. However, much of that is relative: when most apps are hand-crafting SQL, JavaScript, and form handling, a framework is heads above other apps, especially when most attackers go for low-hanging fruit. However, when we get to a point where most apps are in frameworks, where would attackers turn their attention? Is an app inherently secure, or secure because it's less of a target? (Think the Mac vs. PC security arguments)
> What you linked to was comparable to saying Groovy is insecure because of the most recent vulnerability found in Java browser plugins.
Not really, because in .NET separating the "language" from the "framework" is a little thornier.
And the difference is all the more moot from a practical point of view: you still have to rush out and patch everything.
> However, when we get to a point where most apps are in frameworks, where would attackers turn their attention? Is an app inherently secure, or secure because it's less of a target?
You're not wrong in that widespread deployments of the same code base are what make these kinds of attacks possible in the first place; that's one downside of this kind of monoculture.
I can tell you however that these frameworks make it easier to write secure code in the first place. My business partner in my consultancy is a security researcher, and his job is to break apps. Frameworks like Rails make his life "harder" (in so far that one looks good by finding vulnerabilities); there is a ton of automated tooling that can probe and exploit a myriad of common-developer-mistakes-or-misconceptions.
Code you wrote within your team is audited by 10 people, tops. Code like Rails has been seen thousands of eyeballs. Even with several orders of magnitude of more attention, stuff like this still slips by. What are the odds you are better off?
That's probably 10s of thousands of eyes who don't know their arse from their elbow, including the guys who wrote it.
Possibly 2-3 people have read it who know their shit. The rest are just consumers.
Frameworks only centralise the security concerns - they don't necessarily make it better. That is in the hands of the implementor and their ability to build bullet proof abstractions. One fuck up and your system is globally compromised. It is the right solution, but you need the right people. Rails hasn't had the right people.
I agree with your second point, which is why I am a senior member of an architecture team in a company with 80 developers. It's our job to make sure ass and elbow confusion doesn't compromise the product.
If you want to get free security research from the best in the business, running a bitcoin exchange seems like a lovely way to do it. Just keep good logs to a write-only device.
Well, with a Bitcoin bank, at least as a customer you have a chance of not being robbed. By contrast, if you keep your money with an FDIC bank in USD, you are having your funds diluted away every day (the latest proposal is to print a $1 trillion coin).
Bitcoins are constantly being mined by other people that have spent money for physical hardware; every coin they generate devalues whatever currency you're holding. I fail to see how you consider central-bank driven inflation theft but not the whole concept of mining Bitcoins.
Trillion dollar coin or no coin, the debt ceiling attempts to regulate (in part) expenditures already authorized by Congress and signed into law. It's a tempest in a teapot for one party in Congress to argue that it's irresponsible to conduct authorized expenditures, because in fact, Congress did authorize the expenditures.
The two transactions, debt providing cash to the government, and seigniorage (difference in value from the metal in the coin and the fiat value asserted) providing cash to the government for the coin issuance are approximately equally inflationary, over time, assuming that the debt remains outstanding. If such a coin were undertaken, in all probability, it would be repurchased by the Treasury and retired, and debt would be issued. Indeed, the a return of the coin to the Treasury could be via issuance of debt directly to the Federal Reserve.
A little perspective on Federal Reserve Bank's process to create cash:
Federal Reserve Balance Sheet - by James Hamilton on Econobrowser
are approximately equally inflationary, over time.
Exactly. Both terminate in the end of the US as the world's reserve currency, with the yuan as its obvious replacement. China has already signed deals with Russia, Australia, Brazil, Turkey, and the UAE to eliminate the USD from bilateral trade. [1]
Your arguments appear to be directed at people who support the Republican party or are concerned about the partisan points here. Bush, Obama, Bernanke, Greenspan, Krugman, and the whole gang are peas in a pod. Bush won reelection in 2004 by having Greenspan inflate a housing bubble with Krugman cheering[2] the Fed Chairman on. Obama won reelection in 2012 by having Bernanke re-inflate[3] a housing bubble with Krugman cheering the Fed Chairman on.
To fight this recession the Fed needs more than a
snapback; it needs soaring household spending to offset
moribund business investment. And to do that, as Paul
McCulley of Pimco put it, Alan Greenspan needs to create a
housing bubble to replace the Nasdaq bubble.
Paul Krugman: August 2, 2002
The Federal Reserve said it will expand its holdings of
long-term securities with open-ended purchases of $40
billion of mortgage debt a month in a third round of
quantitative easing as it seeks to boost growth and reduce
unemployment.
Perhaps I'm being nieve but it seems like very bad coding when front end exploits can lead to cash being stolen. I would expect the bare minimum of a message bus or some other separation between back end payment components and the public facing boxes.
Disclaimer: I know virtually nothing about bitcoin past what I've read on HN.
Bitcoin are uniquely identifiable by nature. Has there been any attempt to create and maintain a manifest of "tainted" (i.e., stolen) bc that could be referenced during transactions?
If a receiver of bc knows that they are tainted, and that the next receiver might refuse them, then they might refuse them as well.
I understand that I'm hand-waving over the "Alice reports the bc she just paid Bob as stolen" problem, and I don't have an answer to that---maybe users subscribe to this service that investigates bc robbery---just thinking out loud.
That is possible, but the problem is the time it takes to disseminate the knowledge of the crime is longer than the time to trade the bitcoins. So if the thief immediately exchanged them with some merchant right after the robbery, then sometime later, the coins were marked as tainted, the merchant would suffer as well, since they're now holding the coins.
This would create a chilling effect on trade since now you have to worry about the legitimacy of the other party, which brings us right back to the problems we have with credit cards, etc.
So where's DHH's long blog post? Last I checked, he was still in charge. He's quick to talk about hypermedia, or his latest Le Mans effort, or how profitable Rails apps are.
I wondered this myself, but I think the reason is that there is a lot of eyes on 37signals and DHH. I think they downplay it a bit till the storm rides over and people get patched up.
And this is why I would NEVER in 10,000 years trust an anonymous form of money that can't be recovered or tracked to a group of average developers who in this case are obviously are amateur and don't even respond to massive critical security updates. I'm sure all the rest are like that to some degree as well. No thanks, I'll stick with cash under my matress before ever using that.
I feel bad for anyone that actually got screwed because of this.
You are wrong, bitcoins can be "tracked". The whole point of the Bitcoin block chain is to track all transactions. The community has developed a few tool to track "tainted" money.
Also, you already trust an anonymous form of money: cash. Why so? Mostly because insurance exists against cash theft. As the Bitcoin ecosystem develops, eventually an insurance market will develop too. It sounds like Bitcoin is too unmature for you. So, wait. In this theft case, the exchange itself is providing this insurance to you: they guaranteed they will cover the stolen funds themselves.
Also, the beauty of Bitcoin is that you don't have to trust an exchange like the one that was the victim of the theft. You can decide to take care of your own security by storing bitcoins on your own computer. There are a few efforts in progress to develop credit-card sized hardware wallet in order to provide extremely safe bitcoin wallets to non-technical users who are unable to, or don't know how to keep a computer secure for hosting a Bitcoin wallet. Again, it sounds like you need to wait for these efforts to mature before judging Bitcoin.
Alright, fair enough. I suppose my point moreso was that the fate of your very hard earned cash was bested by a rails update that any noob developer should have seen.
Given that simple scenario, think about who is watching your money..
You're confusing several things there. Bitcoin the protocol and rails the framework are not the same thing. Bitcoin was never compromised, rails was, and if these devs would have done their work and patched their servers they'd have been fine.
That's exactly what I'm talking about. I know the difference.
You are trusting your money with someone who can't even make simple critical updates to an app.
Furthermore: unless some established institution wants to work with bitcoin.. like a bank, then youre leaving your money up to the hands of some individual developers who, as made apparent by this post, dont really have their shit together.
I could be wrong, there could be some massively secured bitcoin bank somewhere with a large team of security experts, insurance, etc... but based on the fact that most bitcoin banks i see use an unstyled bootstrap theme I can't imagine they really know what theyre doing.
cliffnotes: I have yet to see a bitcoin bank website that doesnt look amateur as hell. I bet money that whatever bitcoin bank was hacked had all kinds of pages on it about "how we have a full team of security advisors making sure your money is safe!" yeah right.
bitcoin itself is cool, the mediums used to store your money are what I'm not trusting.
It's likely due to confirmation bias, but it seems that almost every bitcoin company has some (usually careless or inexcusable) gap in their security...
I built a simple program to transfer money between two of my wallets, and .01 bitcoin (a substantial fraction of my bitcoin wealth) disappeared as a transaction cost.
I asked around and was told "oh, yeah, they changed the defaults recently so there is always a transaction cost, you should pay closer attention to mailing list X, it's more up-to-date than the API documentation."
I decided I didn't like dealing with something where I had to assume the fine print was out to screw me and walked away. I have other things to do with my life.
(I probably am misremembering a few details of something that took place a few years ago.)
I suspect that a lot of anti ruby / rails people are happy to have the occasion to prove that the language and framework that they didn't want to learn is ...bad... and are posting these news all around the web... with that small grin in their mind... fair enough... but rest assured, Ruby & Rails haven't even came close to the end of their ass-kicking :)
You say that like it's an epic conquest to learn Rails. You assume that people who criticize Rails haven't learned it. Probably a large number of haters, yes, but there's also plenty who have taken the weekend or so it takes to get a good working knowledge of Rails. That's what makes Rails great: you can be productive fast. I'd venture to say there's more Java/C# devs who know Rails than vice-versa.
"Ass-kicking"? Is this high school football or professional programming? If a language or framework has major security holes, it should fail in the marketplace, no matter how much "ass kicking" it has done.
Rereading your post, I'm going to assume it's a troll post. After all, when I see your username, I can't help but imagine, "Do a couple of quick sets down at Gold's, then come back and slam out some Rails, yeah brah!"
> You say that like it's an epic conquest to learn Rails.
> [...] there's also plenty who have taken the weekend or so it takes to get a good working knowledge of Rails.
It is a fair enough conquest to learn Rails the proper way, knowing exactly what is happening under the hood.
Rails productivity doesn't come from how easy it is to generate some pre-built basic controllers or models without knowing what is involved, Rails productivity comes from how well it is engineered and connected in the whole picture. In fact, all Rails pro's will tell you that they have stopped using those "automagical features that make productivy fast" as soon as they were able to understand what they were doing, for the sake of more granular customization.
So, in 2 words, you won't have a good working knowledge of Rails in a week-end, expecially if you don't know ruby. You'll just learn to use some "generators".
> If a language or framework has major security holes, it should
> fail in the marketplace
It should in a perfect world designed by an IT professional which fortunately it isn't.
It will not in reality, and fortunately we have plenty of cases for this.
> I'm going to assume it's a troll post. After all, when I see your username I can't help but imagine [...]
> Probably a large number of haters, yes, but there's also plenty who have taken the weekend or so it takes to get a good working knowledge of Rails.
IMHO, this is a misconception, though I must admit it's one that gets pushed by a lot of parties. There's a lot of moving parts in rails and a lot of magic shortcuts, but IMHO you should actually know what goes on behind the scenes before using rails for a serious project.
> If a language or framework has major security holes, it should fail in the marketplace
So no more Spring, no more ASP.NET? Come on, we should be beyond that. Holes appear everywhere. What matters is how they are handled.
I'm building a new site from scratch soon, and was considering what language, and decided against RoR because of this. Perhaps not rationally, but it's been 5 years since I last did RoR, and I know there's a lot I don't know that's changed in that time. So better to stick with devils I know.
It's a decision about how uninformed I am. While I could certainly learn to become an expert in RoR security, I shouldn't do it on this specific project.
Bitcoin, the unregulated currency of OC & black hats gets hacked. This really isn't a big surprise. There's little or no come back for an individual, group or even nation state on this. This is evolution at work, where instead of survival, its a more tangible quality being selected for. The most ruthless, unremorseful and skilled the hacker, the more bitcoin they make allowing them to buy/build more RATs
Are these different exchanges at least talking to each other and trying to learn from experience?
Is there a Best Current Practice for all steps in BitCoin - for people wanting to buy or sell bitcoins; for people wanting to trade goods for bitcoin; for people wanting to run bitcoin financial services or exchanges?
the comments for this item have gone way off topic and just to be clear if you look at bitcoincharts recording of trading history for this exchange you will see that no more than $3000 changed hands via the exchange. That means that the total amount lost is well under that.
> The system was not breached, no passwords were compromised (they are salted and multiple times hashed anyways)
When they say "multiple times" I hope that means they're using PBKDF2 or bcrypt, because if they were simply using SHA1 then their users are even more doomed.
Given that this is a Remote Code Execution vulnerability I'd be very careful about the "not breached" as well. For all we know, the attacker could still have a shell or a rootkit on the server.
They probably had a decent chunk in cold storage, which is why they can afford to 'cover the losses': "Before the wild speculations beginn, the service will be recovered and we pay the losses out of our own pockets." [0]
Basically all the comments points to how amateurish that exchange was run compared to a real online banking website.
Now how many real banks do run their website using Rails? Ruby?
You guys certainly aren't as stupid as to believe this is the latest major 0-day Rails exploit to create havoc right?
And now comes the answers containing the logical fallacy: "All languages/frameworks have security issues". Which is rubbish in that it would imply that all the languages/frameworks do offer exactly the same level of security...
While you're obviously correct to imply that languages/frameworks have different levels of security the problem with that proposition is how does a prospective user of the framework assess the level of security it provides?
You could argue that "big, enterprise" systems are likely to be more secure, but experience with things like Oracle databases around 8/9/10 would indicate that's not always a good measure.
You could argue (and people do) that the framework being open source is a good thing, or a bad thing.
So absent that information how would someone factor that into their choice of system?
Most languages are inappropriate for highly sensitive information or other critical systems. You don't see the the aerospace industry putting Ruby hardware controllers into planes, nor do you see the defense industry putting classified information behind Ruby web servers.
The Bitcoin economy is learning, repeatedly, the hard way, that financial systems security is one of the most difficult, intransigent problems that any business will face. The goal posts are constantly moving, and there are always people trying to break in.
