> But it takes a special kind of arrogance for this young man to believe that his moral judgment on the dilemma suddenly trumps that of two (incredibly different) presidents, both houses of the U.S. Congress, both political parties, the U.S. court system and more than 30,000 of his co-workers.
Conversely, it takes a special kind of arrogance for two (incredibly different) presidents, both houses of the U.S. Congress, both political parties, the U.S. court system and more than 30,000 of his co-workers to ignore the fact that 54% of people surveyed think this is a good thing.
I meant new projects. I just wouldn't describe him as "too productive" now, not compared to the early days. Unlike that other lovable teddy bear, Linus. RMS has even written about his shift out of development IIRC, about how political work is more important to him now.
> Are all of these bootstrapped, or are some of them self-funded?
HN doesn't seem to make the distinction, for self-funding of less than $100K.
The thing I find particularly fatuous: "We were bootstrapped until we took VC money", as if everyone who takes VC money isn't in the same camp. I guess the company I founded was bootstrapped until our A round valued at $40M. Hey I created a $40M company by bootstrapping!
The poster's confused, but I'm not sure it's necessarily true that the city of Detroit should have a value that's greater than zero. If the current cost of paying pensions and the cost of maintaining (underused) infrastructure is much larger than the expected tax base, than the value of the city (not including private property) could well be negative.
That said, it's unlikely that's true, because there's still a lot of option value available if someone's willing to make hard decisions and/or shed some costs through bankruptcy. (But it's going to be really unpopular, like not paying pensions or simply shutting down city services to certain neighborhoods.)
America doesn't really have a model for shrinking city infrastructure. Detroit is the first test of what happens when a major modern city stops growing and starts shrinking in a long-term way. It's hard to scale down government and infrastructure in a smooth way.
> Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed.
So they can't rule out the possibility that sensitive personal information, which cannot be accessed, has been accessed. Got it.
Apparently our intelligence, which cannot be insulted, has been insulted.
What I find slightly unnerving is that Apple didn't make this clearer.
If they know that credit card information was not affected, they should say that. E.g. "Sensitive personal information (such as credit card data) was encrypted and cannot be accessed, ..."
It's reasonable to suppose that 'sensitive' includes credit card information, but as it stands it's something we have to interpret.
I'd suggest we all check our credit/debit card statements more often over the coming days, just to be sure. =)
>What I find slightly unnerving is that Apple didn't make this clearer.
Apple is not a startup. They were ranked 6th in Fortune 500 for 2013. They are going to be rehearsed, political, and vague with their descriptions. Were you actually expecting them to release a postmortem on their blog with a link to the GitHub repo with the fix?
Sure, but I don't think it's a bad idea to raise the median level of expected standards. It seems reasonable to ask for clearer reports and some kind of a postmortem.
One of the hopes for the notion of startups searching / optimizing in these kinds of niche spaces (transparency, communication on a more personal / no-bullshit level, whatnot) might be that these kinds of optimizations will hopefully change what is to be expected from IT businesses in general (at least in terms of communication and so on.) One can at least hope..
If they say X wasn't leaked while it was, they will open themselves for litigation. A company of Apple's size cannot afford to make mistakes there. So, they have to put in weasel words such as "such as".
Also, this isn't a postmortem (yes, we may never see one, it is premature to comment on that _now_)
I do see your point. It just seemed odd to me that they didn't take that simple step to clarify what is arguably the most pressing question on everybody's mind: is my CC/bank data safe?
This is most likely just me being too paranoid and literal, of course. =) In general I'm not too disappointed with how they've handled this - it could've been far worse.
Passwords could be hashed, but credit-cards are the big one you have to keep in plaintext. If you want to bill the card without asking for the number to be reentered, there's no way to avoid storing the number and expiration date. PCI does mandate that you keep less than necessary to initiate a new charge, though: you are not allowed to store the 3-digit verification code from the back of the card. Future charges from the same vendor can go through based on the stored information (without re-sending the verification code), but charges from a new vendor would need the code, so this is intended to make it harder for someone who stole the saved information to initiate a new charge. A loophole is that in-person charges do not use the verification code, so someone could use the saved information to fabricate physical cards, and try to use them at stores (the U.S. doesn't typically use either chipped or PIN-protected credit cards, so cloning a card from the number is relatively easy, prevented more or less only by the heuristic fraud-detection algorithms).
Credit cards don't need to be kept in plaintext. I'm a big supporter of having the frontend encrypt the data using a public key. The private key is stored only on backend servers.
So now if something needs to kick off a billing process the frontend sends a signal using a defined service method (preferably something so simple that it is secure) and then the backend goes off and decrypts the data followed by doing the actual processing required.
If the frontend and backend are on two seperate networks, and the frontend is only allowed to talk over TCP/IP port 5930 for example to the backend, now you have reduced your attack surface tremendously while making customer data more secure.
The last system I worked on that actually stored it’s own CCs (Lately it’s been all tokens, all the time, for me) did roughly this with the added, fun, feature no SSH or remote shells on the backend box.
You sent messages to add or charge our client’s credit cards from the front end - on the ultra-simple protocol, to the 1 (!) open network service on the backend. And that’s all the input it took from the network.
If something more complex was needed someone with much higher permissions than I went to the server room and typed into the terminal. Which really minimized attack surface.
Couldn't you also do something like this? Store each user's key, transformed in such a way that you could get it back only if you have the password. Serve the key to the user's session on login (maybe -- depending on how long you store the session, you may want to require password reentry to initiate any charges). Encrypt all sensitive data with the user's key, such that only that logged in user can read it back.
The major drawback would be the same as the benefit. Since you can't know your users' CC numbers, you also can't make recurring charges.
Pipe-dream solution to that -- you should be able to get a token from your payment provider that authorizes you and only you to charge the CC. Should that token leak, you barely even need to revoke it. It can't be used by anyone else, because you need both the token and your company's api secret to charge anything, and even then, all they can do is send (easily refundable) money to your account.
Even better - how about simply doing a form of OAuth with the service provider? A token would be authorized for recurring billing or anything else. I think Verified By Visa is an example of something like that...
If such a provider could also SMS you on your chosen # to confirm the purchase then the system would be secure!
> ...but credit-cards are the big one you have to keep in plaintext. If you want to bill the card without asking for the number to be reentered, there's no way to avoid storing the number and expiration date.
Not necessarily, if you're using a payment gateway that supports token billing...
Yes, but then you're going to start running into the "don't keep all your eggs in one basket" situation. Sure there are companies out there that will store that information for you, so you don't have to worry about living up to the standards of storing it, but what if that company is compromised? You can't just say "oh they should just let someone else deal with storing that information..." SOMEONE is going to have store the actual information in the end.
> A loophole is that in-person charges do not use the verification code, so someone could use the saved information to fabricate physical cards, and try to use them at stores (the U.S. doesn't typically use either chipped or PIN-protected credit cards, so cloning a card from the number is relatively easy, prevented more or less only by the heuristic fraud-detection algorithms).
This is untrue. The magnetic stripe contains significantly more data than what is printed on the card and much of that Discretionary Data (DD) is used during authorization of 'card-present' transactions.
Specifically, the magnetic stripe contains the CVV1, which is used for card-present transactions. The number on the back is the CVV2, used for card-not-present transactions.
> Future charges from the same vendor can go through based on the stored information (without re-sending the verification code), but charges from a new vendor would need the code, so this is intended to make it harder for someone who stole the saved information to initiate a new charge.
That's not true >"charges from a new vendor would need the code". Online credit card transactions only require a credit card number, expiry month & expiry year. The verification code is optional and is used as a fraud check / deterrent. Payments with an invalid verification code are highly suspicious. Therefore, when Apple (or any merchant) asks for the verification code initially, it passes the initial fraud tests and the card is stored as a "verified card" (or perhaps, only verified cards are stored). Further charges are then most probably legitimate (since it passed the previous fraud check).
Most banks provide the ability to get a billing token to avoid having to store card details at all. In order to do recurring billing you only need to store the token and the CVV on the back.
I would imagine Apple would not trust the ability to bill its customers to a third party. They have touted their collection of CC numbers for quite a few years, it's treated as an asset to the company.
You're not in the phone book, then? County property tax database? I mean, your home address is not exactly something you can really hope to keep secret.
Credit cards can be cancelled. Home addresses plus other information could be valuable to identity thieves. Maybe it's not that big a deal, but the idea of hackers (criminals?) knowing my name, email and home address seems a bit creepy.
Well they are in this weird space of being able to be used to pull money from the account though ACH/demand drafts, so they _should_ be secret, but then as you said they are on the bottom of every check. Which is super weird, and not the case in other countries' banking systems.
"First of all, this does not affect iTunes customer accounts—this is a different system and all iTunes customer information is completely safe, Apple told me.
It’s also important to note that the hacker did not get access to any app code or even the servers where the app information was stored. The hacker also did not get access to any credit card information.
The only thing that the hacker could have gotten access to was the names, email addresses and mailing addresses of the developers. At this point, Apple doesn’t know if the hacker even managed to see that information. Worst case, that is all the information they would have seen, according to Apple."
If by "reality distortion field," you mean the legal community, then yes. Having been through something similar recently, the lawyers will likely be making sure everyone involved understands the concept of PII: https://en.wikipedia.org/wiki/Personally_identifiable_inform...
How are names, mailing addresses, and email addresses sensitive personal information?
I would imagine that for most of the people signed up, it wouldn't be that hard to track down their name and email just from knowing the name of their app.
One of the understood requirements of publishing an app on the App Store is that developers must provide some means for customers to contact them directly (support page, email address, etc). If you're selling apps on the app store, people can already peddle their wares to your email account.
So yeah, developer's names, addresses and emails are not secrets by any means. Why would anyone buy an app from someone they had no means of identifying?
"The intruder had good intent with trying to "secure" our personal information. But despite nothing being hacked, as it was only a 'threat', we still need to tear down and build up the system from scratch again. In the spirit of transparency we've waited 72 hours before giving you this nonsense bullshit. Please note that some (that is all) of you will from now on get regular viagra offerings in cyrillic. Good for you!"
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
Congress in this instance has not made any law prohibiting a reporter from publishing a story, and reporters being required to testify is just one of a myriad of circumstances in which parties to controversies can be required to testify in one way or another.
If the freedom of the press is infringed, and the infringement was legal, that must mean Congress made a law infringing on the freedom of the press, right?
This is like arguing that reporters should be able to break into computers to get information for stories; after all, anything you did to criminalize that would be an infringement on the press.
I was disputing your claim that this wasn't a first amendment violation because Congress didn't make a relevant law. Now you're arguing that this wasn't a first amendment violation because there was no infringement on the freedom of the press, which is a much more tenable argument.
How was the freedom of the press infringed? I mean, the government requires that journalists and newspapers pay taxes, so is that another infringement?
Constitutional freedom of the press is the right to publish information, not a special privilege of members of the professional media to avoid generally-applicable legal duties.
I'm no Ch9 expert, but my understanding is that a receiver will be appointed. That person is not elected. So while the politicians retain executive power, the purse strings are taken away from them.
There will be much unhappiness and gnashing of teeth before it's all finished.
What I don't see in the comments yet: This is interesting not only for Detroit, but for the precedent it sets. There are 10 or 15 municipalities that will study how to screw the retirees & bondholders as thoroughly as Detroit plans to and then go down that path.
I have a hard time feeling sorry for bondholders in these situations. There is always some risk in lending money. Perhaps they should try and find more creditworthy institutions next time.
A lot of money in the US is being lent with the assumption that creditors will always be bailed out by the state or federal government; that mindset exasperates excessive borrowing and spending at the local level and encourages creditors to make risky loans. This is the textbook definition of a moral hazard.
Even as a credit analyst, I agree that you can't really feel sorry for the bondholders here. If you want to lend in any market, you need to assume the risk that the debtor goes bankrupt. Pensioners are a different story though.
However it's absolutely not true that "a lot of money in the US is being lent with the assumption that creditors will always be bailed out by the state or federal government", at least not a large amount relative to the total bond market size. Rates are low now, yes, but that's because the Treasury rates are so low, not because of some implicit government backing of credit that is making assets less risky. In fact, spreads (bond yield - treasury yield) are near historical norms.
> Even as a credit analyst, I agree that you can't really feel sorry for the bondholders here. If you want to lend in any market, you need to assume the risk that the debtor goes bankrupt. Pensioners are a different story though.
Very much agree.
> However it's absolutely not true that "a lot of money in the US is being lent with the assumption that creditors will always be bailed out by the state or federal government", at least not a large amount relative to the total bond market size.
This is more subtle. While bankruptcies even on the scale of Detroit don't work with an implicit backstop assumption, large-scale muni bankruptcies on the scale predicted by Meredith Whitney are a different story. Let's face it: When push came to shove, Fannie and Freddie were not allowed to enter runoff mode.
There doesn't seem to be an opinion that this will kick over the can and start the bankruptcy run, but throw in a couple of more and the political&banking dynamics would turn interesting in a hurry.
I'm very liberal, but I don't see this as screwing the retirees. I think they got a better than they should have deal. The unions over-reached and they got rates of return that were unsustainable. We haven't even talked about the gaming of the system that happens (punching up salary for the last year, so their retirement benefit goes up).
The police chief in a town near mine retired on something like $300-400K and it was discovered that he had taken a job at another city, several hundred miles away.
There is so much corruption and abuse of the municipal retirement plans that I think a reboot is in order.
In California the police can pre-retire and collect their retirement while they are still working at their same job. So you have the San Luis Obispo sheriff making upwards of $600,000.
If you're ever living in San Francisco making $130K as a programmer yet still wondering if you've made the right career choice, browse the public salary databases in the area to confirm the fact that you indeed did not.
If you make $130k in California as a programmer, plus maybe $10k in employer health insurance contribution and another $10k in 401k matching ($150k total comp), you're in the same overall pay bracket as a "sewers supervisor" in San Rafael or a BART train operator: http://www.mercurynews.com/salaries/bay-area?appSession=8741....
I particularly like the idea of promising firefighters a too-good pension, make them run into burning buildings to save people, and then reneging on the promise now that they won't be running into buildings any more. Serves them right for trusting a promise, the fools.
I wonder what effect that will have on future muni workers?
In general, firefighters are very well paid, so there is that consolation price. Yes, it does suck, but the result is the rest of us pick up the tab. I was just in the news today that unfunded state pensions are at the $1T mark.
Also, there's the issue of how we got here. When the police and firefighters say "we need this, or else" it's a little hard to turn them down. I don't think they are completely without blame.
Could you post the numbers that lead you to believe that most or all of the specific people here have unjust or unreasonable pensions? Because I'm pretty sure those numbers don't exist.
Note that much of Detroit's debt is insured by monoline insurers who viewed the probability of a majour U.S. city entering Chapter 9 in the way S&P and Moody's viewed a nationally correlated housing meltdown pre-2008. I have not yet seen how this bankruptcy will (a) affect the monolines' solvency, or, (b) change their behaviour around municipal credit wraps.
Interesting. Though the article, from 12 July 2013, quotes a 20% recovery rate on Detroit's GO bonds (it's somewhat humorous to see Detroit's "full faith and credit"-backed bonds referred to as unsecured by Bloomberg). I'm seeing the market buzzing around 75 to 80.
Assuming a 75% recovery rate and 95% coverage, that means the monolines would be liable for about $475 million. I'm not sure (a) what fraction of the capital of U.S. monoline which insure municipal debt that is, or, (b) how that is distributed across variably capitalised muncipal monoline insurers.
