Web Developer Security Checklist - <AUTHOR> https://simplesecurity.sensedeep.com/web-developer-security-checklist-f2e4f43c9c56 <comment><USER2> While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section:

> Encrypt all data at rest in the database

ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something?

I'm not even sure what this is supposed to mean and it is certainly not common practise.

> Use secondary encryption for data identifying users and any sensitive data > like access tokens, email addresses or billing details

So _two_ layers of encryption!? Again, how is one supposed to look up an access token or email address if it is encrypted? And it strikes me that if you don't trust the first level of encryption, the solution is to fix that, not add _another_ one.

> Fully prevent SQL injection by only using SQL prepared statements and stored > procedures

That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries.

I could go on. The costs of implementing these recommendations would be staggering for the questionable benefits they would provide. It is absolutely possible to have excellent security without implementing any of these ideas, and I don't think they're helpful at all - and certainly not "simple".

<comment><USER3> Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it.

Also this business of two layers of encryption: yep, anything encrypted can't be indexed or searched (basically). At best you can encrypt the query input too and compare for strict equality---sort of like hashing passwords. (Is that what he means?) I've never seen anyone hash email addresses though. And encrypting billing details . . . okay, I guess, although if the app has the decryption key, then what security are you really adding?

<comment><AUTHOR> If the hacker gets access to the database due to a network config error, then they will be able to query the database, but only get records with some sensitive fields encrypted.

Given the number of email addresses that have been hacked and stolen (3.75 billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra bit of encryption on email addresses is worthwhile. We push that into our ORM layer and can easily flag any field in the database to be encrypted.

On very, very high volume accessed tables, you may not want to do that. But for user logon details -- for us it was a no brainer.

<comment><USER4> Wait, so you encrypt the user's email before it's inserted into the table?

Are you using a different field for 'username' on logins, or do you have to jump through some hoops to find an encrypted email to do a login check against the pw hash?

<comment><USER5> Can't you encrypt the entered email and search with that?

<comment><AUTHOR> Password hashes are handled separately using bcrypt - another story.

For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search with the encrypted value that is stored in the db. App code provides plain- text email, ORM encrypts and searches with that value. Symmetric encryption of short strings is pretty fast and this is not a high volume API.

We use rate limiting on the API to protect against DOS on this API.

<comment><USER6> If it's symmetric, then doesn't an app vulnerability make it possible for you to leak your key? Then the app also contains access credentials to the DB, so vulnerabilities in the app will still lead to real access to the DB, right?

<comment><AUTHOR> Yes, we're not protecting against the app being attacked, the key being jacked and then the attacker getting access to the db. Rather, we're protecting the database against being accessed directly. That could happen due to an error in configuring network access to the database or another service could be compromised that has access to the same database -- as has happened to many mongo databases over this year.

<comment><USER4> So your solution to fixing a basic ops problem 'software package A was exposed to the internet with(out|effectively no) auth' is: encrypt shit in an ORM layer and destroy your ability to do anything beyond absolute string comparison queries.

No thanks.

<comment><AUTHOR> No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive.

And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

<comment><USER7> It does seem like emails are a good fit for encryption. I can't see wanting to do anything more than simple equality checks.

<comment><USER8> I could see a use case to see which emails are from what TLD.

For instance, all @gmail, all @yahoo, all @aol.

Maybe you want to do the cool "hey we noticed your email on haveibeenpwnd, you should change you password here just in case". In which case, anything other than plain text could prevent that from happening.

Hashing an email in that sense gets much more difficult, no?

<comment><USER9> If you have enough emails that you can't SELECT * FROM users and do that query in memory, you're probably in a spot where you should not be picking security advice from a blog like this.

(That's not a negative as to this blog, it's really good and I've recommended it to multiple clients already, but that level of acumen should already be assumed at that scale. If you don't have it, this blog post is insufficient.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> OWASP has published a release candidate of the OWASP "top-ten" available as a PDF at [https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2...](https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf). They also support the creation and maintenance of quite a few OSS tools to help secure systems.

To those who are claiming some of these steps are too onerous or would cause performance issues: Are you sure? For an individual system, maybe some of these checkboxes are indeed overkill. Or perhaps your system isn't as secure as you believe? To be fair, there are systems that don't require as much security because the data simply doesn't matter - if they systems contain email address / password hash combinations, they should still treated very carefully.

I think the biggest mistake I've seen made time and time again is that teams go the cheap route and put the database on an Internet connected machine. Don't build a whole architecture until you've got customers to support it but don't be quite that cheap at the beginning.

For systems that require higher than average security, I've been part of a team that went to _MUCH_ further extremes.

<comment><USER11> Can you elaborate a bit more detail around a MVP-style architecture where the database isn't on the public internet?

I assume you're talking about something like a public facing load balancer that connects into a private network where the web servers and database server live, and you'd need a bastion host (or just the load balancer) to connect into the private network and access any of the machines.

<comment><USER10> Yes ... that's about the simplest form. If you want to get really fancy you can use a further cloistered machine with hardware encryption and a key that's only inserted when the machine is booted but that's pretty excessive. The main thing is that you don't want your database server's port exposed to the Internet and you don't want your database on your web servers (the most likely part of your infrastructure to be compromised).

</comment></comment></comment><comment><USER12> There are 168 comments on this thread all earnestly discussing what is pretty clearly a marketing document written by someone without a firm grip on most of the bullets they've written.

Is there that much of a need for another "security checklist", that we'll dive in this deep on a really bad one? Seriously asking!

Finally: if you're worried about "APTification" or whatever it is this company is talking about, and you're deploying in AWS or GCP, do what Ryan's team at Slack did and get auditd monitoring on all your servers, and perhaps get osquery instrumentation set up as well. Attack detection systems like the product this post sells are pretty far down the list of things you should be considering.

<comment><AUTHOR> As the author, I should clarify that I am a developer - full time and have been for years. If my english seems to imply a lack of depth of understanding - I'm sorry.

The purpose of the checklist is to get people thinking about items they may have forgotten to address during their dev. In the push to ship new products quickly, that happens all too often.

I agree with you that there are many more important and basic things to do first when securing your app - than worrying about APTs. I did not think the checklist gave that impression?

<comment><USER13> English is not the problem.

You are missing fundamentals like the Seven Deadly Sins of Web Security. Also missing is ninja threat model.

These are the thing that will wipe you out.

</comment></comment></comment><comment><USER14> This list could just as well be called "List of security stuff I learned about when making my product". Some of the stuff is just Draconian, certainly not applicable for any arbitrary web developer.

<comment><USER15> There are rarely any checklists applicable everywhere in the same way. Why not treat it as: list of ideas to evaluate and prioritise/ignore into your own checklist for future/current project? It's not like it's all invalid because it's not fully applicable.

<comment><USER14> No, I think it's valuable as a work log and bucket of ideas on how to improve security. It's just how it's framed that irks me.

</comment></comment></comment><comment><USER16> Hope the moderators edit the post title to include that this is a 'security' checklist, and not just a 'steps I need to develop a simple website' checklist. I am thinking quite a few people skipped past this article not realising the intended audience.

<comment><USER17> Agreed. The original title of "Web Developer Security Checklist" is much better.

</comment></comment><comment><USER18> My biggest worry with this checklist is that while it helps already security- minded people and web developer professionals remember what they should already be doing, it doesn't really help security novices (who may search for something like this) make their app more secure. Why?

1\. The checklist tells me what I need to do, but not how to do it right.

I could imagine many security novices reading one of these items, implementing the first solution they find on StackOverflow, and checking it off in a "fixed it, boss" kind of manner. That may lead them to thinking their app is more secure than they should, and is then a detriment to the security of their app.

2\. The checklist doesn't really help me decide in what order to do things, and what perceived increase in security I'll receive

Storing sensitive data in the database using bcrypt is pretty easy to implement (many times baked into web frameworks), and provides a good amount of security for the time it takes. Compare that to something like implementing CSP however, which may involve moving a ton of files around your app, adding nonces/hashes, etc, and it gets me an A+ on secureheaders.io, but I'm not sure if all the pain was worth it for my basic application.

3\. The checklist makes things way harder for a developer to think about.

Anyone wanting to build a web app looking at this list would probably be too overloaded with information to want to implement much of this, when in reality, they could start off with something like Heroku where they just push it up and it works, and many of the security concerns have been taken care of for them.

<comment><AUTHOR> Thanks for your well structured comments.

The purpose of the checklist was to get people to think. It is really hard to do much more without going very long.

A number of people have suggested that I link implementation background off each item. I think that can work and layer the info as well.

<comment><USER18> I know your pain -- things like this get long fast, and it's hard to include everything all at once without going on forever. I would definitely appreciate implementing some background off of each item!

Another thing that might help is knowing about services or open source solutions that can bundle a lot of the checklist together. Heroku might be a paid one, for example, but there might be things like ansible scripts out there that do a lot of this from security professionals, I'd love to know how to be able to package a lot of these checklist items together more easier.

<comment><AUTHOR> Coding is easy, writing is just darn hard!!

Thanks for the ideas. I'll check those out.

</comment></comment></comment></comment><comment><USER19> "Hack yourself"

May I suggest the opposite, and say if you're going to pen test your infrastructure, don't have the same people maintaining the infrastructure trying to hack the infrastructure.

<comment><AUTHOR> Do both. I'm a big believer in having dev learn and own a part of the security process. You learn an enormous amount by hacking yourself. But you are right, you definitely need other eyes to pen test as well.

<comment> FLUX-YOU >Do both. I'm a big believer in having dev learn and own a part of the security process.

Devs already do enough, take some bloody ownership of security outside and inside of code.

When devs start having to whiteboard security issues in interviews, then you can make us responsible for it because we'll appropriately charge you for being decent at two things instead of one.

<comment><USER9> This is...shortsighted. Security is _part of_ your development work. It always has been, always will be. You need to understand application and server-level security--the former is always your responsibility and while you may have specialists for the latter they do not replace you understanding the fundamentals of it. The server is part of your "stack", even if the "full- stack" people want you to believe it ends at the language runtime.

If you are a web developer and in your interviews you _aren 't_ demonstrating that you can think in a security-conscious way, your interviewers need to reflect.

<comment> FLUX-YOU >Security is part of your development work

So is everything else, apparently: databases, algorithms, data structures, operating systems, cloud infrastructure, front end design, business logic features, etc., etc., etc. -- the list just keeps fucking growing and you people are turning devs into skill black holes where they're never going to master anything. All of it apparently matters at one point or another and you're not a good developer if you're not prepared to be the best at everything!

As a web developer, your security knowledge is rarely assessed and tested. If you're not focusing on security 100% of the time, you're not going to be as good as a professional and the bad guys.

You need people focused on security doing the security work. Having someone do business features and security work at the same time is an indication you don't take security seriously because you do not have dedicated people for it. If Bob who's mostly front-end but some back-end says it's secure, I'm not going to believe him. That's the same false confidence that companies parrot to us when they say that "security is a priority", but they have XP machines on their network still and code vulnerable to SQL injection in their code. Don't tell me this doesn't exist because I woke up this morning and _read that exact email_. You can't half-ass security and a line of business developer is not a security professional.

This doesn't mean you get to be lazy and continue to concat SQL strings even after someone has told you it's bad in a code review.

<comment><USER9> _> So is everything else, apparently_

Yes. Sorry (not snarky) that it sounds like you work in a lousy place, but if your "security people" aren't cutting it, you are the line of defense for your users. You need to understand this stuff to be able to do the right thing. Being at least competent--and we're not talking A-plus or best-in-the- business, we're talking a solid C-plus to B, able to consistently make things better rather than leave them static or regress--in these things is your responsibility when you take a job working on stuff that touches these fields, because _somebody has to and you 're a somebody_. "Security people" (and I'm not one, I'm a software developer--though, somehow, [this part is snarky] none of databases, algorithms, operating systems, cloud infrastructure, front end design, business logic features, _or_ application security are beyond me; weird, that) are there to help you, not excuse you from your responsibilities.

There's a lot of stuff to understand! This is why you are paid the medium bucks. Remove "not your job" from your vocabulary and you'll be better at not just these things, but the things you think are your job, too. Because each bit informs the rest.

<comment> FLUX-YOU >Remove "not your job" from your vocabulary and you'll be better at not just these things

No one else is removing that from their vocabulary. I don't see the incentive for me to do that.

This is the problem. You haven't realized that everyone is saying "not my job" and pushing it all onto developers.

<comment><USER9> _> I don't see the incentive for me to do that._

Oh, I don't know, to not be bad at what you do for a living so you can call yourself a _professional_ without it being a farce?

I don't care what other people are doing and you shouldn't either. I care about doing the right thing and building good systems that work for people rather than expose them to risk and you should too--and that means understanding the breadth of your _profession_. The people who are pushing responsibilities onto you are the people that software is automating out of existence and are of no account except that you get to feel good by "pushing back" in ways that just make everything worse.

<comment> FLUX-YOU >I don't care what other people are doing and you shouldn't either.

Until their decisions affect your work, and you don't get to say anything about it. Because the people pushing around responsibilities are usually your bosses or equals, so you can't really do anything about that. If you get to work in a silo where you're responsible for everything and you understand everyone and do it well, great, you're a master of the universe. You should be a multi-millionaire by retirement at 45.

But most developers won't ever approach that level. Putting your best people in the best slots is a practical approach for teams > 1\. And there's no reason you should be mixing responsibilities and watering down everyone's chance at becoming good at ~literally everything in development~

<comment><USER9> Let me restate, so you can catch it: I'm not saying _be good at everything_. I am saying _be bad at nothing relevant to your work_.

Security is without exception and in all circumstances critically relevant to web development. You cannot be an adequate web developer if you cannot look at a system and break down its security impact and how to mitigate it. You can be a bad one, but you can't be even an adequate one.

Less excuses, more practice. It's what you signed up for.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> It is shocking to me to see how many developers giving this checklist a hard time. Every single item is solid advice and what I would have presumed sane people considered common sense/best practice.

Just goes to show how bad a job we have done in the InfoSec world of educating developers.

<comment><USER21> I got downvoted in another reply, but "security by checklist" was one of the biggest complaints that SANS and other security firms had about enterprise and government IT security policies.

Not that it's a bad checklist, but most "web developers" will not have the background to understand and implement all of these things properly, even if they think they do. Security is not a checklist -- "OK, all boxes ticked, we're done" \-- it is also an ongoing, reactive and proactive set of processes and constantly re-verifying that everything you think is so, is actually so. And if you rely on "web developers" to get all of this right you will at some point be disappointed.

<comment><AUTHOR> I think we can all agree that developers can get better educated about security and can participate building security into the product from the very start. It is hard to engineer security in via a sec-team at a later stage. Education is the key.

<comment><USER22> How is something like "Use CSP without allowing unsafe-* backdoors" in any way educational? If I'm a newbie web developer, even coming over from embedded systems, how do I know what CSP is? What do I use CSP for? How do I start with CSP? What do I do to configure CSP? What does CSP even stand for? I don't know, it wasn't even defined!

Basically, this is a useless listicle. If you know anything about web security you get nothing from it and if you don't know anything about web security you still get nothing from it.

<comment><AUTHOR> Try this to get you started:

[https://www.troyhunt.com/understanding-csp-the-video- tutoria...](https://www.troyhunt.com/understanding-csp-the-video-tutorial- edition/)

<comment><USER22> I don't need to get started and I don't need that link; I, personally, know how to develop secure webapps. I am criticizing your listicle for being useless because it is. Your "educational" resource is not educational for anyone.

</comment></comment></comment></comment></comment></comment><comment><USER23> A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure.

For example, this code was from a guy in Stack Overflow:

        ... function (req, res, next) {
            if (err) return console.log(err)

What will that piece of code do? Leak the request object, the response object, including the underlying client connection... keep the connection open, leak memory... and at scale, make your server run out of sockets and memory. Then, when memory is low, swapping kicks in, overloading your CPU as well. In short, kills your machine with only a little 1 line of code mistake.

There are less trivial ways of running into the same situation, but the lesson is that node.js is not a babyproofed technology and needs to be used with care.

This piece of advice is one of the most important, and the most overlooked/ignored in the node community.

<comment><USER24> Well, I've avoided the node hype because of people warning about bad debugging experience. With that, I'm going to try to avoid touching it ever.

I've used many web stacks over the years and not a single one defaults to blowing up like that. They all follow proper modularization... The framework cleans up objects that the framework creates, you deal with yours.

In any other framework forgetting to end the request would result in the request automatically ending when your code finishes. This includes Vert.x and Undertow which are just as asynchronous as Node(but also multithreaded).

Also how the hell does that leak memory? Is JS reference counting that bad? I've done some really stupid things in Java and C# but never leaked memory enough that it mattered.

<comment><USER23> It's not a problem with the garbage collector, just how the objects are referenced. Basically you need to ensure the request reaches a terminal state where you either close the connection (ServerResponse.end) or send a response (ServerResponse.send and similar). All the cleanup happens after you do that.

<comment><USER24> Is there not an OnDispose or some kind of hook to detect when requests can end? To end a request in every framework I've used you just return from your code back to the framework. You shouldn't have to worry about a framework object like request state.

<comment><USER23> There are ways to detect this, but since express declares itself as an "minimalistic, non-opinionated framework" it's up to you to do it and do it correctly, or have correctly implemented logic that does not run into this issue.

</comment></comment></comment></comment></comment><comment><USER25> Prepared statements are amazing. Found out about them very soon after I started programming (incidentally my first language was PHP), and switched to PDO right away. This was years ago, I don't understand how people are still using the deprecated and insecure mysql_* functions, you can still find them all over SO and my university "web" class was teaching them as well...

<comment><USER26> You'll be glad to hear that they've finally been removed since PHP 7.0 so slowly but surely they're being consigned to history.

And there seems to be much better awareness about the perils of mysql_* functions amongst PHP devs these days.

However, 5.6 is still in security support until 31st December 2018, so all that bad advice on SO and elsewhere is still relevant and lurking, waiting to be found by inexperienced devs.

</comment></comment><comment><USER27> When do we get a SaaS which just comes with all this built-in? I want to pick a framework and let the service add all these things, including automatic updates.

<comment><USER9> What you want, and what is effective and feasible, are at odds. Trying to build a framework for this to work in the general case will--not may, will-- result in something that doesn't work in that general case for anybody.

You can't framework away _security_. Parts can be abstracted, but that abstraction is for ease-of-use, not correctness; you need to understand what's going on and why. It's your job to. (Or pay someone else to. But we're expensive.)

<comment><AUTHOR> I agree with you, but I understand his wish though.

Security sometimes is just hard and it is unrealistic to hope that all developers, everywhere, all the time will get it right.

The more the platform can do, the better.

<comment><USER9> I understand it too, but it's, to be honest, horseshit. Well-meaning horseshit, but horseshit despite it.

Security is hard. It is irreducibly hard when you add the constraint that arbitrary do-whatever code and applications must be supported. Having your platform do things is great-- _to make you faster_. You still have to understand what it's doing because it's very easy to step outside the guarantees of that platform and suddenly no longer benefit from those security features. Sometimes you might even have to do that for business reasons. And then you _must_ know how to safely compensate for it.

It's a rare web developer who isn't safeguarding somebody else's personal information. (Yes, even just name + email. Don't make it easier for other people to be phished.) The onus is on us as a development community to take that seriously and to treat the security of our code and our systems with the caution it mandates.

<comment><AUTHOR> No argument on that (except the horseshit ;-)

</comment></comment></comment></comment></comment><comment><USER28> Not simple by any means, this one is very thorough and one of the better security checklist I've come across in a while! Sensedeep looks very intriguing and I often wondered if anyone has created an alternative to Atomic Secured Linux. Could this be it? Or is it like an ids / ips with a gui?

<comment><AUTHOR> We're just in beta. SenseDeep is part host-IDS and part cloud-side. The key is real-time. We want to detect attacks in real-time on the server or on the cloud-side. It has a GUI on top to unify and give a cloud complete view. The focus is DevOps and not companies with a security team. Not sure if this helps or confuses things.

<comment><USER28> Does your product help satisfy any areas of the pci compliance?

<comment><AUTHOR> I don't want to take the focus off the post and discussion which was about the web checklist. You could dm me twitter @SenseDeepSec or email mob. But briefly, we hit some of the PCI compliance objectives but not all. We expect to cover more ground in this regard quickly.

</comment></comment></comment></comment><comment><USER29> Implementation discussions for each of the checks would be handy for those of us not familiar with all of these practices.

Also those most likely to need such a list.

<comment><AUTHOR> Great idea for a follow on post. I'll do that.

</comment></comment><comment><USER30> > Store and distribute secrets using a key store designed for the purpose. > Don't hard code in your applications.

Curious: Is there a widely-used off the shelf solution/pattern for this? Or a "idiot's guide to writing one"? It's always seemed to me like super bad practice to hard-code a (for example) AWS secret into your app. However if you set up a basic web service to deliver the AWS secret to the app, wouldn't your app need to authenticate with that service with... a hardcoded secret?

<comment><USER21> Sure, classic chicken and egg problem. At some point you need an unencrypted secret.

<comment><USER9> A better way to phrase it is that at some point you need _trust_. AWS IAM instance profiles are a great example of this.

</comment></comment></comment><comment><USER31> This is great!

Unfortunately this old list hasn't been updated in forever:

* Web Developer Checklist || [http://webdevchecklist.com/](http://webdevchecklist.com/)

</comment><comment><USER24> Besides the bad SQL tips most of it is okay. Sounds like the author has little experience with ORM's or SQL abstraction layers with parameterization like ADO.NET, SQLAlchemy, or JDBC.

Besides the SQL stuff mentioned elsewhere, Regex is rarely a safe whitelist. It's better to use specific escapes for HTML or URI or whatever. Most of XSS is finding bad input that isn't filtered. Hardly anyone is stupid enough to not filter input at all, but few filter it enough to prevent all XSS.

Also keeping port 22 closed is just silly. If you have secure credentials no amount of portscanning will hurt you. If you get tired of the logs just move the port and setup fail2ban. This point is controversial so whatever I guess.

<comment><AUTHOR> Thanks for the tips. Can you say which SQL tip is bad, someone has already picked up the Stored procedure comment -- really meant prepared statements.

Regarding regexp. You can do very precise regexp for many patterns. I agree some are harder, but I wouldn't say "rarely" in our experience.

The point about port 22 is that if you have it open, many people tend to use it more than they should. Effective automation should eliminate / greatly reduce the need for it.

If using AWS/cloud, then you can apply a security group to open when you need, but otherwise keep it closed at the network level at least. I agree it does seem to get people all hot an bothered.

<comment><USER24> A lot of Regex is a hint that you shouldn't be using regex. Regex is a bad parser and poor sanitizer.

I would wager that more than 50% of XSS vulnerabilities are due to bad regex when you should be using HTML or URI escape

</comment></comment></comment><comment><USER32> How about extending the same with examples for popular web frameworks like django RoR?

<comment><AUTHOR> I know node better and would be a bit light on other frameworks. Do you have suggestions?

<comment><USER32> Throw across your node work. I will try to replicate the same for RoR. :-)

<comment><AUTHOR> When I post the implementation notes for Node, feel free to speak up with the RoR speak for that item and I'll add it in.

Thank you.

<comment><USER33> I'd be happy to try and do a Python version of this. I'm most familiar with Pyramid, but Flask and Django would be a learning opportunity for me. Much of this advice I've already implemented in Pyramid.

</comment></comment></comment></comment></comment><comment><USER34> > Create immutable hosts instead of long-lived servers that you patch and > upgrade. (See Immutable Infrastructure Can Be More Secure).

An interesting idea, I've not come across before. Anyone know where I can find some case studies on this?

<comment><AUTHOR> I did a post on that here:

[https://simplesecurity.sensedeep.com/immutable- infrastructur...](https://simplesecurity.sensedeep.com/immutable- infrastructure-can-be-dramatically-more-secure-238f297eca49)

but the originator was: Chad Fowler

[http://chadfowler.com/2013/06/23/immutable- deployments.html](http://chadfowler.com/2013/06/23/immutable-deployments.html)

</comment></comment><comment><USER35> There's some good Android & iOS security checklists here - [https://codifiedsecurity.com/2017/04/24/mobile-app- security-...](https://codifiedsecurity.com/2017/04/24/mobile-app-security- testing-checklist-android/) & [https://codifiedsecurity.com/2017/04/19/mobile- app-security-...](https://codifiedsecurity.com/2017/04/19/mobile-app-security- testing-checklist-ios/)

</comment><comment><USER36> "Finally, have a plan"

I'd argue that you're more secure and your life is easier if the plan (threat model), or at least the planning, come first. The greater your understanding of your data, users, platform, and attackers, the more likely you are to make good (e.g. secure, economical) choices about infrastructure, design, implementation, testing, incident response, etc.

"Plans are nothing; planning is everything." \- Dwight D. Eisenhower

</comment><comment><USER37> Is it good to redirect to https when user hit API with http? I have heard somewhere doing so is bad

<comment><USER38> Nop.. it isn't good, secure endpoints for API's shouldn't be exposed in plain, an error should be raised when a developer/app tries to contact via HTTP rather than HTTPs.

<comment><USER8> Is 404 sufficient?

<comment><USER38> Depends on your choice, personally i would choose between 410 or 501 but whatever you choose, just don't allow an implicit redirect with any of the 301/302 codes.

</comment></comment></comment></comment><comment><USER38> General guidance mostly, nothing too deep, seems suited for C-level since there is no discussion on securing the infrastructure (as in hardware, not in software), deployment and way too heavy on looking at the world "from the clouds".

</comment><comment><USER39> Lots of random mostly unnecessary advice that will surely take a simple project and turn it into a big half-baked unmaintainable mess.

Sorry for the harsh words; but good advice needs to be both practical and cost-efficient.

<comment><AUTHOR> Could you highlight what you think are the important items in a web security checklist?

</comment></comment><comment><USER21> Forgot one:

       [ ] Don't rely on security-by-checklist.

</comment><comment><AUTHOR> Thanks everyone for some great comments and discussion. Really appreciate your time and feedback on the article.

I'll fold in the feedback and the ideas and go forward with it.

Thanks all

OP: Michael O'Brien

</comment><comment><USER40> Simple Web Developer Checklist:

#1 make sure the css stylesheets are loading

<comment><USER24> I like this better

</comment></comment><comment><USER41> I would add one more regarding DOS protection:

Sign the session tokens that you issue.

This way you don't need to do any I/O to verify these tokens at the router level.

<comment><AUTHOR> I'm not sure I fully understand what you are saying. Can you elaborate.

<comment><USER41> I came up with this technique when designing our platform ([https://qbix.com/platform](https://qbix.com/platform)) so I don't know if it's widely used.

Many apps include session id tokens in requests, to identify the logged-in user. The session id is usually a bearer token (like in a cookie) which identifies the session on the server.

To mitigate against DDOS attacks, as you said, all publicly available resources can be cached on CloudFlare. (Personally I look forward to content- addressable protocols like IPFS supplanting HTTP.)

However, the non-public resources are usually dynamic and should not be cached. These resources are typically for users who have logged in, or at least have a session.

So our design basically encourages this:

1) if you want to serve non cacheable resources, require that the request included a session id

2) the session id is generated on our server _and signed with an HMAC_ so the app can verify this signature _without_ doing any I/O.

This is because I/O is expensive and hard to parallelize, whereas statelessly checking whether a session token has been issued by our app is easy to implement, even at the external router level. Simply examine the packets coming in, decrypt, look at the request, and verify the HMAC on the session id. If it is wrong then the session id is bogus so we don't expend any more resources within the network on this request.

You can make sessions expensive to start. For example, a user might have to log in with a valid account to get a session.

The big question is, how can we ensure that users don't get too many accounts? To prevent sybil attacks. Any ideas?

</comment></comment></comment><comment><USER42> Isn't best practice when it comes to passwords to actually choose a good one, use a password safe, and _not_ rotate?

<comment><AUTHOR> Both. You want to choose a good password and then not let it get too stale. A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access.

Choose good passwords, long, special chars, preferably random and generated by a password generator / manager. And then change periodically. That period depends on your application.

We change our cloud passwords and keys every 90 days.

<comment><USER43> "A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access."

Any actual evidence for this? My counter-hypothesis is if your password lasts 6 months of attempted hacks it'll last >6 years (unless social engineering attempts succeed).

I ask because rotating goes against the current NIST password guidance. In fact, for your recommendation "Implement simple but adequate password rules that encourage users to have long, random passwords", I'd recommend pointing people in that direction.

<comment><AUTHOR> Sorry, I should be clearer (late here).

With time passing, the chance of you or anyone with access to the password being socially engineered, or some other human error, or a hack on your PC desktop systems, increases linearly with time. The password may last a decade of brute force cracking, but we humans .... continue to make mistakes far more frequently.

So rotating passwords protects against the accumulation of human mistakes and insider threats.

If you are using proper hashing, then your passwords should be safe even if the hashes are compromised.

Could you please point to the NIST recommendation you mention. I thought they said that you should NOT force customers to change passwords. But that is different to you rotating your own critical passwords at a time of your choosing and on your policy.

<comment><USER44> Rotating passwords will only help in a very specific situation: When the password has been leaked, but you have not yet been hacked.

If someone has already gained access to the system, changing passwords are not sufficient.

If no one has gained access to the system, rotating passwords does not protect you against social engineering.

<comment><AUTHOR> Nicely said.

The one mod I'd suggest is:

If someone has gained access to the passwords and has not used the password yet or was not interesting in directly using the password themselves, but rather, they on sold it. There is a window of opportunity that rotation helps.

For example: you may be on one of the password lists being sold in the dark web. The owner of the list isn't hacking you, but those purchasing the list will some time soon.

So more specifically, you could be compromised by malware on a PC holding the password and that password may be extracted, sold and may not be used against you for months. Rotation helps in this case which is more common than we care to admit.

</comment></comment></comment></comment></comment></comment><comment><USER45> How much of this is built into various frameworks such as Rails, Django, EmberJS (for frontend) etc?

<comment><AUTHOR> No much at all.

<comment><USER2> For RoR many of the app-level points are - CSRF, SQL escaping, bcrypt by default, etc. That's a big reason to use such a framework in the first place.

<comment><USER22> Yeah, what kind of shitty frameworks is this person using if the answer to this question is "not much at all?"

</comment></comment></comment></comment><comment><USER46> @aeronautic, there's a typo on your website front page : "acccount" with 3 c.

</comment><comment><USER47> Security is a process and not a product of some checklist.

</comment><comment><USER48> Apparenlty written by somebody who isn't responsible for the actual web development themselves, just upfixed web devs work for enterprise pen testing.

<comment><AUTHOR> Sorry, not true. Spent many years doing full stack web dev and security. Please offer some constructive criticism - gladly received.

<comment><USER49> You are the OP HN needs but not the one we deserve...

</comment></comment></comment><comment><USER24> Come on man, 4 submissions in 5 days all leading to your startup's website? And a profile created 5 days ago with zero comments on anything you didn't post?

You could at least try to make it look like you're doing more than promoting your startup.

<comment><AUTHOR> Been an avid HN reader for ages, but been seriously heads down doing the startup thing for about a year with zero time for blog or posting. Insane hours. Started surfacing a month ago so I can do more than just code and wanted to share a bit.

Not trying to hide the company, in fact pretty proud of it and the new things we're doing. But we are very early stage and still in beta.

I do want to add value through the posts and discussion like this regardless.

</comment></comment><comment><USER50> I do not like this list.

> [ ] Use minimal privilege for the database access user account. Don't use > the database root account.

This advice seems outdated. In general, every significant security breach will get the attacker root access. Playing games with database accounts gets you no security at all, while introducing lots of friction and headache.

<comment><USER20> Sorry, you don't throw away mitigation techniques because they aren't foolproof. This is still excellent advice. Stop using sa and root accounts for your apps.

<comment><USER51> I agree with Spydum. The reason I agree is - Layers of security are required. You should not use a root account for your web application. You should also use escaping, properly formed queries, and prepared statements. You use best practices in an orderly manner and you will be much safer than just picking one "silver bullet". Not every attack provides root access to the database or server. Why make it easier for folks? Least privilege is a viable tool in your bag.</comment></comment></comment>


Pittsburghese Expertise: Dropping "To Be" - <AUTHOR> http://theglassblock.com/2016/07/07/pittsburghese-expertise-dropping-to-be/ <comment><USER3> My wife talks this way all the time, and when we were first dating it really bothered me. Eventually I came across an explanation of the regional-ness of it on the internet somewhere, and I asked her if any of her family is from the Pittsburgh area. As far as she knows, they aren't, but they are from Columbus, OH, which is just down the highway a bit.

I heard that Pittsburgh-ians also tend to use "yinz" for the second-person plural, which I find much better than a plain "you," and much, much better than "You all" or "y'all". (Though I'm now told it is not as commonly used as I assumed it was)

Anyway, I love reading about the various ways american english has diverged, given time and distance.

<comment><USER4> It's "y'all", a contraction of "you all", not "ya'll". Which makes infinitely more sense than "yinz" which is apparently derived from "you ones" or something like that?

I also find that 'dropping of to be' sounds completely unnatural to me. It sounds like something I'd expect a non-native speaker to say.

My personal favorite English change is the cot-caught merger.

Of course, all of my preferences make sense because I grew up internationally or in the south - I wasn't caught up in the cot-caught merger and I picked up y'all because there has to be SOME second person plural!

<comment><USER5> > I picked up y'all because there has to be SOME second person plural!

Same here. Way more elegant solution than "you guys", and less jarring to most people than, say, "youse". The only better solution would be to bring back "thou" for the singular and make "you" plural, but alas, that's unlikely to happen (and I'd be the one using "thou" and "y'all" anyway).

Of course, there are the folks who treat "y'all" as a _singular_ second person pronoun and use "all y'all" for the plural; I've worked with quite a few of those folks.

<comment><USER6> I use y'all for the second person plural and all y'all to when referring to multiple groups. For example: Team A will go to the left, team B will go to the right and then all y'all will charge the center on my mark.

<comment><USER5> I dig it; it's like "persons" v. "people" v. "peoples".

</comment></comment></comment></comment></comment><comment><USER7> I said "<jira ticket> needs deployed" when answering a question the other day at work and the person had to explain why that sentence is not valid.

I grew up about an hour away from Pittsburgh and work/live in Pittsburgh now... what's funny is that Pittsburghese is more prominent just outside of the city.

<comment><USER8> It's perfectly valid. It's just a non-standard construction. ...for American English I'll add.

<comment><USER9> It's regional: [http://microsyntax.sites.yale.edu/needs- washed](http://microsyntax.sites.yale.edu/needs-washed)

</comment></comment></comment><comment><USER10> The article mentions that 'In some parts of England, you'd hear people use a phrase on the model of verbing: "The wine needs opening."'

Is 'needs verbing' really that uncommon? 'Needs fixing' seems like a very common expression that fits that pattern. I guess the article might be trying to say that in some areas of England 'needs verbing' is the default form but I'm still a bit confused by that sentence.

<comment><USER11> It really depends on the tense. I'm from Texas and "needs fixing" sounds completely normal (although it sounds even more natural as "needs fixin'"), while "needs fixed" is awkward as heck.

</comment></comment><comment><USER5> The idea of _needs verbed_ being nonstandard is entirely new to me, and I live on the opposite side of the country from Pittsburgh, as has most (all, AFAIK) of my family. It feels right for things in my day-to-day work, like "the server needs rebooted" or "the bug needs fixed", though for other things, like "the code needs compiling", the _needs verbing_ form feels more natural.

<comment><USER12> Interesting! Can you see any pattern distinguishing the verbs where the -ing complement form sounds more natural vs the -ed?

</comment></comment><comment><USER13> > _In fact, it's possible that you are just now learning, from this article, > that needs verbed isn't the way everybody says it._

I am from Columbus but moved to NYC awhile back. I am just realizing that at some point I switched from "needs washed" to "needs to be washed" and never even realized it.

</comment><comment><USER14> I'm from Western Pennsylvania - an hour North of Pittsburgh - and can confirm.

Interestingly, I've unconsciously learned that "to be" sounds proper, and have been code switching most of my life without even realizing it.

</comment><comment><USER15> It's just a case of re-using the past tense for the gerund instead of using the present participle tense.

Also, shouldn't the correct collective noun be Pittsburgher not Pittsburghese? The name Pitt and the noun Burgh are both Germanic not Romance.

<comment><USER16> The dialect is Pittsburghese, not the people. Pittsburgher or Yinzer is the singular demonym.

And the burgh in Pittsburgh is Scots, not Germanic. For twenty years, they even dropped the h from the end.

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

<comment><USER15> Scots is a North Germanic language with a smattering of West Germanic vocabulary; as opposed to English which is a North Germanic language with a large amount of West Germanic and French vocabulary). A fair number of scholars regard both English and Scots to belong to the West Germanic branch, but in my estimation the grammar of English and Scots is closer to languages like Nynorsk or older forms of Danish (which is where the Angles and Saxons came from). Vocabulary tends to be more flexible and adaptable, via loan words and the like, than grammar.

You're right; the -er suffix is a reference to a person or thing in Germanic languages, my mistake. It should be Pittsburghisch or probably more likely Pittsburghish.

Of course this is nothing more than my humble opinion; opinions like farts etc...

</comment></comment></comment><comment><USER17> I discovered this thanks to a chance encounter on Duolingo (which is based in Pittsburgh, coincidentally). This commenter is from my small hometown in western Pennsylvania, and I in fact knew her in real life: [https://www.duolingo.com/comment/236814$from_email=comment&c...](https://www.duolingo.com/comment/236814$from_email=comment&comment_id=11325709)

</comment><comment><USER8> So according to the article, Pittsburghers and Western Pennsylvanians contstuct it the way those in England do. Huh, we speak Queen's English n'at.

</comment><comment><USER18> To me (Central European/Czech), this sounds like Russians speaking English: IIRC, in Russian, the verb "to be" is mostly implied (resulting in sentences seemingly _without_ a verb), which they carry over when speaking other languages ("Hello, I here. My car needs fixed.").

</comment><comment><USER14> If anyone is interested in a humorous - yet frighteningly accurate - <USER2> of Pittsburgh and Philadelphia speech, watch the "Pawnsylvania" sketches from Kroll Show:

[https://www.youtube.com/watch?v=3qeY0mIn1K0](https://www.youtube.com/watch?v=3qeY0mIn1K0)

</comment><comment><USER19> It's not dropping "to be", it's using a different participle. It's kind of like substituting "vaccinated" for "vaccinating".

"To be or not to be" would still sound exactly the same

</comment><comment><USER20> I've been doing this lately. But only because I can't stand my phone's keyboard. Actually, if I'm not writing professionally or for public consumption, I do far more egregiously 'fun' things with my writing to make it more touch-screen friendly:

Convenience:

probably -> prolly

__ing -> __n

__ed -> __d

I'm -> I

and -> n

something -> summat

Purposeful misspellings:

your -> yoor

maybe -> mebes

work -> werk

word -> werd

programming -> porkgramn

morning -> mern

And randomly drop unneeded words.

"The car needs washd, prolly do next fri mebes if I not busy porkgramn summat fo werk."

<comment><USER21> "Maybe we can eventually make language a complete impediment to understanding." [0]

[http://www.gocomics.com/calvinandhobbes/2013/01/28](http://www.gocomics.com/calvinandhobbes/2013/01/28)

<comment><USER20> It's hard to really jump on that line of thought without more information. Plenty of misunderstanding occurs because people make unwarranted assumptions about what some words have been employed to mean on the basis of familiarity alone. I know a few people who seem to communicate entirely in terms of cultural signals, propaganda, platitudes, and slogans. This is the easiest stuff to understand, but it also doesn't offer anything novel.

If I'm going to say something mundane, I see no harm in asking someone to play a game to understand it. Even if you've failed to understand, there's no real consequence for it.

</comment></comment></comment><comment><USER22> Pittsburghers' heads need examined.

</comment><comment><USER23> As a side note, the OP's username "superchink" seems pretty offensive to Asians on Hacker News.

<comment><USER24> ...which is also his email, which is also the username of the only person who wrote a definition for that word at urbandictionary ([http://www.urbandictionary.com/define.php?term=superchink](http://www.urbandictionary.com/define.php?term=superchink)) ...yeah.

<comment><AUTHOR> Yeah. Actually, I didn't write that definition, as amusing as it may be. I don't consider my username to be suited for Urban Dictionary, since it doesn't qualify as slang.

<comment><USER24> Forgive us for not thinking your name was all about the vinasco super chink. [http://www.applog.com/webstore-products/vimasco- super](http://www.applog.com/webstore-products/vimasco-super)

<comment><AUTHOR> I wonder if people consider that product offensive as well…</comment></comment></comment></comment></comment>


A russian man is suing apple for "turning him gay" - <AUTHOR> https://futurism.com/the-byte/russian-apple-iphone-turning-gay-lawsuit <comment><USER2> The article mentions that in 2013 a "gay propaganda" law [0] was signed by Putin, I wonder if this lawsuit is simply trying to take advantage of the anti-LGBTQ movement that seems to be happening in Russia.

[0] [https://en.wikipedia.org/wiki/Russian_gay_propaganda_law](https://en.wikipedia.org/wiki/Russian_gay_propaganda_law) "for the Purpose of Protecting Children from Information Advocating for a Denial of Traditional Family Values"</comment>


Judge rules on taxi industry lawsuit: Compete with Uber or die - <AUTHOR> http://www.crainsnewyork.com/article/20150909/BLOGS04/150909863/judge-rules-on-taxi-industry-lawsuit-compete-with-uber-or-die <comment><USER5> In SF I always use Uber over taxis for the better experience of hailing and paying for a ride. But within the last year I notice every day how bad Uber drivers are severely affecting the city for the worse.

So many uber drivers don't know how to safely park to pick up or drop off passengers without blocking traffic. Drivers don't know the fastest or safest routes to get around with other drivers, busses, cyclists, pedestrians and construction.

I don't want to see Uber regulated to hell, but I would like to see features of taxis required for drivers like signs on top of the cars indicating cars for hire, and most importantly lots more training about road safety.

<comment> _-__--- There is potential for uber infrastructure to self-regulate - <USER2> giving bad ratings to bad drivers will see them reprimanded in some fashion (I imagine). I've had (mostly) good experiences here in Boston/Cambridge; any bad experiences I've had have been documented with 1 to 2 stars and a quick explanation as to why.

I admit that I have no idea how the reprimanding of drivers of the handling of bad customer reviews is performed by Uber. Hopefully it's done in an honest way.

<comment><USER6> This is just hearsay, but I was told there is basically a minimum rating and if they drop below it for any meaningful amount of time they are fired.

<comment><USER7> How can I report an Uber driver who is not my driver?

</comment></comment></comment></comment><comment><USER8> That's the problem with trying to value an asset that's granted by the government. Just because they have acted a certain way in the past doesn't guarantee that they will continue to act a certain way in the future. Spectrum auctions could be considered similarly. One day the government could decide to auction off tons more spectrum, devaluing the existing licenses. It'd suck that they did that, and that in hindsight you paid too much for what you got, but that's just the way it works.

<comment><USER9> It would suck for existing spectrum holders, but not for the spectrum consumers.

The same thing happens with any commodities, anyway. If I just bought a diamond mine and they discover a massive vein of new diamonds in an easily accessible place, that sucks just the same.

<comment><USER10> Ironically the diamond industry is controlled by a few large companies inflating the price by artificially restricting availability.

</comment></comment></comment><comment><USER11> Taking a libertarian perspective here, the problem isn't Uber. The problem is that the government tried to artificially limit the supply of cabs with medallions, leading to entrenchment, lack of competition and no urgency to innovate within the industry.

So innovation came from outside and it's blowing the whole thing up.

</comment><comment><USER12> It will be interesting to see if this pushes any traditional cab companies to become their own "mini Uber".

i.e. sell all their medallions, get rid of all their regulations and expense overhead, and just operate all their drivers like Uber operate theirs. At which point competing should be easy enough.

I think we're at a very interesting point in the Developed world - in the 80s, 90s and 00s everything about our society became more and more regulated and safety conscious (hotels, taxis, health care, education) meaning costs skyrocketed, and the cost of entry to compete in those markets became astronomical.

Now we're using technology to go back to way things used to be - <USER3> regulation, less rules, (arguably) less safety. Spend some time in the Developing world and you'll see their society still works like this - <USER4> will let you stay in their house for a few bucks a night (airbnb), people buy minivans then drive around picking people up for a fee (uber), etc. etc.

It's interesting we had to use technology to go back to the way things used to be in these areas.

I'm looking forward to seeing the uber/airbnb equivalent for education, healthcare, energy, etc.

<comment><USER13> > I'm looking forward to seeing the uber/airbnb equivalent for education, > healthcare, energy, etc.

The total disregard for laws and regulations? Exciting. Fingers crossed Uber burns up it VC money sooner than later.

It's pretty terrible when people on HN pine for the days of less developed countries (no worker protections, no labor/safety regulations).

<comment><USER12> > _It 's pretty terrible when people on HN pine for the days of less developed > countries (no worker protections, no labor/safety regulations)._

The Developed World can not continue with it's standard of living, it's simply not sustainable. Something has to give.

The way I see it, services like Uber and airbnb can slowly chip it down to something sustainable, or we can hold onto it until the bitter end when it all comes crashing down.

Also, just because a job is offered with no worker protections, no labor/safety regulations etc, it doesn't mean a person has to take it. People vote through their actions.

<comment><USER13> > The Developed World can not continue with it's standard of living, it's > simply not sustainable. Something has to give.

That's not true _at all_. How productive are self-driving cars going to be with no drivers? And electric powertrains? Very! Why would a government allow Uber to have a monopoly on that? They're government owned roads!

You can entirely continue to provide a high quality of life to citizens of a developed country using automation and software.

Shall we continue to socialize the losses and privatize the gains in society? Pardon me for being crass, but fuck that noise.

<comment><USER12> > _That 's not true _at all_._

Go and spend some time in the developing world, then you'll reevaluate that statement.

What you don't see/realize is that we've simply outsourced slavery. The reason your iPhone, etc. are so damn cheap is becuase there are slaves building it, who have a standard of living way, way, way lower than yours.

I'm saying it has to equalize globally, which means our has to come down.

I cried when I visited the silver mines in Bolivia - [http://theroadchoseme.com/potosi](http://theroadchoseme.com/potosi)

<comment><USER13> > What you don't see/realize is that we've simply outsourced slavery. The > reason your iPhone, etc. are so damn cheap is becuase there are slaves > building it, who have a standard of living way, way, way lower than yours.

Foxconn is replacing most of its workers with robots. _Most_ work can be replaced with software and/or robotics in the next 5-20 years.

> I'm saying it has to equalize globally, which means our has to come down.

Completely disagree. Perhaps on meat consumption, and petroleum use (both which need to decline across the entire world).

> I cried when I visited the silver mines in Bolivia

There are responsible ways for mining for the resources you need.

</comment></comment></comment></comment></comment></comment><comment><USER14> Hm, I'm both impressed and a little cockeyed at the ruling by regulators that e-hails are "pre-arranged travel" for the purpose of defining the service and noting its exemption from needing a medallion.

Oh I get it - that's clearly a distinction to hammer home for the benefit of Uber. As the article points out, one of the competitive advantages Uber has is the rapid pace of pickups in Manhattan - within two minutes. Quite a remarkable achievement in getting the efficiency of "pre-arranged travel" down to less than 120 seconds.

I wonder what the conversations around Melrose Credit Union were like when they decided to, metaphorically speaking, put all their eggs in one basket.

<comment><USER15> It's not about amount of time, it's order of operations.

Taxi: already on the street, driving around, I try to get flag one down by essentially luck. Pre-arranged: I contact you, tell you where I am, you specifically set out to pick me up.

Pre-arranged is exactly how traditional car services have always worked. The fact that improved technology means pre-arranged also can be fast is a good thing.

</comment></comment><comment><USER16> Where was this judge for the Aereo case.

</comment><comment><USER17> In Romania most taxi companies have their own app. This change started about 3 years ago.

<comment><USER16> How's Uber doing in Romania?

</comment></comment><comment><USER18> This is fascinating -- as revenues for municipally-backed/traditional taxi companies fall, we are starting to see municipalities raise fees on the taxi unions to make up the shortfall. Oftentimes these taxi unions wield striking as leverage in negotiations, a tactic which is rapidly losing effectiveness and is generally counter-productive.

So the judiciary doesn't care for legal challenges against Uber, municipalities are actively working against taxi unions, and consumers are flocking to Uber in droves -- what is a unionized taxi driver to do in this kind of political and economic climate?

<comment><USER19> > what is a unionized taxi driver to do in this kind of political and economic > climate?

Do the moral thing and step-down from their monopolies, and embrace competition.

Why do you care about immoral people? Those who benefit from monopolies are not above robbers who benefit from a temporary monopoly on violence to bilk their victims.

EDIT: response to ishw (since my posts are being delayed):

The drivers that took credit in order to benefit from an immoral monopoly subsidized by tax-payers had it coming. Public libraries are available and anyone can learn where this road leads by picking up Economics in One Lesson which is eminently readable and widely available.

This is like saying "this gang of robbers paid the government X dollars backed by credit for the right to rob, and we can't put those robbers in a position of defaulting on their now-worthless license to rob". Uhm, yes we can, because the "medallion" they bought is precisely the instrument that makes it illegal for everyone else to compete with them. In other words, a criminal is not exempt from their crime just because they purchased the instrument, that enabled them to commit the crime, with credit.

When you say "Taking the moral highroad is not an option here", therefore, that's just a misinformed reaction to a situation that, as you correctly noted, allows for no way out that isn't harmful to one or both parties. Which is why this sort of engagement (monopolistic or monopsonistic) is to be discouraged and why only voluntary contracts should be enforced by Law.

EDIT: response to mbreese:

Wow... your response is a complete non-sequitur to what I said.

<comment><USER18> The article mentions most medallions are backed by credit -- that would mean the drivers would be put in a position of defaulting on their now-worthless medallions. Such investments would destroy their financial prospects for the near future if not in the long term due to the exorbitant cost associated with holding medallions.

Taking the moral highroad is not an option here. It's easy to advocate the free market from afar, but not everybody is prepared to even begin participating in the free market due to being financially shackled.

I was going to suggest that Uber operate a program of financial assistance to taxi drivers looking to flee the credit-subsidized catastrophe bearing down on them in exchange for multi-year employment contracts, but the collective value of these medallions is estimated at _$10 Billion_. Yes, ten billion USD.

How would such a program work? Could it work?

<comment><USER20> The drivers don't generally personally own the medallions. The medallions are owned by companies who mortgage them to banks. The medallion collapse means these companies almost certainly have negative value, and if the owner isn't making enough money from it they'll just walk away. The bank will then have to legally recognize what is already obvious (that the loan on the medallion will not be paid as agreed, and the collateral is worthless). The bank may have to call in insurance and some bank customers may take some losses. $10 billion isn't going to break the bank insurance industry.

What about the drivers? They've already been fired, that's why the cabs are sitting idle. There's no need to help the financial speculators.

</comment></comment></comment></comment><comment><USER21> Sad thing is, it really shouldn't be that hard for them to compete with Uber. It's a customer service issue.

* Don't make me wait huge amounts of time, especially without telling me. * Any driver who whines about taking a damn credit card should be fired immediately. Ugh. * Start treating customers well. Uber is hit or miss with this.

Far too often I call for a cab and stand around waiting for 40 minutes, then get someone who drives like a maniac and is incredibly rude, and then when I say I need to pay be credit card they whine and cry and outright lie to try to get cash instead.

</comment><comment><USER22> As a New Yorker, I am very pleased with the decision. The reason why the taxis are not being used is not because of Uber but rather because the taxi prices are set too high. The way to fix the problem is for the NY City Taxi Commission to lower the taxi fares. With lower fares, more people will take taxis, especially now that there is the new "Arro" app that allows for e-hail of taxis.

Lower the prices, and more taxis will be in use. Simple economics!

</comment><comment><USER23> Could a maddalion holder accept Uber rides as well?

</comment><comment><USER24> So how much does it pay to be an Ueber driver anyway? Just curious.

PS: Über without the umlaut is spelled Ueber. [1]

[1] [https://en.wikipedia.org/wiki/%C3%9C](https://en.wikipedia.org/wiki/%C3%9C)

<comment><USER25> Company name, unfortunately, is "Uber". Not "Über".

<comment><USER26> Yeah, that's always been a real head-scratcher for me. I see the umlaut in maybe every third reference to the company, and yet they never used it in any official capacity!

Worst case of hypercorrection I've ever seen.

</comment></comment></comment><comment><USER23> Does Uber pay fees to the Taxi Limo Commission?

<comment><USER27> Yes. In NYC Uber is a licensed car service like Carmel and Dial7.</comment></comment>


Expect a Loud Noise from Your Cell Phone at 2:18 PM - <AUTHOR> https://lifehacker.com/expect-a-loud-noise-from-your-cell-phone-at-2-18-pm-1829489066 <comment><USER2> Note that this only applies to the US. We had a similar test in BC back in May: [https://www.cbc.ca/news/canada/british-columbia/emergency- al...](https://www.cbc.ca/news/canada/british-columbia/emergency-alert-system- testing-bc-1.4654903)

</comment><comment><USER3> My phone received a series of "presidential alerts" just before 5 pm as tornadoes swept into Canada's National Capital Region on 21 September. I remember thinking the alert title was a little odd for Canada, but I'm not sure how it's localized. It's a Moto G5+ US version, so maybe that text is baked in. Edit: I see that some Ontario users received "Presidential Alert" in a prior test. I'm in Québec.

</comment><comment><USER4> How long before it gets turned off in everyone's phones as well. It just requires one or two bogus alerts for people to start wanting to block these things (see amber alerts for unrelated geographical areas etc)

<comment><USER5> It's unblockable as far as I know.

<comment><USER6> If it starts being abused manufacturers will add a toggle for it.

</comment></comment></comment><comment><USER7> I didn't get anything.

</comment><comment><USER8> I'm not scared. Bring it on.

Edit (2:18): Got the alert right on schedule. Freaky.</comment>


Why Marriages Fail - <AUTHOR> http://www.shrinktalk.net/archives/why_marriages_fail_1.phtml <comment><USER2> Ok I might be downmodded to hell for this, but hey I can afford the karma and this needs to be said so here goes,

I believe this article shouldn't be on Hacker News. At what point does "interesting to hackers" become "interesting to some subset of people and has nothing to do with hacking per se"? Yes yes hackers get married/have relationships too so this is possibly of interest to them, but then everything in the world that concerns life is possibly interesting and should be posted on HN.At which point there is no difference between HN and say reddit. At least reddit has subreddits.

My heartfelt wish is that these junk articles don't make the front page of HN. So what's next on HN? raising children (hackers have kids too) , home decor (hackers have homes too), politics(hey, hackers vote), sex positions (hackers have sex too ( ;-)) and are possibly interested in "hacking"/evaluating positions) ...

<comment><USER3> The rules about what's on topic explicitly say that articles don't have to be about hacking. They just have to be interesting to the intellectually curious. An article on _any_ topic could be if it was sufficiently insightful. This one seems pretty insightful. Not overwhelmingly so, but it's certainly not a junk article.

<comment><USER2> pg said

" This one seems pretty insightful. Not overwhelmingly so, but it's certainly not a junk article."

fair enough. differing perceptions and all that. I think (note: _I_ think) it was a trashy article, not worth my time I spent in reading it (which is my working definition of "junk") and _I_ don't want to see such articles on the front page so I did my part by (a) flagging it (b) explaining my thought process.

It is upto the rest of the HN community to confirm or reject my perception. And I am completely fine with that. I can always start reading from teh second article from the top :-)

PS: I noticed that the article disappeared from the front page("Dead" ed) and then came back a few minutes later. How does that happen? Just curious.

<comment><USER4> Your comment brakes the rules, the article is within their bounds.

Of course it is not worth anyone's time to read your bitching about this article's relevance, especially considering someone or another posts your same urgent insight on every tenth article that reaches the front page. I really wish you all would stop.

<comment><USER2> "Your comment brakes the rules, the article is within their bounds."

I assume you meant "breaks". You are completely right. Here is the guideline I violated.

"Please don't submit comments complaining that a submission is inappropriate for the site. If you think something is spam or egregiously offtopic, you can flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did. "

While I am not sure, if this guideline is a good one, using a forum such as this implies acceptance of the rules. I was ignorant of this guideline, but the fact remains that I have violated this guideline twice. Once by mentioning the inappropriateness of a submission and then my mentioning I flagged it.

Apologies to everyone. I'll be more careful in the future.

<comment><USER5> Would be kind of nice if the "flag" link went to "approved" after a moderator deemed it worthy. That way we wouldn't keep flagging it after we know the mods had already reviewed it for worthiness.

</comment></comment></comment></comment></comment></comment><comment><USER6> I don't have any deep or insightful comments to make on this article.

I just want to say I read it a month or so ago and was really impressed with it at the time. It's a really intelligent, well written list of reasons why relationship don't work out, and what it takes to make them succeed. It also gives some good insights into couple's counseling.

I hope it does okay on this site, and doesn't get ignored because it's not the usual fare here.

<comment><USER7> I actually think people on HN _will_ enjoy it, because it takes a rather emotional topic and breaks it down into what are the primary reasons he has seen for marriages failing in what, I assume is, his professional opinion.

I think people like me enjoy hard problems, finding out the root cause, and determining a solution. From that perspective, I thoroughly enjoyed this article as it presented some salient causes for a fairly difficult problem (keeping a marriage/relationship going).

It wasn't full of platitude and suggestions to "date once a week" etc - it was a solid breakdown of causes. Coupled with the recent discussion of the bachelor paradox, I really enjoyed the diversion.

</comment></comment><comment><USER8> Because the author of the submitted article seems to fall for a common error in statistical reasoning about the divorce rate in the United States, I'll post a link to a detailed discussion of that fallacy here.

<http://www.nytimes.com/2005/04/19/health/19divo.html>

</comment><comment><USER9> My maternal grandparents are in their 90s, have been married for 68 years, and are still going strong. (Okay, so I'm proud of them.) They relate a story of how they were called up once by a guy doing some research on _why couples stay together._

My grandparents rightly noted that while people are constantly doing studies on "why marriages fail", hardly anyone ever looks at the long-lasting marriages and asks why they _work_.

They told the researcher that theirs worked mainly because they never considered divorce an option. That's a reflection of their culture and morals, but also their desire. They expected to stay together, and they did what it took to stay together. I've only been married for 4 years, but I certainly want that for my own marriage too. (And I blow raspberries to statistics -- I was married when I was 23 and my wife 19. :-)

The article had several good points. But I wonder at this: "If people are miserable together, the shrink's position is to help them separate and live happier lives apart." Why can't the shrink help them see ways to be un- miserable together?

<comment><USER8> Sometimes an example can go a long way. I grew up in another state than the one my maternal grandparents lived in, but I did travel to join their sixtieth wedding anniversary celebration with most of my thirty-four cousins. That's surely helped me and my wife (whose parents have also been married six decades now) stay together for more than twenty-five years. She and I grew up in different countries, speaking different native languages and eating different foods, and have changed radically from our former selves over the years, but we are still each other's best friends.

</comment></comment><comment><USER10> >3) There is far too much emphasis on 'weddings' as opposed to 'marriages.'

This is a nice article, but when reading this point I wanted to share a different perspective.

A colleague of mine got married recently. The marriage lasted 3 days with unnumerable rituals. It culminated with him and his bride having to sit beside a fire from 4 in the afternoon to about 3 at night while the pundit recited slokas.

It was, as you can imagine, an exhausting experience. I don't think he's in any hurry to get divorced and married again!

<comment><USER10> >6) People settle for less than what they want.

Sorry - quick follow up. Many Indians get an "arranged marriage" where you don't really have great expectations. However, many of them go on to form happy, stable, marriages. People want to be happy and husbands and wives tend to grow into each other and find ways to be happy.

<comment><USER11> I think this is one of the major reasons that Americans have so many divorces. They marry for the "feelings", and as soon as those change they want out. The Indians marry for more than that - financial support, children, family name, cultural pressure, etc. The end result is that they are interested in making it happen, and are willing to work for that, whereas Americans think that the fact that it might require effort proves that they are "incompatible".

Imagine if someone tried to run a startup the way most Americans try to manage their marriages; they wouldn't last a week before they gave up - the "feeling" probably wouldn't be there, and there would be something else they'd rather do.

If both you and your spouse want the marriage to work, it can work, whether you "feel" for each other or not. The problem is really when they don't want it to work, and need an excuse.

<comment><USER12> Divorce means wasted years, loneliness, traumatized children, and yes, even in America, social stigma. Nobody wants to be on the dating market as a divorcee, because everybody looks at you and wonders what went wrong and what kind of baggage you have. As a never-married guy, I can say that despite my best intentions I view divorcees with suspicion. If you think people take it lightly, then you're wrong.

In reality, marriage in America illustrates the blade of freedom cutting in both ways. I would like to point out that traditional marriages, Indian or otherwise, carry very strong expectations about the partners' roles and the structure of their home life. If one partner fulfills his or her economic and social role, the other partner's expectations are fulfilled. In American marriages, there are fewer culturally determined and socially enforced rules on who brings what to a marriage. That creates a disorienting number of possibilities. It is harder for two people to live together when every choice made by one closes off possibilities for the other. In a marriage where tradition has already closed off all possibilities except one (if indeed any other possibilities are imaginable) there is less disappointment and less reason to resent one's spouse.

Obviously, it would be nice to have a modern marriage contract, a new set of obligations such that if each spouse fulfills his obligations, then both spouses share a mutually beneficial marriage that supports, rather than hinders, their goals in life. That is what traditional marriages offer, but they are too concrete about household roles and duties. Modern attempts to define marriage are rather abstract and dependent on interpretation; probably that's what bothers you when you say that Americans depend on a "feeling" being there. Modern definitions of marriage are very wishy-washy because there's no concrete division of duties to found them on.

</comment></comment></comment></comment><comment><USER13> because its so easy to get a divorce and there is a huge monetary incentive for women to walk away at the first sign of trouble.

<comment><USER14> Disclaimer: This is personal opinion

If you are marrying someone who would actually weigh the option of dumping you for monetary gain, you're doing it wrong. This is probably incredibly hard to do without _some_ luck, but you should marry someone who would never consider monetary _gain_ in a decision about the relationship. In more concrete terms, someone who, even at the point where your relationship is ending (if it comes to that), is fair-minded enough, has enough self-respect and values your time together enough to give you a fair share.

Many people try to counter this by saying "People (and by this they mean, their core principles) change" (in other words people abandon their principles). I believe there are people who would never abandon their core principles. Marry one of them.

<comment><USER15> Even if financial and legal incencives don't matter for you, they do matter for many people. If you start rewarding women with money for dumping their husbands (as vaksel implied US law does), many families that were close to the brink will disintegrate and many okay families will move that much closer to the brink. We don't live in a world composed of ideal men and women - that's why we need laws and money in the first place.

I find your comment similar in spirit to a common pattern of defending the C++ language against criticism: the idea that, if C++ shortcomings worry you, then the root of your problem is bad design and muddled thinking. It's true, but the language could work to fix the problem instead of making it worse. So too with divorce laws.

<comment><USER14> I have no opinion on the quality of US divorce law. I am saying it should be irrelevant to you if you choose your partner wisely - US divorce law cannot and does not supercede an amicable separation agreement between two people. We don't live in a world of ideal people but I have found that there are enough principled people in the world that with some luck and significant effort you should be able to find one who is principled.

In the vein of your example, I am saying don't complain about Java's (an unprincipled spouse) performance on Windows (an imperfect legal system), use python instead.

<comment><USER15> In my example the unprincipled spouse corresponded to _muddled thinking_ and C++ corresponded to the laws. So your advice of "use Python" translates to "move to another country", quite sensible advice for bachelors in countries where laws favor women.

And your own example doesn't parse for me: Java should be faster than Python in most cases.

(Yeah, I'm all for bringing the thread back on topic as a programming discussion.)

:-)

</comment></comment></comment></comment></comment><comment><USER16> PlinkPlonk says "My heartfelt wish is that these junk articles don't make the front page of HN. So what's next on HN? raising children? "

This is not a junk article. And yes, articles about raising kids were published here and I do not remember any one questioning if it was hacker news. ( <http://www.paulgraham.com/lies.html>). This is intellectually interesting and useful. If hacker news wants to be a community where human beings take part rather than some large drone feeding me with 'programming' news this article stays.

For that matter this article has more insight than many articles about 'ruby' on this site, I cringe when articles get in just because it had the word 'programming' in it. There are many programming articles that were a pure waste of time, did not embody what hackers are about. Hacker is an attitude and not just programming. Hacker is the quality in programming and not just the programming. Just dealing with programming is not an automatic pass to be hacker news (some sites are actually banned!), and by the same account just that something does not contain the word programming does not mean its not hacker news.

Guess what, we are programmers and proud ones. But I personally value my relationships more than my programming abilities (And my girl friend will never say to me: if you love me stop programming!, she loves me too. Its a nice arrangement. :P).

The fear or the question "If we let this article where will this stop?" reminds me of people who ask: If we let gay people marry, then where will this stop ? If you felt pity for such people who did not have a good appreciation for dynamic nature of all things nature, then think a bit more. "Where will this stop?"is not reason enough and is not an automatic pass to raise the objection "this is not hacker news"

There is room here for more insight. Further I said this some 2 years back on this site: I will say it again. Dont have a very narrow view of what you are. Don't define yourself and put your self in such a tiny box "I am a hacker because I think ruby is not a gem". I feel kinship to the person who designs good buildings and the one who designs a good meal which is also cheap. In such a meal I see a succinct program which also is very efficient in terms of memory.

There are insights to be obtained from all of them for programming itself. Further only if you expand your world view and talk about problems people face on a daily basis can you obtain insights into peoples problems that need solutions. And guess what you will suddenly find a new business instead of hacking together your one millionth web based todolist with email and sms feature.

EDIT: adding link to the earlier comment that I refer to <http://news.ycombinator.com/item?id=31799> which was made looong back.

<comment><USER2> " If hacker news wants to be a community where human beings take part rather than some large drone feeding me with 'programming' " news this article stays."

false dichotomy alert! A false dichotomy is a rhetorical device to position your favored option against a rhetorically maligned strawman opposite option.

Given that no one actually wanted "drones feeding me with "programming, , your statement is not very persuasive.

The _actual_ options are about _preferences for_ "insightful" articles about marriages, children etc vs "insightful" articles _centered around_ programming, technology, startups etc. On _this_ choice, people can (and do) differ, and that is perfectly fine.

"If you felt pity for such people who did not have a good appreciation for dynamic nature of all things nature, then think a bit more"

more putting words is my mouth. Where did _I_ (or anyone else) say I felt "pity"? You are imagining the unexpressed motivations of others and reacting to your imagination. In other words, You seem to be setting up straw men and knocking them down.

More strawmen

" Just dealing with programming is not an automatic pass to be hacker news " - Nobody claimed this.

" hacking together your one millionth web based todolist with email and sms feature." - nobody claimed this as a good idea either, especially against "you will suddenly find a new business" (false dichotomy again).

Nutshell : lots of rhetorical smoke, very little fire.

You make one good point ("Hacker is the quality in programming and not just the programming.") amongst all this false angst and strawman burning. And it is a very good one. It makes your post valuable.

I thought the article inappropriate, (still do), flagged it, explained why, and was overridden. That is all right. Getting into a mud throwing contest about motivations is not. So I'll stop. I am done with this thread.

</comment></comment><comment><USER17> He lost me when he linked to an article by Satoshi Kanazawa.

</comment><comment><USER18> I wrote this article and, quite honestly, have no idea how it ended up here. I certainly can't vouche for its place in this particular forum but wanted to say thank you to anyone who read it and commented, whether that be positive or negative. If anyone has suggestions for topics that somehow cut across the hacker/psychology interface, please let me know and I will write about those.

Best, Rob Dobrenski, Ph.D. ShrinkTalk.Net

</comment><comment><USER19> "Fail" is the wrong term. The sincere love between a "male" and a "female" human being (if I name them "man" and "woman", maybe you won't understand, would you?) isn't considered a value anymore...

If it were some business, we would care much much more, and this says it all about current priorities in "modern" society.

Future generations will write about current society: "They destroyed themselves by starting to hate, inside of the most atomic value in human society: The Family..."

</comment><comment><USER20> Legalize... <http://www.carmanfox.com/meet_vancouver_escorts.htm></comment>


Engaging customers online is actually easier than I thought - <AUTHOR> https://inq.social <comment><AUTHOR> Everybody hates when a popup appears begging to complete a survey. There is a better service that helps to ask one question at the time and then adjust your website to each customer. It is Free as well.</comment>


The Inner Guts of Bitbucket [video] - <AUTHOR> http://blog.bitbucket.org/2014/08/11/the-inner-guts-of-bitbucket/

<comment><USER2> Given that Bitbucket has to spend time on fixing performance problems caused by still using basic auth for their API (rather than allowing multiple, revokable API tokens), I don't have too much hope that they'll get around to fixing the most popular, important issues on their own tracker, e.g. mostly useless (and poorly documented) webhooks: [https://bitbucket.org/site/master/issue/7775/post-service- do...](https://bitbucket.org/site/master/issue/7775/post-service-does-not- provide-useful)

While Bitbucket is popular as a cheap (in every sense) clone of GitHub, in many cases you get what you pay for. Paying for GitHub is worth it in terms of less frustration compared to using Bitbucket in general (plus their webhook/integration support and UI is exemplary), but are other services, such as GitLab, any better?

<comment><USER3> I wouldn't move to GitHub even if it was to provide private repositories for free (which it doesn't). BitBucket just works flawlessly for my needs.

<comment><USER4> Aside: anyone with a .edu, .ac.uk or other education-ending email address can get 5 private repos for free.

Is there anything specifically about GitHub which puts you off, or is it just that BitBucket works so you don't want to change?

<comment><USER5> > Is there anything specifically about GitHub which puts you off, or is it > just that BitBucket works so you don't want to change?

Github has a much worse record vs. Egor Homakov than Bitbucket :)

Also, Github is Git-only, while Bitbucket supports both Git and Mercurial. I use both, but prefer Mercurial myself, despite it being less popular.

<comment><USER4> GitHub definitely isn't git-only. It supports SVN too, and can import from SVN, Hg and TFS

</comment></comment></comment></comment></comment><comment><USER6> Anyone know why they use two layers of pgbouncer? The speaker mentions this briefly in the Q&A but doesn't go into detail.

<comment><USER7> Layer one is for connection pooling on the application servers, layer two (on the database server) is mostly for control purposes.</comment></comment>